So after following up with Jakub in private we found the source of the issue: the ID range
was indeed the culprit, but the old ID range was being cached in the sssd cache. Removing
the cache and restarting the sssd service, then running `ldbsearch -H
/var/lib/sss/db/cache_<domain> -b cn=ranges,cn=sysdb` verified that the new range
had taken, and a login was successful.
David Eddleman
On 8/10/17, 2:00 PM, "Jakub Hrozek via FreeIPA-users"
<freeipa-users(a)lists.fedorahosted.org> wrote:
On 10 Aug 2017, at 20:15, Eddleman, David via FreeIPA-users
<freeipa-users(a)lists.fedorahosted.org> wrote:
>This probably means the user can’t be resolved at all, so the authentication process
doesn’t even make it to the PAM phase. Does ‘getent passwd user@domainfqdn’ work?
Returns nothing.
>Are you testing on the IDM server itself or on one of the clients? I would suggest to
make the IDM server work first.
On the IDM server itself. I previously tested on a client but I’ve since done a complete
reinstall of the OS and IPA server.
>Either way, you’ll want to enable the SSSD debug logs and take a look there.
The only thing that seems to stand out is an error of “Object SID [SID] has a RID that is
larger than ldap_idmap_range_size”. But from a quick Google search that leads me to
believe that’s a red herring. Otherwise I have a full debug log from when attempting to
login with an AD user.
Could you please share the logs (feel free to send them to me directly if they contain
confidential information) along with the output of “ipa idrange-find” ?
> Don’t use domain-local groups. Domain-local groups can only be
assigned to a cross-forest group membership by accident, IPA needs to be fixed to disallow
that.
Understood. I also tried mapping with a Global group but that returned an error; only
using Domain Local or Universal group seemed to work. But for some reason now attempting
to re-add the group is returning a “trusted domain object not found” error. With a little
testing it seems like the group member is only capable of being added if the AD group is
set as a Domain Local; the previous error occurs if the group is a Global or Universal
one. The forest level is Windows 2012, if that helps at all.
David Eddleman
From: FreeIPA User Group <freeipa-users(a)lists.fedorahosted.org>
Reply-To: FreeIPA User Group <freeipa-users(a)lists.fedorahosted.org>
Date: Wednesday, August 9, 2017 at 8:22 AM
To: FreeIPA User Group <freeipa-users(a)lists.fedorahosted.org>
Cc: Jakub Hrozek <jhrozek(a)redhat.com>
Subject: [Freeipa-users] Re: Unable to login with AD users
On 8 Aug 2017, at 16:58, Eddleman, David via FreeIPA-users
<freeipa-users(a)lists.fedorahosted.org> wrote:
Hello,
I have created a FreeIPA solution using Red Hat’s IDM product.
FreeIPA version: 4.5.0
OS version: RHEL 7.4
I have successfully installed the server portion and can authenticate to it using local
IDM users, such as the ‘admin’ user. I have created a one-way trust between the IPA realm
and an AD realm successfully, as `ipa trust-show` demonstrates, returning the SID of the
domain. I have also created the local POSIX and external groups and mapped them. `ipa
group-show <extgroupname>` returns the external member SID just fine.
However, I cannot authenticate in the server over SSH using one of those AD users. I’ve
checked the HBAC rules and they are fine. One thing I noticed when monitoring the
securelog when testing is that the IDM users make a call to pam_sss, as expected, but the
AD users do not.
This probably means the user can’t be resolved at all, so the authentication process
doesn’t even make it to the PAM phase. Does ‘getent passwd user@domainfqdn’ work?
Are you testing on the IDM server itself or on one of the clients? I would suggest to
make the IDM server work first.
Either way, you’ll want to enable the SSSD debug logs and take a look there.
I have tried multiple ways of passing the user and all are rejected -- user@netbios,
user@domainfqdn, netbios\user, and domainfqdn\user.
Either netbios\user or user@domainfqdn work, the others do not.
The user in question is in a single group in AD, and it has been tested with the group
being both Domain Local and Universal with the same results. There is only one member of
the group, the user that I am attempting login with.
Don’t use domain-local groups. Domain-local groups can only be assigned to a cross-forest
group membership by accident, IPA needs to be fixed to disallow that.
Domain-local groups are just that, local to the domain they are defined in and during
login, the membership to a domain local group from a non-local domain is stripped from the
PAC and would remove the group membership of the user in that group during login.
Have I missed something?
David Eddleman
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org