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-08-2012, 12:53 AM
Arpit Tolani
 
Default Problems with nsaccountlock attribute

Hie

On Mon, May 7, 2012 at 10:41 AM, David Baird <dbaird@waikato.ac.nz> 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.




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?



May be https://fedorahosted.org/389/ticket/300
I recently faced this issue with disabledroles only & upgrading to latest version resolved the issue. Looks like this issue persists with disabled roles as well along with password policies.













--

389 users mailing list

389-users@lists.fedoraproject.org

https://admin.fedoraproject.org/mailman/listinfo/389-users
Regards
Arpit Tolani

--
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 07:26 AM.

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