From jb25718@sac.sfbay.sun.com Thu Jul 16 15:30:35 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6GMUZEM029827 for ; Thu, 16 Jul 2009 15:30:35 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6GMUX68007704; Thu, 16 Jul 2009 15:30:35 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KMW0040HBUXPY00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 16 Jul 2009 15:30:33 -0700 (PDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMW00D60BUXW170@nwk-avmta-1.sfbay.Sun.COM>; Thu, 16 Jul 2009 15:30:33 -0700 (PDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6GMUWYr032191; Thu, 16 Jul 2009 15:30:32 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6GMUVgS029822; Thu, 16 Jul 2009 15:30:31 -0700 (PDT) Received: (from jb25718@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n6GMUV9o029818; Thu, 16 Jul 2009 15:30:31 -0700 (PDT) Date: Thu, 16 Jul 2009 15:30:31 -0700 (PDT) From: Jordan Brown Subject: IDMU Support for idmap [PSARC/2009/398 FastTrack timeout 07/23/2009] To: PSARC-ext@sun.com Cc: cifs-eng@sun.com, winchester@sun.com Message-id: <200907162230.n6GMUV9o029818@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 5572 Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: IDMU Support for idmap 1.2. Name of Document Author/Supplier: Author: Jordan Brown 1.3 Date of This Document: 16 July, 2009 4. Technical Description SUMMARY Integrate Solaris Windows identity management with Microsoft's Identity Management for UNIX (IDMU). BACKGROUND - IDMU Microsoft offers a feature (unbundled for Windows 2003 and before, bundled for Windows 2003R2 and later) called "Identity Management for Unix", or IDMU. (It's part of what was called "Services For Unix" in its unbundled form.) The primary goal of SFU and IDMU is to support Windows as a NIS/NFS server - basically, the same role that we have with CIFS, only reversed. IDMU adds a "UNIX Attributes" panel to the Active Directory Users and Computers user interface that lets the administrator specify a number of UNIX-related parameters: UID, GID, login shell, home directory, and similar for groups. These parameters are made available through AD through a schema similar to (but not the same as) RFC2307, and through NIS service. BACKGROUND - Existing Solaris support for Directory-based identity mapping There is an existing idmap feature "directory-based" or "ds-based" mapping, where user-defined attributes are added to the Active Directory or LDAP schema to provide the UNIX name associated with a Windows identity, or the Windows name associated with a UNIX identity. IDMU is similar to DS-based mapping in its "Active Directory only" mode, but stores numeric UIDs and GIDs in the directory, rather than storing UNIX user and group names. PROBLEM IDMU offers user interface and storage for Windows-UNIX identity mapping information, integrated with Active Directory user/group management. Customers have requested that Solaris identity mapping take advantage of this mechanism. PROPOSAL Add a flag (as an SMF property, like other idmap configuration flags) that enables use of IDMU data. DETAILS On the idmap FRMI, svc:/system/idmap:default, add the property config/idmu_enabled. True enables IDMU support; false disables it. The default if the property does not exist is that support is disabled. For implementation reasons and to reduce configuration complexity, IDMU support is mutually exclusive with the existing DS-based mapping support. If both are enabled, a warning message will be logged and DS-based mapping will be disabled. Like DS-based mapping, if IDMU data and local name-based mapping rules are both available for a particular identity, the IDMU data will be used. Because IDMU data is maintained on a per-domain basis and Active Directory does not ensure UID uniqueness between domains, this phase of IDMU support will use IDMU data only from the domain to which the Solaris system is joined. COMMENTS It may be possible to use this IDMU support along with the NIS maps exported by the Windows Active Directory server to fully integrate UNIX and Windows identity, managed entirely from the Active Directory user interface. Although this project is a significant component of such a potential integration, this configuration was not a goal and has not been tested. FUTURE A future phase may add the ability for an administrator to allow Solaris to use IDMU data from other domains, with the assumption that the administrator is manually managing the UID space across those domains. ISSUES The current plan is that if both IDMU and DS-based mapping are enabled, a warning message is logged and DS-based mapping is not used. In the future, if we were to enable coexistence of the two features, a system in this state might unexpectedly change behavior. An alternative proposal is to put the idmap service into "maintenance" mode if this situation is encounted, to force the administrator to resolve the conflict. DELIVERY VEHICLE Solaris RELEASE Patch COMMITMENT LEVEL IDMU support: Committed The fact that IDMU and DS-based mapping are incompatible is not an interface; they might be made compatible in the future. REFERENCE DOCUMENTS Identity Management for UNIX: Welcome (Microsoft Technet) http://technet.microsoft.com/en-us/library/cc782782(WS.10).aspx Integrated Identity Management in Active Directory Domain Services http://technet.microsoft.com/en-us/library/cc780098(WS.10).aspx Includes screen shot of the Active Directory user information dialog box showing the UNIX Attributes panel. MANUAL PAGE Update idmap(1M), in the "Service Properties" section: config/ds_name_mapping_enabled Enable/disable directory-based name mapping. Note that if this and config/idmu_enabled are both set to "true", this value is ignored. config/idmu_enabled Enables support for Microsoft Identity Management for UNIX (IDMU). This Windows component allows the administrator to specify a UNIX user ID for each Windows user, mapping the Windows identity to the corresponding UNIX identity. Only IDMU data from the domain the Solaris system is a member of is used. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Darren.Moffat@sun.com Fri Jul 17 01:58:33 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6H8wXYx023869 for ; Fri, 17 Jul 2009 01:58:33 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6H8wSIM025628; Fri, 17 Jul 2009 09:58:32 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KMX00G0B4XIE500@nwk-avmta-2.sfbay.sun.com>; Fri, 17 Jul 2009 01:58:30 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMX00BCT4XHC390@nwk-avmta-2.sfbay.sun.com>; Fri, 17 Jul 2009 01:58:30 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6H8wTpL001914; Fri, 17 Jul 2009 08:58:29 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KMX009001T80R00@fe-emea-10.sun.com>; Fri, 17 Jul 2009 09:58:29 +0100 (BST) Received: from [129.156.173.199] ([unknown] [129.156.173.199]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KMX004QV4X7O780@fe-emea-10.sun.com>; Fri, 17 Jul 2009 09:58:19 +0100 (BST) Date: Fri, 17 Jul 2009 09:58:19 +0100 From: Darren J Moffat Subject: Re: IDMU Support for idmap [PSARC/2009/398 FastTrack timeout 07/23/2009] In-reply-to: <200907162230.n6GMUV9o029818@sac.sfbay.sun.com> Sender: Darren.Moffat@sun.com To: Jordan Brown Cc: PSARC-ext@sun.com, cifs-eng@sun.com, winchester@sun.com Message-id: <4A603D2B.6020000@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907162230.n6GMUV9o029818@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20090127) Status: RO Content-Length: 849 Jordan Brown wrote: > config/ds_name_mapping_enabled > > Enable/disable directory-based name mapping. Note that if > this and config/idmu_enabled are both set to "true", this > value is ignored. > > config/idmu_enabled > > Enables support for Microsoft Identity Management for UNIX > (IDMU). This Windows component allows the administrator to > specify a UNIX user ID for each Windows user, mapping the > Windows identity to the corresponding UNIX identity. > Only IDMU data from the domain the Solaris system is a member > of is used. Seems perfectly reasonable to me. If condif/ds_name_mapping_enabled didn't already exist I would have suggested a config options system that didn't allow the user to so easily enable both options but given the existing precendent this case is fine as specified. -- Darren J Moffat From Nicolas.Williams@sun.com Fri Jul 17 12:29:14 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6HJTDLC016228 for ; Fri, 17 Jul 2009 12:29:13 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6HJTBv2010795; Fri, 17 Jul 2009 13:29:12 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KMX00609Y4NT000@nwk-avmta-1.sfbay.Sun.COM>; Fri, 17 Jul 2009 12:29:11 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMX001FNY4LXRE0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 17 Jul 2009 12:29:10 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n6HJQJYI010194; Fri, 17 Jul 2009 14:26:19 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n6HJQJqV010193; Fri, 17 Jul 2009 14:26:19 -0500 (CDT) Date: Fri, 17 Jul 2009 14:26:19 -0500 From: Nicolas Williams Subject: Re: IDMU Support for idmap [PSARC/2009/398 FastTrack timeout 07/23/2009] In-reply-to: <4A603D2B.6020000@Sun.COM> To: Darren J Moffat Cc: Jordan Brown , PSARC-ext@sun.com, cifs-eng@sun.com, winchester@sun.com Message-id: <20090717192618.GU1274@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200907162230.n6GMUV9o029818@sac.sfbay.sun.com> <4A603D2B.6020000@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 2054 On Fri, Jul 17, 2009 at 09:58:19AM +0100, Darren J Moffat wrote: > Jordan Brown wrote: > > config/ds_name_mapping_enabled > > > > Enable/disable directory-based name mapping. Note that if > > this and config/idmu_enabled are both set to "true", this > > value is ignored. > > > > config/idmu_enabled > > > > Enables support for Microsoft Identity Management for UNIX > > (IDMU). This Windows component allows the administrator to > > specify a UNIX user ID for each Windows user, mapping the > > Windows identity to the corresponding UNIX identity. > > Only IDMU data from the domain the Solaris system is a member > > of is used. > > Seems perfectly reasonable to me. > > If condif/ds_name_mapping_enabled didn't already exist I would have > suggested a config options system that didn't allow the user to so > easily enable both options but given the existing precendent this case > is fine as specified. Ideally we would have a way to validate this sort of rule (mutually exclusive properties) when configuration is edited. Right now that would be svccfg(1M), which, even with Extended SMF Templates, will not provide support for mutually exclusive props. We could, and should instead move all idmap configuration tasks from svccfg(1M) to idmap(1M). But that's not this case. Until a case comes along to move idmap configuration to idmap(1M) I believe that it would be best for the idmap service to go into maintenance in the face of incorrect configuration. This will allow configuration errors to be detected sooner (at service refresh time), and most likely by the administrator that made the config changes. What the i-team proposes (ignoring parts of conflicting configuration), seems to me like asking for trouble: when in a much later update the service adds support for up-till-then unsupported configuration, the system's behavior could change quite unexpectedly. Putting the service into maintenance instead is easy to implement, and, IMO more user friendly in the absence of the ideal solution (see above). Nico -- From Jordan.Brown@sun.com Tue Jul 21 14:03:55 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6LL3sbe029474 for ; Tue, 21 Jul 2009 14:03:54 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n6LL3YDt023158 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 22 Jul 2009 05:03:53 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KN500J07H6FXK00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Tue, 21 Jul 2009 14:03:51 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KN500JM7H6DUJ00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Tue, 21 Jul 2009 14:03:49 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6LL3n19022826 for ; Tue, 21 Jul 2009 14:03:49 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KN500B00H2NTP00@fe-sfbay-09.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Tue, 21 Jul 2009 14:03:49 -0700 (PDT) Received: from [129.145.155.47] ([unknown] [129.145.155.47]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KN50042KH6CC9C0@fe-sfbay-09.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Tue, 21 Jul 2009 14:03:49 -0700 (PDT) Date: Tue, 21 Jul 2009 14:03:48 -0700 From: Jordan Brown Subject: Re: IDMU Support for idmap [PSARC/2009/398 FastTrack timeout 07/23/2009] In-reply-to: <200907162230.n6GMUV9o029818@sac.sfbay.sun.com> Sender: Jordan.Brown@sun.com To: PSARC-ext@sun.com Message-id: <4A662D34.1010403@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_qeJNM+h1zov92cszdyTPVw)" X-PMX-Version: 5.4.1.325704 References: <200907162230.n6GMUV9o029818@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Status: RO Content-Length: 12444 This is a multi-part message in MIME format. --Boundary_(ID_qeJNM+h1zov92cszdyTPVw) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT In response to discussion about how best to enable this feature, and how it interacts with the existing "Directory-based name mapping" feature, I'd like to update the specification. Capsule summary: Instead of adding a new boolean flag to enable this feature, replace the existing boolean controlling directory-based name mapping with a new property "config/directory_based_mapping" with values: none - no directory based mapping name - existing name-based mapping idmu - new IDMU-based mapping To aid in the transition, idmapd(1M) will update the system to use the new property when it encounters the old property. Enclosed please find the revised specification and diffs. I don't personally think this change requires significant additional review time, but if the committee wants me to restart the timer it'd be OK. --Boundary_(ID_qeJNM+h1zov92cszdyTPVw) Content-type: text/plain; name=IDMU-1.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=IDMU-1.txt SUMMARY Integrate Solaris Windows identity management with Microsoft's Identity Management for UNIX (IDMU). BACKGROUND - IDMU Microsoft offers a feature (unbundled for Windows 2003 and before, bundled for Windows 2003R2 and later) called "Identity Management for Unix", or IDMU. (It's part of what was called "Services For Unix" in its unbundled form.) The primary goal of SFU and IDMU is to support Windows as a NIS/NFS server - basically, the same role that we have with CIFS, only reversed. IDMU adds a "UNIX Attributes" panel to the Active Directory Users and Computers user interface that lets the administrator specify a number of UNIX-related parameters: UID, GID, login shell, home directory, and similar for groups. These parameters are made available through AD through a schema similar to (but not the same as) RFC2307, and through NIS service. BACKGROUND - Existing Solaris support for Directory-based identity mapping There is an existing idmap feature "directory-based" or "ds-based" mapping, where user-defined attributes are added to the Active Directory or LDAP schema to provide the UNIX name associated with a Windows identity, or the Windows name associated with a UNIX identity. IDMU is similar to DS-based mapping in its "Active Directory only" mode, but stores numeric UIDs and GIDs in the directory, rather than storing UNIX user and group names. PROBLEM IDMU offers user interface and storage for Windows-UNIX identity mapping information, integrated with Active Directory user/group management. Customers have requested that Solaris identity mapping take advantage of this mechanism. PROPOSAL Replace the existing SMF property used to enable directory-based name mapping with one that allows the administrator to select the existing behavior, IDMU, or neither. DETAILS On the idmap FRMI, svc:/system/idmap:default: * Deprecate the property config/ds_name_mapping_enabled. * Replace it with a new property config/directory_based_mapping, with values: * "none" - no directory-based mapping * "name" - existing name-based mapping * "idmu" - new IDMU-based mapping For implementation reasons and to reduce configuration complexity, IDMU support is mutually exclusive with the existing DS-based mapping support. If idmapd detects that directory_based_mapping is not set, but ds_name_mapping_enabled is set, idmapd will set directory_based_mapping appropriately and delete the setting of ds_name_mapping_enabled. If idmapd detects that both directory_based_mapping and ds_name_mapping_enabled are set, it will delete ds_name mapping_enabled. If they were set to select different behaviors, it will log a warning message. Like the existing name-based mapping, if IDMU data and local name-based mapping rules are both available for a particular identity, the IDMU data will be used. Because IDMU data is maintained on a per-domain basis and Active Directory does not ensure UID uniqueness between domains, this phase of IDMU support will use IDMU data only from the domain to which the Solaris system is joined. COMMENTS It may be possible to use this IDMU support along with the NIS maps exported by the Windows Active Directory server to fully integrate UNIX and Windows identity, managed entirely from the Active Directory user interface. Although this project is a significant component of such a potential integration, this configuration was not a goal and has not been tested. FUTURE A future phase may add the ability for an administrator to allow Solaris to use IDMU data from other domains, with the assumption that the administrator is manually managing the UID space across those domains. DELIVERY VEHICLE Solaris RELEASE Patch COMMITMENT LEVEL Committed (Note that idmap was developed for Solaris Nevada and has not been released for Solaris 10, and so the existing ds_name_mapping_enabled SMF property has never been formally released.) REFERENCE DOCUMENTS Identity Management for UNIX: Welcome (Microsoft Technet) http://technet.microsoft.com/en-us/library/cc782782(WS.10).aspx Integrated Identity Management in Active Directory Domain Services http://technet.microsoft.com/en-us/library/cc780098(WS.10).aspx Includes screen shot of the Active Directory user information dialog box showing the UNIX Attributes panel. MANUAL PAGE Update idmap(1M), in the "Service Properties" section: * Delete the paragraph describing config/ds_name_mapping_enabled. * add a section: config/directory_based_mapping Controls support for identity mapping using data stored in a directory service. "none" disables directory-based mapping. "name" enables name-based mapping using the properties described above. "idmu" enabled mapping using Microsoft's Identity Management for UNIX (IDMU). This Windows component allows the administrator to specify a UNIX user ID for each Windows user, mapping the Windows identity to the corresponding UNIX identity. Only IDMU data from the domain the Solaris system is a member of is used. * Update this paragraph: If configured to use a directory service, idmapd(1M) will first try to use the /- name -/ mapping infomration that is stored on user or group objects in the Active Directory and/or the native LDAP directory service. For example, an AD object for a given Windows user or group can be augmented to include the corresponding Solaris user or group name /+ or numeric id +/. Similarly, the native LDAP object for a given Solaris user or group can be augmented to include the corresponding Windows user or group name. --Boundary_(ID_qeJNM+h1zov92cszdyTPVw) Content-type: text/plain; name=IDMU-1.txt.dif Content-transfer-encoding: 7BIT Content-disposition: inline; filename=IDMU-1.txt.dif diff -r 786e87a47176 IDMU-1.txt --- a/IDMU-1.txt Thu Jul 16 14:39:37 2009 -0700 +++ b/IDMU-1.txt Tue Jul 21 14:00:47 2009 -0700 @@ -40,24 +40,38 @@ PROPOSAL - Add a flag (as an SMF property, like other idmap configuration flags) - that enables use of IDMU data. + Replace the existing SMF property used to enable directory-based + name mapping with one that allows the administrator to select + the existing behavior, IDMU, or neither. DETAILS - On the idmap FRMI, svc:/system/idmap:default, add the property - config/idmu_enabled. True enables IDMU support; false disables - it. The default if the property does not exist is that support is - disabled. + On the idmap FRMI, svc:/system/idmap:default: + + * Deprecate the property config/ds_name_mapping_enabled. + + * Replace it with a new property config/directory_based_mapping, + with values: + * "none" - no directory-based mapping + * "name" - existing name-based mapping + * "idmu" - new IDMU-based mapping For implementation reasons and to reduce configuration complexity, IDMU support is mutually exclusive with the existing DS-based - mapping support. If both are enabled, a warning message will be - logged and DS-based mapping will be disabled. + mapping support. - Like DS-based mapping, if IDMU data and local name-based mapping - rules are both available for a particular identity, the IDMU data - will be used. + If idmapd detects that directory_based_mapping is not set, but + ds_name_mapping_enabled is set, idmapd will set directory_based_mapping + appropriately and delete the setting of ds_name_mapping_enabled. + + If idmapd detects that both directory_based_mapping and + ds_name_mapping_enabled are set, it will delete ds_name + mapping_enabled. If they were set to select different behaviors, + it will log a warning message. + + Like the existing name-based mapping, if IDMU data and local + name-based mapping rules are both available for a particular + identity, the IDMU data will be used. Because IDMU data is maintained on a per-domain basis and Active Directory does not ensure UID uniqueness between domains, this @@ -80,16 +94,6 @@ that the administrator is manually managing the UID space across those domains. -ISSUES - - The current plan is that if both IDMU and DS-based mapping are - enabled, a warning message is logged and DS-based mapping is not - used. In the future, if we were to enable coexistence of the two - features, a system in this state might unexpectedly change - behavior. An alternative proposal is to put the idmap service into - "maintenance" mode if this situation is encounted, to force the - administrator to resolve the conflict. - DELIVERY VEHICLE Solaris @@ -100,10 +104,11 @@ COMMITMENT LEVEL - IDMU support: Committed + Committed - The fact that IDMU and DS-based mapping are incompatible is not an - interface; they might be made compatible in the future. + (Note that idmap was developed for Solaris Nevada and has not been + released for Solaris 10, and so the existing ds_name_mapping_enabled + SMF property has never been formally released.) REFERENCE DOCUMENTS @@ -119,17 +124,34 @@ Update idmap(1M), in the "Service Properties" section: - config/ds_name_mapping_enabled + * Delete the paragraph describing config/ds_name_mapping_enabled. - Enable/disable directory-based name mapping. Note that if - this and config/idmu_enabled are both set to "true", this - value is ignored. + * add a section: - config/idmu_enabled + config/directory_based_mapping - Enables support for Microsoft Identity Management for UNIX - (IDMU). This Windows component allows the administrator to - specify a UNIX user ID for each Windows user, mapping the - Windows identity to the corresponding UNIX identity. - Only IDMU data from the domain the Solaris system is a member - of is used. + Controls support for identity mapping using data stored in a + directory service. + + "none" disables directory-based mapping. + + "name" enables name-based mapping using the properties + described above. + + "idmu" enabled mapping using Microsoft's Identity Management + for UNIX (IDMU). This Windows component allows the + administrator to specify a UNIX user ID for each Windows user, + mapping the Windows identity to the corresponding UNIX + identity. Only IDMU data from the domain the Solaris system is + a member of is used. + + * Update this paragraph: + + If configured to use a directory service, idmapd(1M) will first + try to use the /- name -/ mapping infomration that is stored on + user or group objects in the Active Directory and/or the native + LDAP directory service. For example, an AD object for a given + Windows user or group can be augmented to include the corresponding + Solaris user or group name /+ or numeric id +/. Similarly, the + native LDAP object for a given Solaris user or group can be augmented + to include the corresponding Windows user or group name. --Boundary_(ID_qeJNM+h1zov92cszdyTPVw)-- From Darren.Moffat@Sun.COM Wed Jul 22 02:22:36 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6M9MaJ9024694 for ; Wed, 22 Jul 2009 02:22:36 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6M9MZiV026709 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 22 Jul 2009 02:22:35 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KN600E03FDM7R00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 22 Jul 2009 02:22:34 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KN600DIRFDLZC00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 22 Jul 2009 02:22:34 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6M9MW1u005631 for ; Wed, 22 Jul 2009 09:22:33 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KN600700F7P5Z00@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 22 Jul 2009 10:22:09 +0100 (BST) Received: from [129.156.173.199] ([unknown] [129.156.173.199]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KN6007U7FCQVTD0@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 22 Jul 2009 10:22:02 +0100 (BST) Date: Wed, 22 Jul 2009 10:22:02 +0100 From: Darren J Moffat Subject: Re: IDMU Support for idmap [PSARC/2009/398 FastTrack timeout 07/23/2009] In-reply-to: <4A662D34.1010403@sun.com> Sender: Darren.Moffat@Sun.COM To: Jordan Brown Cc: PSARC-ext@Sun.COM Message-id: <4A66DA3A.4060009@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907162230.n6GMUV9o029818@sac.sfbay.sun.com> <4A662D34.1010403@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20090127) Status: RO Content-Length: 1020 Jordan Brown wrote: > In response to discussion about how best to enable this feature, and how > it interacts with the existing "Directory-based name mapping" feature, > I'd like to update the specification. > > Capsule summary: > > Instead of adding a new boolean flag to enable this feature, replace the > existing boolean controlling directory-based name mapping with a new > property "config/directory_based_mapping" with values: > none - no directory based mapping > name - existing name-based mapping > idmu - new IDMU-based mapping > > To aid in the transition, idmapd(1M) will update the system to use the > new property when it encounters the old property. > > Enclosed please find the revised specification and diffs. > > I don't personally think this change requires significant additional > review time, but if the committee wants me to restart the timer it'd be OK. I'm happy, thank you very much for addressing this and for dealing with the upgrade issue too. -- Darren J Moffat From Jordan.Brown@sun.com Wed Jul 22 10:13:17 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6MHDHTB010686 for ; Wed, 22 Jul 2009 10:13:17 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6MHDEMr028586 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 22 Jul 2009 10:13:17 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KN700M051649A00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 22 Jul 2009 11:13:16 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KN700FTN164MF40@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 22 Jul 2009 11:13:16 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6MHDGgj024297 for ; Wed, 22 Jul 2009 10:13:16 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KN70090008R9900@fe-sfbay-10.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 22 Jul 2009 10:13:16 -0700 (PDT) Received: from [129.145.155.47] ([unknown] [129.145.155.47]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KN7005HU15SG2G0@fe-sfbay-10.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 22 Jul 2009 10:13:04 -0700 (PDT) Date: Wed, 22 Jul 2009 10:13:04 -0700 From: Jordan Brown Subject: 2009/398 IDMU support for idmap - approved Sender: Jordan.Brown@sun.com To: psarc-ext@sun.com Message-id: <4A6748A0.5010009@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Status: RO Content-Length: 43 This case was approved at today's meeting.