Sssd experts,

This is all on RHEL7.

I have sssd properly authenticating against AD for my multi-domain forest.  All good – even cross-domain auth (as long as I don’t use tokengroups.)  Our company’s AD implementation is RFC2307bis schema-extended.

Now – for complicated reasons – I’m told I need to get nis automaps and nis netgroups in AD and also working on the clients (via sssd) also.

As a first testing step, I’ve stood up an openLDAP server on another RHEL7 server.  And schema extended it with RFC 2307 bis.    

http://bubblesorted.raab.link/content/replace-nis-rfc2307-rfc2307bis-schema-openldap

I added an initial automap.

When I query via ldapsearch, all looks good:

[root@spikerealmd02 sssd]# ldapsearch -LLL -x -H ldap://austgcore17.us.example.com -b 'ou=automount,ou=admin,dc=itzgeek,dc=local' -s sub -D 'cn=ldapadm,dc=itzgeek,dc=local' -w ldppassword 'objectClass=automountMap'

dn: automountMapName=auto.master,ou=automount,ou=admin,dc=itzgeek,dc=local

objectClass: top

objectClass: automountMap

automountMapName: auto.master

 

dn: automountMapName=auto.home,ou=automount,ou=admin,dc=itzgeek,dc=local

objectClass: top

objectClass: automountMap

automountMapName: auto.home

 

[root@spikerealmd02 sssd]# ldapsearch -LLL -x -H ldap://austgcore17.us.example.com -b 'ou=automount,ou=admin,dc=itzgeek,dc=local' -s sub -D 'cn=ldapadm,dc=itzgeek,dc=local' -w ldppassword 'objectClass=automount'

dn: automountKey=/home2,automountMapName=auto.master,ou=automount,ou=admin,dc=

 itzgeek,dc=local

objectClass: top

objectClass: automount

automountKey: /home2

automountInformation: ldap:automountMapName=auto.home,ou=automount,ou=admin,dc

 =itzgeek,dc=local --timeout=60 --ghost

 

dn: automountKey=/,automountMapName=auto.home,ou=automount,ou=admin,dc=itzgeek

 ,dc=local

objectClass: top

objectClass: automount

automountKey: /

automountInformation: -fstype=nfs,rw,hard,intr,nodev,exec,nosuid,rsize=8192,ws

 ize=8192 austgcore17.us.example.com:/export/&

 

[root@spikerealmd02 sssd]#

 

Next, the sssd client configuration. 

In my good sssd client’s sssd.conf file, I added “autofs” to my services line and added an “autofs” section.  That is,  I have changed my /etc/sssd/sssd.conf file as so:

[sssd]

services = nss,pam,autofs

[autofs]

debug_level = 9

autofs_provider = ldap

ldap_uri= ldap://austgcore17.us.example.com

ldap_schema = rfc2307bis

ldap_default_bind_dn = cn=ldapadm,dc=itzgeek,dc=local

ldap_default_authtok = ldppassword

ldap_autofs_search_base = ou=automount,ou=admin,dc=itzgeek,dc=local

ldap_autofs_map_object_class = automountMap

ldap_autofs_map_name = automountMapName

ldap_autofs_entry_object_class = automount

ldap_autofs_entry_key = automountKey

ldap_autofs_entry_value = automountInformation

 

[nss]

debug_level = 9

 

I appended sss to automount line in /etc/nsswitch.conf file:

 

automount:  files sss

 

 

Yet, when I try to restart autofs service it (eventually) times out:

 

 [root@spikerealmd02 sssd]#  systemctl restart sssd

[root@spikerealmd02 sssd]# systemctl restart autofs

Job for autofs.service failed because a timeout was exceeded. See "systemctl status autofs.service" and "journalctl -xe" for details.

 

Journalctl –xe reports this:

 

Dec 03 11:14:09 spikerealmd02.us.example.com [sssd[ldap_child[9653]]][9653]: Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]: Preauthentication failed. Unable to create GSSAPI-encrypted LDAP connection.

Dec 03 11:14:15 spikerealmd02.us.example.com [sssd[ldap_child[9680]]][9680]: Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]: Preauthentication faile

Dec 03 11:14:22 spikerealmd02.us.example.com systemd[1]: autofs.service start operation timed out. Terminating.

Dec 03 11:14:22 spikerealmd02.us.example.com systemd[1]: Failed to start Automounts filesystems on demand.

-- Subject: Unit autofs.service has failed

-- Defined-By: systemd

-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel

--

-- Unit autofs.service has failed.

--

-- The result is failed.

Dec 03 11:14:22 spikerealmd02.us.example.com systemd[1]: Unit autofs.service entered failed state.

Dec 03 11:14:22 spikerealmd02.us.example.com systemd[1]: autofs.service failed.

Dec 03 11:14:22 spikerealmd02.us.example.com polkitd[897]: Unregistered Authentication Agent for unix-process:9073:241010 (system bus :1.132, object path /org/freedeskt

 

 

/var/log/sssd/ssd_nss.log looks like this:

 

(Mon Dec  3 11:11:13 2018) [sssd[autofs]] [sysdb_get_certmap] (0x0020): Failed to read certmap config, skipping.

(Mon Dec  3 11:11:13 2018) [sssd[autofs]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x55f7263a1fc0

 

(Mon Dec  3 11:11:13 2018) [sssd[autofs]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x55f7263a2080

 

(Mon Dec  3 11:11:13 2018) [sssd[autofs]] [ldb] (0x4000): Running timer event 0x55f7263a1fc0 "ltdb_callback"

 

(Mon Dec  3 11:11:13 2018) [sssd[autofs]] [ldb] (0x4000): Destroying timer event 0x55f7263a2080 "ltdb_timeout"

 

(Mon Dec  3 11:11:13 2018) [sssd[autofs]] [ldb] (0x4000): Ending timer event 0x55f7263a1fc0 "ltdb_callback"

 

(Mon Dec  3 11:11:13 2018) [sssd[autofs]] [sysdb_get_certmap] (0x0400): No certificate maps found.

 

What is wrong?  BTW, for now – I don’t care about a GSSAPI SASL LDAP binding;  a simple binding is what I want.

 

BTW, I have not modified the /etc/autofs.conf file.  I considered this, but it seems that if I did – it’d be bypassing nss / sssd.  Also, I’d have another SASL creds hanging out there that’d I’d have to periodically rotate on all clients, instead of relying on SSSD’s machine account that’s auto-rotated every 30 days.