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
