[Freeipa-users] AD Primary Groups are ignored in FreeIPA?

[Simpson Lachlan]

> -----Original Message-----
> From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-
> bounces at redhat.com] On Behalf Of Alexander Bokovoy
> Sent: Monday, 16 May 2016 11:46 PM
> To: Lachlan Musicman
> Cc: freeipa-users at redhat.com
> Subject: Re: [Freeipa-users] AD Primary Groups are ignored in FreeIPA?
> 
> On Mon, 16 May 2016, Lachlan Musicman wrote:
> >Hola,
> >
> >We have an interesting scenario that is hard to find any information on.
> >
> >Due to permission restrictions, a NAS that is mounted and visible by
> >both AD and 'nix clients, every user belongs to a particular primary group.
> What scope these primary groups have in AD?

They are a mix of Global and Universal.

> >When we try doing idoverride's on the groups, it fails with the Primary
> >Group. In some cases, the primary group doesn't even appear in a getent
> >or id request. Sometimes it appears with incorrect name or GID.
> >
> >We have found it hard to get repeatable "failures", but here are two:
> >
> >1. getent group <groupname> (where groupname is any group, but is a
> >primary group for a subset of members)
> >
> > - does not return any member that has groupname as a primary group in AD.
> >
> >2. Overriding a group
> >
> >if the user has that group as a primary group (in AD), it will override
> >the name, but not the GID.
> >else, the override works.
> >
> >There were a number of other unusual results that are hard to explain
> >how to reproduce because it was all so seemingly random.
> Primary groups in AD are a bit complex. SSSD needs to improve on their handling
> as, for example, Samba only recognizes primary groups from AD, not any others,
> and there should be some coherence to make things actually work correctly.

Yep - for us it's a samba issue at the bottom (the last yak to shave is the samba straddling both windows and linux domains, which is a solved problem/fixed constraint).

>
> >I feel like it would be an obvious need - to translate or override AD
> >primary groups to FreeIPA groups, but this doesn't seem possible.
> There is only one primary group for a user. For Kerberos operations we currently
> don't take ID overrides into account when constructing MS-PAC, so if AD users
> comes with GSSAPI to a FreeIPA client, its primary group SID will stay pinned to
> AD's group, ignoring ID overrides.

What is MS-PAC?

> I'm not sure it would be possible to amend primary group SIDs with ID overrides in
> general because a numeric value in the override for a gid does not mean there is
> an actual group with a proper SID and name in FreeIPA for that gid.


Not interested in changing the SID. I want to change the GID. When the AD groups are read in FreeIPA they are given a GID like 1718800000.

I want that GID to be the same as it is in AD - eg 10004. That way, when a user rights to the shared drive on the linux side, the file is given the group ownership 10004. Which, when read on the Windows side, correctly maps to a group of users (instead of an individual). This is working in the current non-IPA system, but that system is not integrated. We want to integrate, hence FreeIPA.

> There is another issue, though. If a users' primary group has a domain local
> scope, FreeIPA will not be able to use that group through the forest boundary, at
> least, it should be ignored according to the AD specs.

Ah, hence the scope question. 

No, none are Domain Local to my knowledge. 

Cheers
L.
This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.