From gww@sac.sfbay.sun.com Tue Nov 20 17:09:08 2007 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 lAL197Ms019838 for ; Tue, 20 Nov 2007 17:09:08 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lAL18mKg019845; Wed, 21 Nov 2007 09:09:07 +0800 (SGT) 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 <0JRU0020L0J37300@brm-avmta-1.central.sun.com>; Tue, 20 Nov 2007 18:09:03 -0700 (MST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JRU00GCY0J3W240@brm-avmta-1.central.sun.com>; Tue, 20 Nov 2007 18:09:03 -0700 (MST) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lAL192wq010899; Tue, 20 Nov 2007 17:09:02 -0800 (PST) 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 lAL191uJ019833; Tue, 20 Nov 2007 17:09:01 -0800 (PST) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id lAL191Zl019829; Tue, 20 Nov 2007 17:09:01 -0800 (PST) Date: Tue, 20 Nov 2007 17:09:01 -0800 (PST) From: Gary Winiger Subject: 2007/663 Winchester directory-based name mapping [FastTrack timeout 11/30/2007] To: PSARC-ext@Sun.COM Cc: nicolas.williams@Sun.COM Message-id: <200711210109.lAL191Zl019829@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 10362 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@example.com to + UNIX user joe by adding the UNIX name to AD object for + joe@example.com. + # idmap set-namemap winuser:joe@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 From Darren.Moffat@sun.com Wed Nov 21 02:52:22 2007 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 lALAqMZJ029088 for ; Wed, 21 Nov 2007 02:52:22 -0800 (PST) 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 lALAqKqG056717 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 21 Nov 2007 03:52:22 -0700 (MST) 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 <0JRU00A03RJ94J00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 21 Nov 2007 02:52:21 -0800 (PST) Received: from gmp-eb-mail-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JRU00BSHRJ8QIC0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 21 Nov 2007 02:52:21 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lALAqKWA005095 for ; Wed, 21 Nov 2007 10:52:20 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JRU00L01MCPSM00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 21 Nov 2007 10:52:20 +0000 (GMT) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JRU00AZ6RIRJA00@fe-emea-10.sun.com>; Wed, 21 Nov 2007 10:52:03 +0000 (GMT) Date: Wed, 21 Nov 2007 10:52:03 +0000 From: Darren J Moffat Subject: Re: 2007/663 Winchester directory-based name mapping [FastTrack timeout 11/30/2007] In-reply-to: <200711210109.lAL191Zl019829@sac.sfbay.sun.com> Sender: Darren.Moffat@sun.com To: Gary Winiger Cc: PSARC-ext@sun.com, Nicolas.Williams@sun.com Message-id: <47440DD3.3040001@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200711210109.lAL191Zl019829@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070924) Status: RO Content-Length: 1002 If I'm understanding this case correctly there are NO new LDAP schema needed for any of the modes, but using one is allowed. Will the LDIF files be shipped as part of Solaris if so where ? (Hint: /usr/share/lib/ldif would be a good place), even as examples it would be nice. Is there a reason why default values for the {nldap,ad}_*_attr properties can't be defined ? I would have thought there might be some reasonable default that could be selected based on the normal schema in use with AD or NLDAP is that not the case ? What is the default value for config/ds_name_mapping_enabled ? I think it is false but I couldn't find it explicitly mentioned in the proposal. What is the behaiour if config/ds_name_mapping_enabled is set to true and none of the _attr properties have a value ? Isn't the _enabled suffix redundant since this property is of type boolean ? Man Page nit, AD is used without reference to that fact that this means "Microsoft Active Directory" -- Darren J Moffat From carlsonj@phorcys.east.sun.com Wed Nov 21 07:02:19 2007 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 lALF2Jc6002361 for ; Wed, 21 Nov 2007 07:02:19 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lALF1iu7036715; Wed, 21 Nov 2007 08:02:18 -0700 (MST) 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 <0JRV0030J33T0U00@brm-avmta-1.central.sun.com>; Wed, 21 Nov 2007 08:02:17 -0700 (MST) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JRV0027G33MY200@brm-avmta-1.central.sun.com>; Wed, 21 Nov 2007 08:02:10 -0700 (MST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id lALF1K3c010214; Wed, 21 Nov 2007 10:01:20 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id lALF1K2c010211; Wed, 21 Nov 2007 10:01:20 -0500 (EST) Date: Wed, 21 Nov 2007 10:01:20 -0500 From: James Carlson Subject: Re: 2007/663 Winchester directory-based name mapping [FastTrack timeout 11/30/2007] In-reply-to: <200711210109.lAL191Zl019829@sac.sfbay.sun.com> To: Gary Winiger Cc: PSARC-ext@sun.com, Nicolas.Williams@sun.com Message-id: <18244.18496.636352.47397@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200711210109.lAL191Zl019829@sac.sfbay.sun.com> Status: RO Content-Length: 1569 Gary Winiger writes: > + config/ad_unixuser_attr > + Specify the name of the AD attribute that contains the UNIX > + user name. There is no default. Unless I misunderstand how this is supposed to be used, it sounds like the schema for AD is really placed into the hands of the administrator, and thus could be different at every site, or even between groups within a site. And it will need to be separately configured on every client system. The logical conclusion is that you'll probably need to associate attribute names with particular LDAP servers, and I don't see how that'd be done with this proposal. This sounds at least a little messy, as though we're handing users a kit of parts and telling them to build a system out of it. Is there any way we can avoid exposing so much of the internal design to users? Why can't there be default names reserved? > 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. Architectural issues have nothing to do with the management structure or the project team composition. Is this project delivering through the same consolidation as libsldap? If not, then either a contract will be needed or the library's stability will need to be promoted. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Nicolas.Williams@sun.com Wed Nov 21 08:41:50 2007 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 lALGfnLN003613 for ; Wed, 21 Nov 2007 08:41:49 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lALGfaZI004459; Wed, 21 Nov 2007 16:41:47 GMT 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 <0JRV00K0T7PMW100@nwk-avmta-1.sfbay.Sun.COM>; Wed, 21 Nov 2007 08:41:47 -0800 (PST) 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 <0JRV007467PLGJC0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 21 Nov 2007 08:41:46 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lALGfia8028252; Wed, 21 Nov 2007 10:41:44 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lALGfiaJ028251; Wed, 21 Nov 2007 10:41:44 -0600 (CST) Date: Wed, 21 Nov 2007 10:41:44 -0600 From: Nicolas Williams Subject: Re: 2007/663 Winchester directory-based name mapping [FastTrack timeout 11/30/2007] In-reply-to: <47440DD3.3040001@Sun.COM> To: Darren J Moffat Cc: Gary Winiger , PSARC-ext@sun.com Mail-followup-to: Darren J Moffat , Gary Winiger , PSARC-ext@sun.com Message-id: <20071121164144.GA28246@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200711210109.lAL191Zl019829@sac.sfbay.sun.com> <47440DD3.3040001@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: 1595 On Wed, Nov 21, 2007 at 10:52:03AM +0000, Darren J Moffat wrote: > If I'm understanding this case correctly there are NO new LDAP schema > needed for any of the modes, but using one is allowed. No, schema extensions are required for all modes. > Will the LDIF files be shipped as part of Solaris if so where ? (Hint: > /usr/share/lib/ldif would be a good place), even as examples it would be > nice. We certainly could. Our intention had been to have them in the docs.sun.com guide book only. > Is there a reason why default values for the {nldap,ad}_*_attr > properties can't be defined ? I would have thought there might be some > reasonable default that could be selected based on the normal schema in > use with AD or NLDAP is that not the case ? We're following others' lead in the market. > What is the default value for config/ds_name_mapping_enabled ? I think > it is false but I couldn't find it explicitly mentioned in the proposal. It has to be false since values for some of the other properties have to be provided before idmapd can perform ds name mapping. > What is the behaiour if config/ds_name_mapping_enabled is set to true > and none of the _attr properties have a value ? A message will be logged to LOG_WARN and the feature will remain disabled. > Isn't the _enabled suffix redundant since this property is of type boolean ? Hmmm, I don't think so -- users looking at the property name alone wouldn't know its type. > Man Page nit, AD is used without reference to that fact that this means > "Microsoft Active Directory" We'll fix that. Nico -- From Nicolas.Williams@Sun.COM Wed Nov 21 08:45:19 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lALGjJR1003667 for ; Wed, 21 Nov 2007 08:45:19 -0800 (PST) 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 lALGjGJL021718; Wed, 21 Nov 2007 08:45:18 -0800 (PST) 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 <0JRV00B057VI6V00@brm-avmta-1.central.sun.com>; Wed, 21 Nov 2007 09:45:18 -0700 (MST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JRV002WT7VHXJ70@brm-avmta-1.central.sun.com>; Wed, 21 Nov 2007 09:45:17 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lALGjHDe028259; Wed, 21 Nov 2007 10:45:17 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lALGjHXE028258; Wed, 21 Nov 2007 10:45:17 -0600 (CST) Date: Wed, 21 Nov 2007 10:45:17 -0600 From: Nicolas Williams Subject: Re: 2007/663 Winchester directory-based name mapping [FastTrack timeout 11/30/2007] In-reply-to: <18244.18496.636352.47397@gargle.gargle.HOWL> To: James Carlson Cc: Gary Winiger , PSARC-ext@Sun.COM Mail-followup-to: James Carlson , Gary Winiger , PSARC-ext@sun.com Message-id: <20071121164516.GB28246@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200711210109.lAL191Zl019829@sac.sfbay.sun.com> <18244.18496.636352.47397@gargle.gargle.HOWL> 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: 1532 On Wed, Nov 21, 2007 at 10:01:20AM -0500, James Carlson wrote: > Gary Winiger writes: > > + config/ad_unixuser_attr > > + Specify the name of the AD attribute that contains the UNIX > > + user name. There is no default. > > Unless I misunderstand how this is supposed to be used, it sounds like > the schema for AD is really placed into the hands of the > administrator, and thus could be different at every site, or even > between groups within a site. And it will need to be separately > configured on every client system. Correct. > The logical conclusion is that you'll probably need to associate > attribute names with particular LDAP servers, and I don't see how > that'd be done with this proposal. Not particular LDAP servers but particular domains. > This sounds at least a little messy, as though we're handing users a > kit of parts and telling them to build a system out of it. Is there > any way we can avoid exposing so much of the internal design to users? > Why can't there be default names reserved? We've been asked to provide a feature found in other products, and this is what they do. > > 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. > > Architectural issues have nothing to do with the management structure > or the project team composition. > > Is this project delivering through the same consolidation as libsldap? Yes. Nico -- From Darren.Moffat@sun.com Wed Nov 21 08:53:53 2007 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 lALGrqYu003821 for ; Wed, 21 Nov 2007 08:53:53 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lALGrYfq008334 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 22 Nov 2007 00:53:51 +0800 (SGT) 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 <0JRV00M0389QJI00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Nov 2007 08:53:50 -0800 (PST) Received: from gmp-eb-mail-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 <0JRV007MY89PGJD0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Nov 2007 08:53:50 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lALGrnav021254 for ; Wed, 21 Nov 2007 16:53:49 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JRV00H0189B2500@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Nov 2007 16:53:49 +0000 (GMT) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JRV000MG89NNU20@fe-emea-09.sun.com>; Wed, 21 Nov 2007 16:53:48 +0000 (GMT) Date: Wed, 21 Nov 2007 16:53:47 +0000 From: Darren J Moffat Subject: Re: 2007/663 Winchester directory-based name mapping [FastTrack timeout 11/30/2007] In-reply-to: <20071121164144.GA28246@Sun.COM> Sender: Darren.Moffat@sun.com To: Darren J Moffat , Gary Winiger , PSARC-ext@sun.com Message-id: <4744629B.9080202@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200711210109.lAL191Zl019829@sac.sfbay.sun.com> <47440DD3.3040001@Sun.COM> <20071121164144.GA28246@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20070924) Status: RO Content-Length: 2090 Nicolas Williams wrote: > On Wed, Nov 21, 2007 at 10:52:03AM +0000, Darren J Moffat wrote: >> If I'm understanding this case correctly there are NO new LDAP schema >> needed for any of the modes, but using one is allowed. > > No, schema extensions are required for all modes. > >> Will the LDIF files be shipped as part of Solaris if so where ? (Hint: >> /usr/share/lib/ldif would be a good place), even as examples it would be >> nice. > > We certainly could. Our intention had been to have them in the > docs.sun.com guide book only. We made that mistake with the RBAC Schema and avoided it in PSARC/2006/277 (Kerberos records in LDAP) that case also created /usr/share/lib/ldif/ and basically set precedence that that is where they go. >> Is there a reason why default values for the {nldap,ad}_*_attr >> properties can't be defined ? I would have thought there might be some >> reasonable default that could be selected based on the normal schema in >> use with AD or NLDAP is that not the case ? > > We're following others' lead in the market. Why can't we be better ? >> What is the default value for config/ds_name_mapping_enabled ? I think >> it is false but I couldn't find it explicitly mentioned in the proposal. > > It has to be false since values for some of the other properties have to > be provided before idmapd can perform ds name mapping. I thought so. >> What is the behaiour if config/ds_name_mapping_enabled is set to true >> and none of the _attr properties have a value ? > > A message will be logged to LOG_WARN and the feature will remain > disabled. But the service won't go into maintenance mode, even though it is clearly misconfigured ? >> Isn't the _enabled suffix redundant since this property is of type boolean ? > > Hmmm, I don't think so -- users looking at the property name alone > wouldn't know its type. How would you be looking at it and not see it's type ? svcprop(1) shows you the property and so does the svccfg(1) listprop sub command. It isn't a big issue it just looked redundant to me. -- Darren J Moffat From Nicolas.Williams@sun.com Wed Nov 21 09:09:11 2007 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 lALH9Aj5004363 for ; Wed, 21 Nov 2007 09:09:11 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lALH8tCf031649; Wed, 21 Nov 2007 10:09:09 -0700 (MST) 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 <0JRV0080D8Z86F00@nwk-avmta-2.sfbay.sun.com>; Wed, 21 Nov 2007 09:09:08 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JRV0074P8Z4TQ10@nwk-avmta-2.sfbay.sun.com>; Wed, 21 Nov 2007 09:09:04 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lALH93YX028307; Wed, 21 Nov 2007 11:09:03 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lALH93Rt028306; Wed, 21 Nov 2007 11:09:03 -0600 (CST) Date: Wed, 21 Nov 2007 11:09:03 -0600 From: Nicolas Williams Subject: Re: 2007/663 Winchester directory-based name mapping [FastTrack timeout 11/30/2007] In-reply-to: <4744629B.9080202@Sun.COM> To: Darren J Moffat Cc: Gary Winiger , PSARC-ext@sun.com Mail-followup-to: Darren J Moffat , Gary Winiger , PSARC-ext@sun.com Message-id: <20071121170903.GD28246@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200711210109.lAL191Zl019829@sac.sfbay.sun.com> <47440DD3.3040001@Sun.COM> <20071121164144.GA28246@Sun.COM> <4744629B.9080202@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: 2954 On Wed, Nov 21, 2007 at 04:53:47PM +0000, Darren J Moffat wrote: > Nicolas Williams wrote: > >On Wed, Nov 21, 2007 at 10:52:03AM +0000, Darren J Moffat wrote: > >>If I'm understanding this case correctly there are NO new LDAP schema > >>needed for any of the modes, but using one is allowed. > > > >No, schema extensions are required for all modes. > > > >>Will the LDIF files be shipped as part of Solaris if so where ? (Hint: > >>/usr/share/lib/ldif would be a good place), even as examples it would be > >>nice. > > > >We certainly could. Our intention had been to have them in the > >docs.sun.com guide book only. > > We made that mistake with the RBAC Schema and avoided it in > PSARC/2006/277 (Kerberos records in LDAP) that case also created > /usr/share/lib/ldif/ and basically set precedence that that is where > they go. Then we'll ship them there. > >>Is there a reason why default values for the {nldap,ad}_*_attr > >>properties can't be defined ? I would have thought there might be some > >>reasonable default that could be selected based on the normal schema in > >>use with AD or NLDAP is that not the case ? > > > >We're following others' lead in the market. > > Why can't we be better ? Any default attribute names that we picked would be completely arbitrary and are not likely to match usage on the field (about which we do not have enough information, thus we don't know what attribute names users use most commonly -- users have had to pick them arbitrarily also). > >>What is the behaiour if config/ds_name_mapping_enabled is set to true > >>and none of the _attr properties have a value ? > > > >A message will be logged to LOG_WARN and the feature will remain > >disabled. > > But the service won't go into maintenance mode, even though it is > clearly misconfigured ? It can still provide ephemeral mapping and name-based mapping rules. Suppose there are no name-based mapping rules: idmapd can still map SIDs to ephemeral UIDs and GIDs. Later, when the sysadmin notices the problem they can fix ds-name mapping, refresh the service and now the old ephemeral IDs will still map to the SIDs that were previously mapped ephemerally but some or all of those SIDs may now map to non-ephemeral UIDs and GIDs. OTOH, putting the service in maintenance would be a much more obvious indication of trouble. We'll make this change then. > >>Isn't the _enabled suffix redundant since this property is of type > >>boolean ? > > > >Hmmm, I don't think so -- users looking at the property name alone > >wouldn't know its type. > > How would you be looking at it and not see it's type ? If you delete the property then you won't be able to see it :) > svcprop(1) shows you the property and so does the svccfg(1) listprop sub > command. It isn't a big issue it just looked redundant to me. Right, it's just a property name. We'll take your advice if you insist, but I don't agree that it's redundant. Nico -- From Darren.Moffat@sun.com Wed Nov 21 09:19:21 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lALHJLuu004637 for ; Wed, 21 Nov 2007 09:19:21 -0800 (PST) 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 lALHJKxZ004711 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 21 Nov 2007 09:19:21 -0800 (PST) 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 <0JRV0030X9G8CD00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Nov 2007 09:19:20 -0800 (PST) Received: from gmp-eb-mail-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 <0JRV001WE9G62Q00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Nov 2007 09:19:19 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lALHJIBc023645 for ; Wed, 21 Nov 2007 17:19:18 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JRV00J019AYUP00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Nov 2007 17:19:18 +0000 (GMT) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JRV00AT09G5JA20@fe-emea-10.sun.com>; Wed, 21 Nov 2007 17:19:17 +0000 (GMT) Date: Wed, 21 Nov 2007 17:19:17 +0000 From: Darren J Moffat Subject: Re: 2007/663 Winchester directory-based name mapping [FastTrack timeout 11/30/2007] In-reply-to: <20071121170903.GD28246@Sun.COM> Sender: Darren.Moffat@sun.com To: Darren J Moffat , Gary Winiger , PSARC-ext@sun.com Message-id: <47446895.6060607@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200711210109.lAL191Zl019829@sac.sfbay.sun.com> <47440DD3.3040001@Sun.COM> <20071121164144.GA28246@Sun.COM> <4744629B.9080202@Sun.COM> <20071121170903.GD28246@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20070924) Status: RO Content-Length: 2406 Nicolas Williams wrote: >>>> Is there a reason why default values for the {nldap,ad}_*_attr >>>> properties can't be defined ? I would have thought there might be some >>>> reasonable default that could be selected based on the normal schema in >>>> use with AD or NLDAP is that not the case ? >>> We're following others' lead in the market. >> Why can't we be better ? > > Any default attribute names that we picked would be completely > arbitrary and are not likely to match usage on the field (about which we > do not have enough information, thus we don't know what attribute names > users use most commonly -- users have had to pick them arbitrarily > also). Okay thats fine then. >>>> What is the behaiour if config/ds_name_mapping_enabled is set to true >>>> and none of the _attr properties have a value ? >>> A message will be logged to LOG_WARN and the feature will remain >>> disabled. >> But the service won't go into maintenance mode, even though it is >> clearly misconfigured ? > > It can still provide ephemeral mapping and name-based mapping rules. > > Suppose there are no name-based mapping rules: idmapd can still map SIDs > to ephemeral UIDs and GIDs. Later, when the sysadmin notices the That was the point, just firing off to syslog wouldn't get it noticed. > problem they can fix ds-name mapping, refresh the service and now the > old ephemeral IDs will still map to the SIDs that were previously mapped > ephemerally but some or all of those SIDs may now map to non-ephemeral > UIDs and GIDs. > > OTOH, putting the service in maintenance would be a much more obvious > indication of trouble. We'll make this change then. Thanks, that makes more sense here since the intent was obviously there to use that feature. >>>> Isn't the _enabled suffix redundant since this property is of type >>>> boolean ? >>> Hmmm, I don't think so -- users looking at the property name alone >>> wouldn't know its type. >> How would you be looking at it and not see it's type ? > > If you delete the property then you won't be able to see it :) > >> svcprop(1) shows you the property and so does the svccfg(1) listprop sub >> command. It isn't a big issue it just looked redundant to me. > > Right, it's just a property name. We'll take your advice if you insist, > but I don't agree that it's redundant. I don't insist so feel free to leave it as is. -- Darren J Moffat From carlsonj@phorcys.east.sun.com Wed Nov 21 09:28:13 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lALHSDka004737 for ; Wed, 21 Nov 2007 09:28:13 -0800 (PST) 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 lALHSCrJ007375; Wed, 21 Nov 2007 09:28:12 -0800 (PST) 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 <0JRV0041V9UYRO00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 21 Nov 2007 09:28:10 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JRV001IN9UW2R10@nwk-avmta-1.sfbay.Sun.COM>; Wed, 21 Nov 2007 09:28:09 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id lALHRGpM011512; Wed, 21 Nov 2007 12:27:19 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id lALHRFhQ011509; Wed, 21 Nov 2007 12:27:15 -0500 (EST) Date: Wed, 21 Nov 2007 12:27:15 -0500 From: James Carlson Subject: Re: 2007/663 Winchester directory-based name mapping [FastTrack timeout 11/30/2007] In-reply-to: <20071121164516.GB28246@Sun.COM> To: Nicolas Williams Cc: PSARC-ext@sun.com, Gary Winiger Message-id: <18244.27251.941082.723217@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200711210109.lAL191Zl019829@sac.sfbay.sun.com> <18244.18496.636352.47397@gargle.gargle.HOWL> <20071121164516.GB28246@Sun.COM> Status: RO Content-Length: 2599 Nicolas Williams writes: > On Wed, Nov 21, 2007 at 10:01:20AM -0500, James Carlson wrote: > > The logical conclusion is that you'll probably need to associate > > attribute names with particular LDAP servers, and I don't see how > > that'd be done with this proposal. > > Not particular LDAP servers but particular domains. OK, yes, that's what I meant. There's no good way to do that, is there? (I'm thinking ahead to what this means for NWAM. I'm not sure how a user would manage that sort of configuration.) > > This sounds at least a little messy, as though we're handing users a > > kit of parts and telling them to build a system out of it. Is there > > any way we can avoid exposing so much of the internal design to users? > > Why can't there be default names reserved? > > We've been asked to provide a feature found in other products, and this > is what they do. I understand that. I was hoping we could manage to do better, though. (My mother would ask, "if all your friends decided to jump off a bridge, would you?") Can we at least suggest some recommended names? If nothing else, that'll encourage more people to set up their systems that way by default and lessen the chance of having the service just break in ordinary use. > > > 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. > > > > Architectural issues have nothing to do with the management structure > > or the project team composition. > > > > Is this project delivering through the same consolidation as libsldap? > > Yes. In that case, the fact that it's "Contracted" is immaterial. It's Consolidation Private, which means that others in the consolidation may use it without needing any special coordination. (I suspect that someone is laboring under a misunderstanding of the "Contracted" modifier. It means that contracts *exist* on the interface, and thus it serves as a warning to the supplier that the interface can't change the way the supplier would expect, and does not mean that contracts are *required.* The requirement for contracts follows the natural usage boundaries of the interface: if you're in the same consolidation, then Consolidation Private is open to you, otherwise it requires a contract.) -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Darren.Moffat@sun.com Wed Nov 21 09:32:13 2007 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 lALHWCf7004831 for ; Wed, 21 Nov 2007 09:32:12 -0800 (PST) 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 lALHW9Ls042259 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 21 Nov 2007 10:32:12 -0700 (MST) 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 <0JRV0050JA1ODG00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Nov 2007 09:32:12 -0800 (PST) Received: from gmp-eb-mail-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 <0JRV0019KA1M2Y10@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Nov 2007 09:32:11 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lALHWAWb024752 for ; Wed, 21 Nov 2007 17:32:10 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JRV008019MPVA00@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Nov 2007 17:32:10 +0000 (GMT) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JRV000SQA12NU20@fe-emea-09.sun.com>; Wed, 21 Nov 2007 17:31:50 +0000 (GMT) Date: Wed, 21 Nov 2007 17:31:50 +0000 From: Darren J Moffat Subject: Re: 2007/663 Winchester directory-based name mapping [FastTrack timeout 11/30/2007] In-reply-to: <18244.27251.941082.723217@gargle.gargle.HOWL> Sender: Darren.Moffat@sun.com To: James Carlson Cc: Nicolas Williams , PSARC-ext@sun.com, Gary Winiger Message-id: <47446B86.9080200@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200711210109.lAL191Zl019829@sac.sfbay.sun.com> <18244.18496.636352.47397@gargle.gargle.HOWL> <20071121164516.GB28246@Sun.COM> <18244.27251.941082.723217@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.6 (X11/20070924) Status: RO Content-Length: 980 James Carlson wrote: >>> This sounds at least a little messy, as though we're handing users a >>> kit of parts and telling them to build a system out of it. Is there >>> any way we can avoid exposing so much of the internal design to users? >>> Why can't there be default names reserved? >> We've been asked to provide a feature found in other products, and this >> is what they do. > > I understand that. I was hoping we could manage to do better, though. > (My mother would ask, "if all your friends decided to jump off a > bridge, would you?") > > Can we at least suggest some recommended names? If nothing else, > that'll encourage more people to set up their systems that way by > default and lessen the chance of having the service just break in > ordinary use. There are suggested names in the sample schema in the case dir. I suggested, and the team has agreed to, include them in /usr/share/lib/ldif/ so I guess they have already done that. -- Darren J Moffat From carlsonj@phorcys.east.sun.com Wed Nov 21 09:47:54 2007 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 lALHlr2i004975 for ; Wed, 21 Nov 2007 09:47:53 -0800 (PST) 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 lALHldjO003930; Thu, 22 Nov 2007 01:47:49 +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 <0JRV0090BARMXO00@nwk-avmta-2.sfbay.sun.com>; Wed, 21 Nov 2007 09:47:46 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JRV007PLARLTU40@nwk-avmta-2.sfbay.sun.com>; Wed, 21 Nov 2007 09:47:45 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id lALHkuJ5014468; Wed, 21 Nov 2007 12:46:56 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id lALHktPe014465; Wed, 21 Nov 2007 12:46:55 -0500 (EST) Date: Wed, 21 Nov 2007 12:46:55 -0500 From: James Carlson Subject: Re: 2007/663 Winchester directory-based name mapping [FastTrack timeout 11/30/2007] In-reply-to: <47446B86.9080200@Sun.COM> To: Darren J Moffat Cc: Nicolas Williams , PSARC-ext@sun.com, Gary Winiger Message-id: <18244.28431.956413.718709@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200711210109.lAL191Zl019829@sac.sfbay.sun.com> <18244.18496.636352.47397@gargle.gargle.HOWL> <20071121164516.GB28246@Sun.COM> <18244.27251.941082.723217@gargle.gargle.HOWL> <47446B86.9080200@Sun.COM> Status: RO Content-Length: 771 Darren J Moffat writes: > James Carlson wrote: > > Can we at least suggest some recommended names? If nothing else, > > that'll encourage more people to set up their systems that way by > > default and lessen the chance of having the service just break in > > ordinary use. > > There are suggested names in the sample schema in the case dir. I > suggested, and the team has agreed to, include them in > /usr/share/lib/ldif/ so I guess they have already done that. But not as defaults for the configuration options themselves? I'm confused. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Nicolas.Williams@sun.com Wed Nov 21 09:52:31 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lALHqV1o005074 for ; Wed, 21 Nov 2007 09:52:31 -0800 (PST) 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 lALHqSUU015788; Wed, 21 Nov 2007 09:52:28 -0800 (PST) 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 <0JRV00G1BAZG9600@brm-avmta-1.central.sun.com>; Wed, 21 Nov 2007 10:52:28 -0700 (MST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JRV002HOAZEXZB0@brm-avmta-1.central.sun.com>; Wed, 21 Nov 2007 10:52:27 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lALHqQSj028372; Wed, 21 Nov 2007 11:52:26 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lALHqQV2028371; Wed, 21 Nov 2007 11:52:26 -0600 (CST) Date: Wed, 21 Nov 2007 11:52:26 -0600 From: Nicolas Williams Subject: Re: 2007/663 Winchester directory-based name mapping [FastTrack timeout 11/30/2007] In-reply-to: <18244.28431.956413.718709@gargle.gargle.HOWL> To: James Carlson Cc: Darren J Moffat , PSARC-ext@sun.com, Gary Winiger Mail-followup-to: James Carlson , Darren J Moffat , PSARC-ext@sun.com, Gary Winiger Message-id: <20071121175225.GJ28246@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200711210109.lAL191Zl019829@sac.sfbay.sun.com> <18244.18496.636352.47397@gargle.gargle.HOWL> <20071121164516.GB28246@Sun.COM> <18244.27251.941082.723217@gargle.gargle.HOWL> <47446B86.9080200@Sun.COM> <18244.28431.956413.718709@gargle.gargle.HOWL> 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: 841 On Wed, Nov 21, 2007 at 12:46:55PM -0500, James Carlson wrote: > Darren J Moffat writes: > > James Carlson wrote: > > > Can we at least suggest some recommended names? If nothing else, > > > that'll encourage more people to set up their systems that way by > > > default and lessen the chance of having the service just break in > > > ordinary use. > > > > There are suggested names in the sample schema in the case dir. I > > suggested, and the team has agreed to, include them in > > /usr/share/lib/ldif/ so I guess they have already done that. > > But not as defaults for the configuration options themselves? I'm > confused. They are examples. We didn't feel comfortable picking default names. Of course, nothing stops us -- we can pick some, but they're not likely to be correct in any environment where such attributes exist. From jek3@sun.com Mon Nov 26 18:10:13 2007 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 lAR2ADYs024510 for ; Mon, 26 Nov 2007 18:10:13 -0800 (PST) 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 lAR2ACuQ042514; Mon, 26 Nov 2007 19:10:12 -0700 (MST) 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 <0JS5000017CY4R00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 26 Nov 2007 18:10:10 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JS500MHR7CX8K10@nwk-avmta-1.sfbay.Sun.COM>; Mon, 26 Nov 2007 18:10:09 -0800 (PST) Received: from [129.150.12.137] (vpn-129-150-12-137.SFBay.Sun.COM [129.150.12.137]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id lAR2A8OB792141; Mon, 26 Nov 2007 18:10:09 -0800 (PST) Date: Mon, 26 Nov 2007 16:09:37 -1000 From: Joseph Kowalski Subject: Re: 2007/663 Winchester directory-based name mapping [FastTrack timeout 11/30/2007] In-reply-to: <200711210109.lAL191Zl019829@sac.sfbay.sun.com> To: Gary Winiger Cc: PSARC-ext@sun.com, nicolas.williams@sun.com Message-id: <474B7C61.9010704@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200711210109.lAL191Zl019829@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 1830 Gary Winiger wrote: > 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). > Jim and Darren seem to have already expressed concern about "can't we do better"? This does seem to follow some other vendor's half-baked implementation. This discussion seems to have been interrupted by the break - I hope the discussion continues. > - 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. > Just for my information, why would somebody used Mixed mode? > 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) > In the OpenSolaris context, I wouldn't think that the community would be very empathetic to this rationale. Is this project complete? Specifically, it seems that any proposed phasing which implements a feature without the fully supported administrative tools just seems wrong. I don't see an issue with the ordering/separation of the modes, but the tools must be there with the first integration. - jek3 From Nicolas.Williams@sun.com Mon Nov 26 19:35:16 2007 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 lAR3ZF96026361 for ; Mon, 26 Nov 2007 19:35:16 -0800 (PST) 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 lAR3Z7LM003445; Tue, 27 Nov 2007 11:35:12 +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 <0JS500K05BAM4A00@nwk-avmta-2.sfbay.sun.com>; Mon, 26 Nov 2007 19:35:10 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JS5001DIBALK5F0@nwk-avmta-2.sfbay.sun.com>; Mon, 26 Nov 2007 19:35:10 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lAR3Z939001160; Mon, 26 Nov 2007 21:35:09 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lAR3Z8if001159; Mon, 26 Nov 2007 21:35:08 -0600 (CST) Date: Mon, 26 Nov 2007 21:35:08 -0600 From: Nicolas Williams Subject: Re: 2007/663 Winchester directory-based name mapping [FastTrack timeout 11/30/2007] In-reply-to: <474B7C61.9010704@sun.com> To: Joseph Kowalski Cc: Gary Winiger , PSARC-ext@sun.com Mail-followup-to: Joseph Kowalski , Gary Winiger , PSARC-ext@sun.com Message-id: <20071127033508.GM776@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200711210109.lAL191Zl019829@sac.sfbay.sun.com> <474B7C61.9010704@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: 3811 On Mon, Nov 26, 2007 at 04:09:37PM -1000, Joseph Kowalski wrote: > Gary Winiger wrote: > >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). > > > Jim and Darren seem to have already expressed concern about "can't we do > better"? This does seem to follow some other vendor's half-baked > implementation. I believe we've addressed Darren's issue to his satisfaction, I'll answer your and James' questions below. > This discussion seems to have been interrupted by the break - I hope the > discussion continues. Indeed, it has been. There are good reasons why we must allow the attribute names to be configurable and why we cannot provide default attribute names. Namely: - Consider a customer with multiple NIS domains with similar, but not quite the same content. This happens a lot in real life (we have one customer with some 30 such domains). Now, if you're mapping Windows users to Unix users, but the usernames for Joe Random are different in several NIS domains... well, then if we don't allow the attribute names to be configurable then such a customer could not cope. - We could pick default attribute names, but a) if our defaults are incorrect for some customer then enabling the feature would be sufficient to get the idmap service to come online, but insufficient to function correctly, and b) we're not likely to pick good defaults, both because of the user's potential need for multiple sets of attributes (see above) and because of the existing deployments where users had to pick arbitrary attribute names. To provide default attribute values would mean negating the value of the advice that Darren gave us (to put the service in maintenance if ds-based mapping is enabled but the necessary attribute names are not configured). > > - 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. > > > Just for my information, why would somebody used Mixed mode? Because it allows you to have asymetry in mapping. E.g., you can map multiple Windows users to one Unix user and vice versa. We already support this now via name-based mapping rules (see the -d option of the idmap(1M) add sub-command -- -d stands for 'directional'). > >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) > > > In the OpenSolaris context, I wouldn't think that the community would > be very empathetic to this rationale. Is this project complete? I don't follow this. How does OpenSolaris make any difference here vs. pre-OpenSolaris days? > Specifically, it seems that any proposed phasing which implements a > feature without the fully supported administrative tools just seems > wrong. I don't see an issue with the ordering/separation of the > modes, but the tools must be there with the first integration. There exist tools already, namely ldapmodify(1) and a variety of directory browser applications. Nico -- From jek3@sun.com Tue Nov 27 11:42:27 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lARJgRBo019487 for ; Tue, 27 Nov 2007 11:42:27 -0800 (PST) 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 lARJgRF1029130; Tue, 27 Nov 2007 11:42:27 -0800 (PST) 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 <0JS60050JK2Q7V00@brm-avmta-1.central.sun.com>; Tue, 27 Nov 2007 12:42:26 -0700 (MST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JS600ENCK2ODEC0@brm-avmta-1.central.sun.com>; Tue, 27 Nov 2007 12:42:24 -0700 (MST) Received: from [129.150.12.137] (vpn-129-150-12-137.SFBay.Sun.COM [129.150.12.137]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id lARJgN43142278; Tue, 27 Nov 2007 11:42:24 -0800 (PST) Date: Tue, 27 Nov 2007 09:41:52 -1000 From: Joseph Kowalski Subject: Re: 2007/663 Winchester directory-based name mapping [FastTrack timeout 11/30/2007] In-reply-to: <20071127033508.GM776@Sun.COM> To: Joseph Kowalski , Gary Winiger , PSARC-ext@sun.com Message-id: <474C7300.6000300@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200711210109.lAL191Zl019829@sac.sfbay.sun.com> <474B7C61.9010704@sun.com> <20071127033508.GM776@Sun.COM> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 4608 Nicolas Williams wrote: > On Mon, Nov 26, 2007 at 04:09:37PM -1000, Joseph Kowalski wrote: > >> Gary Winiger wrote: >> >>> 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). >>> >>> >> Jim and Darren seem to have already expressed concern about "can't we do >> better"? This does seem to follow some other vendor's half-baked >> implementation. >> > > I believe we've addressed Darren's issue to his satisfaction, I'll > answer your and James' questions below. > > >> This discussion seems to have been interrupted by the break - I hope the >> discussion continues. >> > > Indeed, it has been. > > There are good reasons why we must allow the attribute names to be > configurable and why we cannot provide default attribute names. Namely: > > - Consider a customer with multiple NIS domains with similar, but not > quite the same content. This happens a lot in real life (we have one > customer with some 30 such domains). Now, if you're mapping Windows > users to Unix users, but the usernames for Joe Random are different > in several NIS domains... well, then if we don't allow the attribute > names to be configurable then such a customer could not cope. > > - We could pick default attribute names, but > > a) if our defaults are incorrect for some customer then enabling the > feature would be sufficient to get the idmap service to come online, > but insufficient to function correctly, > > and > > b) we're not likely to pick good defaults, both because of the user's > potential need for multiple sets of attributes (see above) and > because of the existing deployments where users had to pick arbitrary > attribute names. > > To provide default attribute values would mean negating the value of the > advice that Darren gave us (to put the service in maintenance if > ds-based mapping is enabled but the necessary attribute names are not > configured). > Hummm,... Perhaps additional documentation? A cheat sheet for the common case? It just seems that we are just throwing too much stuff at a administrator, without sufficient guidance. >>> - 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. >>> >>> >> Just for my information, why would somebody used Mixed mode? >> > > Because it allows you to have asymetry in mapping. E.g., you can map > multiple Windows users to one Unix user and vice versa. We already > support this now via name-based mapping rules (see the -d option of the > idmap(1M) add sub-command -- -d stands for 'directional'). > Thanks. >>> 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) >>> >>> >> In the OpenSolaris context, I wouldn't think that the community would >> be very empathetic to this rationale. Is this project complete? >> > > I don't follow this. How does OpenSolaris make any difference here vs. > pre-OpenSolaris days? > The proposed phasing is to accommodate Sun's internal needs/dependencies. Why should OpenSolaris be subject to a phased integration, particularly when the project doesn't seem to be complete in the initial phases. >> Specifically, it seems that any proposed phasing which implements a >> feature without the fully supported administrative tools just seems >> wrong. I don't see an issue with the ordering/separation of the >> modes, but the tools must be there with the first integration. >> > > There exist tools already, namely ldapmodify(1) and a variety of > directory browser applications. > It seems that the preferred interface is idmap(1M), right? I'm really uncomfortable with the phasing,... perhaps "derail uncomfortable"... > Nico > - jek3 From gww@eng.sun.com Tue Nov 27 16:11:24 2007 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 lAS0BNxs001159 for ; Tue, 27 Nov 2007 16:11:24 -0800 (PST) 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 lAS0BCFT002948; Wed, 28 Nov 2007 08:11:21 +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 <0JS600E0LWIRC100@nwk-avmta-2.sfbay.sun.com>; Tue, 27 Nov 2007 16:11:15 -0800 (PST) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JS600AQUWIQ5I50@nwk-avmta-2.sfbay.sun.com>; Tue, 27 Nov 2007 16:11:14 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id lAS0BEOo002474; Tue, 27 Nov 2007 16:11:14 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id lAS09h8V004318; Tue, 27 Nov 2007 16:09:43 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id lAS09hrF004317; Tue, 27 Nov 2007 16:09:43 -0800 (PST) Date: Tue, 27 Nov 2007 16:09:43 -0800 (PST) From: Gary Winiger Subject: Re: 2007/663 Winchester directory-based name mapping [FastTrack timeout 11/30/2007] To: PSARC-ext@sun.com, gww@sac.sfbay.sun.com, jek3@sun.com Message-id: <200711280009.lAS09hrF004317@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 2060 > >>> 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) > >>> > >>> > >> In the OpenSolaris context, I wouldn't think that the community would > >> be very empathetic to this rationale. Is this project complete? > >> > > > > I don't follow this. How does OpenSolaris make any difference here vs. > > pre-OpenSolaris days? > > > The proposed phasing is to accommodate Sun's internal > needs/dependencies. Why > should OpenSolaris be subject to a phased integration, particularly when > the project > doesn't seem to be complete in the initial phases. Sun's internal issues are not architectural here. IMO, the question is is the project complete with AD-only mode and no idmap sub-commands. If it's judged not to be complete, then how do we make it complete? Is it sufficient to document how to talk to AD with the local ldap client interfaces? Afterall the AD admin needs to configure the AD Schema (if not already present) and the Solaris admin has to configure the the SMF properties. Would we really expect the Solaris admin to then configure the mappings, or would we expect either that the AD admin has a preexisting set of mappings or would configure them on AD? It seems to me if the operational model is that the configuration (except for the properties) is done on AD, then documentation needs to be supplied by the project team to accommodate that and the project is complete in phase 1. If on the other hadn the operational model is that the Solaris admin does the mappings, then I'm concerned that native ldap commands are sufficiently intuative to use. Gary.. From Nicolas.Williams@sun.com Wed Nov 28 13:44:29 2007 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 lASLiSOw008296 for ; Wed, 28 Nov 2007 13:44:28 -0800 (PST) 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 lASLiPiX029161; Wed, 28 Nov 2007 21:44:26 GMT 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 <0JS800909KE0BH00@nwk-avmta-2.sfbay.sun.com>; Wed, 28 Nov 2007 13:44:24 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JS8007CSKE0I030@nwk-avmta-2.sfbay.sun.com>; Wed, 28 Nov 2007 13:44:24 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lASLiJlj002486; Wed, 28 Nov 2007 15:44:19 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lASLiJqv002485; Wed, 28 Nov 2007 15:44:19 -0600 (CST) Date: Wed, 28 Nov 2007 15:44:19 -0600 From: Nicolas Williams Subject: Re: 2007/663 Winchester directory-based name mapping [FastTrack timeout 11/30/2007] In-reply-to: <200711280009.lAS09hrF004317@marduk.eng.sun.com> To: Gary Winiger Cc: PSARC-ext@sun.com, gww@sac.sfbay.sun.com, jek3@sun.com Mail-followup-to: Gary Winiger , PSARC-ext@sun.com, gww@sac.sfbay.sun.com, jek3@sun.com Message-id: <20071128214418.GH1524@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200711280009.lAS09hrF004317@marduk.eng.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: 735 This case was approved today. The spec changes agreed to are: - If ds-based mapping is enabled (see config/ds_name_mapping_enabled property) then at least one set of config/*_attr and config/*_class attributes must be set, otherwise the service will go into maintenance on startup. - We will ship schema LDIF files in /usr/share/lib/ldif/. - We will include pointers to Windows documentation on how to make Active Directory schema changes and how to manipulate the new attributes of Windows users and groups. For the record, one very good Windows documentation URL for this is: http://technet.microsoft.com/en-us/library/Bb727064.aspx - We will integrate phase 3 at the same time as phase 2. Nico -- From gww@eng.sun.com Fri Nov 30 11:36:34 2007 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 lAUJaXel016179 for ; Fri, 30 Nov 2007 11:36:34 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lAUJaUeA022554 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Fri, 30 Nov 2007 19:36:33 GMT 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 <0JSC0000P3SUSG00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 30 Nov 2007 11:36:30 -0800 (PST) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSC00I3F3STHBB0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 30 Nov 2007 11:36:29 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id lAUJaTFa022742; Fri, 30 Nov 2007 11:36:29 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id lAUJYuAt027540; Fri, 30 Nov 2007 11:34:56 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id lAUJYumJ027539; Fri, 30 Nov 2007 11:34:56 -0800 (PST) Date: Fri, 30 Nov 2007 11:34:56 -0800 (PST) From: Gary Winiger Subject: Re: 2007/663 Winchester directory-based name mapping [FastTrack timeout 11/30/2007] To: PSARC-ext@sun.com Cc: nicolas.williams@sun.com Message-id: <200711301934.lAUJYumJ027539@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 387 This case was approved for phased delivery at the 28 Nov. PSARC meeting as Nico noted with the understanding that the initial phase will support only Active Directory and name mapping will be administered on the AD system by an AD admin. The second phase will include other directory servers and idmap(1M) subcommands for name mapping administration by the Solaris admin. Gary.. From Nicolas.Williams@sun.com Fri Mar 21 11:42:20 2008 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 m2LIgJeM019513 for ; Fri, 21 Mar 2008 11:42:19 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m2LIgGsk018407 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Sat, 22 Mar 2008 02:42:18 +0800 (SGT) 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 <0JY300405FYHN800@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 21 Mar 2008 11:42:17 -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 <0JY300063FYHGJ80@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 21 Mar 2008 11:42:17 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m2LIgDkJ022290 for ; Fri, 21 Mar 2008 13:42:13 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m2LIgDcV022289 for psarc-ext@sun.com; Fri, 21 Mar 2008 13:42:13 -0500 (CDT) Date: Fri, 21 Mar 2008 13:42:13 -0500 From: Nicolas Williams Subject: Updated schema update instructions for [PSARC/2007/663] To: psarc-ext@sun.com Mail-followup-to: psarc-ext@sun.com Message-id: <20080321184213.GR16998@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 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: 286 We've obtained 5 OIDs from the Sun OID arc for identifying the LDAP schema objects involved in this case. We've correspondingly also updated the schema update instructions and placed them in a new file in the case directory: schema-extension-instructions-2008-03-21.txt Nico --