Active Directory name service module (nss_ad) [PSARC/2008/441 FastTrack timeout 07/18/2008]

Nicolas Williams nw141292 at sac.sfbay.sun.com
Fri Jul 11 14:53:43 PDT 2008


I'm filing this fasttrack on behalf of Baban Kenkre.  The timer is set
to expire on 7/18/2008.  The project team requests patch binding, though
there is no intention to backport.


1.  Introduction

   1.1. Project/Component Working Name:
        NSS_AD: Name Service Module for AD
   1.2. Name of Document Author/Supplier:
        Author:  Baban Kenkre
   1.3  Date:
        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 at domain or group at domain). nss_ad will
      neither accept nor return non-qualified user and group names.
      E.g. getpwnam("foo") will fail but getpwnam("foo at domain") will
      pass provided "foo at 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.  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 at 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.


8.  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 at 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.


9.  Relevant ARC cases and CRs

   o  6722476 name service switch module for AD (nss_ad) 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


10.  Supporting Documents

   +---------------------+-----------------------------------+
   | Filename            | Description                       |
   +---------------------+-----------------------------------+
   | ad.5.txt            | ad(5) manpage                     |
   |                     |                                   |
   | nsswitch.conf.4.txt | Modified nsswitch.conf(4) manpage |
   +---------------------+-----------------------------------+

   In addition to the above the Solaris admin guide will include a
   chapter on AD name service in Solaris.


11.  References

   [1]  "Well-Known SIDs", <http://support.microsoft.com/kb/243330>.

   [2]  "SMB URL", <http://www.watersprings.org/pub/id/
        draft-crhertel-smb-url-12.txt>.


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  |
   +--------------------------+-----------------+----------+



More information about the opensolaris-arc mailing list