Chapter 11. Policy: Using Automount

Automount is a way of making directories on different servers available, automatically, when requested by a user. This works exceptionally well within an IdM domain since it allows directories on clients within the domain to be shared easily. This is especially important with user home directories (Section 5.1, "Setting up User Home Directories").

In IdM, automount works with the internal LDAP directory and, if it is configured, DNS services.

11.1. About Automount and IdM

Automount is a way to manage, organize, and access directories across multiple systems. Automount automatically mounts a directory whenever that resource is requested. Automount also provides a coherent structure to the way that these directories are organized. Every single directory, or mount point is called a key. Multiple keys that are grouped together are a map, and maps are associated according to their physical or conceptual location.

The base configuration file for autofs is the auto.master file in the /etc/ directory. There can be multiple auto.master configuration files in separate server locations, if necessary.

When autofs is configured on a server and that server is a client in an IdM domain, then all of the configuration information for automount is stored in the IdM directory. Rather than being stored in separate text files, the autofs configuration - maps, locations, and keys - are stored as LDAP entries. For example, the default map file, auto.master, is stored as:

dn: automountmapname=auto.master,cn=default,cn=automount,dc=example,dc=comobjectClass: automountMapobjectClass: topautomountMapName: auto.master

IMPORTANT

Identity Management does not set up or configure autofs. That must be done separately. Identity Management works with an existing autofs deployment.

Each new location is added as a container entry under cn=automount,dc=example,dc=com, and each map and each key are stored beneath that location.

As with other IdM domain services, automount works with IdM natively. The automount configuration can be managed by IdM tools:

Locations, using ipa automountlocation* commands
Both direct and indirect maps, using ipa automountmap* commands
Keys, using ipa automountkey* commands

For automount to work within the IdM domain, the NFS server must be configured as an IdM client. Configuring NFS itself is covered in the Red Hat Enterprise Linux Storage Administration Guide.

11.2. Configuring Automount

IMPORTANT

Identity Management does not set up or configure autofs. That must be done separately, as described in these procedures. Identity Management works with an existing autofs deployment.

TIP

Test that the /home directory can be mounted from the command line successfully before changing the automount configuration. Making sure that NFS is already working properly makes it easier to troubleshoot any potential IdM automount configuration errors later.

11.2.1. Configuring autofs on Red Hat Enterprise Linux

Edit the /etc/sysconfig/autofs file to specify the schema attributes that autofs searches for:

## Other common LDAP naming#MAP_OBJECT_CLASS="automountMap"ENTRY_OBJECT_CLASS="automount"MAP_ATTRIBUTE="automountMapName"ENTRY_ATTRIBUTE="automountKey"VALUE_ATTRIBUTE="automountInformation"

Specify the LDAP configuration. There are two ways to do this. The simplest is to let the automount service discover the LDAP server and locations on its own:
```
LDAP_URI="ldap:///dc=example,dc=com"
```
Alternatively, explicitly set which LDAP server to use and the base DN for LDAP searches:
```
LDAP_URI="ldap://ipa.example.com"SEARCH_BASE="cn=location,cn=automount,dc=example,dc=com"
```
Note
The default value for location is default. If additional locations are added (Section 11.5, "Configuring Locations"), then the client can be pointed to use those locations, instead.
Edit the /etc/autofs_ldap_auth.conf file so that autofs allows client authentication with the IdM LDAP server. Change authrequired to yes and set the principal to the Kerberos host principal:
```
<autofs_ldap_sasl_conf usetls="no" tlsrequired="no" authrequired="yes" authtype="GSSAPI" clientprinc="host/server.example.com@EXAMPLE COM"  />
```
If necessary, run klist -k to get the exact host principal information.
Check the /etc/nssswitch.conf file, so that LDAP is listed as a source for automount configuration:
```
automount: files ldap
```
Restart autofs:
```
# service autofs restart
```
Test the configuration by listing a user's /home directory:
```
# ls /home/userName
```
If this does not mount the remote file system, check the /var/log/messages file for errors. If necessary, increase the debug level in the /etc/sysconfig/autofs file by setting the LOGGING parameter to debug.

