2007/663 Winchester directory-based name mapping [FastTrack timeout 11/30/2007]

[Gary Winiger]

I'm sponsoring this fast track for Nico Williams and the Winchester
project team.  It adds another mapping style to the existing
Winchester project.  The added interfaces request a Uncommitted
taxonomy which matches the existing Winchester taxonomy.
The case requests a Patch release binding (though a backport is not
currently planned).

A full diffmk-ed idmap(1M) man page is in the case directory along
with directions for adding the LDAP support to existing servers.

The timer is set for 30 Nov, 2007 (to account for mpk17 shutdown and
the holidays ;-)

Gary..
==================================================================

BACKGROUND
----------
PSARC/2006/315 (Winchester) introduced a facility for mapping Windows
identities to/from Solaris identities.

That case included two forms of ID mapping: a) ephemeral ID mapping,
where UIDs and GIDs are assigned to Windows SIDs dynamically and
on-demand, and b) name-based mapping, where Windows user/group names are
matched to Solaris user/group names via locally-stored, configurable
mapping rules.  This case adds a new ID mapping method.

Winchester was modified by PSARC/2007/616 (Winchester update for diagonal
ID mapping) to accommodate the Windows use of groups and users
interchangeably.


PROBLEM
-------
Locally stored name-based mapping rules are not easy to administer in
cases where there are many such rules or where there are many servers to
deploy name-based rules to.  A competitor supports storing name-based
mappings not as rules but as user/group object attributes in LDAP, both
in native LDAP (i.e., RFC2307bis+ schemas) and in Active Directory.

We call this directory-based name mapping, and we propose to add this
feature to the Solaris ID mapping facility.


PROPOSAL
--------
Implement directory-based name mapping, where the Unix user/group names
of any Windows user/group and vice-versa are stored in the directory
object representing the one, the other or both of Unix and Windows
entities.

This approach requires new attributes be added to users and groups in
the directory. To match other implementations, and to allow for multiple
mappings between a Windows forest and multiple Unix domains we will make
the names of the new LDAP object attributes configurable.

The possible schema extensions and the population of the directories
is outside the boundaries of this case, beyond the instructions
that will be provided to the administrators as outlined in
schema-extension-instructions.txt (in the case directory) for adding
the schema where needed and the use of idmap(1M) set-namemap ... (see below)
for adding mappings.

 o Behavior

   There will be three modes of directory-based name mapping:

    - AD-only mode

      When mapping a Windows SID to a UID/GID, idmapd will do an LDAP
      search in the AD global catalog for the user/group object with
      that SID looking for an attribute that will name the corresponding
      Unix user/group name, then it will call getpw/grnam_r() to resolve
      the Unix name to a UID/GID.

      When mapping a UID/GID to a SID, idmapd will first resolve the
      UID/GID to a Unix user/group name with getpwuid/grgid_r(), then it
      will do an LDAP search in the AD global catalog for the user/group
      object which has the configured attribute with that Unix
      user/group name as its value -- the resulting object's SID will be
      the result.

    - Native-LDAP-only mode

      When mapping a Windows SID to a UID/GID, idmapd will first resolve
      the SID to a Windows name as it does today (i.e., via LDAP
      searches of the Active Directory global catalog), then it will do
      an LDAP search of the AD global catalog to resolve the SID to a
      user/group name, then it will search native LDAP for a user/group
      object with the configured attribute with that Windows user/group
      name as its value.

      When mapping a UID/GID to a SID, idmapd will do a native LDAP
      search for the user/group object with that UID/GID and will
      retrieve the configured attribute with that the Windows user/group
      name, then it will resolve the resulting Windows name to a SID as
      it does today.

    - Mixed mode

      When mapping a Windows SID to a UID/GID idmapd will use the
      procedure described above for AD-only mode.

      When mapping a UID/GID to a SID, idmapd will use the procedure
      described above for Native-LDAP-only mode.


 o Configuration

   The mode of directory-based name mapping will be configurable via a
   new property of the svc:/system/idmap service (using svccfg(1M)).
   From the updated manpage:

+ config/ad_unixuser_attr
+    Specify the name of the AD attribute that contains the UNIX
+    user name. There is no default.
 
+ config/ad_unixgroup_attr
+    Specify the name of the AD attribute that contains the UNIX
+    group name. There is no default.
 
+ config/ad_unixacct_class
+    Specify the name of the AD object class that contains the UNIX
+    account attributes. There is no default.
 
+ config/nldap_winname_attr
+    Specify the name of the Native LDAP attribute that contains
+    the Windows user/group name. There is no default.
 
