Questions about start_tls

[rah600]

I'm trying to setup nss_ldap on CentOS 5.2 to authenticate against openldap 2.3.27, using ppolicy and a password quality checker. I have two questions.

First, I am using start_tls and everything seems to be working. However, I can see in debug mode that the password is being sent clear text when I change the password, in spite of the fact that I have "pam_password crypt" in ldap.conf --

0010:  6a 65 66 66 2c 6f 75 3d  50 65 6f 70 6c 65 2c 64   jeff,ou=People,d 
0020:  63 3d 73 68 75 74 74 65  72 73 74 6f 63 6b 2c 64   c=mydomain,d 
0030:  63 3d 63 6f 6d 80 08 71  77 65 61 73 64 31 40 a0   c=com..mypassword@. 
0040:  1d 30 1b 04 19 31 2e 33  2e 36 2e 31 2e 34 2e 31   .0...1.3.6.1.4.1 
0050:  2e 34 32 2e 32 2e 32 37  2e 38 2e 35 2e 31         .42.2.27.8.5.1

Is there something else I need to do to encrypt everything, have I misconfigured something, or am misunderstanding start_tls? There are no complaints in the debug output about tls.

Second, and probably related, the password quality checking isn't working. Although I can successfully change the password and I do get prompted to change the password when time runs out on it, it does not check it against its history -- I can enter the same password every other time without complaint.

It might be another clue that, when I do change the password, the first prompt says "Enter login(LDAP) password:", and the next prompt says "New password". I was under the impression that the second prompt should also contain "LDAP". Is that correct?

Any help or guidance will be greatly appreciated. I'm about at wit's end with this one.

Here's my ldap.conf ...

base dc=mydomain,dc=com
ssl start_tls
tls_checkpeer no
use_sasl off
timelimit 120
bind_timelimit 120
bind_timelimit 30
bind_policy soft
idle_timelimit 3600
pam_filter objectclass=posixAccount
pam_lookup_policy yes
pam_password crypt
uri ldap://10.0.1.20/ ldap://10.0.1.21/
debug 2

Here's /etc/pam.d/system-auth

auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        sufficient    pam_ldap.so use_first_pass
auth        required      pam_deny.so

account     required      pam_unix.so broken_shadow
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     [default=bad success=ok user_unknown=ignore] pam_ldap.so
account     required      pam_permit.so

password    sufficient    pam_ldap.so
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     optional      pam_ldap.so
session     required      pam_mkhomedir.so skel=/etc/skel/

On Tuesday 09 December 2008 23:32:27 maillists0@... wrote:
> I'm trying to setup nss_ldap on CentOS 5.2 to authenticate against openldap
> 2.3.27, using ppolicy and a password quality checker. I have two questions.
>
> First, I am using start_tls and everything seems to be working. However, I
> can see in debug mode that the password

Which password? The old one, or the new one? I would expect the old password
to be sent in the clear ... as a simple bind is being done.

> is being sent clear text when I
> change the password, in spite of the fact that I have "pam_password crypt"
> in ldap.conf --
>
> 0010:  6a 65 66 66 2c 6f 75 3d  50 65 6f 70 6c 65 2c 64   jeff,ou=People,d
> 0020:  63 3d 73 68 75 74 74 65  72 73 74 6f 63 6b 2c 64   c=mydomain,d
> 0030:  63 3d 63 6f 6d 80 08 71  77 65 61 73 64 31 40 a0  
> c=com..mypassword@.
>
> 0040:  1d 30 1b 04 19 31 2e 33  2e 36 2e 31 2e 34 2e 31   .0...1.3.6.1.4.1
> 0050:  2e 34 32 2e 32 2e 32 37  2e 38 2e 35 2e 31         .42.2.27.8.5.1
>
> Is there something else I need to do to encrypt everything, have I
> misconfigured something, or am misunderstanding start_tls?

Well, where are you seeing this (where does the output above come from)? If it
comes from the debug output, this is normal AFAIK.

> There are no
> complaints in the debug output about tls.
>
> Second, and probably related, the password quality checking isn't working.

You don't provide your password policy, so it's difficult to comment here.
However, if you have tested the policy with another tool (say ldappasswd)
which does LDAP password change extended operations, then ... you should
probably change pam_password to 'exop'. OpenLDAP cant enforce anything if it
receives the encrypted password.

> Although I can successfully change the password and I do get prompted to
> change the password when time runs out on it, it does not check it against
> its history -- I can enter the same password every other time without
> complaint.

AFAIK, password history can be enforced even with pam_password crypt (or
similar), but again, you haven't provided anything regarding your OpenLDAP
configuration.

