Hi,
I am using openldap-2.4.19-4 on fedora 12 machine. Does anybody know how to enable/disable a user account in openLDAP? I know ppolicy overlay but I don't require this password based locking.
Thanks in advance.
Am 21.11.2011 14:25, schrieb Jayavant Patil:
Hi,
I am using openldap-2.4.19-4 on fedora 12 machine. Does anybody know how to enable/disable a user account in openLDAP? I know ppolicy overlay but I don't require this password based locking.
Thanks in advance.
Hi,
we lock UNIX/Samba/Kerberos accounts in our system by "invalidating" the userPassword (i.E. putting some random string before the '{HASH}' part), settings the loginShell to '/bin/false' and putting the 'D' flag in sambaAcctFlags.
Scrambling userPassword will prevent logins based on simple bind, changing the loginShell prevents PublicKey logins and 'D' in sambaAcctFlags disables logins with Samba and Heimdal Kerberos.
Regards, Christian Manal
Christian Manal wrote:
Am 21.11.2011 14:25, schrieb Jayavant Patil:
Hi,
I am using openldap-2.4.19-4 on fedora 12 machine. Does anybody know how to enable/disable a user account in openLDAP? I know ppolicy overlay but I don't require this password based locking.
we lock UNIX/Samba/Kerberos accounts in our system by "invalidating" the userPassword (i.E. putting some random string before the '{HASH}' part), settings the loginShell to '/bin/false' and putting the 'D' flag in sambaAcctFlags.
With this approach you cannot re-enable an account without going through a passwort reset process. This might be ok in your deployment but it's not what temporay disabling a user is about.
I usually do this with ACLs for userPassword attribute.
Ciao, Michael.
Am 21.11.2011 15:59, schrieb Michael Ströder:
Christian Manal wrote:
Am 21.11.2011 14:25, schrieb Jayavant Patil:
Hi,
I am using openldap-2.4.19-4 on fedora 12 machine. Does anybody know how to enable/disable a user account in openLDAP? I know ppolicy overlay but I don't require this password based locking.
we lock UNIX/Samba/Kerberos accounts in our system by "invalidating" the userPassword (i.E. putting some random string before the '{HASH}' part), settings the loginShell to '/bin/false' and putting the 'D' flag in sambaAcctFlags.
With this approach you cannot re-enable an account without going through a passwort reset process.
Yes you can. For example, I change userPassword for a user from
userPassword: {SSHA}srR7zMWHgzmz6t68TodubAzNfexsL6em
to
userPassword: foobar{SSHA}srR7zMWHgzmz6t68TodubAzNfexsL6em
The password will now be interpreted as clear text. The user would have to know the hash for his password and the random 'foobar' part, to log in. To re-enable the password, I simply remove everything before '{SSHA}'.
Regards, Christian Manal
Christian Manal wrote:
Am 21.11.2011 15:59, schrieb Michael Ströder:
Christian Manal wrote:
Am 21.11.2011 14:25, schrieb Jayavant Patil:
Hi,
I am using openldap-2.4.19-4 on fedora 12 machine. Does anybody know how to enable/disable a user account in openLDAP? I know ppolicy overlay but I don't require this password based locking.
we lock UNIX/Samba/Kerberos accounts in our system by "invalidating" the userPassword (i.E. putting some random string before the '{HASH}' part),
With this approach you cannot re-enable an account without going through a passwort reset process.
Yes you can. For example, I change userPassword for a user from
userPassword: {SSHA}srR7zMWHgzmz6t68TodubAzNfexsL6em
to
userPassword: foobar{SSHA}srR7zMWHgzmz6t68TodubAzNfexsL6em
The password will now be interpreted as clear text. The user would have to know the hash for his password and the random 'foobar' part, to log in. To re-enable the password, I simply remove everything before '{SSHA}'.
No doubt: With IT everything is possible - everything...but if it makes sense is another question.
While this might work for you with custom code having ACLs for userPassword is the much cleaner approach without having to mess with password values and without having to any write custom code:
In this example organizationalStatus=0 means active:
access to attrs=userPassword filter=(&(objectClass=inetOrgPerson)(!(organizationalStatus=0))) by group="cn=Admins,ou=Groups,ou=example" =wx by group="cn=Replicas,ou=Groups,ou=example" read by * none
access to attrs=userPassword filter=(&(objectClass=inetOrgPerson)(organizationalStatus=0)) by group="cn=Admins,ou=Groups,ou=example" =swx by group="cn=Replicas,ou=Groups,ou=example" read by self =wx by * =x
Ciao, Michael.
Am 21.11.2011 18:21, schrieb Michael Ströder:
Christian Manal wrote:
Am 21.11.2011 15:59, schrieb Michael Ströder:
Christian Manal wrote:
Am 21.11.2011 14:25, schrieb Jayavant Patil:
Hi,
I am using openldap-2.4.19-4 on fedora 12 machine. Does anybody know how to enable/disable a user account in openLDAP? I know ppolicy overlay but I don't require this password based locking.
we lock UNIX/Samba/Kerberos accounts in our system by "invalidating" the userPassword (i.E. putting some random string before the '{HASH}' part),
With this approach you cannot re-enable an account without going through a passwort reset process.
Yes you can. For example, I change userPassword for a user from
userPassword: {SSHA}srR7zMWHgzmz6t68TodubAzNfexsL6em
to
userPassword: foobar{SSHA}srR7zMWHgzmz6t68TodubAzNfexsL6em
The password will now be interpreted as clear text. The user would have to know the hash for his password and the random 'foobar' part, to log in. To re-enable the password, I simply remove everything before '{SSHA}'.
No doubt: With IT everything is possible - everything...but if it makes sense is another question.
It gets the job done. I never said it was clean :P
While this might work for you with custom code having ACLs for userPassword is the much cleaner approach without having to mess with password values and without having to any write custom code:
True, your way is more optimal and I may actually "steal" it.
As for custom code, I already need that to change the other attributes I mentioned, plus some from a homebrew schema. So, at least for my environment, it doesn't really matter.
Regards, Christian Manal
Am 21.11.2011 18:52, schrieb Michael Ströder:
Christian Manal wrote:
As for custom code, I already need that to change the other attributes I mentioned, plus some from a homebrew schema. So, at least for my environment, it doesn't really matter.
You can make the other attributes invisible by ACL too...
Yeah, I could restrict access to the appropriate Samba and Kerberos attributes. But if I "hide" loginShell, users will just get a default shell and therefore still be able to login via ssh public key. So I either set an invalid shell or change permissions for the keyfiles in their home directory. Both require custom code and by changing the shell, I keep everything inside LDAP.
And as I said, I have a custom schema in my DIT that needs some attributes set for locked accounts, so I need custom code anyway. And since everything that doesn't use simple bind in my environment honors the 'D' flag in sambaAcctFlags, it is imho just as clean as using ACLs, for those applications.
Regards, Christian Manal
On Monday, 21 November 2011 16:17:33 Christian Manal wrote:
Am 21.11.2011 14:25, schrieb Jayavant Patil:
Hi,
I am using openldap-2.4.19-4 on fedora 12 machine. Does anybody know how
to enable/disable a user account in openLDAP? I know ppolicy overlay but I don't require this password based locking.
Thanks in advance.
Hi,
we lock UNIX/Samba/Kerberos accounts in our system by "invalidating" the userPassword (i.E. putting some random string before the '{HASH}' part), settings the loginShell to '/bin/false' and putting the 'D' flag in sambaAcctFlags.
Scrambling userPassword will prevent logins based on simple bind, changing the loginShell prevents PublicKey logins
No, it prevents starting a shell by ssh with public key, it doesn't prevent access which does not spawn a shell (such as ssh tunnel).
and 'D' in sambaAcctFlags disables logins with Samba and Heimdal Kerberos.
But if you use anything else that uses Samba's password hashes (such as FreeRADIUS with mschap), that won't lock the user out.
IMHO, there is currently no convenient complete solution.
Regards, Buchan
Am 22.11.2011 11:25, schrieb Buchan Milne:
On Monday, 21 November 2011 16:17:33 Christian Manal wrote:
Am 21.11.2011 14:25, schrieb Jayavant Patil:
Hi,
I am using openldap-2.4.19-4 on fedora 12 machine. Does anybody know how
to enable/disable a user account in openLDAP? I know ppolicy overlay but I don't require this password based locking.
Thanks in advance.
Hi,
we lock UNIX/Samba/Kerberos accounts in our system by "invalidating" the userPassword (i.E. putting some random string before the '{HASH}' part), settings the loginShell to '/bin/false' and putting the 'D' flag in sambaAcctFlags.
Scrambling userPassword will prevent logins based on simple bind, changing the loginShell prevents PublicKey logins
No, it prevents starting a shell by ssh with public key, it doesn't prevent access which does not spawn a shell (such as ssh tunnel).
I know it's not perfect, but it's good enough for us.
and 'D' in sambaAcctFlags disables logins with Samba and Heimdal Kerberos.
But if you use anything else that uses Samba's password hashes (such as FreeRADIUS with mschap), that won't lock the user out.
That's right. Luckily, we don't have anything like that. If it ever comes around, I can still modify my ACLs.
IMHO, there is currently no convenient complete solution.
Agreed.
Regards, Christian Manal
In many cases, I guess we could also just save a backup of the account (e.g. in ldif form) and just delete it.
The downside is that, if there are entries referencing that account, they would remain orphaned and we would have to make sure that such entries - if there are any - are also handled appropriately. That's DIT-dependent.
In any case, what I like to do (in our not really big/complex DIT), when any type of automation is needed (for tasks that are not rare), is to write a simple PHP mini-app providing functionality (through a web-server based GUI) to administrative people (and myself) and handling all associated dependencies automatically. I like the freedom offered by PHP and experience has proven it is a reliable solution. Fortunately, admins work on different DIT areas (with appropriate ACLs) and so there are no risks of overlapped transactions (which would otherwise be an issue as LDAP does not support transactions - yet).
I am not an LDAP expert, that's just my 2c. My way is by no means meant to be a suggested way of doing things. It just may help someone investigate some DIT management approaches.
Nick
Nick Milas wrote:
In many cases, I guess we could also just save a backup of the account (e.g. in ldif form) and just delete it.
I usually strongly discourage such a practice.
In deployments I setup entries are just disabled also to make the uid persistent. And then have a unique constraint on uid.
The downside is that, if there are entries referencing that account, they would remain orphaned and we would have to make sure that such entries - if there are any - are also handled appropriately. That's DIT-dependent.
Yes. Note that references are not only within the DIT. There are also many references to the user-IDs in different systems.
Ciao, Michael.
openldap-technical@openldap.org
-
Buchan Milne -
Christian Manal -
Jayavant Patil -
Michael Ströder -
Nick Milas