On 05/06/2012 11:11 PM, David Baird wrote:
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.
If something altered the virtual attribute scheme, there would _not_ be
any indication in the users' entries with modifyTimestamp.
modifyTimestamp is only updated when the entry is a direct target of an
ldapmodify operation, or an indirect target via a non-virtual attribute
plugin, such as memberof or referential integrity.
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.
IPA can, but not plain 389.
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?
Just try looking for ADD/MOD/DEL in your access log, for starters.
Thanks in advance,
David.
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
