389-ds-base

Clone
Source Code
GIT

#48929 IPA ID override DNs are not resolved properly
Closed: wontfix None Opened 7 years ago by mbabinsk.

Closed: wontfix
Reopen Issue

When modifying user ID overrides in FreeIPA using idoverrideuser-mod, direcotry server fails to resolve object DNs and throws error 32 when searching for the modified user override. 

[root@master1 freeipa-4-2-3]# ipa idoverrideuser-add test_view tuser
------------------------------
Added User ID override "tuser"
------------------------------
  Anchor to override: tuser
[root@master1 freeipa-4-2-3]# ipa idoverrideuser-show test_view tuser --all 
  dn: ipaanchoruuid=:IPA:ipa.test:ab06513c-4dc2-11e6-bd25-52540037867b,cn=test_view,cn=views,cn=accounts,dc=ipa,dc=test
  Anchor to override: tuser
  ipaoriginaluid: tuser
  objectclass: ipaSshGroupOfPubKeys, ipaOverrideAnchor, top, ipaUserOverride, ipasshuser
[root@master1 freeipa-4-2-3]# ipa idoverrideuser-mod test_view tuser --shell /bin/bash
ipa: ERROR: an internal error has occurred
[root@master1 freeipa-4-2-3]# systemctl restart dirsrv@IPA-TEST.service 
[root@master1 freeipa-4-2-3]# ipa idoverrideuser-show test_view tuser --all 
ipa: ERROR: tuser: User ID override not found
[root@master1 freeipa-4-2-3]# rpm -q 389-ds-base
389-ds-base-1.3.5.10-1.fc24.x86_64

After downgrading 389-ds-base and restarting directory server the DNs are searched for properly and ID views work as expected.

[root@master1 freeipa-4-2-3]# dnf install -y 389-ds-base-1.3.5.6-1.fc24.x86_64 --allowerasing

[root@master1 freeipa-4-2-3]# systemctl restart dirsrv@IPA-TEST.service 
[root@master1 freeipa-4-2-3]# ipa idoverrideuser-show test_view tuser --all 
  dn: ipaanchoruuid=:IPA:ipa.test:ab06513c-4dc2-11e6-bd25-52540037867b,cn=test_view,cn=views,cn=accounts,dc=ipa,dc=test
  Anchor to override: tuser
  Login shell: /bin/bash
  ipaoriginaluid: tuser
  objectclass: ipaSshGroupOfPubKeys, ipaOverrideAnchor, top, ipaUserOverride, ipasshuser

Marking as 'critical' since it break ID view functionality in FreeIPA required for proper AD trust and legacy setup support.

Steps to reproduce:

1.) install FreeIPA server and 389-ds 1.3.5.10-1
2.) create a test user and a ID view
3.) create an ID override for the user in the view
4.) modify the override (add shell or UID/GID) and list the override

Expected result:

ID override will be shown with new values

Actual result:

Internal server error is thrown and the override cannot be search directly, only through subtree search.

I reproduced and after idoverriduser-mod, the following strange search results are found:

{{{
ldapsearch -LLL -o ldif-wrap=no -Y GSSAPI -h vm-058-204.abc.idm.lab.eng.brq.redhat.com -p 389 -s base -b "cn=new_view,cn=views,cn=accounts,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com" dn

dn: cn=new_view,cn=views,cn=accounts,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com

[root@vm-058-204 ~]# ldapsearch -LLL -o ldif-wrap=no -Y GSSAPI -h vm-058-204.abc.idm.lab.eng.brq.redhat.com -p 389 -b "cn=new_view,cn=views,cn=accounts,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com" dn
dn: cn=new_view,cn=views,cn=accounts,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com

dn: ipaanchoruuid=:IPA:abc.idm.lab.eng.brq.redhat.com:a98f08b2-4fe8-11e6-bd61-001a4a2314bd,cn=new_view,cn=views,cn=accounts,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com

[root@vm-058-204 ~]# ldapsearch -LLL -o ldif-wrap=no -Y GSSAPI -h vm-058-204.abc.idm.lab.eng.brq.redhat.com -p 389 -b "ipaanchoruuid=:IPA:abc.idm.lab.eng.brq.redhat.com:a98f08b2-4fe8-11e6-bd61-001a4a2314bd,cn=new_view,cn=views,cn=accounts,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com" dn

No such object (32)
Matched DN: cn=views,cn=accounts,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com
}}}

after restart the search succeeds, there is probably a side effect of the mod on the entrycache

I have not yet found what causes the different behaviour in 1.3.5.6 and 1.3.5.10, but there is a problem in slapi-nis contributing. The function idview_replace_target_dn() corruptd the sdn in the pblock:

{{{
(gdb) p *sdn
$17 = {flag = 11 '\v',
udn = 0x7fd25c001090 "ipaanchoruuid=:IPA:abc.idm.lab.eng.brq.redhat.com:a98f08b2-4fe8-11e6-bd61-001a4a2314bd,cn=new_view,cn=views,cn=accounts,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com",
dn = 0x7fd25c001150 "ipaanchoruuid=:IPA:abc.idm.lab.eng.brq.redhat.com:a98f08b2-4fe8-11e6-bd61-001a4a2314bd,cn=new_view,cn=views,cn=accounts,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com", ndn = 0x0,
ndn_len = 171}

after

(gdb)
562 if (plugin_call_plugins(pb, SLAPI_PLUGIN_PRE_SEARCH_FN) == 0)
(gdb)

(gdb) p *sdn
$18 = {flag = 15 '\017',
udn = 0x7fd25c001090 "ipaanchoruuid=:IPA:abc.idm.lab.eng.brq.redhat.com:a98f08b2-4fe8-11e6-bd61-001a4a2314bd,cn=new_view,cn=views,cn=accounts,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com",
dn = 0x7fd25c001150 "ipaanchoruuid=:IPA:abc.idm.lab.eng.brq.redhat.com:a98f08b2-4fe8-11e6-bd61-001a4a2314bd,",
ndn = 0x7fd25c001520 "ipaanchoruuid=:ipa:abc.idm.lab.eng.brq.redhat.com:a98f08b2-4fe8-11e6-bd61-001a4a2314bd,cn=new_view,cn=views,cn=accounts,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com",
ndn_len = 171}
}}}

so either 1.3.5.10 has a regression, or it exposes this corrupted pblocj earlier

I tested a fix for slapi-nis, which lets the test scenario succeed

will talk to slapi-nis experts about it

the change in behaviour for IPA was introduced with the fix for: https://fedorahosted.org/389/ticket/48637

The core problem seems to be that a base search fails because slapi-nis corrupts the targetdn in the pblock. If the entry is in the entry cacche already (as a consequence of a previous subtree search) the search succeeds.

The fix for #48637 removed the dn from the dn cache when an entry was removed from the entry cache. The IPA test scenario does a MOD of an entry followed by a base search for the entry, and befor teh fix the dn was in the dn cache, and after the fix it is not and we see the failing search.

So, th efix in slapi-nis should fix all issues

the fix will be provided for slapi-nis via bz 1360245

Metadata Update from @lkrispen:
- Issue set to the milestone: 1.3.5.12
7 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/1988

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Invalid)
3 years ago

Login to comment on this ticket.

Metadata
None
None
None
None
critical
None
None
Community
Powered by Pagure 5.13.3
Documentation • File an Issue • About • SSH Hostkey/Fingerprint
© Red Hat, Inc. and others.