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