Linux - EnterpriseThis forum is for all items relating to using Linux in the Enterprise.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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"
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
Last edited by custangro; 11-12-2010 at 04:25 PM.
Click here to see the post LQ members have rated as the most helpful post in this thread.
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...
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.
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.
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.
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...
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!".
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.
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.
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).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.