Hi All,
Our instance of 389 (version 1.2.8.1 running on Centos 5.7) has recently begun
exhibiting problems with account locking.
Locking (or inactivating if you prefer) an account, either by using the 389
console, or the ns-inactivate.pl script works initially and the user object
displays the correct attributes...
nsrole "cn=nsdisabledrole,dc=..." "cn=nsmanageddisabledrole,dc=..."
nsroledn "cn=nsManagedDisabledRole,dc=..."
nsaccountlock "true"
and an ldapsearch confirms the existence of the nsaccountlock attribute.
However, after some period of time has elapsed (haven't quite narrowed down
exactly when it occurs) the nsaccountlock attribute is no longer present,
meaning the account is no longer locked.
About two weeks ago, I removed all entries from nsManagedDisabledRole and
restarted dirsrv, then inactivated approximately 16 accounts. As of Thursday
last week they were all still as expected with the nsaccountlock attribute
present. As of this morning (Monday) none of the accounts have the
nsaccountlock attribute present. The modifytimestamp for the user object
remains unchanged, which would indicate an issue with the management of the
virtual nsaccountlock attribute.
Does anyone have any idea what might be causing this? Replication is not an
issue as we only have a single server. There is an AD sync agreement active, but
it's my understanding that 389 cannot sync account locking with Active Directory.
Is the management of the virtual attribute nsaccountlock logged at all? Is
there a specific log level (either in access log or error log) that will give a
clue as to what is happening?
Thanks in advance,
David.
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
