LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Enterprise (http://www.linuxquestions.org/questions/linux-enterprise-47/)
-   -   RHEL 6 LDAP now requires TLS (http://www.linuxquestions.org/questions/linux-enterprise-47/rhel-6-ldap-now-requires-tls-843917/)

custangro 11-12-2010 12:04 PM

RHEL 6 LDAP now requires TLS
 
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 (Post 4164491)
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 (Post 4164270)
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 (Post 4166963)
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 (Post 4157216)
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 (Post 4398478)
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

RHEL 6 LDAP now requires TLS
 
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 (Post 4541150)
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).


All times are GMT -5. The time now is 09:24 PM.