Select Your Language

Infrastructure and Management

Cloud Computing

Storage

Runtimes

Integration and Automation

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

    Posted on

    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?

    by

    points

    Responses

    Red Hat LinkedIn YouTube Facebook X, formerly Twitter

    Quick Links

    Help

    Site Info

    Related Sites

    © 2026 Red Hat