Enable/Disable user account in openLDAP

Post by 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

Michael Ströder

2011-11-21 14:59:01 UTC

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.

Christian Manal

2011-11-21 15:29:38 UTC

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

Michael Ströder

2011-11-21 17:21:30 UTC

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.

Christian Manal

2011-11-21 17:34:32 UTC

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

Post by Michael StrÃ¶der
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

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

Michael Ströder

2011-11-21 17:52:36 UTC

Post by Christian Manal
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...

Ciao, Michael.

Christian Manal

2011-11-22 08:06:17 UTC

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

Nick Milas

2011-11-22 20:27:18 UTC

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

Michael Ströder

2011-11-23 10:46:23 UTC

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.

Buchan Milne

2011-11-22 10:25:43 UTC

Post by 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).

Post by Christian Manal
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

Christian Manal

2011-11-22 11:31:20 UTC

Post by Buchan Milne