Thanks.

I didn't realize that to have autofs query against a new LDAP backend, I had to invent another "domain".

So now I have 3 AD domains -- AMER, EMEA and APAC -- as well as one LDAP domain (LDAP).  In order
for the AD domains to not get queried for autofs content, I have to set:

    autofs_provider = none

in each of those AD domains.

I still don't have it perfect;  my LDAP rfc2307bis structure isn't perfect.  But it's close enough that automount -m shows me LDAP-based automount maps, as well as the files-based automount maps.

Thanks all.
Spike

On Mon, Dec 10, 2018 at 2:38 AM Jakub Hrozek <jhrozek@redhat.com> wrote:
On Wed, Dec 05, 2018 at 12:28:18PM -0600, Spike White wrote:
> 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

All the options below should be specified in the domain section, not the
autofs section. The autofs responder only talks to the automounter
'client' (e.g. when you run automount -m), not to LDAP. The only process
in SSSD that ever talks to LDAP is sssd_be.

Running automount -m is also IMO a good way to test the config.

>
> 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.

The domain log would tell you more, i.e. what principal did sssd_be try
to authenticate, but the tl;dr is that sssd_be couldn't authenticate to
the LDAP server.

>
> …
>
> 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.


Strictly speaking, automounter doesn't go through libc's NSS, just uses
the same config file (same goes for sudo..).

But yes, you don't need to touch the autofs config file, just make sure
'sss' is present in the automounter line in nsswitch.conf
_______________________________________________
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave@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