cross-forest trust, client system cannot id AD users.

[Steve Dainard]

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 [e-mail]
uid=1587([e-mail]) gid=1028(employees)
groups=1028(employees),1041([e-mail]
),1060([e-mail]),10(wheel),1027([e-mail]
),1086([e-mail]),1029([e-mail])

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:

(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): [[e-mail]].
(Tue Oct 17 14:02:44 2017) [sssd[be[ipadomain.zone]]]
[ipa_s2n_get_user_done] (0x0400): [[e-mail]].
(Tue Oct 17 14:02:44 2017) [sssd[be[ipadomain.zone]]]
[ipa_s2n_get_user_done] (0x0400): [[e-mail]].
(Tue Oct 17 14:02:44 2017) [sssd[be[ipadomain.zone]]]
[ipa_s2n_get_user_done] (0x0400): [[e-mail]].
(Tue Oct 17 14:02:44 2017) [sssd[be[ipadomain.zone]]]
[ipa_s2n_get_user_done] (0x0400): [[e-mail]].
(Tue Oct 17 14:02:44 2017) [sssd[be[ipadomain.zone]]]
[ipa_s2n_get_user_done] (0x0400): [[e-mail]].
(Tue Oct 17 14:02:44 2017) [sssd[be[ipadomain.zone]]]
[ipa_s2n_get_user_done] (0x0400): [[e-mail]].

Thanks,
Steve

[Jakub Hrozek]

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 [e-mail]
> uid=1587([e-mail]) gid=1028(employees)
> groups=1028(employees),1041([e-mail]
> ),1060([e-mail]),10(wheel),1027([e-mail]
> ),1086([e-mail]),1029([e-mail])
>
> 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?
> (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): [[e-mail]].
> (Tue Oct 17 14:02:44 2017) [sssd[be[ipadomain.zone]]]
> [ipa_s2n_get_user_done] (0x0400): [[e-mail]].
> (Tue Oct 17 14:02:44 2017) [sssd[be[ipadomain.zone]]]
> [ipa_s2n_get_user_done] (0x0400): [[e-mail]].
> (Tue Oct 17 14:02:44 2017) [sssd[be[ipadomain.zone]]]
> [ipa_s2n_get_user_done] (0x0400): [[e-mail]].
> (Tue Oct 17 14:02:44 2017) [sssd[be[ipadomain.zone]]]
> [ipa_s2n_get_user_done] (0x0400): [[e-mail]].
> (Tue Oct 17 14:02:44 2017) [sssd[be[ipadomain.zone]]]
> [ipa_s2n_get_user_done] (0x0400): [[e-mail]].
> (Tue Oct 17 14:02:44 2017) [sssd[be[ipadomain.zone]]]
> [ipa_s2n_get_user_done] (0x0400): [[e-mail]].

[Justin Stephenson]

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

[Steve Dainard]

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([e-mail]) gid=1028([e-mail])
groups=1028([e-mail]),10(wheel),1027([e-mail]
),1029([e-mail]),1041([e-mail]
),1060([e-mail]),1086([e-mail])
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.

Its still a bit odd that the wheel group appears to be a client local wheel
group rather than @IPADOMAIN. 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 <
[e-mail]> 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 [e-mail]
> > > uid=1587([e-mail]) gid=1028(employees)
> > > groups=1028(employees),1041([e-mail]
> > > ),1060([e-mail]),10(wheel),1027(clus
> > > [e-mail]
> > > ),1086([e-mail]),1029([e-mail])
> > >
> > > 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): [[e-mail]].
> > > (Tue Oct 17 14:02:44 2017) [sssd[be[ipadomain.zone]]]
> > > [ipa_s2n_get_user_done] (0x0400): [[e-mail]].
> > > (Tue Oct 17 14:02:44 2017) [sssd[be[ipadomain.zone]]]
> > > [ipa_s2n_get_user_done] (0x0400): [[e-mail]].
> > > (Tue Oct 17 14:02:44 2017) [sssd[be[ipadomain.zone]]]
> > > [ipa_s2n_get_user_done] (0x0400): [[e-mail]].
> > > (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): [[e-mail]].
> > > (Tue Oct 17 14:02:44 2017) [sssd[be[ipadomain.zone]]]
> > > [ipa_s2n_get_user_done] (0x0400): [[e-mail]].
> >
> > FreeIPA-users mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > rahosted.org
>
> FreeIPA-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Jakub Hrozek]

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

[Steve Dainard]

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