[389-users] Password synchronisation beetween openldap and AD 2008 R2

[Dan Lavu]

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:
> On 01/16/14 11:07, Louis-Marie Plumel wrote:
>> My environment is 99 % under linux and authentication is full LDAP.
>> For some 30 workstations under windows, i had to create an AD under 
>> 2008 R2. For some reasons, i have to synchronize password beetween 
>> LDAP and AD. Linux users will keep authentication on LDAP. (windows 
>> users are on LDAP AND AD, and if they want to change their password, 
>> they have to do this on LDAP. That's why i want to synchronise their 
>> password beetween LDAP and AD).
>> LM
>>
> 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.
>
>> 2014/1/16 Petr Spacek <pspacek at redhat.com <mailto:pspacek at redhat.com>>
>>
>>     On 16.1.2014 16:55, Louis-Marie Plumel wrote:
>>
>>           Ok ok, i'm going to see what you sent to me . To be sure,
>>         is  389DS may be an
>>         intermediate between my two actual servers?
>>
>>         Not sure what you mean here.
>>
>>
>>         Is my actual LDAP can be used by 389DS? I'm sorry for these
>>         requests i'm
>>         novice in this domain....
>>
>>
>>     Could you describe what are you trying to achieve?
>>
>>     What is the use case? Logging to workstations? To web apps? File
>>     sharing over NFS with centralized identity store? What else?
>>
>>     Petr^2 Spacek
>>
>>
>>         2014/1/16 Rich Megginson <rmeggins at redhat.com
>>         <mailto:rmeggins at redhat.com>>
>>
>>               On 01/16/2014 08:12 AM, Louis-Marie Plumel wrote:
>>
>>               Ok ok, i'm going to see what you sent to me . To be
>>             sure, is  389DS may
>>             be an intermediate between my two actual servers?
>>
>>             Not sure what you mean here.
>>
>>               I have to keep my actual LDAP and remain the master and
>>             synchronization must
>>             be a single direction (LDAP -> AD).
>>
>>             389 supports one way sync.
>>
>>               Will users have to change their password?
>>
>>             Yes, unfortunately.
>>
>>
>>               My goal is that everything will be transparent.
>>
>>             Then you may want to look into IPA with AD cross domain
>>             trust as Petr
>>             suggested.
>>
>>                regards
>>
>>
>>             2014/1/16 Petr Spacek <pspacek at redhat.com
>>             <mailto:pspacek at redhat.com>>
>>
>>                 On 16.1.2014 15:59, Rich Megginson wrote:
>>
>>                     On 01/16/2014 07:57 AM, Louis-Marie Plumel wrote:
>>
>>                         Hello,
>>
>>                         Actually , i work with openldap.
>>                         I've installed an AD 2008 R2.My challenge is
>>                         to work with both and
>>                         synchronise LDAP and AD 2008 R2. After a long
>>                         research on the web, i
>>                         don't
>>                         find any information about howto synchronise
>>                         passwords . That's why i
>>                         come
>>                         here to see if with 389 DS it's possible or not.
>>
>>
>>                     Yes.
>>
>>                     https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Windows_Sync.html
>>
>>
>>                   There is also one completely different option: Use
>>                 trust between AD and
>>                 Unix domain. It depends on your requirements ...
>>
>>                 See
>>                 http://www.freeipa.org/page/Trusts
>>
>>                 or join mailing list
>>                 https://www.redhat.com/mailman/listinfo/freeipa-users
>>
>>     --
>>     389 users mailing list
>>     389-users at lists.fedoraproject.org
>>     <mailto:389-users at lists.fedoraproject.org>
>>     https://admin.fedoraproject.org/mailman/listinfo/389-users
>>
>>
>>
>>
>> -- 
>> Louis-Marie Plumel
>> louismarie.plumel at gmail.com <mailto:louismarie.plumel at gmail.com>
>>
>>
>>
>> --
>> 389 users mailing list
>> 389-users at lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>
> --
> 389 users mailing list
> 389-users at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20140116/60b0c99c/attachment.html>