Part V Active Directory Naming Service

This part describes the configuration and administration of the nss_ad naming service module. This naming service module enables a Solaris system to access user and group information from Active Directory (AD) servers in an AD domain.

Chapter 17 Setting Up Solaris Active Directory Clients

The nss_ad naming service module provides a back end for the passwd, shadow, and group files. The nss_ad module uses Active Directory (AD) and its native schema as the naming service to resolve user and group names and IDs from across an AD forest.

Overview of the nss_ad Naming Service Module

The Solaris client must be joined to an AD domain before any of the AD interoperability functionality, including nss_ad, can be used. The kclient utility is used to join the client to AD. During the join operation, kclient configures Kerberos v5 on the client. Thereafter, nss_ad can be used to resolve naming service requests by specifying ad as a source in the nsswitch.conf file for the supported databases. The nss_ad module uses host credentials to look up naming service information in AD.

The nss_ad module uses DNS server records to auto-discover AD directory servers, such as domain controllers and global catalog servers. Therefore, DNS must be properly configured on the Solaris client. The nss_ad module also uses the LDAP v3 protocol to access naming information from AD servers. The AD server schema requires no modification because nss_ad works with the native AD schema.

The nss_ad module does not currently support logins of Windows users onto a Solaris system. Until such logins are supported, such users should continue to log in by using traditional back ends such as nis and ldap.

The idmap and nscd services must be enabled to use nss_ad. The nss_ad module uses the idmap service to map between Windows security identifiers (SIDs), Solaris user identifiers (UIDs), and group identifiers (GIDs).

Ensure that all AD user and group names are qualified with domain names such as user@domain or group@domain. For example, getpwnam(dana) will fail, but getpwnam(dana@domain) will succeed, provided that dana is a valid Windows user in the domain named domain.

The following additional rules also pertain to the nss_ad module:

• Like AD, nss_ad performs case-insensitive matching of user and group names.

• Only use the nss_ad module in UTF-8 locales or in domains where users and groups have only ASCII characters in their names.

• Well-known SIDs are a set of SIDs that identify generic users or generic groups in the Windows world. They are not domain specific and their values remain constant across all Windows operating systems. The names of well-known SIDs are qualified with the string BUILTIN, for example, Remote Desktop Users@BUILTIN.

• The nss_ad module does not support enumeration. Therefore, the getpwent() and getgrent() interfaces and commands that use them such as getent passwd and getent group cannot retrieve information from AD.

• The nss_ad module currently supports only the passwd and group files. nss_ad does not support other naming service databases that follow the passwd entry, such as audit_user and user_attr. If the ad back end is processed (based on the configuration), it returns NOT FOUND for these databases.

Configuring the nss_ad Naming Service Module

The nss_ad module requires that the Solaris client use DNS for host resolution.

How to Configure the nss_ad Module

1. Edit the /etc/resolv.conf file to point to the correct domain, using the correct search order.

   Pointing to the correct DNS domain and servers in the /etc/resolv.conf file usually involves specifying the domain controller as the DNS server.

   ---

   Note –

   The AD domain name must be specified in /etc/resolv.conf either by means of the domain directive or as the first item in the list specified by the search directive.

   If both directives are specified, then whichever is last takes precedence. This is required for the idmap auto-discovery feature to work properly.

   ---

   In the following example, the AD domain, ad.example, is specified by the domain directive. The dig commands verify that the AD server, which is specified by the nameserver directive, can be resolved by using its name and IP address.

   % cat /etc/resolv.conf domain ad.example nameserver 192.168.11.22 % dig -x 192.168.11.22 +short myserver.ad.example % dig myserver.ad.example +short 192.168.11.22

2. Edit the etc/nsswitch.conf file, and add dns to the list of naming services for hosts and ipnodes.

   For example, the file might look like the following:

   % egrep '^hosts|^ipnodes' /etc/nsswitch.conf hosts: files dns ipnodes: files dns

   ---

   Note –

   To include additional naming services such as nis or ldap for host resolution, add them after dns in the /etc/nsswitch.conf file.

   ---

3. Verify that the DNS service is enabled and online.

   For example:

   % svcs svc:/network/dns/client STATE STIME FMRI online Oct_14 svc:/network/dns/client:default

