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 [email protected] > > _______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
