This case *looks* fairly obvious. I can't think of any situation where
the new behavior would be undesirable relative to the old behavior.
It seems, though, that this is possibly too useful not to backport.
Having a disagreement here between Solaris 10 and OpenSolaris
authentication seems potentially problematic. Hence, if this change is
approved, I'd actually recommend backporting it as well.
So +1 from me. Hopefully Gary is also reviewing this and making sure
that neither Nico nor I are missing anything.
- Garrett
Gary Winiger wrote:
> This case was never published to psarc-ext. I'm doing so on behalf
> of Nico (the I below) and extending the timer for a week from publication.
>
> Gary..
> ======
> I'm submitting this fasttrack on behalf of Erwin Aitenbichler, an
> OpenSolaris contributor. The release binding is micro/patch (with no
> intention to backport). This case introduces new behavior in
> nss_ldap(5) that rises to the level of an interface; this behavior will
> be Committed.
>
> BACKGROUND
>
> Microsoft's Active Directory (AD) can be used as Solaris name service
> repository through nss_ldap(5) by using Windows Identity Management
> for Unix (IDMU) or Service For Unix (SFU) and configuring schema
> mapping on the Solaris native LDAP clients. This is true on Solaris
> 10, Solaris Nevada, and OpenSolaris.
>
> PROBLEM
>
> AD supports richer group (as in Unix group) semantics than Unix. For
> example, it supports nested groups. But nss_ldap(5) does not support
> these semantics.
>
> Specifically, nss_ldap(5) uses the RFC2307bis+ memberUid attribute of
> group objects to construct a list of all users in a group. Whereas
> AD uses a different attribute, 'member', containing not UIDs but the
> DNs of members' directory objects (which may be users and groups
> alike). Also, each group object has a 'memberof' attribute listing the
> groups that the group is a member of.
>
> PROPOSAL
>
> nss_ldap(5)'s getbynam/getbygid entry points will use the 'member'
> attribute if the memberUid attribute is not present or has an empty
> value for the given group, but the member attribute is present and
> has a non-empty value. And nss_ldap(5) will expand the list of
> members recursively by searching the directory for each listed member
> and looking up any member group's members.
>
> nss_ldap(5)'s getbymember entry point will find the user's DN and
> then will query all groups a user is member of using this DN. For
> each group, the memberof attribute will be chased recursively to
> obtain the full list of groups that the user is a member of directly
> or indirectly.
>
> In both cases loops in group membership will be detected to prevent
> infinite looping.
>
> No additional configuration is needed to enable this feature.
>
>
