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=ccnrt...@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
(cn=compat) populated by the slapi-nis plugin. The intent is to make
AD users available to non-SSSD clients that can only use LDAP as an

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=bootc...@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
uidNumber: 1952401134
loginShell: /bin/bash
homeDirectory: /home/bootc...@ccnr.priv.my.dom.local
uid: bootc...@ccnr.priv.my.dom.local

dn: uid=testc...@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
uidNumber: 1952401133
loginShell: /bin/bash
homeDirectory: /home/testc...@ccnr.priv.my.dom.local
uid: testc...@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)

Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to