4. Use the kclient utility to join the system to the AD domain.

   For example:

   % /usr/sbin/kclient -T ms_ad

5. Edit the nsswitch.conf file by adding ad to passwd and group.

   For example:

   % egrep '^passwd|^group' /etc/nsswitch.conf passwd: files nis ad group: files nis ad

   ---

   Note –

   /etc/nsswitch.ad is a sample configuration file that can be copied to /etc/nsswitch.conf. It uses AD for passwd and group, DNS for host lookups, and files for the remaining databases. Because the AD naming service is not yet a complete Solaris solution, add other naming services as appropriate to the nsswitch.conf file.

   ---

6. Enable the idmap service.

   % svcadm enable idmap

7. Enable the nscd service.

   % svcs name-service-cache STATE STIME FMRI disabled 13:15:48 svc:/system/name-service-cache:default % svcadm enable name-service-cache

   ---

   Note –

   The nscd module automatically restarts whenever /etc/nsswitch.conf is changed.

   ---

8. Verify that you can access user and group information from AD.

   For example:

   % getent passwd 'test_user@example' test_user@example:x:2154266625:2154266626:test_user:: % getent passwd 2154266625 test_user@example:x:2154266625:2154266626:test_user::

Password Updates

The passwd(4) man page contains a list of valid formats for the passwd entry in the nsswitch.conf file. Adding ad to these configurations in the nsswitch.conf file is supported. However, changing AD user passwords through the passwd command is not supported. If found in the passwd entry during a password update, ad is skipped. Use the kpasswd command to update AD user passwords.

The ad search order can be added to existing valid passwd and group entries in nsswitch.conf. For example:

passwd: files  ad
group:  files  ad

How the nss_ad Naming Service Module Retrieves Data From AD

The following section describes how the nss_ad module resolves naming service requests for the passwd, shadow, and group files by retrieving corresponding data from AD.

Retrieving passwd Information

The following syntax shows the proper form of a passwd entry:

username:password:uid:gid:gecos:home-directory:login-shell

See the passwd(4) man page for more information.

The nss_ad module retrieves passwd information from AD as follows:

• username – Field uses the value of the samAccountName AD attribute and is qualified by the domain name in which the object resides, for example, terryb@example.com.

• password – Field uses the value of x because the user password is not available in the AD object.

• uid – Field uses the Windows user's SID from the objectSID AD attribute, which is mapped to the UID by using the idmap service.

• gid – Field uses the Windows user's primary group SID, which is mapped to the GID by using the idmap service. The group SID is obtained by appending the value of the primaryGroupID AD attribute to the domain SID. For users in AD, the primaryGroupID attribute is an optional attribute, so it might not exist. If the attribute does not exist, nss_ad uses the idmap diagonal mapping facility to map the user SID from the objectSID attribute.

• gecos – Value of the CN AD attribute.

• home-directory – Value of the homeDirectory AD attribute, if a value exists. Otherwise, the field is left empty.

• login-shell – Field is left empty because there is no login shell attribute in the native AD schema.

Retrieving shadow Information

The following syntax shows the proper form of a shadow entry:

username:password:lastchg:min:max:warn:inactive:expire:flag

See the shadow(4) man page for more information.

The nss_ad module retrieves shadow information from AD as follows:

• username – Field uses the value of the samAccountName AD attribute and is qualified by the domain name in which the object resides, for example, terryb@example.com.

• password – Field uses the value of *NP* because the user password is not available in the AD object.

The rest of the shadow fields are left empty because shadow fields are irrelevant with AD and Kerberos v5.

Retrieving group Information

The following syntax shows the proper form of a group entry:

groupname:password:gid:user-list

See the group(4) for man page for more information.

The nss_ad module retrieves information from AD as follows:

• groupname – Field uses the value of the samAccountName AD attribute and is qualified by the domain name in which the object resides, for example, admins@example.

• password – Field is left empty because the Windows groups do not have passwords.

• gid – Field uses the Windows group's SID from the objectSID AD attribute, which is mapped to the GID by using the idmap service.

• user-list – Field is left empty.