Howard Wilkinson wrote:
I think I have worked this out but want ot make sure I have got it correct!Are you sure about this? What application does the hashing? AFAIK, AD needs the clear text password in order to do its own specific hashing and encryption.Whereas the sync agreement for the FDS <-> AD is from a single FDS server to a single AD domain controller the Passsync facilitiy needs to be installed on all Domain Controllers (am I right?)The reason for this is that the password is hashed before injection into the AD
and propagated to other DC's so it is then useless to the Passsync code. The hook therefore needs to be on the DC that receives the password change, which can be any DC in the environment....FDS must get the clear text password in order to perform its own hashing which is different from the way AD does hashing.
This gets a little tricky. In general, AD <-> FDS sync is a simple synchronization protocol, not a full blown multi-master replication protocol as FDS to FDS or AD to AD. FDS cannot be a full replication peer with AD. However, samba4 is getting closer and closer . . .A further concern arises with a multi-master FDS and a multiple DC AD. Can the system be set up with multiple FDS <-> AD sync agreements and still allow the results to propagate within the FDS. This would make sense from a fault-tolerant perspective, and off-hand I think the replications should preserve behaviour, but can anybody spot a problem?
-- Howard Wilkinson Phone: +44(20)76907075 Coherent Technology Limited Fax:23 Northampton Square, Mobile: +44(7980)639379 United Kingdom, EC1V 0HL Email: [EMAIL PROTECTED]------------------------------------------------------------------------ -- Fedora-directory-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/fedora-directory-users
smime.p7s
Description: S/MIME Cryptographic Signature
-- Fedora-directory-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/fedora-directory-users
