1. Introduction 1.1. Project/Component Working Name: NSSAD: Name Service Module for AD 1.2. Name of Document Author/Supplier: Author: Baban Kenkre 1.3 Date of This Document: 11 July, 2008 2. Background Microsoft's Active Directory (AD) can be used as Solaris name service repository through nss_ldap by installing Microsoft's Services for Unix (SFU) or Microsoft's Identity Services for Unix on the AD server and configuring schema mapping on the Solaris clients. 3. Problem There are two main problems with using nss_ldap for AD name service. 1. nss_ldap can only access data from a single AD domain whereas in AD we could have several domains in an AD forest. An AD forest is a collection of domains with implicit trust relationship. A key requirement for AD interoperability is to reference data especially users and groups from across the forest and not just a single domain. 2. Another key requirement for Solaris AD interoperability is the use of native AD schema by Solaris clients for name service lookups. idmap service supports AD with native schema and therefore equivalent support is needed for name-service. The current implementation of nss_ldap module makes widespread use of RFC2307bis and other elements not native to AD (e.g. DUAProfiles). Therefore, modifying nss_ldap to support both i.e RFC2307bis and native AD codepaths would be difficult and error-prone. 4. Solution To address the problems stated above, this case proposes a new name service module for Solaris called nss_ad that will resolve name service requests by performing AD lookups for mappable data such as passwd, shadow and groups using the native AD schema and from across the AD forest. Support for the printers database will be addressed by a follow-on RFE. Native AD schema lacks equivalent classes and attributes for other nsswitch databases. A future project may add support for these databases where AD is extended with relevant schemas. 5. Out of scope o Supporting logons of Windows users onto Solaris system is beyond the scope of this case. Much more work is needed here including but not limited to (i) Support ephemeral UIDs/GIDs in lastlog, tmpfs (ii) support SIDs in audit trails (iii) username/groupname length limitations and so on. Till this is supported, users will continue to logon using traditional backends such as nis and ldap. However, by using nss_ad i.e. adding "ad" to the list of sources for passwd and group in nsswitch.conf(4) (e.g. passwd: files ldap ad) the Solaris client will be able to resolve Windows names and ephemeral UIDs/GIDs using the same getXbyY interfaces used to resolve Unixnames and ids. o nss_ad will not support SFU initially and will be limited to native AD schema. If SFU is deployed then nss_ldap must be used. o getXbysid() and getsidbyY() interfaces. o Front-end tools for name-service configuration. 6. Configuration o The Solaris client must be joined to an AD domain before any of the AD Interop functionality including nss_ad can be used. AD domain join can be done either using smbadm(1M) or the kclient(1M) tool. Thereafter, nss_ad can be used to resolve name service requests by specifying "ad" as the source in nsswitch.conf(4) file for supported databases. o nss_ad will initially auto-discover AD servers until a separate service is available that auto-discovers servers for all name service components. Such a service is beyond the scope of this case. o AD is also a KDC and Solaris AD client is a krb5 client of AD. Kerberos is automatically configured on the Solaris AD client at the time of AD join. nss_ad (like the idmap service) will use host credentials to lookup name service information in AD using SASL/ GSSAPI/KRB5. nscd must be enabled to use nss_ad. o nss_ad does not support the notion of default domain and therefore will require that all AD user and group names be qualified with domain names (i.e. user@domain or group@domain). nss_ad will neither accept nor return non-qualified user and group names. E.g. getpwnam("foo") will fail but getpwnam("foo@domain") will pass provided "foo@domain" is a valid Windows user. *Special case*: Well-known SIDs [1] 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. nss_ad will accept these users and groups without any domain qualifier. The well-known user "Nobody" will not be accepted. o PSARC/2008/342 effectively added some support for ls(1) to display Windows user/group names (only for ACLs but not file owner/group), but this case adds support for any application using get{pw,gr}{nam,uid,gid}() to do the same. 7. Password Updates passwd(1) manpage contains a list of valid password update configurations for the passwd entry in nsswitch.conf(4) file. Adding 'ad' to these configurations will be supported though changing AD users' passwords through passwd(1) won't be supported. 'ad' will be skipped if found in the passwd entry during password update. AD users' passwords can be updated using kpasswd(1) command. passwd(1) and nsswitch.conf(4) manpages as well as the Solaris Admin Guide will be updated to reflect this. 8. Other consumers of passwd entry As mentioned previously "ad" can be added to any of the existing valid passwd and group entries in nsswitch.conf. Examples: passwd: files ad OR passwd: files ldap ad This allows consumers of get{pw|gr}{nam|uid|gid} to resolve Windows names and ephemeral IDs. Other name service databases such as audit_user(4) and user_attr(4) that follow passwd entry in nsswitch.conf will not be affected by the additional backend in the passwd entry. This backend will be processed (based on the configuration) and if it's 'ad' then it will return NOTFOUND because RBAC is not yet suppported by AD. 9. Mapping to passwd(4) and shadow(4) Mapping of Windows user to passwd(4) form will be done as follows: o The Windows's user object belongs to objectClass "user". o Unix username (pw_name, sp_namp) is taken from the value of the "samAccountName" AD attribute of the user object, qualified with the name of the domain in which that object resides (e.g., "foo@example"). o nss_ad will use the idmap(1M) service to map Windows SID from AD attribute "objectSID" to POSIX UID (pw_uid). o The AD attribute "primaryGroupID" contains the RID of the user's primary group. This RID when appended to the domain SID gives the primary group's SID. nss_ad will use the idmap(1M) service to map this group SID to POSIX GID (pw_gid). "primaryGroupID" is not a mandatory attribute for Window's user therefore if it does not exists then nss_ad will use idmap's diagonal mapping facility to map the user SID to GID and use it for pw_gid. o pw_gecos field will use the full name of the Windows's user from the AD attribute "CN". o The AD attribute "homeDirectory" (if present) will contain the Windows user's home directory. If the homeDirectory string is in UNC format then nss_ad will convert it into a SMB URL and use it for pw_dir. See draft-crhertel-smb-url-12 [2]. We think using the SMB URL is okay because Solaris doesn't support logon of Windows users yet. If the homeDirectory refers to a local Windows directory indicated by the prefix "[A-Z]:\" (e.g. C:\Documents and Settings\foo) then pw_dir will be left empty. o There is no login shell in native AD schema. This field will be left empty. o The user password is not available in the AD object and therefore sp_pwdp will be "*NP*" and pw_passwd will be "x". o nss_ad will leave shadow fields empty (i.e. -1 for sp_lstchgst, sp_min, sp_max, sp_warn, sp_inact, sp_expire and 0 for sp_flag) because shadow fields are irrevalent with AD and krb5. 10. Mapping to group(4) Mapping of Windows group to group(4) form will be done as follows: o The Windows's group object belongs to objectclass "group". o Unix groupname (gr_name) is taken from the value of the "samAccountName" AD attribute of the group object, qualified with the name of the domain in which that object resides (e.g., "admins@example"). o nss_ad will use the idmap(1M) service to map Windows SID from AD attribute "objectSID" to POSIX GID (gr_gid). o The multi-valued AD attribute "member" contains LDAP DNs of objects representing the group's members. The Unix gr_mem list will be constructed by retrieving the "samAccountName" for each of these objects, with each name qualified with the name of the domain in which that object resides. o The gr_passwd field will be left NULL because the Windows group AD object does not contain the group's password. 11. Relevant ARC cases and CRs o 6722476 name service switch module for AD (nssad) needed o PSARC/2006/315 Winchester:ID Mapping service o PSARC/2006/247 NSS2 umbrella case o PSARC/2007/694 Duckwater: Simplified name services management o PSARC/2008/256 Native LDAP tool command line argument additions o PSARC/2008/342 Further SID support 12. Supporting Documents +---------------------+-----------------------------------+ | Filename | Description | +---------------------+-----------------------------------+ | ad.5.txt | ad(5) manpage | | | | | nsswitch.conf.4.txt | Modified nsswitch.conf(4) manpage | | | | | passwd.1.txt | Modified passwd(1) manpage | | | | | nsswitch.ad | Sample nsswitch.conf file | +---------------------+-----------------------------------+ In addition to the above the Solaris Admin Guide will include (i) a chapter on nss_ad and (ii) the Naming and Directory services (DNS, NIS, and LDAP) chapter will be modified to clarify the password update issue related to AD users. 13. References [1] "Well-Known SIDs", . [2] "SMB URL", . Appendix A. Interfaces +--------------------------+-----------------+----------+ | Interface | Classification | Delivery | +--------------------------+-----------------+----------+ | New nsswitch source "ad" | Committed | N/A | | | | | | /usr/lib/nss_ad.so.1 | Committed | SUNWcsu | | | | | | /usr/lib/libadutils.so.1 | Project Private | SUNWcsu | +--------------------------+-----------------+----------+