TIP

If there are problems with automount, then cross-reference the automount attempts with the 389 Directory Server access logs for the IdM instance, which will show the attempted access, user, and search base.

It is also simple to run automount in the foreground with debug logging on.

automount -f -d

This prints the debug log information directly, without having to cross-check the LDAP access log with automount's log.

11.3. Setting up a Kerberized NFS Server

Identity Management can be used to set up a Kerberized NFS server.

NOTE

The NFS server does not need to be running on Red Hat Enterprise Linux.

11.3.1. Setting up a Kerberized NFS Server

Obtain a Kerberos ticket before running IdM tools.
```
[jsmith@server ~]$ kinit admin
```
If the NFS host machine has not been added as a client to the IdM domain, then create the host entry. See Section 6.2, "Adding Host Entries".
Create the NFS service entry in the IdM domain. For example:
```
[jsmith@server ~]$ ipa service-add nfs/nfs-server.example.com
```
For more information, see Section 6.5.1, "Adding and Editing Service Entries and Keytabs".
Generate an NFS service keytab for the NFS server using the ipa-getkeytab command.
The NFS server may be on a Red Hat Enterprise Linux machine in the IdM domain or a different Unix machine. For a Red Hat Enterprise Linux machine, the ipa-getkeytab command can be run on the NFS server machine. Otherwise, the ipa-getkeytab command should be run on a Red Hat Enterprise Linux machine in the IdM domain and then copied over to the NFS server.
If ipa-getkeytab command is run on the NFS server, then save the keys directly to the host keytab. For example:
```
[jsmith@server ~]$ ipa-getkeytab -s server.example.com -p nfs/nfs-server.example.com -k /etc/krb5.keytab
```
For a Red Hat Enterprise Linux machine, that's all you need to do.
NOTE
Only DES keys are supported on Red Hat Enterprise Linux 5.
When generating keys to copy over to another system, then generate the key but do not save it in the host keytab. The key must be added separately to the keytab after it is copied to the NFS server:
1. Save the keytab to a temporary file. For example:
```
[jsmith@server ~]$ ipa-getkeytab -s server.example.com -p nfs/nfs-server.example.com -k /tmp/nfs.keytab
```
2. Copy the keytabs over to the NFS server.
3. Set the file permissions to 0700.
4. Add the service key to the keytab file.
```
[root@nfs-server ~]#  (  echo rkt /tmp/nfs.keytab; echo wkt /etc/krb5.keytab) |ktutil
```
TIP
Verify that the NFS service has been properly configured in IdM, with its keytab, by checking the service entry:
```
[jsmith@server ~]$ ipa service-show nfs/ipaclient2.example.comPrincipal: NFS/[email protected]: True
```

Install the NFS packages. For example:

[root@nfs-server ~]# yum install nfs-utils

Configure weak crypto support. This is required for every NFS client if any client (such as a Red Hat Enterprise Linux 5 client) in the domain will use older encryption options like DES.

Edit the krb5.conf file to allow weak crypto.

[root@nfs-server ~]# vim /etc/krb5.confallow_weak_crypto = true

Update the IdM server Kerberos configuration to support the DES encryption type.

[jsmith@ipaserver ~]$ ldapmodify -x -D "cn=directory manager" -w password -h ipaserver.example.com -p 389dn: cn=EXAMPLEREALM,cn=kerberos,dc=example,dc=comchangetype: modifyadd: krbSupportedEncSaltTypeskrbSupportedEncSaltTypes: des-cbc-crc:normal-add: krbSupportedEncSaltTypeskrbSupportedEncSaltTypes: des-cbc-crc:special-add: krbDefaultEncSaltTypeskrbDefaultEncSaltTypes: des-cbc-crc:special

