3:35 a.m.
How are you trying to set this? I don't know of any active
measures to
ensure this is disabled. Be aware that group sync hasn't been tested in
IPA for many years now, probably close to a decade. It may well work
fine but I'd test in a separate environment to be sure first.
Since the FreeIPA setup is not used at the moment its okay if anything breaks.
But thanks for the warning, that was unexpecting for me. I've tried changing this
using the following:
# ldapmodify -x -D "cn=directory manager" -W < change_prefix.ldap
With the file:
dn: cn=meTohades.hq.example.de,cn=replica,cn=dc\3Dpriv\2Cdc\3Dexample\
2Cdc\3Dde,cn=mapping tree,cn=config
changetype: modify
replace: nsds7WindowsReplicaSubtree
nsds7WindowsReplicaSubtree: DC=hq,DC=example,DC=de
replace: nsds7NewWinGroupSyncEnabled
nsds7NewWinGroupSyncEnabled: true
I can't find this attribute mentioned in either 389-ds or IPA so its
possible the users are being filtered for some other reason. If you flip
this to 0 are you saying they would be synced?
This attribute is an AD attribute [0] indicating that "the user had its ACLs
changed to a more secure value". I've changed the value for one user, but
this didn't change the behaviour. But doing a query for admin users using
the sync agreement user works:
# ldapsearch -xLLL \
-H ldaps://hades.hq.example.de \
-D ipa-sync(a)hq.example.de \
-W \
-b cn=users,dc=hq,dc=example,dc=de \
(CN=Theodor van Nahl)
Because of that I don't see a permission problem as cause.
Best regards,
Theo
[0]: https://docs.microsoft.com/en-us/windows/win32/adschema/a-admincount