On Mon, Oct 7, 2019, at 11:00 AM, Spike White wrote: > James, > [Moved response below] > > On Mon, Oct 7, 2019 at 9:51 AM James Cassell > <fedoraproj...@cyberpear.com> wrote: > > On Mon, Oct 7, 2019, at 10:32 AM, Spike White wrote: > > > James, > > > > > > Let me see if I understand your statement. Suppose my desired UID for > > > admspike_white is 1234. So using POSIX attributes, you had assigned > > > uidNumber == 1234 and gidNumber == 1234 on the user account > > > admspike_white in AD. For each user you had done this. > > > > > > But you had not do the step further and created an actual group object > > > with name 'admspike_white' and gidNumber == 1234. > > > > > > If that's correct, to my mind: > > > > > > 1. without auto_private_groups, your user's account reference to > > > gidNumber == 1234 is a "dangling reference". A reference to a group > > > object that does not exist in your AD deployment. > > > 2. with auto_private_groups, sssd takes the uidNumber (of 1234), > > > invents the fiction of a group with the same name and gidNumber of > > > 1234. id admspike_white reports this fiction as the primary group. In > > > this case, the gidNumber == 1234 would be ignored by sssd (except it'd > > > be reported as one of the supplemental groups in the 'id' command). > > > > > > Do I have this right? > > > > > > > > > All correct except with auto_private_groups, the primary gid shows as the > > gidNumber, but it resolves the group name to the username, so there is no > > nameless group. ...iirc, without the gidNumber, the user failed to resolve > > at all. > >
> Yeah ok. But it's not really "resolving" the group name. That is, it's > not looking up in AD for a group with that gidNumber and returning the > name of that group. > By resolving, I meant from an nss perspective. > sssd internally is inventing the fiction of a group with the same group > name as the user name and the same gidNumber as the user's uidNumber. > So with auto_private_groups = true, id would return the same whether > you set gidNumber on the user account or not. (sssd is ignoring that > field for primary group when auto_private_group == true). > Just tested it. Without auto_private_groups = True, sssd fails entirely to resolve users without gidNumber set. Instead,`id user-no-gid` returns "no such user" With `auto_private_groups = True`, it behaves as you describe, "creating" a group named for the user. V/r, James Cassell > Spike > > > > V/r, > > James Cassell > > > > > > > Spike > > > > > > > > > On Fri, Oct 4, 2019 at 11:17 AM Goetz, Patrick G > > <pgo...@math.utexas.edu> wrote: > > > > > > > > > > > > On 10/4/19 8:21 AM, James Cassell wrote: > > > > > We had previously assigned POSIX attributes to all users in AD. We > > assigned a uidNumber to each user and also a gidNumber that is the same > > number as the uidNumber for each given user. > > > > > > > > Wait, you did this in AD? How? I thought all the SIDs need to be > > > > unique because everything in AD is in a single namespace. > > > > > > > > _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