Edit the NFS server configuration to use NFSv4 security by uncommenting the SECURE_NFS line.
```
[root@nfs-server ~]# vim /etc/sysconfig/nfsSECURE_NFS="yes"
```
If the NFS server and client are in different DNS domains, then configure the NFS domain.
```
[root@nfs-server ~]# vim /etc/idmapd.confDomain = example.com
```
Edit the /etc/exports file and add the Kerberos information:
```
/export  *(rw,sec=sys:krb5:krb5i:krb5p)
```

Restart the NFS server.

[root@nfs-server ~]# service nfs restart

Configure the NFS server as an NFS client, following the directions in Section 11.3.2, "Setting up a Kerberized NFS Client".

11.3.2. Setting up a Kerberized NFS Client

Obtain a Kerberos ticket before running IdM tools.
```
[jsmith@server ~]$ kinit admin
```
If the NFS client is not enrolled as a client in the IdM domain, then set up the required host entries, as described in Section 6.2, "Adding Host Entries".
Generate an NFS service keytab for the NFS client using the ipa-getkeytab command.
The NFS client may be on a Red Hat Enterprise Linux machine in the IdM domain or a different Unix machine. For a Red Hat Enterprise Linux machine, the ipa-getkeytab command can be run on the NFS client machine. Otherwise, the ipa-getkeytab command should be run on a Red Hat Enterprise Linux machine in the IdM domain and then copied over to the NFS client.
If ipa-getkeytab command is run on the NFS client, then save the keys directly to the host keytab. For example:
```
[jsmith@server ~]$ ipa-getkeytab -k /etc/krb5.keytab -p host/[email protected]
```
For a Red Hat Enterprise Linux machine, that's all you need to do.
When generating keys to copy over to another system, then generate the key but do not save it in the host keytab. The key must be added separately to the keytab after it is copied to the NFS server:
1. Save the keytab to a temporary file. For example:
```
[jsmith@server ~]$ ipa-getkeytab -p host/[email protected] -k /tmp/nfs.keytab
```
2. Copy the keytabs over to the NFS client.
3. Set the file permissions to 0700.
4. Add the service key to the keytab file.
```
[root@nfs-client-server ~]# ( echo rkt /root/nfs-client.keytab; echo wkt /etc/krb5.keytab) |ktutil
```
Edit the NFS common configuration to enable client-side secure NFS, by uncommenting the SECURE_NFS line.
```
[root@nfs-client-server ~]# vim /etc/sysconfig/nfsSECURE_NFS="yes"
```
If the NFS server and client are in different DNS domains, then configure the NFS domain. The idmapd.conf must be the same on the NFS client as it is on the NFS server.
```
[root@nfs-client-server ~]# vim /etc/idmapd.confDomain = example.com
```

Start the GSS daemon.

[root@nfs-client-server ~]# service rpcgssd start[root@nfs-client-server ~]# service rpcbind start[root@nfs-client-server ~]# service rpcidmapd start

Mount the directory.

[root@nfs-client-server ~]# echo "$NFSSERVER:/this /mnt/this nfs4 sec=krb5i,rw,proto=tcp,port=2049"  >>/etc/fstab[root@nfs-client-server ~]# mount -av

11.4. Configuring Kerberized CIFS

While Identity Management and Samba can be integrated together, that is not done automatically. The IdM server needs to be configured to create and manage Samba groups, and then the Red Hat Enterprise Linux machine can be configured to use a Kerberos-aware CIFS client.

11.4.1. Setting up Samba Groups in IdM

IdM is not configured to create Samba groups by default. It is possible to change the IdM configuration so that groups are automatically configured as Samba groups that work with the CIFS server.

NOTE

IdM works with a Samba file server, not a Samba domain controller.

