On 01/16/14 14:43, Dan Lavu wrote:
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.
If one is using 389DS, that may be true, but using it with a
"generic" LDAP implementation one must do the change in the Windows
universe. In this case the desire seems to be to use OpenLDAP, not
change the LDAP implementation.
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.
No, the password sync code gets the password while it is still plain
text and syncs to the LDAP server. Once a Windows AD server saves
the password it has been hashed and is replicated to the other
Windows AD servers in hashed format. The replicas cannot resubmit
it to the password sync code.
Just to clarify, I am talking about the password sync documented
here:
http://directory.fedoraproject.org/wiki/Howto:WindowsSync#Installing_PassSync
The registry change I made (after installing) was:
[HKEY_LOCAL_MACHINE\SOFTWARE\PasswordSync]
"User Name Field"="uid"
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:
On 01/16/14 11:07, Louis-Marie
Plumel wrote:
I installed the Windows password sync from the 389DS project on
our DCs and it works with the Sun/Solaris/Java directory server
just fine. It should work with any LDAP server.
However:
1. The Windows DCs will be the master of the passwords. Users
will need to change their passwords in that environment.
2. It must be installed on all DCs as you never know which DC
the Windows client will send the change to.
3. You may need to adjust the parameters of the module by
editing the registry after installation. The default attributes
did not suit our needs. We use the UID attribute for the LDAP
equivalent of the Windows SamAccountName attribute.
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
|
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users