Strange problem with 389 console

[Brian Bresina]

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.


-- 


"I am not completely worthless, I can always serve as a bad example."

[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.

[David Baird]

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(a)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