[SOLVED] RHEL 6 LDAP now requires TLS

custangro · 11-12-2010, 12:04 PM

So I've downloaded RHEL 6.0 to test on our systems here at work...now it seems that RHEL 6.0 (when running system-config-authentication) now is "forcing" us to use TLS...but the command line option "works"

Code:

root@rhel6# authconfig --enableldap --enableldapauth --enablemkhomedir --ldapserver=ldap1.example.com,ldap2.example.com --ldapbasedn="dc=example,dc=com" --update

Which came back with this output...

Code:

Starting sssd:                                             [  OK  ]
Starting oddjobd:                                          [  OK  ]

Now logged in as "root" I can "su" to the users on my LDAP server no problem...but I cannot "ssh" or login into the console with the users...the log file is this...

Code:

Nov 12 09:39:18 rhel6-test sssd[be[default]]: Could not start TLS encryption. unsupported extended operation
Nov 12 09:39:22 rhel6-test sssd[be[default]]: Could not start TLS encryption. unsupported extended operation
Nov 12 09:39:26 Nov 12 09:39:17 anteater sshd[1543]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.2.122  user=chrish
Nov 12 09:39:18 rhel6-test sshd[1543]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.2.122 user=chrish
Nov 12 09:39:18 rhel6-test sshd[1543]: pam_sss(sshd:auth): received for user chrish: 4 (System error)
Nov 12 09:39:20 rhel6-test sshd[1543]: Failed password for chrish from 192.168.2.122 port 49940 ssh2
Nov 12 09:39:22 rhel6-test sshd[1543]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.2.122 user=chrish
Nov 12 09:39:22 rhel6-test sshd[1543]: pam_sss(sshd:auth): received for user chrish: 4 (System error)
Nov 12 09:39:24 rhel6-test sshd[1543]: Failed password for chrish from 192.168.2.122 port 49940 ssh2
Nov 12 09:39:26 rhel6-test sshd[1543]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.2.122 user=chrish
Nov 12 09:39:26 rhel6-test sshd[1543]: pam_sss(sshd:auth): received for user chrish: 4 (System error)
Nov 12 09:39:27 rhel6-test sshd[1543]: Failed password for chrish from 192.168.2.122 port 49940 ssh2
Nov 12 09:39:27 rhel6-test sshd[1544]: Connection closed by 192.168.2.122 sssd[be[default]]: Could not start TLS encryption. unsupported extended operation

and this...

Code:

Nov 12 09:39:18 rhel6-test sssd[be[default]]: Could not start TLS encryption. unsupported extended operation
Nov 12 09:39:22 rhel6-test sssd[be[default]]: Could not start TLS encryption. unsupported extended operation
Nov 12 09:39:26 Nov 12 09:39:17 rhel6-test sshd[1543]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.2.122  user=chrish
Nov 12 09:39:18 rhel6-test sshd[1543]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.2.122 user=chrish
Nov 12 09:39:18 rhel6-test sshd[1543]: pam_sss(sshd:auth): received for user chrish: 4 (System error)
Nov 12 09:39:20 rhel6-test sshd[1543]: Failed password for chrish from 192.168.2.122 port 49940 ssh2
Nov 12 09:39:22 rhel6-test sshd[1543]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.2.122 user=chrish
Nov 12 09:39:22 rhel6-test sshd[1543]: pam_sss(sshd:auth): received for user chrish: 4 (System error)
Nov 12 09:39:24 rhel6-test sshd[1543]: Failed password for chrish from 192.168.2.122 port 49940 ssh2
Nov 12 09:39:26 rhel6-test sshd[1543]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.2.122 user=chrish
Nov 12 09:39:26 rhel6-test sshd[1543]: pam_sss(sshd:auth): received for user chrish: 4 (System error)
Nov 12 09:39:27 rhel6-test sshd[1543]: Failed password for chrish from 192.168.2.122 port 49940 ssh2
Nov 12 09:39:27 rhel6-test sshd[1544]: Connection closed by 192.168.2.122 sssd[be[default]]: Could not start TLS encryption. unsupported extended operation

