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 <jhro...@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.dain...@addomain.com) gid=1028(employ...@ipadomain.zone)
> > groups=1028(employ...@ipadomain.zone),10(wheel),
> 1027(clus...@addomain.com
> > ),1029(sys...@addomain.com),1041(confluence-administrat...@addomain.com
> > ),1060(employees-vancou...@addomain.com),1086(dev...@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.dain...@addomain.com
> > >>> uid=1587(steve.dain...@addomain.com) gid=1028(employees)
> > >>> groups=1028(employees),1041(confluence-administrat...@addomain.com
> > >>> ),1060(employees-vancou...@addomain.com),10(wheel),1027(clus
> > >>> t...@addomain.com
> > >>> ),1086(dev...@addomain.com),1029(sys...@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): [employ...@addomain.com].
> > >>> (Tue Oct 17 14:02:44 2017) [sssd[be[ipadomain.zone]]]
> > >>> [ipa_s2n_get_user_done] (0x0400): [dev...@addomain.com].
> > >>> (Tue Oct 17 14:02:44 2017) [sssd[be[ipadomain.zone]]]
> > >>> [ipa_s2n_get_user_done] (0x0400): [employees-vancou...@addomain.com
> ].
> > >>> (Tue Oct 17 14:02:44 2017) [sssd[be[ipadomain.zone]]]
> > >>> [ipa_s2n_get_user_done] (0x0400): [wh...@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): [sys...@addomain.com].
> > >>> (Tue Oct 17 14:02:44 2017) [sssd[be[ipadomain.zone]]]
> > >>> [ipa_s2n_get_user_done] (0x0400): [clus...@addomain.com].
> > >>>
> > >> _______________________________________________
> > >> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> > >> To unsubscribe send an email to freeipa-users-le...@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
> > >
>
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

Reply via email to