RHEL 6, Active Directory, pam, sssd, TLS and kickstart

Latest response

I am currently working on building a kickstart profile for a RHEL6 build. All our servers are still running RHEL5 at the moment.

Our RHEL5 servers authenticate to our Active Directory server using pam, nscd and kerberos. However, after just copying our base kickstart profile and changing the settings to use RHEL6, the authentication does not work.

Since it seems that RHEL is moving toward using sssd, we want to build a profile that uses sssd and pam rather than nscd. But I'm having some trouble getting this working. I'm starting out by just building a RHEL6.3 server and then getting the authentication configured. Once that's successful, I'll translate that into a kickstart script and test that.

After much Googling and such, I have not found anything that actuall works. I've found stuff that is close, but nothing that matches what we're doing. Either they're using sssd and pam to authenticate with AD without TLS or they're not using AD or they're not using sssd or they're using winbind or some such thing.

Perhaps someone here can help me figure out what we're doing wrong?

Here is how I have set up the sssd.conf file:

[sssd]
 config_file_version = 2
 services = nss, pam
 domains = LDAP

[nss]
 filter_users = root
 filter_groups = root
 reconnection_retries = 3

[pam]
 reconnection_retries =3
 offline_credentials_expiration = 2
 offline_failed_login_attempts = 3
 offline_failed_login_delay = 5

[domain/LDAP]
 debug_level = 5
 enumerate = true
 cache_credentials = true
 id_provider = ldap
 access_provider = ldap
 auth_provider = krb5
 chpass_provider = krb5
 min_id = 1000

 entry_cache_timeout = 1

 ldap_uri = ldap://server1.domain.com,ldap://server2.domain.com,ldap://server3.domain.com
 ldap_search_base = dc=domain,dc=com
 ldap_user_object_class = user
 ldap_group_object_class = group
 ldap_user_home_directory = unixHomeDirectory
 ldap_id_use_start_tls = true
 ldap-tls_reqcert = demand
 ldap-tls_cacertdir = /etc/openldap/cacerts
 ldap_default_bind_dn = cn=serviceaccount,dc=domain,dc=com
 ldap_default_authtok_type = password
 ldap_default_authtok = accountpassword
 ldap_access_filter = &(objectClass=User)
 krb5_server = domain.com
 krb5_realm = DOMAIN.COM
 krb5_aut_timeout = 15

When starting sssd, I check the sssd_LDAP.log file and I am seeing the following:

(Sun Dec  9 03:28:15 2012) [sssd[be[LDAP]]] [sdap_sys_connect_done] (4): Executing START TLS
(Sun Dec  9 03:28:15 2012) [sssd[be[LDAP]]] [sdap_connect_done] (3): START TLS result: Success(0), (null)
(Sun Dec  9 03:28:15 2012) [sssd[be[LDAP]]] [sdap_process_result] (4): ldap_result gave -1, something bad happend!
(Sun Dec  9 03:28:15 2012) [sssd[be[LDAP]]] [fo_set_port_status] (4): Marking port 389 of server 'server3.domain.com' as 'not working'
(Sun Dec  9 03:28:15 2012) [sssd[be[LDAP]]] [fo_resolve_service_send] (4): Trying to resolve service 'LDAP'
(Sun Dec  9 03:28:15 2012) [sssd[be[LDAP]]] [fo_resolve_service_send] (1): No available servers for service 'LDAP'
(Sun Dec  9 03:28:15 2012) [sssd[be[LDAP]]] [sdap_id_op_connect_done] (1): Failed to connect, going offline (5 [Input/output error])
(Sun Dec  9 03:28:15 2012) [sssd[be[LDAP]]] [be_run_offline_cb] (3): Going offline. Running callbacks.
(Sun Dec  9 03:28:16 2012) [sssd[be[LDAP]]] [remove_krb5_info_files] (5): Could not remove [/var/lib/sss/pubconf/kdcinfo.DOMAIN.COM], [2][No such file or directory]
(Sun Dec  9 03:28:16 2012) [sssd[be[LDAP]]] [remove_krb5_info_files] (5): Could not remove [/var/lib/sss/pubconf/kpasswdinfo.TRTC.COM], [2][No such file or directory]
 

Regarding the last two lines, I had found https://bugzilla.redhat.com/show_bug.cgi?id=621541, but it says that the issue there was fixed in an earlier release of sssd than we what have (we have 1.5.1-66). I'm not sure that's even relevant at the moment or if that is yet another issue that I have to deal with.

Has anyone gotten this to work?

DC
Log in to join the conversation

Responses

DS Red Hat Pro 408 points
11 December 2012 7:19 PM

Dan,

Can you outline the steps you followed to get to this point? I have found a pretty thurough writeup on authenticating against AD using SSSD in the Red Hat knowledge base below:

https://access.redhat.com/knowledge/solutions/43646

Let me know if this helps at all.

-- David Sirrine

DC Pro 539 points
11 December 2012 8:39 PM

David,

Thanks, I'll follow that article and try it out. I didn't see anything in there about TLS, but hopefully it can at least get me going in the right direction.

