[Freeipa-users] it's a weird one - how AD users get into IPA ?

[lejeczek]

On 10/06/16 11:23, Alexander Bokovoy wrote:
> On Fri, 10 Jun 2016, lejeczek wrote:
>> On Fri, 2016-06-10 at 11:01 +0200, Jakub Hrozek wrote:
>>> On Fri, Jun 10, 2016 at 09:54:19AM +0100, lejeczek wrote:
>>> > hi everyone
>>> >
>>> > there is a master IPA which in some weird way puts AD 
>>> users into
>>> > its ldap
>>> > catalog. I say weird cause there is no trust nor other 
>>> sync
>>> > established,
>>> > there was a trust agreement, one way type, but now 
>>> 'trust-find'
>>> > shows
>>> > nothing, that trust was removed.
>>> >
>>> > but still when I create a user @AD DS a second later I 
>>> see it in
>>> > IPA's ldap,
>>> > eg.
>>> >
>>> > dn: 
>>> uid=ccnrtest at ccnr.aaa.private.dom,cn=users,cn=compat,dc=private 
>>>
>>> > ,dc=c
>>> >  cnr,dc=aaa,dc=private,dc=dom
>>> >
>>> > how to trace the culprit config responsible for this?
>>>
>>> Check the DN, this is not the IPA tree (cn=account), but 
>>> the compat
>>> tree
>>> (cn=compat) populated by the slapi-nis plugin. The 
>>> intent is to make
>>> the
>>> AD users available to non-SSSD clients that can only use 
>>> LDAP as an
>>> interface.
>>>
>> any chance this plugin gets included without user/admin 
>> intention, eg.
>> during migrate-ds ?
> The slapi-nis plugin is enabled by default when IPA is 
> installed because
> ou=sudoers tree is emulated by the slapi-nis.
>
>> is ipa toolkit or I have to go directly to ldap to 
>> de/activate
>> plugin(s) ?
> See ipa-compat-manage
>
I've set up another replica, configuration on sssd and kdc 
site virtually identical, nsswith too, ipa-compat-manage 
etc. No trusts traces on both ends.
Master still(after reboot and sss_cache cleanup) receives, 
or rather pulls AD's users, whereas replica(s) don't.
This is hilarious, but how is this possible?
I add a user @AD DC and on master I ldapsearch and first few 
lines are:

dn: cn=compat,dc=private,dc=ccnr,dc=priv,dc=my,dc=dom,dc=local
objectClass: extensibleObject
cn: compat

dn: 
cn=users,cn=compat,dc=private,dc=ccnr,dc=priv,dc=my,dc=dom,dc=local
objectClass: extensibleObject
cn: users

dn: 
uid=bootccnr at ccnr.priv.my.dom.local,cn=users,cn=compat,dc=private,dc=ccnr,dc=priv,dc=my,dc=dom,dc=local
objectClass: ipaOverrideTarget
objectClass: posixAccount
objectClass: top
cn: ccnr boot
gidNumber: 1952400513
gecos: ccnr boot
ipaAnchorUUID:: 
OlNJRDpTLTEtNS0yMS0xMTQ0OTE1MDkxLTIyNTIxNzUyMTUtNzAyNTMwMDMyLT
  ExMzQ=
uidNumber: 1952401134
loginShell: /bin/bash
homeDirectory: /home/bootccnr at ccnr.priv.my.dom.local
uid: bootccnr at ccnr.priv.my.dom.local

dn: 
uid=testccnr at ccnr.priv.my.dom.local,cn=users,cn=compat,dc=private,dc=ccnr,dc=priv,dc=my,dc=dom,dc=local
objectClass: ipaOverrideTarget
objectClass: posixAccount
objectClass: top
cn: ccnr tester
gidNumber: 1952400513
gecos: ccnr tester
ipaAnchorUUID:: 
OlNJRDpTLTEtNS0yMS0xMTQ0OTE1MDkxLTIyNTIxNzUyMTUtNzAyNTMwMDMyLT
  ExMzM=
uidNumber: 1952401133
loginShell: /bin/bash
homeDirectory: /home/testccnr at ccnr.priv.my.dom.local
uid: testccnr at ccnr.priv.my.dom.local

could it be that "compat" part happens only on master? I 
mean - should only happen on master?(even though replicas 
use ipa-compat-manage)
regards,
L.