FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Directory

 
 
LinkBack Thread Tools
 
Old 05-07-2012, 05:11 AM
David Baird
 
Default Problems with nsaccountlock attribute

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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 05-07-2012, 01:09 PM
Rich Megginson
 
Default Problems with nsaccountlock attribute

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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 

Thread Tools




All times are GMT. The time now is 06:29 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org