Thank you for your time, Rob.  I see what I was doing wrong, when I was running `ipa group-find` I wasn't using the `--private` flag, which won't show the primary user groups.  I see that user still has a private group with the corresponding uid-matched gid, so I will go ahead and make the necessary changes.

To answer your second question: other than the IPA users' home directories across the infrastructure we haven't found files/directories owned by this group.

Again thank you for your help,
Devin


On Tue, Apr 16, 2019 at 9:53 AM Rob Crittenden <rcritten@redhat.com> wrote:
Devin Roark via FreeIPA-users wrote:
> Hello,
>
> I have inherited a freeipa cluster and during a cleanup of groups.  We
> discovered one of the groups that was deleted was set as a couple user's
> primary gid in the past, which I'm assuming was a manual process because
> it looks like the default behavior is the standard groupname/gid
> matching the username/uid in FreeIPA.  This causes errors when on
> enrolled hosts, bash runs the id command behind the scenes and
> subsequently breaks some automated pipelines for these users.
>
> Although doing an `ipa group-find --gid=${CORRESPONDING_UID}` doesn't
> return any groups but users still match uid's and gid's,  my thinking is
> if we modify these two users to use their UID's as their primary group
> again the issues will be resolved.
>
> My question is will this have any known unintended consequences?

But the user will still point to a non-existent group so I don't know
that anything will change. Why not create a matching group for the user
with the same name and uid and set the user's gid to that?

I assume you've already checked for files owned by the now-deleted groups.

rob