Okay, now I know what you are going to say "why don't you use TLS? It's more secure and blah blah blah"

But to be honest...I am not going to completely change my infrastructure JUST to test rhel6...the migration to use TLS is more than just a days work

I just want to know if I can "tweek" pam so that it won't care about a TLS...

-C

custangro · 11-12-2010, 05:32 PM

Answered my own question with some "poking around"

If you edit the /etc/sysconfig/authconfig file and change the

Code:

FORCELEGACY=no

To...

Code:

FORCELEGACY=yes

the LDAP auth will work without TLS as it did in RHEL5

baysie · 11-19-2010, 06:52 AM

I have the same problem - but unfortunately this fix doesn't work for me:

Code:

Quote:

authconfig --enableldap --enableldapauth --ldapserver=123.456.78.910 --ldapbasedn="dc=example,dc=com" --update

Returns:

Quote:

Starting nslcd: [ OK ]

But I still cannot see our LDAP users, let alone SU or SSH as them. Performing a "getent passwd" generates the following errors in /var/log/messages:

Quote:

Nov 19 12:40:34 lwkm004-vm nslcd[2756]: [7b23c6] failed to bind to LDAP server ldap://123.456.78.910/: Connect error
Nov 19 12:40:34 lwkm004-vm nslcd[2756]: [7b23c6] no available LDAP server found

Obviously the LDAP server exists, and it works fine with our RHEL5 and Ubuntu systems...

Any ideas? Cheers.

thamlang · 11-19-2010, 10:37 AM

First, I would like to thank you, custango for the instruction. It seems to work without TLS connecting to the LDAP.
Since I am using Red Hat Directory Service 8 / 389 Directory Server with the TLS connection, I am able to connect it.

Here is how to do it. After the fresh installation from RHEL 6, create /etc/ldap.conf

base dc=rhel,dc=com
uri ldap://demo.rhel.com
ssl start_tls
tls_cacertdir /etc/openldap/cacerts
bind_policy soft
pam_password md5

create /etc/openldap/ldap.conf

URI ldap://demo.rhel.com
BASE dc=rhel,dc=com
TLS_CACERTDIR /etc/openldap/cacerts
TLS_REQCERT allow

Make sure you scp /etc/dirsrv/slapd-demo/cacert.asc(LDAP server) to /etc/openldap/cacerts/cacert.pem(client)

click System --> Administration --> Authentication
User Account Database: LDAP
LDAP Search Base DN dc=rhel,dc=com
LDAP Server ldap://demo.rhel.com
check Use TLS to encrypt connections
Click Download CA Certificate ...
Certificate URL : https://demo.rhel.com:636
Click OK and Apply

