I know this forum is about sssd, but I am working with a customer that cannot run sssd due to a configuration issue on their ldap servers. I didn't know where else to ask this question other than to raise a formal elevation which I can do if so requested or this is found to be a bug.
This customer has opted to use nslcd over encrypted links. In testing this configuration I noticed two oddities. These two lines are required in nslcd.conf to get the encryption started:
ssl start_tls ssl on
I was always under the impression that if you use ssl, you shouldn't use or start TLS and visa versa, if TLS has been started, then don't start ssl. Am I misinterpreting what is being enabled with these two options.
What is even stranger, is that they are position dependent. The start_tls line must come before the ssl on line otherwise the encryption will not start correctly and the connections will fail.
To my knowledge this seems to be the only position dependent option I have run it to so far.
Was this intended ?
Al Licause HP L2 UNIX Network Services HP Customer Support Center Hours 7am-3pm Pacific time USA Manager: tom.cernilli@hp.com
On 08/16/2013 06:03 PM, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote:
I know this forum is about sssd, but I am working with a customer that cannot run sssd due to a
configuration issue on their ldap servers. I didn’t know where else to ask this question other
than to raise a formal elevation which I can do if so requested or this is found to be a bug.
This customer has opted to use nslcd over encrypted links. In testing this configuration I noticed
two oddities. These two lines are required in nslcd.conf to get the encryption started:
ssl start_tls
ssl on
I was always under the impression that if you use ssl, you shouldn’t use or start TLS and visa versa,
if TLS has been started, then don’t start ssl. Am I misinterpreting what is being enabled with these
two options.
What is even stranger, is that they are position dependent. The start_tls line must come before the
ssl on line otherwise the encryption will not start correctly and the connections will fail.
To my knowledge this seems to be the only position dependent option I have run it to so far.
Was this intended ?
Al Licause
HP L2 UNIX Network Services
HP Customer Support Center
Hours 7am-3pm Pacific time USA
Manager: tom.cernilli@hp.com
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
My guess is that the position dependence you mention means that when you specify more than one setting for ssl in nslcd.conf (see http://linux.die.net/man/5/nslcd.conf or 'man nslcd.conf' on your local system), only the first one is used and subsequent ones are ignored (contrary to other configs where only the last reference is the one used.)
The syntax of the nslcd.conf file allows for one of three settings to ssl: on, off, or start_tls, so the two lines you're using are actually two different settings. Your customer is using tls (as they should, since it supercedes ssl), so the correct setting in nslcd.conf is 'ssl start_tls'. The second line, 'ssl on' shouldn't be needed, and the fact that the configuration breaks when that's the first setting suggests that it's being ignored once start_tls is triggered.
Have you tried removing the 'ssl on' line from nslcd.conf? The customer configuration /should/ work correctly without that, if it doesn't then I'm thinking that's a bug.
/Harry
On Sat, 2013-08-17 at 07:32 -0400, Harry Sutton wrote:
On 08/16/2013 06:03 PM, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote:
I know this forum is about sssd, but I am working with a customer that cannot run sssd due to a
configuration issue on their ldap servers. I didn’t know where else to ask this question other
than to raise a formal elevation which I can do if so requested or this is found to be a bug.
This customer has opted to use nslcd over encrypted links. In testing this configuration I noticed
two oddities. These two lines are required in nslcd.conf to get the encryption started:
ssl start_tls
ssl on
I was always under the impression that if you use ssl, you shouldn’t use or start TLS and visa versa,
if TLS has been started, then don’t start ssl. Am I misinterpreting what is being enabled with these
two options.
What is even stranger, is that they are position dependent. The start_tls line must come before the
ssl on line otherwise the encryption will not start correctly and the connections will fail.
To my knowledge this seems to be the only position dependent option I have run it to so far.
Was this intended ?
Al Licause
HP L2 UNIX Network Services
HP Customer Support Center
Hours 7am-3pm Pacific time USA
Manager: tom.cernilli@hp.com
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
My guess is that the position dependence you mention means that when you specify more than one setting for ssl in nslcd.conf (see http://linux.die.net/man/5/nslcd.conf or 'man nslcd.conf' on your local system), only the first one is used and subsequent ones are ignored (contrary to other configs where only the last reference is the one used.)
The syntax of the nslcd.conf file allows for one of three settings to ssl: on, off, or start_tls, so the two lines you're using are actually two different settings. Your customer is using tls (as they should, since it supercedes ssl), so the correct setting in nslcd.conf is 'ssl start_tls'. The second line, 'ssl on' shouldn't be needed, and the fact that the configuration breaks when that's the first setting suggests that it's being ignored once start_tls is triggered.
Have you tried removing the 'ssl on' line from nslcd.conf? The customer configuration should work correctly without that, if it doesn't then I'm thinking that's a bug.
/Harry
btw you can use the nss-pam-ldapd list for questions concerning nslcd: http://lists.arthurdejong.org/nss-pam-ldapd-users/
Thanks much Harry,
I commented one of these lines and then the other and even rebooted the system just to clear any cache that might be hanging on to old data….and now neither line seems to be necessary.
Ah…the frustrations of ldap and all of its related components.
Al Licause HP L2 UNIX Network Services HP Customer Support Center Hours 7am-3pm Pacific time USA Manager: tom.cernilli@hp.com
From: sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users-bounces@lists.fedorahosted.org] On Behalf Of Harry Sutton Sent: Saturday, August 17, 2013 4:33 AM To: sssd-users@lists.fedorahosted.org Subject: Re: [SSSD-users] RHEL V6.4: nslcd need to start tls and ssl in a specific order
On 08/16/2013 06:03 PM, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: I know this forum is about sssd, but I am working with a customer that cannot run sssd due to a configuration issue on their ldap servers. I didn’t know where else to ask this question other than to raise a formal elevation which I can do if so requested or this is found to be a bug.
This customer has opted to use nslcd over encrypted links. In testing this configuration I noticed two oddities. These two lines are required in nslcd.conf to get the encryption started:
ssl start_tls ssl on
I was always under the impression that if you use ssl, you shouldn’t use or start TLS and visa versa, if TLS has been started, then don’t start ssl. Am I misinterpreting what is being enabled with these two options.
What is even stranger, is that they are position dependent. The start_tls line must come before the ssl on line otherwise the encryption will not start correctly and the connections will fail.
To my knowledge this seems to be the only position dependent option I have run it to so far.
Was this intended ?
Al Licause HP L2 UNIX Network Services HP Customer Support Center Hours 7am-3pm Pacific time USA Manager: tom.cernilli@hp.commailto:tom.cernilli@hp.com
_______________________________________________
sssd-users mailing list
sssd-users@lists.fedorahosted.orgmailto:sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
My guess is that the position dependence you mention means that when you specify more than one setting for ssl in nslcd.conf (see http://linux.die.net/man/5/nslcd.conf or 'man nslcd.conf' on your local system), only the first one is used and subsequent ones are ignored (contrary to other configs where only the last reference is the one used.)
The syntax of the nslcd.conf file allows for one of three settings to ssl: on, off, or start_tls, so the two lines you're using are actually two different settings. Your customer is using tls (as they should, since it supercedes ssl), so the correct setting in nslcd.conf is 'ssl start_tls'. The second line, 'ssl on' shouldn't be needed, and the fact that the configuration breaks when that's the first setting suggests that it's being ignored once start_tls is triggered.
Have you tried removing the 'ssl on' line from nslcd.conf? The customer configuration should work correctly without that, if it doesn't then I'm thinking that's a bug.
/Harry
sssd-users@lists.fedorahosted.org
-
Harry Sutton -
Jakub Hrozek -
Licause, Al (CSC AMS BCS - UNIX/Linux Network Support)