FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Directory

 
 
LinkBack Thread Tools
 
Old 07-17-2012, 04:40 PM
 
Default Deactivating accounts

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--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 07-17-2012, 05:13 PM
Arpit Tolani
 
Default Deactivating accounts

Hello


On Tue, Jul 17, 2012 at 10:10 PM, <harry.devine@faa.gov> wrote:



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


Regards
Arpit Tolani




--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 07-17-2012, 07:38 PM
Rich Megginson
 
Default Deactivating accounts

On 07/17/2012 11:13 AM, Arpit Tolani wrote:
Hello





On Tue, Jul 17, 2012 at 10:10 PM, <harry.devine@faa.gov>
wrote:




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.



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












--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users





--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 07-18-2012, 01:58 PM
Arpit Tolani
 
Default Deactivating accounts

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


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 

Thread Tools




All times are GMT. The time now is 10:45 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org