Hi Jakub,

As a follow up, you are correct - neither the primary group or wheel group that existed in AD needed to be created in IPA.

Thanks

On Fri, Oct 20, 2017 at 1:01 AM, Jakub Hrozek <jhrozek@redhat.com> wrote:
On Thu, Oct 19, 2017 at 05:34:41PM -0700, Steve Dainard wrote:
> Thanks Jakub and Justin,
>
> It definitely is related to the wheel group. For a quick explanation, the
> wheel group exists in AD with a gid of 10 so users who belong to that group
> automatically have wheel/sudo perms on EL systems (we use posix attributes
> in AD for all our users/groups).
>
> The easy fix seems to have been to add a wheel group with gid 10 to the IPA
> side, no group members. Now I get:
>  uid=1587(steve.dainard@ADDOMAIN.com) gid=1028(employees@IPADOMAIN.zone)
> groups=1028(employees@IPADOMAIN.zone),10(wheel),1027(cluster@ADDOMAIN.com
> ),1029(sysops@ADDOMAIN.com),1041(confluence-administrators@ADDOMAIN.com
> ),1060(employees-vancouver@ADDOMAIN.com),1086(devops@ADDOMAIN.com)
> context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
>
> I got the idea from the RH IPA docs mentioning if a user has a primary
> group in AD with a gid, the group must also exist in IPA albeit doesn't
> need any members.
> If this step isn't completed some secondary group
> memberships may not be resolved on the IPA side.

Maybe the docs are not totally clear, but the requirement is a bit different
-- it is actually that each GID number the user is a member of (as reported
by "id -G") must be resolvable into a group object with getgrgid() (or,
with getent group $gidnumber) on the command line.

>
> Its still a bit odd that the wheel group appears to be a client local wheel
> group rather than @IPADOMAIN.

I think this is because /etc/nsswitch.conf defines "groups" as "files sss".

So the initgroups operation returns a list of gids, which are then translated
into names, but because files precedes sss, the local group name is used first.

By the way, you might be interested in
https://sourceware.org/glibc/wiki/Proposals/GroupMerging

(I keep forgetting it this is already backported to RHEL-7, though..)

