[SOLVED] RHEL 6 LDAP now requires TLS

brunodeep · 01-25-2012, 06:57 AM

I Know you point
I request a change to my ldap admins set SSL ON soon.

Thanks

chenjintao_ii · 01-28-2012, 08:00 PM

Quote:

Originally Posted by sgallagh

SSSD does not allow this. Unlike pam_ldap, SSSD will always refuse to broadcast users' passwords. If there is no encryption available on the communication, we throw an error instead of exposing your users.

Does it mean that if I use SSSD, the pam_ldap will be unavailable? What's the relationship between pam and SSSD?

sgallagh · 01-30-2012, 06:27 AM

Quote:

Originally Posted by chenjintao_ii

Does it mean that if I use SSSD, the pam_ldap will be unavailable? What's the relationship between pam and SSSD?

SSSD provides pam_sss.so, which replaces pam_ldap.so in your PAM stack. This provides SSSD's interface to the authentication services. They are not strictly mutually-exclusive, but it's highly recommended not to try to run them at the same time.

The SSSD essentially rolls the functionality of nss-pam-ldapd, pam_ldap and pam_krb5 into a single package (with multiple pieces).*

* Not all pieces are 100% compatible yet, but the vast majority of common cases are fully supported.

master_bitbucket · 02-02-2012, 07:08 AM

I have sssd setup against my AD servers for authentication and it's working but I'm seeing some very strange behavior when logging in. The SSH connection is made quickly and I'm prompted for my password. After entering the password the connection seems to hang and while that's happening this is what I see in /var/log/secure. Why is pam_unix failing and then pam_sss succeeding? I've looked and /etc/pam.d/system-auth and it looks like what I would expect. Does anyone have any ideas?

Code:

Feb  2 07:44:35 server01 sshd[30324]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.1.5.61  user=testuser
Feb  2 07:44:36 server01 sshd[30324]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.1.5.61 user=testuser
Feb  2 07:44:36 server01 sshd[30324]: Accepted password for testuser from 10.1.5.61 port 61269 ssh2
Feb  2 07:44:36 server01 sshd[30324]: pam_unix(sshd:session): session opened for user testuser by (uid=0)

sgallagh · 02-04-2012, 08:12 AM

It's expected that pam_unix should fail. The user isn't maintained by pam_unix (as in, they're not a local user). This is expected behavior. The PAM stack first tries to see if the user is local and authenticates them against /etc/shadow. If that fails, it moves on to trying to use SSSD. There is no issue there.

The hang in ssh on the other hand is a bit more concerning. It looks like maybe SSSD isn't responding to the pam_session_open() request properly for you. Can you paste your /etc/pam.d/password-auth file for me to look at? (sshd uses password-auth, NOT system-auth).

master_bitbucket · 02-19-2012, 01:49 PM

Here is my password-auth file

Code:

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
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

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

password    requisite     pam_cracklib.so try_first_pass retry=3 type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    sufficient    pam_sss.so use_authtok
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     required      pam_unix.so
session     optional      pam_sss.so

sgallagh · 02-21-2012, 07:16 AM

Nothing out of the ordinary there. Does logging in at a local terminal work properly? If so, it's possible that something is wrong with your SSH daemon and not with SSSD.

master_bitbucket · 02-21-2012, 08:12 AM

It does in fact look like a problem with SSH as one issue, but I think there is still an issue with SSSD.

This morning I've been building a new VM template based on CentOS 6.2 and I was following the Fedora SSSD configuration guide. I took my working sssd.conf and used the /etc/pam.d/system-auth file from the guide. I started everything up and it was working. However, I couldn't ssh to the host as a user in my configured SSSD domain (ldap). The handoff to sssd wasn't happening. I'm a little confused as to why this is. It seems like the configuration detailed in the guide should include everything that needs to be changed.

Code:

Feb 21 08:26:24 localhost sshd[2289]: pam_unix(sshd:session): session opened for user root by (uid=0)
Feb 21 08:29:31 localhost sshd[2289]: Received disconnect from 10.1.5.61: 11: disconnected by user
Feb 21 08:29:31 localhost sshd[2289]: pam_unix(sshd:session): session closed for user root
Feb 21 08:29:47 localhost sshd[2350]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.1.5.61  user=testuser
Feb 21 08:29:50 localhost sshd[2350]: Failed password for testuser from 10.1.5.61 port 64875 ssh2
Feb 21 08:29:55 localhost sshd[2350]: Failed password for testuser from 10.1.5.61 port 64875 ssh2
Feb 21 08:30:16 localhost sshd[1439]: Received signal 15; terminating.

I changed the /etc/pam.d/sshd configuration to the following and I can now login successfully but the login delay is there.

Code:

#%PAM-1.0
auth       include      system-auth
account    required     pam_nologin.so
account    include      system-auth
password   include      system-auth
session    optional     pam_keyinit.so force revoke
session    include      system-auth
session    required     pam_loginuid.so

This is changed from the system default which is

Code:

#%PAM-1.0
auth	   required	pam_sepermit.so
auth       include      password-auth
account    required     pam_nologin.so
account    include      password-auth
password   include      password-auth
# pam_selinux.so close should be the first session rule
session    required     pam_selinux.so close
session    required     pam_loginuid.so
# pam_selinux.so open should only be followed by sessions to be executed in the user context
session    required     pam_selinux.so open env_params
session    optional     pam_keyinit.so force revoke
session    include      password-auth

What am I doing wrong in the PAM SSH config? Also, I see two distinct periods of hanging in the SSSD log for my domain. I turned the debug level up to 5 and was watching when I performed a login. The attached file has the details. Notice right away there is a pause.

Thanks for all the help.

sgallagh · 02-22-2012, 06:15 AM

Well, first of all I would recommend on CentOS 6.2 that you use authconfig to set up SSSD (it handles most of the tricky bits of setting up password-auth, system-auth and nsswitch.conf for you.

You can run it from the command-line (see authconfig --help) or the graphical UI with authconfig --gtk

The nine-second gap there is a bit long, but during that period we're contacting LDAP and storing results. It may be that your LDAP server is taking a long time to respond. We need logs at level 6 or higher (preferably level 9, but that's VERY noisy) to get the details on why that's taking so long.

master_bitbucket · 02-22-2012, 07:58 AM

I ran authconfig and was able to keep my setup in place and put back the system provided /etc/pam.d/sshd and I can still login as remote users. However, the hang is still there during authentication. I have some mostly sanitized level 9 debug output from my connection attempt. Is there somewhere I can email you the log?

sgallagh · 02-23-2012, 06:38 AM

Quote:

Originally Posted by master_bitbucket

I ran authconfig and was able to keep my setup in place and put back the system provided /etc/pam.d/sshd and I can still login as remote users. However, the hang is still there during authentication. I have some mostly sanitized level 9 debug output from my connection attempt. Is there somewhere I can email you the log?

It might be best to open a bug at http://bugs.centos.org and attach the log to it (sanitized as necessary). Post the bug number here so I know where to look.

master_bitbucket · 03-09-2012, 08:43 AM

I posted a bug report and the ID is 0005585. I'll watch the bug for any updates and if you need more information I can provide.

tubulardon · 04-18-2012, 05:26 PM

Hi all, dragging this back to the stone age of the original poster (and a few others in between)... I have been stuck with trying to get a somewhat modern version of Linux authenticate with our corporate Microsoft AD Server 2003 which is not set up to use TLS or anything. Yes, I had have a discussion with our IT guys and they are aware of the problem but claim that via routing, etc etc, it isn't a problem and unfortunately I am not in a position to establish corporate policy. But... I really do want to have a Linux box that I can log into that also can work with the device drivers I need to load (and since 99% of users here are MS, IT says linux isn't supported, so I need to solve this problem myself or give up and have to use Windows... grrr!)

