[389-users] Deactivating accounts

[Arpit Tolani]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20120718/57986a62/attachment.html>