Go to main content

Working With Oracle® Solaris 11.3 Directory and Naming Services: DNS and NIS

Exit Print View

Updated: October 2017

Overview of the nss_ad Naming Service Module

The Oracle Solaris client must be joined to an AD domain before any of the AD interoperability functionality, including nss_ad, can be used. Use the kclient utility to join the client to AD. During the join operation, kclient configures Kerberos v5 on the client. Thereafter, you can use nss_ad 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 Oracle 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.

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

You must enable the idmap and svc:/system/name-service/cache services to use nss_ad. The nss_ad module uses the idmap service to map between Windows security identifiers (SIDs), UNIX user identifiers (UIDs), and group identifiers (GIDs).

Make sure to qualify all AD user and group names with domain names such as user@domain or group@domain. For example, getpwnam(abc) will fail, but getpwnam(abc@domain) will succeed provided that abc 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. These SIDs 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 enumeration 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.