As for how I got to this point, it's been all manual edits thusfar. I installed sssd with yum, edited the sssd.conf file, started the service, made sure I had the cert from my AD server, etc. We've been changing debug levels trying to narrow down what's failing and why. So far, from what we can tell, we're not getting authenticated properly for some reason. We've verified that we've got the correct LDAP user and password to connect to AD with, we've verified the cert. Just not sure why it's failing.

We tried setting it up without any TLS or SSL...just ran it wide open and it worked fine, but that's not really how we want to have it set up in a production environment.

I'll try the solution you posted and then I'll post the results from that. We're trying to use a kickstart script, so I'll be using the CLI method outlined in that article.

DC Pro 539 points
11 December 2012 9:44 PM

David,

I configured the sssd.conf file according to the article you linked to. The good news is, I have a successful AD authentication!! That is a first!!

There are still a couple of things that I have to work out from here:

In AD, using UNIX utilities plugin to enable user accounts for Linux, it creates a group with the same ID as he user (e.g. if UID=10450, then GID = 10450). The downside is that AD adds the "-group" suffix to the name of the group. We'll need to strip that off when the Linux box grabs the user information. Otherwise, if I were to look at the ownership of my home directory, it shows up being owned by username.username-group instead of username.username.

In the course of working that out, I'm hoping to find exactly what it was that made the difference here to make it work. Plus, I'll want to do further testing and verify that we are using only and all the necessary options and settings to make this work exactly as desired.

Thanks so much for pointing me to that article!! I've been searching the web for weeks and I could never find a posted configuration that actually worked for us before. I'm on the home stretch!!

Henry Hutton's picture Red Hat Guru 4309 points
11 December 2012 10:09 PM

Dan, thanks for following up with your results- I voted both of your comments up as I'm glad that David jumped in and pointed you in the right direction. He's a rock star.

Also, if you have time it would be very helpful if you would vote on that particular knowledge article (https://access.redhat.com/knowledge/solutions/43646) and possibly leave a comment to add any context related to your particular situation. That'll help future customers benefit from your experience!

DC Pro 539 points
11 December 2012 10:47 PM

Ok...I found the solution for the groupname issue:

ldap_group_name = msSFU30Name

So, now here is my auth line from my kickstart file:

--enablesssd --enablesssdauth --ldapserver="server1.domain.com" --ldapbasedn="dc=domain,dc=com" --enablerfc2307bis  --krb5kdc="domain.com" --krb5adminserver="domain.com" --krb5realm="DOMAIN.COM" --disableforcelegacy --enablelocauthorize  --enablemkhomedir

And this is my current /etc/sssd/sssd.conf file:

[domain/LDAP]

 cache_credentials = True
 enumerate = true

 id_provider = ldap
 auth_provider = krb5
 chpass_provider = krb5
 min_id = 10000

 ldap_default_bind_dn = cn=serviceaccount,dc=domain,dc=com
 ldap_default_authtok_type = password
 ldap_default_authtok = accountpassword

 ldap_schema = rfc2307bis
 ldap_user_object_class = person
 ldap_group_object_class = group
 ldap_group_name = msSFU30Name
 ldap_user_gecos = displayName
 ldap_user_home_directory = unixHomeDirectory
 ldap_force_upper_case_realm = true

 ldap_uri = ldap://server1.domain.com
 ldap_tls_cacertdir = /etc/openldap/cacerts
 ldap_id_se_start_tls = true

 krb5_realm = DOMAIN.COM
 krb5_kpasswd = domain.com
 krb5_kdcip = domain.com

[sssd]
 services = nss, pam
 config_file_version = 2

 domains = LDAP

[nss]
 filter_users = root
 filter_groups = root
 reconnection_retries = 3

[pam]
 reconnection_retries = 3
 offline_credentials_expiration = 2
 offline_failed_login_attempts = 3
 offline_failed_login_delay = 5

[ssh]

For our krb5_kpasswd and krb5_kdcip values, I don't think we use a standard port number, so our file would have these values as:

krb5_kpasswd = domain.com:port
krb5_kdcip = domain.com:port

That may not be relevant for many people, but it's something to check if you can't get this working correctly...check with your AD admin (or look at how an existing, working server is configured) in case you need to specify the port for kerberos.

The above sssd.conf file is saved on our Satellite in one of the default configuration channels, so it gets pulled down during the kickstart build.

I think the next thing on my list is going to be to look into [ssh] and [sudo] and see if that can help streamline things for us as well. In the meantime, we now have a working kickstart RHEL 6.3 profile.

Thanks again to all who helped out with this!

DC Pro 539 points
13 December 2012 6:01 PM

Another update that may be of use to note...

After going back to this in order to determine why my original config did not work, I found that there were two things that seemed significant:

First, I did not already have a copy of the AD cert on my system in the /etc/openldap/cacerts directory. Nor was there a hash link to the cert. So, I had to copy the cert to that directory and then run the commands:

# openssl x509 -noout -hash -in <cert file>
<cert hash>

# ln -s <cert file> <cert hash>.0

The second thing I noticed after going back over my original sssd.conf file as posted above was that there were a couple values related to the tls cert that I accidentally had used the "-" character instead of the "_" character. One of those was the ldap_tls_cacertdir where I had put ldap-tls_cacertdir.

I went back to the drawing board, made sure I had my cert and hash link in place, fixed the typos in my sssd.conf file and, viola!! It worked just fine. Apparently, I was very close when I first started.

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.