Obtain the Samba Windows security ID (SID) for the Samba domain. This ID is used as part of the IdM group configuration.
```
[root@ipaserver ~]# net getlocalsidSID for EXAMPLE domain  is: S-1-2-3-4
```
Obtain a Kerberos ticket before editing the IdM configuration.
```
[root@server ~]# kinit admin
```
Add two Samba-related object classes, sambaSAMAccount for users and sambaGroupMapping for groups, to the IdM configuration entry.
IMPORTANT
The object class list is the complete list of object classes for the user and group entries. Be sure to include all existing object classes in the list along with the new attribute, or new entries will be created with the wrong object classes and will not work in the IdM domain.
Add sambaSAMAccount for users:
```
$ ipa config-mod --userobjectclasses=top,person,organizationalperson,inetorgperson,inetuser,posixaccount, krbprincipalaux,krbticketpolicyaux,ipaobject,sambaSAMAccount
```
Add sambaGroupMapping for groups:
```
$ ipa config-mod --groupobjectclasses=top,groupofnames,nestedgroup,ipausergroup,ipaobject,sambaGroupMapping
```
Unique Samba IDs must be created for groups as they are added, with the Samba file server SID used as a prefix to identify the CIFS domain. This is configured by creating a Distributed Numeric Attribute Plug-in instance in the internal 389 Directory Server instance for the IdM server.
The DNA Plug-in configuration includes:
- The attribute to create on entries (dnatype).
- The entries to add the attribute to, based on an LDAP filter (dnafilter).
- The Samba file server SID to prepend to the attribute numbers (dnaprefix); this include a hyphen on the end of the number.
- The directory suffix to check for matching entries (dnascope); since this includes both users and groups, it should be the root suffix.
- The number to use to begin counting Samba IDs (dnanextvalue).
```
[root@server ~]# ldapadd -x -D "cn=Directory Manager" -w secret dn: cn=SambaGroupSid,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=configobjectClass: topobjectClass: extensibleObjectcn: SambaSiddnatype: sambaSIDdnaprefix: S-1-2-3-4-dnafilter: (|(objectclass=sambasamaccount)(objectclass=sambagroupmapping))dnascope: dc=example,dc=comdnanextvalue: 1
```
The DNA Plug-in is described in the Red Hat Directory Server 9.0 Administrator's Guide.
Every Samba groups requires a sambaGroupType attribute. Since this value is always 4, this can be defined automatically by using a class of service (CoS) to supply the value. A CoS uses a template entry with a defined value and then automatically applies that value to all entries within the scope of the template.
1. Create the CoS definition entry in the groups subtree (cn=groups,cn=accounts,dc=example,dc=com), so that all the group entries are updated with the sambaGroupType attribute.
```
[root@ipaserver ~]# ldapadd -x -D "cn=directory manager" -w secret dn: cn=SambaCoS,cn=groups,cn=accounts,dc=example,dc=comobjectclass: topobjectclass: cosSuperDefinitionobjectclass: cosPointerDefinitioncosTemplateDn: cn=SambaCoS,cn=ipaConfig,dc=etc,dc=example,dc=comcosAttribute: sambaGrouptType
```
2. Create the CoS template entry, which defines the sambaGroupType attribute. This is done outside the groups subtree, such as the cn=ipaConfig subtree.
```
[root@ipaserver ~]# ldapadd -x -D "cn=directory manager" -w secret dn: cn=SambaCoS,cn=ipaConfig,dc=etc,dc=example,dc=comchangetype: addobjectclass: topobjectclass: extensibleObjectobjectclass: cosTemplatesambaGroupType: 4
```
Classes of service are described in the Red Hat Directory Server 9.0 Administrator's Guide.

11.4.2. Configuring the CIFS Client

mount.cifs is described in detail in its manpage.

Obtain a Kerberos ticket before running IdM tools.
```
[jsmith@server ~]$ kinit admin
```
If the CIFS client is not enrolled as a client in the IdM domain, then set up the required host entries, as described in Section 6.2, "Adding Host Entries".
Generate an CIFS service keytab for the CIFS client using the ipa-getkeytab command, and save the keys directly to the host keytab. For example:
```
[jsmith@server ~]$ ipa-getkeytab -k /etc/krb5.keytab -p host/[email protected]
```
If the CIFS server and client are in different DNS domains, then configure the CIFS domain. The idmapd.conf must be the same on the CIFS client as it is on the CIFS server.
```
[root@cifs-client ~]# vim /etc/idmapd.confDomain = example.com
```

