Hello
> We have several users who no longer need access, but may in the future,
> so we have set them to be Inactive in their profile. However, we noticed
> that these accounts have re-activated themselves and those users could log
> back in if they wanted to. How do we make accounts that we specifically
> make inactive by pressing the Inactivate button stay that way?
>
> We are using the following 389 versions on CentOS 5.7 64-bit:
>
> 389-ds-base-1.2.9.9-1.el5
> 389-admin-1.1.29-1.el5
> 389-ds-console-1.2.6-1.el5
> 389-adminutil-1.1.15-1.el5
> 389-admin-console-1.1.8-1.el5
> 389-ds-console-doc-1.2.6-1.el5
> 389-ds-base-libs-1.2.9.9-1.el5
> 389-dsgw-1.1.9-1.el5
> 389-console-1.1.7-3.el5
> 389-admin-console-doc-1.1.8-1.el5
> 389-ds-1.2.1-1.el5
>
> Thanks for any help!
> Harry
>
>
Add below attribute with same value in user's ldap entry.
nsAccountLock: true
# cat entry.ldif
dn: uid=tuser, ou=people,dc=example,dc=com
changetype: modify
add: nsaccountlock
nsaccountlock: true
# ldapmodify -x -a -D "cn=Directory manager" -w password -f entry.ldif
I don't think so. The original poster mentioned the Inactivate button. I
assume this means using the Console feature to inactivate users. Users
inactivated in this way should not just magically become re-activated.
This is a problem.
Could be related to
https://fedorahosted.org/389/ticket/300
I got a scenerio, where cos were getting corrupted & Disbaled Roles stopped
working over a
period of time. Upgrading to 8.2.9 fixed the issue.
http://rhn.redhat.com/errata/RHBA-2012-0510.html
* Prior to this update, the cos cache could become corrupted under load. As
a
consequence, passwd policies defined by the subtree could fail to work. This
update modifies the update so that the cos cache no longer becomes
corrupted and
passwd policies now persist. (BZ#787743)
The problem with using plain ldapmodify is that it doesn't work
with the
mechanism used by the Console and the ns-inactivate.pl script, which use
a Roles/CoS scheme to put inactive users into a specific Role and then use
CoS to add nsAccountLock: TRUE to all members of that Role.
The first step is to make sure that when you do a search of the supposedly
inactive user's entry like this:
ldapsearch -xLLL .... uid=inactiveuser \* nsAccountLock
you see nsAccountLock: TRUE
and then at some point in the future you see nsAccountLock: FALSE or just
don't see it at all.
When you say "log back in" - just after inactivating the user in the
Console, did you verify that the user could not log in? And then did you
at some point in the future see that the user could log in again? When you
say "log back in" - do you mean the operating system login?
Regards
Arpit Tolani