Account activation and inactivation no longer seems to be working with my 389 console system. Unfortunately, there are several people with admin rights to the ldap servers so I am unsure if someone might have messed the server up. Currently, I can select inactivate for an account and I will get back a box showing no errors. If I look at the account however, only the nsmangeddisalble role and nsdisabled roles have been set. The nsaccountlock is never added to the account. Also, if you right click on the account the activate is always greyed out. I can manually add the nsaccountlock attribute and set it to true. If I do this, the activate will appear when I right click on the account but when I activate it only the roles will be removed, the nsaccountlock attribute is still in place. Also I have noticed that there are two entries for some of the attributes if I go to add them to an account, nsaccount lock is one of them. Sadly, this is running in a production system, so I really need to have a way for other SAs to lock out accounts for users that are no longer on the system with having them added attributes for each account. Anyone know what might be going on here? Thanks.
On 02/06/2012 08:49 AM, Brian Bresina wrote:
Account activation and inactivation no longer seems to be working with my 389 console system. Unfortunately, there are several people with admin rights to the ldap servers so I am unsure if someone might have messed the server up. Currently, I can select inactivate for an account and I will get back a box showing no errors. If I look at the account however, only the nsmangeddisalble role and nsdisabled roles have been set. The nsaccountlock is never added to the account. Also, if you right click on the account the activate is always greyed out. I can manually add the nsaccountlock attribute and set it to true. If I do this, the activate will appear when I right click on the account but when I activate it only the roles will be removed, the nsaccountlock attribute is still in place. Also I have noticed that there are two entries for some of the attributes if I go to add them to an account, nsaccount lock is one of them. Sadly, this is running in a production system, so I really need to have a way for other SAs to lock out accounts for users that are no longer on the system with having them added attributes for each account. Anyone know what might be going on here? Thanks.
The way the console does account lockout (and the command line scripts such as ns-inactivate.pl) is to use Roles and Class of Service to provide the nsAccountLock attribute as a virtual attribute based on membership in the "disabled" role. If you have manually set the nsAccountLock attribute at some point it has turned into a "real" attribute and is no longer virtual, no longer able to be managed by the console/script virtual attribute mechanism.
On 7/02/2012 4:52 a.m., Rich Megginson wrote:
On 02/06/2012 08:49 AM, Brian Bresina wrote:
Account activation and inactivation no longer seems to be working with my 389 console system. Unfortunately, there are several people with admin rights to the ldap servers so I am unsure if someone might have messed the server up. Currently, I can select inactivate for an account and I will get back a box showing no errors. If I look at the account however, only the nsmangeddisalble role and nsdisabled roles have been set. The nsaccountlock is never added to the account. Also, if you right click on the account the activate is always greyed out. I can manually add the nsaccountlock attribute and set it to true. If I do this, the activate will appear when I right click on the account but when I activate it only the roles will be removed, the nsaccountlock attribute is still in place. Also I have noticed that there are two entries for some of the attributes if I go to add them to an account, nsaccount lock is one of them. Sadly, this is running in a production system, so I really need to have a way for other SAs to lock out accounts for users that are no longer on the system with having them added attributes for each account. Anyone know what might be going on here? Thanks.
The way the console does account lockout (and the command line scripts such as ns-inactivate.pl) is to use Roles and Class of Service to provide the nsAccountLock attribute as a virtual attribute based on membership in the "disabled" role. If you have manually set the nsAccountLock attribute at some point it has turned into a "real" attribute and is no longer virtual, no longer able to be managed by the console/script virtual attribute mechanism. -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
I suspect I have fallen victim to this situation.
If this is, in fact, what has occurred, is there any way to determine this?
And more importantly, is there a way to fix it?
Thanks, David
389-users@lists.fedoraproject.org