Externally defined, cross-domain group membership. Prohibited?

[Nordgren, Bryce L -FS]

I have an external LDAP metadirectory acting as an identity provider for my linux domain.
The metadirectory overrides and supplements the upstream identity source (e.g., it passes
thru sn, givenName, mail, telephoneNumber; but overrides or adds uidNumber, gidNumber,
loginShell, etc.) The directory also holds RFC2307 group information, and the groups
contain members from multiple upstream sources. Authentication via simple bind (for web
apps) is passed thru to the relevant upstream provider. LDAP works great.

For command line login, I want to use Kerberos. Each upstream provider is configured as a
domain within sssd which uses LDAP for identities and Kerberos for authentication. The
local, linux domain-wide groups are included as one of the domain definitions, but not the
others. For instance, I have defined domain A, B, and C. Domain A contains group
information having members from all three. Domains B and C essentially have no groups
defined.

"Getent passwd user works." Authentication works.  "getent group test"
works, initially...SSSD is removing users from my group. sss_cache -G restores the user
(i.e., getent group test includes the user), but the first time the user tries to exercise
their permissions by accessing a file on the filesystem, they get a permission denied and
are removed from the group (getent group test does not include the user).

Are cross-realm groups something that sssd is designed to prohibit?




This electronic message contains information generated by the USDA solely for the intended
recipients. Any unauthorized interception of this message or the use or disclosure of the
information it contains may violate the law and subject the violator to civil or criminal
penalties. If you believe you have received this message in error, please notify the
sender and delete the email immediately.

[Simo Sorce]

On Mon, 2014-08-11 at 18:31 +0000, Nordgren, Bryce L -FS wrote:
>  I have an external LDAP metadirectory acting as an identity provider
>  for my linux domain. The metadirectory overrides and supplements the
>  upstream identity source (e.g., it passes thru sn, givenName, mail,
>  telephoneNumber; but overrides or adds uidNumber, gidNumber,
>  loginShell, etc.) The directory also holds RFC2307 group information,
>  and the groups contain members from multiple upstream sources.
>  Authentication via simple bind (for web apps) is passed thru to the
>  relevant upstream provider. LDAP works great.
>  
>  For command line login, I want to use Kerberos. Each upstream provider
>  is configured as a domain within sssd which uses LDAP for identities
>  and Kerberos for authentication. The local, linux domain-wide groups
>  are included as one of the domain definitions, but not the others. For
>  instance, I have defined domain A, B, and C. Domain A contains group
>  information having members from all three. Domains B and C essentially
>  have no groups defined.
>  
>  "Getent passwd user works." Authentication works.  "getent group
> test"
>  works, initially...SSSD is removing users from my group. sss_cache -G
>  restores the user (i.e., getent group test includes the user), but the
>  first time the user tries to exercise their permissions by accessing a
>  file on the filesystem, they get a permission denied and are removed
>  from the group (getent group test does not include the user).
>  
>  Are cross-realm groups something that sssd is designed to prohibit? 
Yes, sssd silos each identity domain completely, the only 'exception' is
local groups but that's almost an accident of how nsswitch worked
historically.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

[Nordgren, Bryce L -FS]

>  Yes, sssd silos each identity domain completely, the only
> 'exception' is local
>  groups but that's almost an accident of how nsswitch worked historically.
>  
Would you consider an RFE to add a "posix domain" group definition (or perhaps
"global groups")? That way, group info brought in via individual domain
declarations would be siloed (because it is assumed to have been defined upstream, where
only the users from that domain are available), but there's at least the possibility
of allowing central control over grouping the set of users available to the local machine.
Frankly, with the exception of the attributes which describe the human (name, contact
info, etc.) I don't have much use for upstream identity information, and I need to
adapt it.

Likewise, a "local domain override" option for identity information would be
useful. (e.g., define an identity store in the global section, to be used by any domain
with "override" in the id slot.) This indicates that mapping/overrides/collision
resolution is handled at the domain level, while still allowing the individual
specification of upstream authentication sources. I'm currently doing this with
OpenLDAP's translucent proxy, but it sounds like the FreeIPA notion of views is
heading in this same direction and will require the same support from sssd.

For the moment, my need is small enough that I can implement a workaround with filesystem
ACLs, but I intend to have bigger needs.




This electronic message contains information generated by the USDA solely for the intended
recipients. Any unauthorized interception of this message or the use or disclosure of the
information it contains may violate the law and subject the violator to civil or criminal
penalties. If you believe you have received this message in error, please notify the
sender and delete the email immediately.