You should first test that your policy works as expected by using OpenLDAP
utilities only. Once you are sure your policy works, then I would look at the
pam_ldap side. Of course, the OpenLDAP lists may be better for assistance in
ensuring your password policy is working correctly.

> It might be another clue that, when I do change the password, the first
> prompt says "Enter login(LDAP) password:", and the next prompt says "New
> password". I was under the impression that the second prompt should also
> contain "LDAP". Is that correct?
>
> Any help or guidance will be greatly appreciated. I'm about at wit's end
> with this one.
>
> Here's my ldap.conf ...

/etc/ldap.conf ? (just to be sure).

>
> base dc=mydomain,dc=com
> ssl start_tls
> tls_checkpeer no
> use_sasl off
> timelimit 120
> bind_timelimit 120
> bind_timelimit 30
> bind_policy soft
> idle_timelimit 3600
> pam_filter objectclass=posixAccount
> pam_lookup_policy yes
> pam_password crypt
> uri ldap://10.0.1.20/ ldap://10.0.1.21/
> debug 2
>
> Here's /etc/pam.d/system-auth
>
> auth        required      pam_env.so
> auth        sufficient    pam_unix.so nullok try_first_pass
> auth        requisite     pam_succeed_if.so uid >= 500 quiet
> auth        sufficient    pam_ldap.so use_first_pass
> auth        required      pam_deny.so
>
> account     required      pam_unix.so broken_shadow
> account     sufficient    pam_succeed_if.so uid < 500 quiet
> account     [default=bad success=ok user_unknown=ignore] pam_ldap.so
> account     required      pam_permit.so
>
> password    sufficient    pam_ldap.so
> password    required      pam_deny.so
>
> session     optional      pam_keyinit.so revoke
> session     required      pam_limits.so
> session     [success=1 default=ignore] pam_succeed_if.so service in crond
> quiet use_uid
> session     optional      pam_ldap.so
> session     required      pam_mkhomedir.so skel=/etc/skel/

[Andrew Findlay-2]

On Wed, Dec 10, 2008 at 09:08:21AM +0200, Buchan Milne wrote:

> AFAIK, password history can be enforced even with pam_password crypt (or
> similar),

Unlikely. Remember that most password hash algorithms include random
salt, so the same password can translate to many thousand different
hash strings. There is no way to know whether two strings using
different salt refer to the same password.

As you said above:

> OpenLDAP cant enforce anything if it
> receives the encrypted password.

It may be wise to set pwdCheckQuality=2 in the password policy to make
sure that passwords are only accepted in clear text.

It would also be wise to write LDAP ACLs such that password changes
are not accepted unless the session is encrypted.

Andrew
--
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                [phone]     |
-----------------------------------------------------------------------

[rah600]

On Wed, Dec 10, 2008 at 10:13 AM, Andrew Findlay <andrew.findlay@...> wrote:

As you said above:

> OpenLDAP cant enforce anything if it
> receives the encrypted password.

It may be wise to set pwdCheckQuality=2 in the password policy to make
sure that passwords are only accepted in clear text.

It would also be wise to write LDAP ACLs such that password changes
are not accepted unless the session is encrypted.

Andrew
--