+ config/nldap_winacct_class
+    Specify the name of the Native LDAP object class that contains
+    the Windows account attributes. There is no default.
 
+ config/ds_name_mapping_enabled
+    Enable/Disable directory-based name mapping.

   When ds-based name mapping is enabled idmapd will try that first,
   then name-based mapping rules, then ephemeral ID mapping.

 o Administrative interfaces

   The idmap(1M) command will have new sub-commands for viewing, setting
   and unsetting a Windows or Unix user/group's directory-based name
   mapping attributes.  From the updated manpage:
 
+ idmap get-namemap name
+ idmap set-namemap [-a authenticationMethod] [-D bindDN]
+       [-j passwdfile] name1 name2

   AD and native LDAP modify operations will be done by the process
   running idmap(1M) and using the calling user's Kerberos V
   credentials, with options for plain password authentication for
   native LDAP (passed in via the -j passwdfile option).  Authorization
   is up to the DS.

+ Example 10 Add directory-based name mapping to AD user object.

+ The following command map Windows user joe at example.com to
+ UNIX user joe by adding the UNIX name to AD object for
+ joe at example.com.

+ # idmap set-namemap winuser:joe at example.com joes

   The idmap command will need to know the name of the auxiliary class,
   if any, that has to be added to a user/group object in order to be
   able to set these attributes; there will be two new service
   properties by which to name these classes.

   Instructions on how to extend LDAP schemas (a requirement for this
   feature) will be included in the documentation (see the case
   directory).  Users will also be instructed to ensure that the new
   attributes are indexed and, in the case of AD, that they are
   replicated to the global catalog.


PHASED DELIVERY
---------------
Due to time pressures we request to deliver in up to three phases:

 - AD-only mode (likely to integrate first)

 - Native LDAP-only and Mixed modes (because of required modifications
   to libsldap)

 - Administrative idmap(1M) sub-commands (likely to integrate last; the
   Sun internal consumer that requested directory-based mappings needs
   the feature more than the new idmap(1M) sub-commands)


NOTES
-----
 o No name service switch extensions

   This project does not propose a new name service database, nor any
   extensions to existing ones.  Technically we could, and if we added
   support for such extensions to the various backends then we could
   store name mappings in NIS and even NIS+ (which is EOFed), not just
   LDAP.

   However, doing so would greatly complicate the project.  Moreover, we
   are adding this feature to better compete with a product that
   provides this same feature, and we expect to see no customer interest
   for storing name mappings in files (name-based rules accomplish this
   already), nor in NIS, nor are we willing to extend NIS+ client
   support.

   Users will be encouraged to set the name service switch for the
   'passwd' and 'group' databases to "files ldap" when using directory-
   based name mapping in mixed or native LDAP-only modes.

 o Interaction with PSARC/2007/616 (Winchester update for diagonal ID
   mapping)

   Directory-based name mapping as specified here supports diagonal
   mapping.

   Any Windows user or group can be mapped to both, a Unix user and a
   Unix group.  Unix users and groups can each map to a single Windows
   user or group, and the type of the latter need not match the type of
   the former.

 o Use of libsldap

   libsldap is Contracted Consolidation Private.  The i-team in this
   case is part of the netrep team, which owns libsldap, therefore no
   contract should be needed.  This project will add new Project Private
   interfaces to libsldap.  These new Project Private interfaces are for
   issuing multiple native LDAP searches and retrieving the results
   asynchronously, all while using the same connections and connection
   management facilities that existing private interfaces in libsldap
   provide.

 o Features not found in the competition

   The competition does not support diagonal mapping, nor ds-based name
   mappings stored only in AD.


INTERFACES
----------
All interfaces introduced in this case are Uncommitted, just as in
PSARC/2007/315.

We request Patch binding, but there is no backport of ID mapping to
S10 updates planned.

New properties of svc:/system/idmap:

 - Properties (type: astring) naming an AD LDAP class and attributes:

    config/ad_unixacct_class
    config/ad_unixuser_attr
    config/ad_unixgroup_attr

 - Properties (type: astring) naming a native LDAP class and attribute:

    config/nldap_winacct_class
    config/nldap_winname_attr

 - Boolean property controlling whether ds-based name mapping is enabled:

    config/ds_name_mapping_enabled

New idmap(1M) sub-commands for viewing and setting ds-based mappings of
Unix and Windows users and groups:

    idmap get-namemap name
    idmap set-namemap [-a authenticationMethod] [-D bindDN]
          [-j passwdfile] name1 name2
    idmap unset-namemap [-a authenticationMethod] [-D bindDN]
          [-j passwdfile] name