Start the GSS daemon.

[root@cifs-client ~]# service rpcgssd start[root@cifs-client ~]# service rpcbind start[root@cifs-client ~]# service rpcidmapd start

Edit the fstab file.

[root@cifs-client ~]# vim /etc/fstab//cifs-client.example.com /mnt/this cifs sec=krb5i,rw,proto=tcp,port=2049

Mount the directory.
```
[root@cifs-client ~]# mount -t cifs
```

11.5. Configuring Locations

A location is a set of maps, which are all stored in auto.master, and a location can store multiple maps. The location entry only works as a container for map entries; it is not an automount configuration in and of itself.

IMPORTANT

Identity Management does not set up or configure autofs. That must be done separately. Identity Management works with an existing autofs deployment.

11.5.1. Configuring Locations through the Web UI

Click the Policy tab.
Click the Automount subtab.
Click the Add link at the top of the list of automount locations.
Enter the name for the new location.
Click the Add and Edit button to go to the map configuration for the new location. Create maps, as described in Section 11.6.1.1, "Configuring Direct Maps from the Web UI" and Section 11.6.2.1, "Configuring Indirect Maps from the Web UI".

11.5.2. Configuring Locations through the Command Line

To create a map, using the automountlocation-add and give the location name.

$ ipa automountlocation-add location

For example:

$ ipa automountlocation-add raleigh----------------------------------Added automount location "raleigh"----------------------------------  Location: raleigh

When a new location is created, two maps are automatically created for it, auto.master and auto.direct. auto.master is the root map for all automount maps for the location. auto.direct is the default map for direct mounts and is mounted on /-.

To view all of the maps configured for a location as if they were deployed on a filesystem, use the automountlocation-tofiles command:

$ ipa automountlocation-tofiles raleigh/etc/auto.master:/-  /etc/auto.direct---------------------------/etc/auto.direct:

11.6. Configuring Maps

Configuring maps not only creates the maps, it associates mount points through the keys and it assigns mount options that should be used when the directory is accessed. IdM supports both direct and indirect maps.

NOTE

Different clients can use different map sets. Map sets use a tree structure, so maps cannot be shared between locations.

IMPORTANT

Identity Management does not set up or configure autofs. That must be done separately. Identity Management works with an existing autofs deployment.

11.6.1. Configuring Direct Maps

Direct maps define exact locations, meaning absolute paths, to the file mount. In the location entry, a direct map is identified by the preceding forward slash:

---------------------------/etc/auto.direct:/shared/man server.example.com:/shared/man

11.6.1.1. Configuring Direct Maps from the Web UI

Click the Policy tab.
Click the Automount subtab.
Click name of the automount location to which to add the map.
In the Automount Maps tab, click the + Add link to create a new map.
In pop-up window, select the Direct radio button and enter the name of the new map.
In the Automount Keys tab, click the + Add link to create a new key for the map.
Enter the mount point. The key defines the actual mount point in the key name. The Info field sets the network location of the directory, as well as any mount options to use.
Click the Add button to save the new key.

11.6.1.2. Configuring Direct Maps from the Command Line

The key defines the actual mount point (in the key name) and any options. A map is a direct or indirect map based on the format of its key.

Each location is created with an auto.direct item. The simplest configuration is to define a direct mapping by adding an automount key the existing direct map entry. It is also possible to create different direct map entries.

Add the key for the direct map to the location's auto.direct file. The --key option identifies the mount point, and --info gives the network location of the directory, as well as any mount options to use. For example:

$ ipa automountkey-add raleigh auto.direct --key=/share --info="-ro,soft, ipaserver.example.com:/home/share"  Key: /share  Mount information: -ro,soft, ipaserver.example.com:/home/share

Mount options are described in the mount manpage, http://linux.die.net/man/8/mount.

On Solaris, add the direct map and key using the ldapclient command to add the LDAP entry directly:

