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 <[email protected]> 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([email protected]) gid=1028([email protected]) > > groups=1028([email protected]),10(wheel), > 1027([email protected] > > ),1029([email protected]),1041([email protected] > > ),1060([email protected]),1086([email protected]) > > 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 < > > [email protected]> 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 [email protected] > > >>> uid=1587([email protected]) gid=1028(employees) > > >>> groups=1028(employees),1041([email protected] > > >>> ),1060([email protected]),10(wheel),1027(clus > > >>> [email protected] > > >>> ),1086([email protected]),1029([email protected]) > > >>> > > >>> 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): [[email protected]]. > > >>> (Tue Oct 17 14:02:44 2017) [sssd[be[ipadomain.zone]]] > > >>> [ipa_s2n_get_user_done] (0x0400): [[email protected]]. > > >>> (Tue Oct 17 14:02:44 2017) [sssd[be[ipadomain.zone]]] > > >>> [ipa_s2n_get_user_done] (0x0400): [[email protected] > ]. > > >>> (Tue Oct 17 14:02:44 2017) [sssd[be[ipadomain.zone]]] > > >>> [ipa_s2n_get_user_done] (0x0400): [[email protected]]. > > >>> (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): [[email protected]]. > > >>> (Tue Oct 17 14:02:44 2017) [sssd[be[ipadomain.zone]]] > > >>> [ipa_s2n_get_user_done] (0x0400): [[email protected]]. > > >>> > > >> _______________________________________________ > > >> FreeIPA-users mailing list -- [email protected] > > >> To unsubscribe send an email to [email protected] > > >> rahosted.org > > >> > > >> _______________________________________________ > > > FreeIPA-users mailing list -- [email protected] > > > To unsubscribe send an email to freeipa-users-leave@lists. > fedorahosted.org > > > >
_______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