Authentication Configuration
Authentication Method LDAP password (In my case, Others may use Kerberos password.

In one of the machine, the installation missing openldap-clients, nss-pam-ldapd, nss-util authconfig-gtk.

yum install open-ldap-clients nss-pam-ldapd nss-util authconfig-gtk -y

custangro · 11-19-2010, 11:22 AM

Quote:

Originally Posted by thamlang

First, I would like to thank you, custango for the instruction. It seems to work without TLS connecting to the LDAP.
Since I am using Red Hat Directory Service 8 / 389 Directory Server with the TLS connection, I am able to connect it.

Here is how to do it. After the fresh installation from RHEL 6, create /etc/ldap.conf

base dc=rhel,dc=com
uri ldap://demo.rhel.com
ssl start_tls
tls_cacertdir /etc/openldap/cacerts
bind_policy soft
pam_password md5

create /etc/openldap/ldap.conf

URI ldap://demo.rhel.com
BASE dc=rhel,dc=com
TLS_CACERTDIR /etc/openldap/cacerts
TLS_REQCERT allow

Make sure you scp /etc/dirsrv/slapd-demo/cacert.asc(LDAP server) to /etc/openldap/cacerts/cacert.pem(client)

click System --> Administration --> Authentication
User Account Database: LDAP
LDAP Search Base DN dc=rhel,dc=com
LDAP Server ldap://demo.rhel.com
check Use TLS to encrypt connections
Click Download CA Certificate ...
Certificate URL : https://demo.rhel.com:636
Click OK and Apply

Authentication Configuration
Authentication Method LDAP password (In my case, Others may use Kerberos password.

In one of the machine, the installation missing openldap-clients, nss-pam-ldapd, nss-util authconfig-gtk.

yum install open-ldap-clients nss-pam-ldapd nss-util authconfig-gtk -y

Thank you for the quick how to

I know I need to start upgrading our infrastructure...although I think I will start delving into Kerberos

(FreeIPA sounds nice)

custangro · 11-19-2010, 11:29 AM

Quote:

Originally Posted by baysie

I have the same problem - but unfortunately this fix doesn't work for me:

Code:

Returns:

But I still cannot see our LDAP users, let alone SU or SSH as them. Performing a "getent passwd" generates the following errors in /var/log/messages:

Obviously the LDAP server exists, and it works fine with our RHEL5 and Ubuntu systems...

Any ideas? Cheers.

I know that RHEL6 comes with IPTables and SELinux enabled by default...

Try and disable these and test...

Code:

root@rhel6# service iptables stop
root@rhel6# setenforce 0

Then do your testing...if it works...then either leave them off...or configure them to work with your system.

-C

baysie · 11-22-2010, 05:35 AM

Thanks Custangro - both IPtables and SELinux are usually the first places I turn to when things don't work as expected. However, they were not the issue this time. It was in fact because I specified the IP of our LDAP server as opposed to it's host / DNS name when updating authconfig. Modifying the authconfig command to reflect this actually managed to bind the client to the LDAP server:

Quote:

authconfig --enableldap --enableldapauth --ldapserver=myldapserver.com --ldapbasedn="dc=example,dc=com" --update

Then obviously I modified the /etc/sysconfig/authconfig as outlined earlier in this thread and all sprang to life.

So this was naivety on my part - but thanks for all of your help. We're braving the move to kerberos in a month so thankfully this will keep us ticking over until then.

Cheers

custangro · 11-22-2010, 10:05 AM

Quote:

Originally Posted by baysie

Thanks Custangro - both IPtables and SELinux are usually the first places I turn to when things don't work as expected. However, they were not the issue this time. It was in fact because I specified the IP of our LDAP server as opposed to it's host / DNS name when updating authconfig. Modifying the authconfig command to reflect this actually managed to bind the client to the LDAP server:

Then obviously I modified the /etc/sysconfig/authconfig as outlined earlier in this thread and all sprang to life.

So this was naivety on my part - but thanks for all of your help. We're braving the move to kerberos in a month so thankfully this will keep us ticking over until then.

Cheers

Glad to hear that you worked it out!

Yeah I am venturing into IPA ( http://freeipa.org ) and testing it on my local machine here at work to see if it's a viable solution...

Let us know how the Kerberos thing works out

User321 · 12-06-2010, 09:59 AM

How do you enable home directories with authconfig? I can't find an option.

There is an option within the gui, but it will not save this setting as it goes on about needing to use tls.

Anyone know?

rhbegin · 06-28-2011, 06:06 PM

Quote:

Originally Posted by custangro

Answered my own question with some "poking around"

If you edit the /etc/sysconfig/authconfig file and change the

Code:

FORCELEGACY=no

To...

Code:

FORCELEGACY=yes

the LDAP auth will work without TLS as it did in RHEL5

I am setting up RHEL6.1 in a test environment, does the 389 in RHEL6.1 have a graphical tool to use?

Any help/advice or link would be great.

custangro · 07-06-2011, 03:07 PM

Quote:

Originally Posted by rhbegin

I am setting up RHEL6.1 in a test environment, does the 389 in RHEL6.1 have a graphical tool to use?

Any help/advice or link would be great.

Try this

Code:

system-config-authentication

CeeEss · 07-12-2011, 03:01 AM

FORCELEGACY works an absolute treat - thanks very much for this, custangro

sgallagh · 11-11-2011, 07:19 AM

I just wanted to chime in here (as an SSSD developer). We made a very conscious decision not to allow LDAP authentication to occur without either TLS or SSL in place. The reason for this is because the LDAP protocol requires that the password be sent in plaintext over the wire. This means that any server between your client machine and your LDAP server (which, if you're off on a business trip could be a couple dozen untrusted servers) can read your password with a trivial network trace (such as wireshark). Even within your corporate network, there's nothing stopping an adminstrator with access to any of the routers from seeing that password.

So we decided that SSSD would refuse to send the password over an unencrypted channel, to protect users from admins that are unaware or unwilling to follow reasonable security features (such as those outlined by Sarbanes-Oxley.

For the record, a much better solution than falling back to FORCELEGACY would be to simply add the following line to your /etc/sssd/sssd.conf in the [domain/default] section:
ldap_tls_reqcert = never.

What this means is that we will attempt to use START_TLS against the LDAP server, and even if we cannot trust the certificate chain, we will still use it for encryption. This leaves you exposed to a man-in-the-middle attack, but it's still more secure than simply shouting to the world: "Hey! This guy's password is 12345!".

bweddell · 12-03-2011, 01:30 PM

I am running CentOS 6 and have a similar problem. I am using openLDAP (openldap-clients-2.4.19-15.el6_0.2.x86_64) and get access denied when trying to login via ssh. In /var/log/secure I get:

pam_sss(sshd:auth): received for user ziggy: 9 (Authentication service cannot retrieve authentication info)

Once I login directly as root (until I get this fixed) I am able to do a id or su of an ldap user.

I am using TLS with my openldap client config and have downloaded the certificate successfully. I set debug to 10 in /etc/sssd/sssd.conf and this didn't matter.

Top of /etc/pam.d/password-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_sss.so use_first_pass
auth required pam_deny.so

I have lots more CentOS 5 installations and didn't have to do anything aside from run authconfig-tui, set TLS and be done with it.

I took sgallagh's advice and put the ldap_tls_reqcert = never entry in domain/default section and restarted sssd - no change.

The only way I can get a ssh ldap login to work is turn off tls AND set the forcelegacy to yes in the /etc/sysconfig/authconfig file.

My biggest challenge is getting more log information that tells me more info - any clues here are also appreciated.

sgallagh · 12-05-2011, 06:34 AM

Quote:

Originally Posted by bweddell

I am running CentOS 6 and have a similar problem. I am using openLDAP (openldap-clients-2.4.19-15.el6_0.2.x86_64) and get access denied when trying to login via ssh. In /var/log/secure I get:

pam_sss(sshd:auth): received for user ziggy: 9 (Authentication service cannot retrieve authentication info)

Once I login directly as root (until I get this fixed) I am able to do a id or su of an ldap user.

I am using TLS with my openldap client config and have downloaded the certificate successfully. I set debug to 10 in /etc/sssd/sssd.conf and this didn't matter.

Top of /etc/pam.d/password-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_sss.so use_first_pass
auth required pam_deny.so

I have lots more CentOS 5 installations and didn't have to do anything aside from run authconfig-tui, set TLS and be done with it.

I took sgallagh's advice and put the ldap_tls_reqcert = never entry in domain/default section and restarted sssd - no change.

The only way I can get a ssh ldap login to work is turn off tls AND set the forcelegacy to yes in the /etc/sysconfig/authconfig file.

My biggest challenge is getting more log information that tells me more info - any clues here are also appreciated.

A good move would be to increase the debug level of the [pam] and [domain/default] sections in /etc/sssd/sssd.conf, restart SSSD (service sssd restart), retry your login and check /var/log/sssd/sssd_pam.log and /var/log/sssd_default.log for possible issues.

Debug levels go from 0-9, defaulting to zero (fatal errors) and going up to 9 (extremely low-level tracing).