RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 874985 - [RFE] AD provider support for automount lookups
Summary: [RFE] AD provider support for automount lookups
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: SSSD Maintainers
QA Contact: Steeve Goveas
Aneta Šteflová Petrová
URL:
Whiteboard:
: 1278694 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-11-09 09:18 UTC by Ondrej Valousek
Modified: 2020-05-02 17:05 UTC (History)
8 users (show)

Fixed In Version: sssd-1.14.0-0.2.beta1.el7
Doc Type: Enhancement
Doc Text:
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
Clone Of:
Environment:
Last Closed: 2016-11-04 07:08:37 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github SSSD sssd issues 2674 0 None closed [RFE] Unable to use AD provider for automount lookups 2021-01-06 20:28:44 UTC
Red Hat Product Errata RHEA-2016:2476 0 normal SHIPPED_LIVE sssd bug fix and enhancement update 2016-11-03 14:08:11 UTC

Description Ondrej Valousek 2012-11-09 09:18:37 UTC 
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
Comment 2 Jakub Hrozek 2012-11-09 09:43:51 UTC 
Upstream ticket:
https://fedorahosted.org/sssd/ticket/1632
Comment 3 Ondrej Valousek 2012-11-12 14:28:34 UTC 
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.
Comment 5 Ondrej Valousek 2012-12-27 09:41:46 UTC 
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
Comment 6 Dmitri Pal 2013-05-13 13:28:05 UTC 
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
Comment 7 Jakub Hrozek 2016-03-28 20:43:45 UTC 
Not modified, the bot got confused
Comment 8 Jakub Hrozek 2016-04-29 08:36:38 UTC 
*** Bug 1278694 has been marked as a duplicate of this bug. ***
Comment 9 Jakub Hrozek 2016-06-21 10:14:38 UTC 
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.
Comment 11 Niranjan Mallapadi Raghavender 2016-08-23 14:36:35 UTC 
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
Comment 13 Ondrej 2016-10-05 12:34:41 UTC 
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
Comment 17 errata-xmlrpc 2016-11-04 07:08:37 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.