> The 'employees@IPADOMAIN' group listed above
> is actually the primary gid in AD Unix attributes, and is defined in IPA
> with the same gid but has no members. I'm guess this is because an EL host
> /etc/group defines 'wheel' by default, but not 'employees'.
>
> Once we get IPA into production I'll pull the wheel group out of AD and
> keep it defined in IPA only.
>
> Thanks,
> Steve
>
> On Thu, Oct 19, 2017 at 11:37 AM, Justin Stephenson via FreeIPA-users <
> freeipa-users@lists.fedorahosted.org> wrote:
>
> > On 10/19/2017 02:14 PM, Jakub Hrozek via FreeIPA-users wrote:
> >
> >> On Tue, Oct 17, 2017 at 02:21:07PM -0700, Steve Dainard via FreeIPA-users
> >> wrote:
> >>
> >>> Hello,
> >>>
> >>> I've installed a 60 day 'self supported' trial of red hat idm on rhel7.
> >>> I've created a cross-forest trust with an AD domain (2012R2) which
> >>> already
> >>> has posix attributes in ldap for users and groups.
> >>>
> >>> On my ipa server I can id/getent my AD user, and can SSH to the ipa
> >>> server
> >>> with my AD credentials/kerberos ticket.
> >>> # id steve.dainard@ADDOMAIN.com
> >>> uid=1587(steve.dainard@ADDOMAIN.com) gid=1028(employees)
> >>> groups=1028(employees),1041(confluence-administrators@ADDOMAIN.com
> >>> ),1060(employees-vancouver@ADDOMAIN.com),10(wheel),1027(clus
> >>> ter@ADDOMAIN.com
> >>> ),1086(devops@ADDOMAIN.com),1029(sysops@ADDOMAIN.com)
> >>>
> >>> I installed Centos 7.4 and joined it to the realm but I'm having
> >>> intermittent issues id'ing users. At first I couldn't id any AD user, but
> >>> then I added a trusted domain ldap_search_base to the ipa servers
> >>> sssd.conf:
> >>>
> >>> ldap_search_base = OU=Employees,OU=Users,OU=Accounts,DC=ADDOMAIN,DC=com
> >>>
> >>> This initially seemed to work intermittently, some users I could id and
> >>> some I could not. I also noticed that the group membership of the users I
> >>> could id was incomplete, notably I have an AD group 'wheel' with gid 10
> >>> that shows on the ipa server side when I id my AD user, but didn't show
> >>> on
> >>> the client side.
> >>>
> >>> I decided to clear out the cache files manually and restart sssd on the
> >>> client, and now I can't id my user, but I can id users outside of the
> >>> ldap_search_base, specifically user accounts which are inactive and exist
> >>> in a inactive-users OU ouside the ldap_search_base. Very confusing.
> >>>
> >>> The sssd server side seems to be iterating through all my AD users
> >>> account
> >>> names in the logs (debug_level = 10) and I don't feel comfortable posting
> >>> logs with their complete names online..
> >>>
> >>>
> >>> IPA server sssd.conf:
> >>>
> >>> [domain/IPADOMAIN.zone]
> >>> cache_credentials = True
> >>> krb5_store_password_if_offline = True
> >>> ipa_domain = IPADOMAIN.zone
> >>> id_provider = ipa
> >>> auth_provider = ipa
> >>> access_provider = ipa
> >>> ipa_hostname = ipa001.IPADOMAIN.zone
> >>> chpass_provider = ipa
> >>> ipa_server = ipa001.IPADOMAIN.zone
> >>> ipa_server_mode = True
> >>> ldap_tls_cacert = /etc/ipa/ca.crt
> >>> debug_level = 10
> >>>
> >>> [sssd]
> >>> services = sudo, nss, ifp, pam, ssh
> >>> domains = IPADOMAIN.zone
> >>> debug_level = 10
> >>>
> >>> [domain/IPADOMAIN.zone/ADDOMAIN.com]
> >>> ldap_search_base = OU=Employees,OU=Users,OU=Accounts,DC=ADDOMAIN,DC=com
> >>> debug_level = 10
> >>>
> >>> [nss]
> >>> memcache_timeout = 600
> >>> homedir_substring = /home
> >>>
> >>> [pam]
> >>>
> >>> [sudo]
> >>>
> >>> [autofs]
> >>>
> >>> [ssh]
> >>>
> >>> [pac]
> >>>
> >>> [ifp]
> >>>
> >>> [secrets]
> >>>
> >>>
> >>>
> >>>
> >>> IPA client ssd.conf:
> >>>
> >>> [domain/IPADOMAIN.zone]
> >>> cache_credentials = true
> >>> krb5_store_password_if_offline = true
> >>> ipa_domain = IPADOMAIN.zone
> >>> id_provider = ipa
> >>> auth_provider = ipa
> >>> ipa_hostname = pearl-pavella.IPADOMAIN.zone
> >>> chpass_provider = ipa
> >>> access_provider = ipa
> >>> ipa_server = _srv_, ipa001.IPADOMAIN.zone
> >>> ldap_tls_cacert = /etc/ipa/ca.crt
> >>> debug_level = 10
> >>>
> >>> [sssd]
> >>> services = nss, pam, sudo, ssh
> >>> domains = IPADOMAIN.zone
> >>> default_domain_suffix = ADDOMAIN.com
> >>> debug_level = 10
> >>>
> >>> [nss]
> >>> homedir_substring = /home
> >>> entry_negative_timeout = 1
> >>>
> >>> [pam]
> >>>
> >>> [sudo]
> >>>
> >>> [autofs]
> >>>
> >>> [ssh]
> >>>
> >>> [pac]
> >>>
> >>>
> >>> # id steve.dainard
> >>> id: steve.dainard: no such user
> >>>
> >>> I've attached the client side sssd_ipadomain.zone.log file. Most
> >>> interestingly I see my AD group memberships are at least listed in this
> >>> log, but oddly the 'wheel' group is @ the ipadomain which should be the
> >>> addomain. I don't have a wheel group on the ipa side, so this seems to be
> >>> the groups list the ipa server resolved and it matches its local wheel
> >>> group gid 10 which was passed along to the client:
> >>>
> >>
> >> I think the local wheel group might be at least one the problems. The
> >> piece that sends the group list to the client decides (based on how the
> >> names are qualified, for now at least) which domain does the group
> >> belong to. And since this is a local group, the output is not qualified,
> >> which is then translated into the IPA domain on the client.
> >>
> >> But you also said, the wheel group should be in the AD domain, so I'm
> >> not sure how does the AD group relate to the local wheel group after all?
> >>
> >
> > I have seen similar issues which happen when very low POSIX gid numbers
> > are assigned in AD causing a lookup conflict with local groups due to
> > matching GID.
> >
> > I would suggest looking for any gidNumber=10 objects in AD and either
> > change the gidNumber or remove the group membership from the affected user,
> > it should be safe to avoid conflicts using id numbers greater than 1000.
> >
> > Kind regards,
> > Justin Stephenson
> >
> >
> >
> >>
> >>> (Tue Oct 17 14:02:44 2017) [sssd[be[ipadomain.zone]]]
> >>> [ipa_s2n_get_user_done] (0x0400): Received [7] groups in group list from
> >>> IPA Server
> >>> (Tue Oct 17 14:02:44 2017) [sssd[be[ipadomain.zone]]]
> >>> [ipa_s2n_get_user_done] (0x0400): [employees@addomain.com].
> >>> (Tue Oct 17 14:02:44 2017) [sssd[be[ipadomain.zone]]]
> >>> [ipa_s2n_get_user_done] (0x0400): [devops@addomain.com].
> >>> (Tue Oct 17 14:02:44 2017) [sssd[be[ipadomain.zone]]]
> >>> [ipa_s2n_get_user_done] (0x0400): [employees-vancouver@addomain.com].
> >>> (Tue Oct 17 14:02:44 2017) [sssd[be[ipadomain.zone]]]
> >>> [ipa_s2n_get_user_done] (0x0400): [wheel@ipadomain.zone].
> >>> (Tue Oct 17 14:02:44 2017) [sssd[be[ipadomain.zone]]]
> >>> [ipa_s2n_get_user_done] (0x0400): [confluence-administrators@add
> >>> omain.com].
> >>> (Tue Oct 17 14:02:44 2017) [sssd[be[ipadomain.zone]]]
> >>> [ipa_s2n_get_user_done] (0x0400): [sysops@addomain.com].
> >>> (Tue Oct 17 14:02:44 2017) [sssd[be[ipadomain.zone]]]
> >>> [ipa_s2n_get_user_done] (0x0400): [cluster@addomain.com].
> >>>
> >> _______________________________________________
> >> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> >> To unsubscribe send an email to freeipa-users-leave@lists.fedo
> >> rahosted.org
> >>
> >> _______________________________________________
> > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> > To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
> >