Apologies if this has been covered before somewhere.
I am trying to implement AD <--> FDS syncronization, and don't
understand what I need to do about setting up the Password Sync on the
AD server when there are (in my case) 3 AD servers.
>From reading the docs, and from my understanding of how windows clients
bind to AD server to change their passwords, it appears that password
sync needs to be installed on every AD server to catch an interactive
password change from a windows client which has bound to any one of 3 AD
AD servers are all serving one domain
AD1 (password sync --> FDS1, sync agreement <--> FDS1)
AD2 (no password sync)
AD3 (no password sync)
FDS servers have 1 master/supplier, one replica/consumer
FDS1 (win sync <--> AD1, supply --> FDS2)
So, if win client talks to a non-passwordsync AD3 and changes password,
then AD3 synchronizes to AD1, then password sync hooks on AD1 can't
understand the already windows-encrypted password from AD3 because it's
not part of the initial interactive password change. If that's true,
then I definitely have to have Password Sync on every AD server, along
with the certs etc etc. Is this the case?
A collateral question is: what happens if you have 3 AD servers with
sync agreements to an FDS server? Will you get 3 updates to FDS on the
same user change? Will FDS updates sent to all 3 AD servers result in
trouble as the AD servers subsequently sync to each other?
I have a problem with ldapsearch -x command!
I'm not able to see all the attribute of my user,in particular his password(the hash of password).
The problem is ACL or ACI set. What I must modify?
From: Richard Megginson <rmeggins(a)redhat.com>
> rm> Did you re-index the attribute after making that change?
Thanks. re-indexing after changing type to Directory String fixed the
problem. Should I just use Directory String instead of IA5String?