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.



Spike White
_______________________________________________
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

Reply via email to