ldapclient -a serviceSearchDescriptor=auto_direct:automountMapName=auto.direct,cn=location,cn=automount,dc=example,dc=com?one

11.6.2. Configuring Indirect Maps

An indirect map essentially specifies a relative path for maps. A parent entry sets the base directory for all of the indirect maps. The indirect map key sets a sub directory; whenever the indirect map location is loaded, the key is appended to that base directory. For example, if the base directory is /docs and the key is man, then the map is /docs/man.

11.6.2.1. Configuring Indirect Maps from the Web UI

Click the Policy tab.
Click the Automount subtab.
Click name of the automount location to which to add the map.
In the Automount Maps tab, click the + Add link to create a new map.
In pop-up window, select the Indirect radio button and enter the required information for the indirect map:
- The name of the new map
- The mount point. The Mount field sets the base directory to use for all the indirect map keys.
- Optionally, a parent map. The default parent is auto.master, but if another map exists which should be used, that can be specified in the Parent Map field.
Click the Add button to save the new key.

11.6.2.2. Configuring Indirect Maps from the Command Line

The primary difference between a direct map and an indirect map is that there is no forward slash in front of an indirect key.

---------------------------/etc/auto.share:man ipa.example.com:/docs/man---------------------------

Create an indirect map to set the base entry using the automountmap-add-indirect command. The --mount option sets the base directory to use for all the indirect map keys. The default parent entry is auto.master, but if another map exists which should be used, that can be specified using the --parentmap option.
```
$ ipa automountmap-add-indirect location mapName --mount=directory [--parentmap=mapName]
```
For example:
```
$ ipa automountmap-add-indirect raleigh auto.share --mount=/share--------------------------------Added automount map "auto.share"--------------------------------
```

Add the indirect key for the mount location:

$ ipa automountkey-add raleigh auto.share --key=docs --info="ipa.example.com:/export/docs"-------------------------Added automount key "docs"-------------------------  Key: docs  Mount information: ipa.example.com:/export/docs

To verify the configuration, check the location file list using automountlocation-tofiles:

$ ipa automountlocation-tofiles raleigh/etc/auto.master:/-  /etc/auto.direct/share  /etc/auto.share---------------------------/etc/auto.direct:---------------------------/etc/auto.share:man ipa.example.com:/export/docs

On Solaris, add the indirect map using the ldapclient command to add the LDAP entry directly:

ldapclient -a serviceSearchDescriptor=auto_share:automountMapName=auto.share,cn=location,cn=automount,dc=example,dc=com?one

11.6.3. Importing Automount Maps

If there are existing automount maps, these can be imported into the IdM automount configuration.

ipa automountlocation-import location map_file [--continuous]

The only required information is the IdM automount location and the full path and name of the map file. The --continuous option tells the automountlocation-import command to continue through the map file, even if the command encounters errors.

For example:

$ ipa automountlocation-import raleigh /etc/custom.map

Identity Management Guide

Chapter 11. Policy: Using Automount

11.1. About Automount and IdM

11.2. Configuring Automount

11.2.1. Configuring autofs on Red Hat Enterprise Linux

11.3. Setting up a Kerberized NFS Server

11.3.1. Setting up a Kerberized NFS Server

11.3.2. Setting up a Kerberized NFS Client

11.4. Configuring Kerberized CIFS

11.4.1. Setting up Samba Groups in IdM

11.4.2. Configuring the CIFS Client

11.5. Configuring Locations

11.5.1. Configuring Locations through the Web UI

11.5.2. Configuring Locations through the Command Line

11.6. Configuring Maps

11.6.1. Configuring Direct Maps

11.6.1.1. Configuring Direct Maps from the Web UI

11.6.1.2. Configuring Direct Maps from the Command Line

11.6.2. Configuring Indirect Maps

11.6.2.1. Configuring Indirect Maps from the Web UI

11.6.2.2. Configuring Indirect Maps from the Command Line

11.6.3. Importing Automount Maps