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

[Joseph Kowalski]

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