Howard Wilkinson
2007-Aug-23 09:24 UTC
[Fedora-directory-users] Installing passsync in a AD domain with multiple domain controllers?
I think I have worked this out but want ot make sure I have got it correct! 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.... 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: howard@cohtech.com
Richard Megginson
2007-Aug-23 14:11 UTC
Re: [Fedora-directory-users] Installing passsync in a AD domain with multiple domain controllers?
Howard Wilkinson wrote:> I think I have worked this out but want ot make sure I have got it > correct! > > 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 ADAre 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.> 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.> > 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?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 . . .> -- > > Howard Wilkinson > > > > Phone: > > > > +44(20)76907075 > > Coherent Technology Limited > > > > Fax: > > > > > > 23 Northampton Square, > > > > Mobile: > > > > +44(7980)639379 > > United Kingdom, EC1V 0HL > > > > Email: > > > > howard@cohtech.com > > > > ------------------------------------------------------------------------ > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users >
Howard Wilkinson
2007-Aug-23 14:38 UTC
Re: [Fedora-directory-users] Installing passsync in a AD domain with multiple domain controllers?
Richard Megginson wrote:> Howard Wilkinson wrote: >> I think I have worked this out but want ot make sure I have got it >> correct! >> >> 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 > 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.This may be terminology, AD is a collection of services running on the Domain Controllers. One of these services is replication which processes the transfer of strictly LDAP based information. By the time replication gets the data therefore the password has been hashed (I am relatively sure about this). The password change hook is called on the domain controller that accepted the password change prior to the hash is applied - YES??? Again I think I have this right! Therefore whichever DC gets to take part in the password change is going to need the passsync service. I am looking for someone to definitively confirm or deny this premise as I need to push this service out to multiple controllers and include it in new builds.>> 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.Got that, hence my concern with placement of the passsync service>> >> 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? > 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 . . .But if I have 2 FDS servers running in multi-master and they both have synchronisation agreements with a single DC will they fight each other, and can they fight the DC''s - deletes are the obvious problem. The ideal topology would have each of a multi-master set of FDS talking to more than one DC each allowing any system to fail and the services carrying providing up to date functionality. Samba4 is something I would love to have but it looks a long way off as far as a replacement for what we have today... :-( Another thing about multi-master FDS''s is which FDS should a DC talk to for its passsync updates? Ideally each DC would pick a different FDS or more than one if the first failed. .... Fault tolerance is fun...>> -- >> >> Howard Wilkinson >> >> >> >> Phone: >> >> >> >> +44(20)76907075 >> >> Coherent Technology Limited >> >> >> >> Fax: >> >> >> >> >> >> 23 Northampton Square, >> >> >> >> Mobile: >> >> >> >> +44(7980)639379 >> >> United Kingdom, EC1V 0HL >> >> >> >> Email: >> >> >> >> howard@cohtech.com >> >> >> >> ------------------------------------------------------------------------ >> >> -- >> Fedora-directory-users mailing list >> Fedora-directory-users@redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-users >> > > ------------------------------------------------------------------------ > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users >-- Howard Wilkinson Phone: +44(20)76907075 Coherent Technology Limited Fax: 23 Northampton Square, Mobile: +44(7980)639379 United Kingdom, EC1V 0HL Email: howard@cohtech.com
Richard Megginson
2007-Aug-23 14:49 UTC
Re: [Fedora-directory-users] Installing passsync in a AD domain with multiple domain controllers?
Howard Wilkinson wrote:> Richard Megginson wrote: >> Howard Wilkinson wrote: >>> I think I have worked this out but want ot make sure I have got it >>> correct! >>> >>> 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 >> 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. > This may be terminology, AD is a collection of services running on the > Domain Controllers. One of these services is replication which > processes the transfer of strictly LDAP based information. By the time > replication gets the data therefore the password has been hashed (I am > relatively sure about this).Ok.> The password change hook is called on the domain controller that > accepted the password change prior to the hash is applied - YES???Yes.> Again I think I have this right! Therefore whichever DC gets to take > part in the password change is going to need the passsync service.Ok. That sounds right then.> > I am looking for someone to definitively confirm or deny this premise > as I need to push this service out to multiple controllers and include > it in new builds. >>> 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. > Got that, hence my concern with placement of the passsync service >>> >>> 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? >> 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 . . . > But if I have 2 FDS servers running in multi-master and they both have > synchronisation agreements with a single DC will they fight each > other, and can they fight the DC''s - deletes are the obvious problem. > The ideal topology would have each of a multi-master set of FDS > talking to more than one DC each allowing any system to fail and the > services carrying providing up to date functionality. > > Samba4 is something I would love to have but it looks a long way off > as far as a replacement for what we have today... :-( > > Another thing about multi-master FDS''s is which FDS should a DC talk > to for its passsync updates? Ideally each DC would pick a different > FDS or more than one if the first failed. .... Fault tolerance is fun...Yes, I''m not sure how fault tolerance works with passsync.>>> -- >>> >>> Howard Wilkinson >>> >>> >>> >>> Phone: >>> >>> >>> >>> +44(20)76907075 >>> >>> Coherent Technology Limited >>> >>> >>> >>> Fax: >>> >>> >>> >>> >>> >>> 23 Northampton Square, >>> >>> >>> >>> Mobile: >>> >>> >>> >>> +44(7980)639379 >>> >>> United Kingdom, EC1V 0HL >>> >>> >>> >>> Email: >>> >>> >>> >>> howard@cohtech.com >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> -- >>> Fedora-directory-users mailing list >>> Fedora-directory-users@redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-directory-users >>> >> >> ------------------------------------------------------------------------ >> >> -- >> Fedora-directory-users mailing list >> Fedora-directory-users@redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-users >> > > > -- > > Howard Wilkinson > > > > Phone: > > > > +44(20)76907075 > > Coherent Technology Limited > > > > Fax: > > > > > > 23 Northampton Square, > > > > Mobile: > > > > +44(7980)639379 > > United Kingdom, EC1V 0HL > > > > Email: > > > > howard@cohtech.com > > > > ------------------------------------------------------------------------ > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users >