I'm a long time Linux user but I have never set-up LDAP authentication before so it was a new thing for me. Much of what I did was gleaned from contributors to this thread but just wanted to put down in full what worked for me. Maybe it will help others in similar situations.

So... here we go:

1) fresh install of Centos 6.2 desktop

2) yum install openldap-clients nss-util nss-pam-ldapd

3) ldapsearch -h <mydomaincontroller> -D "CN=<mybinddn string>" -w <mybinddnpasswd> -b "dc=<mydomain>,dc=<mylocal>?sub" dn
I can see my ldap server! Yay! (No point doing anything messing with authentication until you can see your server).

4) run:
authconfig --enableldap --enableldapauth --enablemkhomedir --ldapserver=<mydc1>,<mydc2> --ldapbasedn="dc=<mydomain>,dc=<mylocal>" --disableldaptls --disablesssd --disablesssdauth --enableforcelegacy --update
Not sure if all these parameters are necessary but I didn't have to edit /etc/sysconfig/authconfig by hand er anything. Note that running system-config-authentication is just scary or misleading because it will not let you set the above combination of choices.

5) edit /etc/pam_ldap.conf and /etc/nslcd.conf
pam_ldap.conf was changed to match what would work on Centos 5 with the same LDAP server.
nslcd.conf I uncommented all the Active Directory Mappings section and also added the
"binddn" and "bindpw" lines from pam_ldap.conf to the end of the file (this addition was important, without those lines, authentication wouldn't work).

6) authentication then worked! but creating home-dirs didn't. Rebooted and creating home-dirs started to work. But the first log in after a reboot was very slow and I was getting a lot of nslcd "Can't contact LDAP server: no such process" errors in /var/log/messages.
I figured that this might be that nslcd was started too early in the boot process and whatever services it was talking to weren't ready yet. Just as a hacky expedient I added "service nslcd restart" into rc.local and that worked! I didn't have the first slow first-log-in problem.

Now I appear to have LDAP authentication working on Centos 6.2 with an old and insecure no-tls AD server - which is great for me! I expect this will not work on other distros (Ubuntu, Fedora, etc).

I hope this helps but of course YMMV.

Don

sgallagh · 04-19-2012, 05:27 AM

When using Active Directory, it is a bad idea to use LDAP for authentication, in part because AD's implementation does not handle password-policy issues correctly (such as expired passwords in the grace period). It is much better instead to use Kerberos for authentication and password changes.

There is an excellent document on configuring SSSD with Active Directory at https://fedorahosted.org/sssd/wiki/C...omain%20Server that would be worth looking into for the better approach to things.

Furthermore, when having issues with SSSD, a good place to start looking is https://fedorahosted.org/sssd/wiki/FAQ

dach384 · 08-24-2012, 01:41 PM

Thx!!! I was able to solve my problem by using this command

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