NFSv4 id mapping through IPA ldap server

[Yanlish Hesap]

Hi All.

We have IPA setup in an AD trust to support our Linux fleet. User home
directories are mounted from a Netapp filer (nfs4 with krb5). The filer
performs uid <-> uidNumber mapping required by kerberized nfs4 via IPA ldap
server.

This setup was working well until we patched our RHEL8 IPA servers last
week, specifically:
389-ds-base-1.4.3.23-14.module+el8.5.0+14377+c731dc97.x86_64
was updated to:
389-ds-base-1.4.3.28-7.module+el8.6.0+15293+4900ec12.x86_64
and,
ipa-server-4.9.6-10.module+el8.5.0+13587+92118e57.x86_64
was updated to:
ipa-server-4.9.8-7.module+el8.6.0+14337+19b76db2.x86_64

This seems to have broken something in IPA, the Netapp filer is no longer
able to resolve uid,uidNumber mappings for AD trust users (it still works
for IPA users.

Ad trust is still working, and IPA clients are able to resolve AD users
through sssd, and log them in (only the home directories are not working).

Directory server logs an entry like the following when the filer attempt lo
look up an AD trust user:
[21/Nov/2022:16:46:22.551318734 +1100] conn=14684 op=1 BIND
dn="uid=netapp-ldap-bind,cn=users,cn=accounts,dc=ipa,dc=localdomain"
method=128 version=3
[21/Nov/2022:16:46:22.552177201 +1100] conn=14684 op=1 RESULT err=0 tag=97
nentries=0 wtime=0.000044925 optime=0.000864628 etime=0.000908138
dn="uid=netapp-ldap-bind,cn=users,cn=accounts,dc=ipa,dc=localdomain"
[21/Nov/2022:16:46:22.554028669 +1100] conn=14684 op=2 SRCH
base="dc=ipa,dc=localdomain" scope=2 filter=
"(&(objectClass=posixAccount)(uid=username@localdomain))"
<(&(objectClass=posixAccount)(uid=[e-mail]))> attrs="uid
uidNumber gidNumber userPassword gecos homeDirectory loginShell"
[21/Nov/2022:16:46:22.554212462 +1100] conn=14684 op=2 RESULT err=0 tag=101
nentries=0 wtime=0.000072472 optime=0.000185686 etime=0.000256338
[21/Nov/2022:16:46:24.003556166 +1100] conn=14205 op=10 UNBIND

Any pointers appreciated!

Regards, Yanlish

[Alexander Bokovoy]

On ti, 22 marras 2022, Yanlish Hesap via FreeIPA-users wrote:
> Hi All.
>
> We have IPA setup in an AD trust to support our Linux fleet. User home
> directories are mounted from a Netapp filer (nfs4 with krb5). The filer
> performs uid <-> uidNumber mapping required by kerberized nfs4 via IPA ldap
> server.
>
> This setup was working well until we patched our RHEL8 IPA servers last
> week, specifically:
> 389-ds-base-1.4.3.23-14.module+el8.5.0+14377+c731dc97.x86_64
> was updated to:
> 389-ds-base-1.4.3.28-7.module+el8.6.0+15293+4900ec12.x86_64
> and,
> ipa-server-4.9.6-10.module+el8.5.0+13587+92118e57.x86_64
> was updated to:
> ipa-server-4.9.8-7.module+el8.6.0+14337+19b76db2.x86_64
>
> This seems to have broken something in IPA, the Netapp filer is no longer
> able to resolve uid,uidNumber mappings for AD trust users (it still works
> for IPA users.
>
> Ad trust is still working, and IPA clients are able to resolve AD users
> through sssd, and log them in (only the home directories are not working).
>
> Directory server logs an entry like the following when the filer attempt lo
> look up an AD trust user:
> [21/Nov/2022:16:46:22.551318734 +1100] conn=14684 op=1 BIND
> dn="uid=netapp-ldap-bind,cn=users,cn=accounts,dc=ipa,dc=localdomain"
> method=128 version=3
> [21/Nov/2022:16:46:22.552177201 +1100] conn=14684 op=1 RESULT err=0 tag=97
> nentries=0 wtime=0.000044925 optime=0.000864628 etime=0.000908138
> dn="uid=netapp-ldap-bind,cn=users,cn=accounts,dc=ipa,dc=localdomain"
> [21/Nov/2022:16:46:22.554028669 +1100] conn=14684 op=2 SRCH
> base="dc=ipa,dc=localdomain" scope=2 filter=
> "(&(objectClass=posixAccount)(uid=username@localdomain))"
> <(&(objectClass=posixAccount)(uid=[e-mail]))> attrs="uid
> uidNumber gidNumber userPassword gecos homeDirectory loginShell"
> [21/Nov/2022:16:46:22.554212462 +1100] conn=14684 op=2 RESULT err=0 tag=101
> nentries=0 wtime=0.000072472 optime=0.000185686 etime=0.000256338
> [21/Nov/2022:16:46:24.003556166 +1100] conn=14205 op=10 UNBIND
>
> Any pointers appreciated!

This looks like you are relying on the compat tree functionality for
represent AD users in the compat tree (cn=compat,$BASEDN). Compat tree
is using SSSD on IPA master to resolve these requests so there should be
traces of those operations, if it succeeded/failed. Raise debug logs in
SSSD to see those.

[Yanlish Hesap]

Thanks, I have stumbled upon a solution yesterday, which was to change the
ldap search base to cn=compat,dc=ipa,dc=localdomain (from
dc=ipa,dc=localdomain). The curious thing is "dc=ipa,dc=localdomain" as the
search base was working before the RHEL8 patch cycle. Wondering if that was
a bug that made our lookups work as a fluke, or is it a new thing that
cn=compat needs to be explicitly specified?

Thanks!

On Tue, Nov 22, 2022 at 8:08 PM Alexander Bokovoy 
wrote:
> This looks like you are relying on the compat tree functionality for
> represent AD users in the compat tree (cn=compat,$BASEDN). Compat tree
> is using SSSD on IPA master to resolve these requests so there should be
> traces of those operations, if it succeeded/failed. Raise debug logs in
> SSSD to see those.
>
> --
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland

[Alexander Bokovoy]

On ke, 23 marras 2022, Yanlish Hesap wrote:
> Thanks, I have stumbled upon a solution yesterday, which was to change the
> ldap search base to cn=compat,dc=ipa,dc=localdomain (from
> dc=ipa,dc=localdomain). The curious thing is "dc=ipa,dc=localdomain" as the
> search base was working before the RHEL8 patch cycle. Wondering if that was
> a bug that made our lookups work as a fluke, or is it a new thing that
> cn=compat needs to be explicitly specified?

There were a number of changes in the recent slapi-nis release and it
might be affecting you in this way. Since your search filter will not
match any of IPA users/groups anyway due to explicit use of AD domain as
required for the compat tree, I'd recommend to set the base DN to
cn=compat,dc=ipa,dc=localdomain instead.
> Thanks!
>
> On Tue, Nov 22, 2022 at 8:08 PM Alexander Bokovoy 
> wrote:
> > This looks like you are relying on the compat tree functionality for
> > represent AD users in the compat tree (cn=compat,$BASEDN). Compat tree
> > is using SSSD on IPA master to resolve these requests so there should be
> > traces of those operations, if it succeeded/failed. Raise debug logs in
> > SSSD to see those.
> >
> > --
> > / Alexander Bokovoy
> > Sr. Principal Software Engineer
> > Security / Identity Management Engineering
> > Red Hat Limited, Finland