Hi there,
Is there any way to lock user in LDAP database ? I mean, in linux, it's possible to use passwd <username> -l to lock user and -u to unlock. Is there a similar function in LDAP ?
Thanks
--- Gustavo Mendes de Carvalho e-mail: gmcarvalho@gmail.com
On Wednesday 04 June 2008 08:00:12 am Gustavo Mendes de Carvalho wrote:
Hi there,
Hi
Is there any way to lock user in LDAP database ? I mean, in linux, it's possible to use passwd <username> -l to lock user and -u to unlock. Is there a similar function in LDAP ?
LDAP is not an autentication mechanism by itself, if you are storing unix/posix accounts in your directory maybe you can add the fields to store the expire values, you can use the latest version of smbldap-tools, they have a very good support for this.
Thanks
Gustavo Mendes de Carvalho e-mail: gmcarvalho@gmail.com
Hello,
Currently we use {CRYPT} passwords. I would like to know if there is a way to use {SHA} passwords. Could existing passwords be in some way converted to {SHA}? Would using the right password-hash directive be enough to make it automagically work and allow users to still be able to authenticate with their current password?
Thank you, Jeroen
On Wednesday 04 June 2008 20:02:55 Jeroen van Aart wrote:
Hello,
Currently we use {CRYPT} passwords. I would like to know if there is a way to use {SHA} passwords.
Yes. See for example the slappasswd man page.
Could existing passwords be in some way converted to {SHA}?
Except by brute-forcing, no.
Would using the right password-hash directive be enough to make it automagically work and allow users to still be able to authenticate with their current password?
If you think logically about this, you will realise that this should be impossible.
The best option here is to change the default password hashing method (see the 'password-hash' directive for slapd.conf), and force password changes (if done via an LDAP password change extended operation, slapd will take care of hashing the password correctly).
Regards, Buchan
Buchan Milne writes:
On Wednesday 04 June 2008 20:02:55 Jeroen van Aart wrote:
Currently we use {CRYPT} passwords. I would like to know if there is a way to use {SHA} passwords.
Yes. See for example the slappasswd man page.
Though why use SHA instead of the default SSHA (salted SHA)? Even CRYPT passwords have a salt.
Could existing passwords be in some way converted to {SHA}?
Except by brute-forcing, no.
You could write an overlay to intercept Simple Bind operations: If the current userPassword is a {CRYPT} and the user-provided password matches it, SHA-hash the user-provided password and replace the stored CRYPT with the new SHA. Though this does make it a bit dubious to claim that the new SHA hash has the strength of SHA rather than the strength it inherited from CRYPT...
(...) The best option here is to change the default password hashing method (see the 'password-hash' directive for slapd.conf), and force password changes (if done via an LDAP password change extended operation, slapd will take care of hashing the password correctly).
And there ought to be a password expiry policy in place so users will need to change old passwords anyway. If LDAP is your authorative store for passwords, see man slapo-ppolicy.
Hallvard B Furuseth wrote:
Though why use SHA instead of the default SSHA (salted SHA)? Even CRYPT passwords have a salt.
Googleapps v2 (not my choice) supports SHA-1 with regards to passwords. I am trying to make LDAP synchronisation works including synchronising passwords. The only other option appears to be plaintext.
And there ought to be a password expiry policy in place so users will need to change old passwords anyway. If LDAP is your authorative store for passwords, see man slapo-ppolicy.
I know about the password policy. It's a bit problematic to implement into the existing system. The main issue I remember is that I wanted to implement the policy for select groups, ou=People for example, but NOT ou=FTPusers or ou=Virtual since those accounts can't readily change the password. I couldn't find a way to do that.
Regards, Jeroen
Jeroen van Aart writes:
I know about the password policy. It's a bit problematic to implement into the existing system. The main issue I remember is that I wanted to implement the policy for select groups, ou=People for example, but NOT ou=FTPusers or ou=Virtual since those accounts can't readily change the password. I couldn't find a way to do that.
For that particular proble, if by "groups" you mean LDAP subtrees: You can put ou=People in a separate database in slapd.conf and mark it as "subordinate" of its parent database so they'll be glued together and act as one database. Though since you mention synchronisation, there were or are some bugs with combining syncrepl with the glue overlay which "subordinate" makes use of. The latest 2.4.* releases including the upcoming 2.4.10 have a number of syncrepl fixes.
On Thursday 05 June 2008 21:42:57 Hallvard B Furuseth wrote:
Jeroen van Aart writes:
I know about the password policy. It's a bit problematic to implement into the existing system. The main issue I remember is that I wanted to implement the policy for select groups, ou=People for example, but NOT ou=FTPusers or ou=Virtual since those accounts can't readily change the password. I couldn't find a way to do that.
For that particular proble, if by "groups" you mean LDAP subtrees: You can put ou=People in a separate database in slapd.conf and mark it as "subordinate" of its parent database so they'll be glued together and act as one database. Though since you mention synchronisation, there were or are some bugs with combining syncrepl with the glue overlay which "subordinate" makes use of. The latest 2.4.* releases including the upcoming 2.4.10 have a number of syncrepl fixes.
Or, you can have one default policy, and override it (by setting the pwdPolicySubentry to the other policy) on all the entries which should not use the default policy. Which one you make the default, you will have to decide.
Regards, Buchan
Buchan Milne wrote:
Or, you can have one default policy, and override it (by setting the pwdPolicySubentry to the other policy) on all the entries which should not use the default policy. Which one you make the default, you will have to decide.
I am curious how the mechanism of enforcing the policy through various login "points" works. For example ssh, subversion, email and ftp all authenticate to LDAP, via pam. Some people use ssh, all people use email and some people use subversion. Ftp is mostly used by external clients, who have no way of acting upon a password expiration.
Email seems to be the common thing amongst all users whose password "should" expire and who can change it. How can LDAP tell an email client, through pam that the password is about to expire, or has expired? Or does this happen automagically?
Thanks, Jeroen
Buchan Milne wrote:
Except by brute-forcing, no.
If you think logically about this, you will realise that this should be impossible.
Yes I pretty much figured both answers, was just making sure I didn't overlook something.
The best option here is to change the default password hashing method (see the 'password-hash' directive for slapd.conf), and force password changes (if done via an LDAP password change extended operation, slapd will take care of hashing the password correctly).
How would I force a password change? Currently authentication through LDAP (using pam) is done mainly for email and ssh to a lesser extent.
Regards, Jeroen
openldap-technical@openldap.org
-
Buchan Milne -
Gustavo Mendes de Carvalho -
Hallvard B Furuseth -
Jeroen van Aart -
Jorge Armando Medina