Hide Forgot
SSSD now enables fetching autofs maps from an AD server You can now use the `autofs_provider=ad` setting in the [domain] section of the `/etc/sssd/sssd.conf` file. With this setting, the System Security Services Daemon (SSSD) fetches *autofs* maps from an Active Directory (AD) server. Previously, when it was required to store *autofs* maps in AD, the AD server administrator had to use the `autofs_provider=ldap` setting and manually configure the LDAP provider, including the bind method, search base, and other parameters. With this update, it is only required to set `autofs_provider=ad` in `sssd.conf`. Note that SSSD expects the *autofs* maps stored in AD to follow the format defined in RFC2307: https://tools.ietf.org/html/rfc2307
Description of problem: I am unable to use AD provider for autofs map storage as of sssd version 1.9.2. Looks like 'ad' provider is supported for everthing but autofs. Ondrej
Upstream ticket: https://fedorahosted.org/sssd/ticket/1632
Further analysis shows that: autofs_provider = ad is not valid configuration, but we could use autofs_provider = ldap ldap_sasl_mech = GSSAPI which works just fine. So, ideally we should be able to use 'autofs_provider = ad' which should work as a synonym for the two config lines above.
This is still an issue as of: sssd-1.9.2-6.upstream_1_9_3.el6_3.x86_64 I still have to specify the ldap_sasl_mech parameter to make it working
Ondrej, Sorry we are running out of time for the release we planned to address this issue in. Since there is a workaround we do not think it is a paressing issue. We will pick it up as soon as we can. Thanks Dmitri
Not modified, the bot got confused
*** Bug 1278694 has been marked as a duplicate of this bug. ***
To reproduce, load automounter entries into AD LDAP. You can use this blog post: https://ovalousek.wordpress.com/2015/10/15/enable-kerberized-nfs-with-sssd-and-active-directory/ Then, on the sssd side, enable the autofs responder (the AD autofs provider is enabled automatically when AD provider is loaded). Finally, run automounter -m to verify sssd was able to load the autofs maps from AD.
Versions: ======== Red Hat Enterprise Linux Workstation release 7.3 Beta (Maipo) sssd-ldap-1.14.0-27.el7.x86_64 sssd-client-1.14.0-27.el7.x86_64 sssd-krb5-common-1.14.0-27.el7.x86_64 sssd-common-1.14.0-27.el7.x86_64 sssd-ipa-1.14.0-27.el7.x86_64 sssd-ad-1.14.0-27.el7.x86_64 sssd-common-pac-1.14.0-27.el7.x86_64 sssd-1.14.0-27.el7.x86_64 sssd-krb5-1.14.0-27.el7.x86_64 sssd-proxy-1.14.0-27.el7.x86_64 python-sssdconfig-1.14.0-27.el7.noarch libsss_nss_idmap-1.14.0-27.el7.x86_64 libsss_idmap-1.14.0-27.el7.x86_64 libsss_autofs-1.14.0-27.el7.x86_64 Windows ======= Windows 2012 R2 Domain: Juno.test Step1: Add automount maps and entries in Windows under ou=Automount,dc=juno,dc=test using below ldif file(autofs.ldif) # mount, example.com dn: ou=automount,dc=juno,dc=test ou: automount objectClass: organizationalUnit # auto.master, automount, CENTAUR.TEST dn: CN=auto.master,OU=automount,dc=juno,dc=test objectClass: top objectClass: nisMap cn: auto.master nisMapName: auto.master # /-, auto.master, mount, example.com dn: cn=/-,cn=auto.master,ou=automount,dc=juno,dc=test objectClass: nisObject objectClass: top cn: /- nisMapEntry: auto.direct nisMapName: auto.master # /home, auto.master, mount, example.com dn: cn=/home,cn=auto.master,ou=automount,dc=juno,dc=test objectClass: nisObject objectClass: top cn: /home nisMapEntry: auto.home nisMapName: auto.master # auto.direct, mount, example.com dn: cn=auto.direct,ou=automount,dc=juno,dc=test objectClass: nisMap objectClass: top cn: auto.direct nisMapName: auto.direct # project1 dn: cn=/project1,cn=auto.direct,ou=automount,dc=juno,dc=test objectClass: nisObject objectClass: top cn: /project1 nisMapEntry: -fstype=nfs,rw nfs-server.example.org:/project1 nisMapName: auto.direct # project1 dn: cn=/project2,cn=auto.direct,ou=automount,dc=juno,dc=test objectClass: nisObject objectClass: top cn: /project2 nisMapEntry: -fstype=nfs,rw nfs-server.example.org:/project2 nisMapName: auto.direct # auto.home, mount, example.com dn: cn=auto.home,ou=automount,dc=juno,dc=test objectClass: nisMap objectClass: top nisMapName: auto.home # /, auto.home, mount, example.com dn: cn=/,cn=auto.home,ou=automount,dc=juno,dc=test objectClass: nisObject objectClass: top cn: / nisMapName: auto.home nisMapEntry: -rw nfs-server.example.org:/home/& $ldapadd -x -D "cn=Administrator,cn=Users,dc=juno,dc=test" -w Secret123 -h winsrv1.juno.test -f autofs.ldif NFS Server Setup ================ 1. Configure another RHEL7 system as NFS Server providing /project1 and /project2 as nfs shares /project1 *.*(rw,sync,fsid=0) /project2 *.*(rw,sync,fsid=0) 2. Restart NFS service $ systemctl start nfs $ exportfs -a 3. Create project1 and prjoject2 directories $mkdir /project1 $mkdir /project2 $touch /project1/foo1 $touch /project2/foo2 RHEL7.3 Client Setup =================== 1. Join RHEL7.3 System to Windows AD using realm command $realm join --membership-software=adcli juno.test [sssd] domains = juno.test config_file_version = 2 services = nss, pam [domain/juno.test] ad_domain = juno.test krb5_realm = JUNO.TEST realmd_tags = manages-system joined-with-adcli cache_credentials = True id_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = True use_fully_qualified_names = True fallback_homedir = /home/%u@%d access_provider = ad 2. Edit /etc/sssd/sssd.conf to enable autofs service in "sssd" section [sssd] domains = juno.test config_file_version = 2 services = nss, pam, autofs [domain/juno.test] ad_domain = juno.test krb5_realm = JUNO.TEST realmd_tags = manages-system joined-with-adcli cache_credentials = True id_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = True use_fully_qualified_names = True fallback_homedir = /home/%u@%d access_provider = ad debug_level = 9 3. Edit /etc/nsswitch.conf and enable sss lookup for automount automount: files sss 4. Restart autofs service and sssd service $ systemctl restart autofs $ systemctl restart sssd 5. Verify sssd_autofs service is running root 17215 1 0 19:25 ? 00:00:00 /usr/sbin/sssd -D -f root 17216 17215 0 19:25 ? 00:00:00 /usr/libexec/sssd/sssd_be --domain juno.test --uid 0 --gid 0 --debug-to-files root 17217 17215 0 19:25 ? 00:00:00 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --debug-to-files root 17218 17215 0 19:25 ? 00:00:00 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --debug-to-files root 17219 17215 0 19:25 ? 00:00:00 /usr/libexec/sssd/sssd_autofs --uid 0 --gid 0 --debug-to-files 6. Run automount -m [root@dhcp223-163 project1]# automount -m autofs dump map information =========================== global options: none configured Mount point: /misc source(s): instance type(s): file map: /etc/auto.misc cd | -fstype=iso9660,ro,nosuid,nodev :/dev/cdrom Mount point: /net source(s): type: hosts winsrv1.juno.test | (null) dhcp223-2.pnq.redhat.com | (null) localhost | (null) Mount point: /- source(s): instance type(s): sss map: auto.direct /project2 | -fstype=nfs,rw nfs-server.example.org:/project2 /project1 | -fstype=nfs,rw nfs-server.example.org:/project1 Mount point: /home source(s): instance type(s): sss map: auto.home * | -rw nfs-server.example.org:/home/& 6. Access /project1 from the RHEL7.3 client system [root@dhcp223-163 ~]# cd /project1 [root@dhcp223-163 project1]# ll total 0 -rw-r--r--. 1 root root 0 Aug 23 19:30 foo1
I would (for sake of completeness) also say that in this case SSSD expect automount maps are in AD stored in the RFC2307 format - contrary to users and groups where SSSD refers to RFC2307bis
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2016-2476.html