Thanks to both of you for the responses. Changing pam_password from md5 (which was inserted by Redhat's authconfig) to exop fixed the password policy issues.  Also, setting pwdCheckQuality=2 was helpful in troubleshooting.

I still see in the debug output that the old password is being sent in cleartext when I change it. To be sure I understand correctly, Buchan: this is normal and necessary for ppolicy to check against the history?

Andrew, do you know of a handy example of an acl that enforces encryption on passwd changes?

Thanks again.

[Andrew Findlay-2]

Please keep replies on-list: it helps others in the future.

On Wed, Dec 10, 2008 at 02:25:44PM -0500, maillists0@... wrote:

> Thanks to both of you for the responses. Changing pam_password from md5
> (which was inserted by Redhat's authconfig) to exop fixed the password
> policy issues.  Also, setting pwdCheckQuality=2 was helpful in
> troubleshooting this issue.
>
> I still see in the debug output that the old password is being sent in
> cleartext when I change it. To be sure I understand correctly: this is
> normal and necessary for ppolicy to check against the history?

Not so much for the history check, but it is common to require the
client to include the old password in the change request to prevent
someone using a hijacked connection to change a password that they do
not know.

Also, if you are using simple bind on an un-encrypted connection then
the bind password will be sent in clear.

> Andrew, do you know of a handy example of an acl that enforces encryption on
> passwd changes?

Just add a Security Strength Factor to the access control
statement that permits the user to change their password.  Something
like this:

access to attrs=userPassword
        by ssf=64 self =w
        by * auth

That would require at least 64-bit encryption. Remember that it is up
to the *client* to request that encryption using TLS. I would suggest
always using encryption for NSS and PAM clients.

There are some examples using SSF in the Admin Guide:
http://www.openldap.org/doc/admin24/access-control.html#Access%20Control%20Examples

Andrew
--
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                [phone]     |
-----------------------------------------------------------------------

[Chapman, Kyle]

From: owner-nssldap@... [mailto:owner-nssldap@...] On Behalf Of maillists0@...
Sent: Wednesday, December 10, 2008 2:28 PM
To: Buchan Milne; nssldap@...
Subject: Re: [nssldap] Questions about start_tls

On Wed, Dec 10, 2008 at 10:13 AM, Andrew Findlay <andrew.findlay@...> wrote:

As you said above:

> OpenLDAP cant enforce anything if it
> receives the encrypted password.

It may be wise to set pwdCheckQuality=2 in the password policy to make
sure that passwords are only accepted in clear text.

It would also be wise to write LDAP ACLs such that password changes
are not accepted unless the session is encrypted.

Andrew
--

Thanks to both of you for the responses. Changing pam_password from md5 (which was inserted by Redhat's authconfig) to exop fixed the password policy issues.  Also, setting pwdCheckQuality=2 was helpful in troubleshooting.

I still see in the debug output that the old password is being sent in cleartext when I change it. To be sure I understand correctly, Buchan: this is normal and necessary for ppolicy to check against the history?

Andrew, do you know of a handy example of an acl that enforces encryption on passwd changes?

Thanks again. 

 

 

http://www.openldap.org/doc/admin24/access-control.html#Access%20Control%20Examples

another way, in slapd.conf

security ssf=1 update_ssf=112

 

NOTICE: This E-mail may contain confidential information. If you are not
the addressee or the intended recipient please do not read this E-mail
and please immediately delete this e-mail message and any attachments
from your workstation or network mail system. If you are the addressee
or the intended recipient and you save or print a copy of this E-mail,
please place it in an appropriate file, depending on whether
confidential information is contained in the message.

[rah600]

Remember that it is up
to the *client* to request that encryption using TLS. I would suggest
always using encryption for NSS and PAM clients.

I'm confused about this. In /etc/ldap.conf, I have "ssl start_tls". When I set debug to 2, I can see that the output of the server is encrypted and there are a lot of "tls_read: want/got" messages, with no complaints. The only output that isn't encrypted is from the client. I am using a self-signed certificate, so I set tls_checkpeer to "no". Is this to be expected, or is tls on the client-side silently failing?

[Andrew Findlay-2]

On Wed, Dec 10, 2008 at 03:16:02PM -0500, maillists0@... wrote:

> > Remember that it is up
> > to the *client* to request that encryption using TLS. I would suggest
> > always using encryption for NSS and PAM clients.
> >
> >
> I'm confused about this. In /etc/ldap.conf, I have "ssl start_tls". When I
> set debug to 2, I can see that the output of the server is encrypted and
> there are a lot of "tls_read: want/got" messages, with no complaints. The
> only output that isn't encrypted is from the client. I am using a
> self-signed certificate, so I set tls_checkpeer to "no". Is this to be
> expected, or is tls on the client-side silently failing?

I have not tried this, but I suspect that the client-side debug is
showing stuff before is gets encrypted for transmission. It would not
be much use for debugging otherwise!

You can check what is on the wire using wireshark.

As a general point I would suggest always making a long-lived CA
certificate and using that to sign your server certificates. It makes
management of certs much easier when you have many servers and clients.
You can then distribute the CA cert to the clients and use it to
verify server certs - very important if you want real security.

Andrew
--
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                [phone]     |
-----------------------------------------------------------------------

[rah600]

On Wed, Dec 10, 2008 at 3:23 PM, Andrew Findlay <andrew.findlay@...> wrote:

I have not tried this, but I suspect that the client-side debug is
showing stuff before is gets encrypted for transmission. It would not
be much use for debugging otherwise!

You can check what is on the wire using wireshark.

As a general point I would suggest always making a long-lived CA
certificate and using that to sign your server certificates. It makes
management of certs much easier when you have many servers and clients.
You can then distribute the CA cert to the clients and use it to
verify server certs - very important if you want real security.

Andrew
--

I did tcpdump and all is well. This is funny, and I'd be embarrassed if I wasn't so so relieved to find that there's not something wrong with the installation. I'll def look at certificate verification and longer-lived certs. Thanks again for your help.