1. The Windows DCs will be the master of the passwords. Users will
need to change their passwords in that environment. Not true, the password synchronization is based upon certain attributes in the database. 389 will only sync to AD if the ntuser objectClass is available, and AD, it's posixAccount? iirc. 2. It must be installed on all DCs as you never know which DC the Windows client will send the change to. Nope, it's a single point of failure, it must be installed onto *ONE* DC otherwise they will be overwriting each other. 3. Right that is a limitation, but there are bad workarounds for it. You can modify and create a pointer from SamAccountname to UID in the AD schema, but the UID will be UID in 389, does your application point to AD or 389? As Petr stated, I do suggest looking at IdM/IPA as an alternative solution because it contains the compat tree for legacy applications and RHEL7/Fedora it currently supports a trust which will then negate having AD users change their passwords. Just make sure you have fully redundant IPA and AD servers so authentication will not break. Dan On 01/16/2014 12:08 PM, Gary Algier
wrote:
|
-- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users