[389-users] Strange problem with 389 console

[Rich Megginson]

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.