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@lists.fedorahosted.org> wrote:
> On 10 Aug 2017, at 20:15, Eddleman, David via FreeIPA-users
<freeipa-users@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@lists.fedorahosted.org>
> Reply-To: FreeIPA User Group <freeipa-users@lists.fedorahosted.org>
> Date: Wednesday, August 9, 2017 at 8:22 AM
> To: FreeIPA User Group <freeipa-users@lists.fedorahosted.org>
> Cc: Jakub Hrozek <jhro...@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@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@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
>
>
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
