Hello dear programmers, one last question to close this question. > This is documented a little in the admin guide: > http://www.redhat.com/docs/manuals/dir-server/ag/7.1/sync.html#2859334 When I read through all these explanations, I realize, that I use the (default) user uid=admin,ou=system from the ApacheDS at the PDC side and connect to this ApacheDS with LDAP connection from the FDS. The ApacheDS itself is a priviliged system service and connects to the PDC without need to login and knowledge of any account. I can ask for information via windows replication or via command line ldaptools. With the command line tools I connect to the ApacheDS and therfore I have to login as uid=admin,ou=system. But when I look at the documentation I realize that the bind ID in the example is uid=sync manager,cn=config and therefore one would asume, that this is the user to connect to at the remote (AD, NT PDC) server. When looking at the way above this makes sense, but there are some remarks missing in the docu and I think it is the main cause for my problem: This user has to exist in the remote server! And that fact isn't mentioned in the docu! So I initialized a password for the uid=admin in the usersync.conf and created the replication agreement with another bind ID I like more (for example uid=winsync,ou=admins). Of course I got errormessages and no connection. In the AD it is no problem, because you can see the problem in the log tool at the AD and create that sync manager. But(!!!) in the NT PDC case it is difficult, because it isn't mentioned anywhere that there exists a LDAP server at the PDC (now I know - thanks to you) and I have to connect to a user at this LDAP server. In addition the log at the PDC is a little poor and doesn't give me any hints about the problem. OK...so I guess (correct me please if I'm wrong).... Solution 1) Use only the uid=admin,ou=system user in the replication tool (in the NT PDC case) with the password initialized from the usersync.con file..... but explain it in the manuals as well (including Picture, please ;) Solution 2) create via ldapcreate the user I want to use (uid=sync manager,ou=system for example) and use this one for the replication agreement...... but explain it in the manuals as well (including Picture, please ;) Maybe I'm completely wrong, but this is what I think I learned from this discussion (correct me please if I'm wrong). And in this case these facts should be added to the manuals, because one of the main arguments for me to introduce the FDS in a Windows - based company at the moment, is to replace the old NT4 PDC or switch from the AD to a more powerfull LDAP server. And the documentation for this service is a little poor - up till now. Thanks Hartmut > > quoting: > > NT4 LDAP Service. This is a special LDAP server application that must be > installed on the primary domain controller for NT4 sync. It is only used > for NT4 and is not needed for Active Directory deployments. The purpose > of the NT4 LDAP Service is to provide a similar view of users and groups > as is available via LDAP from Active Directory. This allows almost all > of the Directory Server Windows Sync code to be the same for both Active > Directory and NT4. > > How it works may give you some better insight: > > NT4, unlike AD, does not support LDAP. It does however have an API > that allows an application running on the PDC to read and write the NTLM > user database. This is called the 'NetXXX api' because many of the > functions have names like 'NetUserEnum()'. > What the NTDS does is to 'reflect' that API as an LDAP > server. It does this using ApacheDS (chosen because it gives us a working > LDAP server that can be quickly customized, and because it will run without > huge testing effort on an old platform like NT4), and a custom ApacheDS > back-end. > The back-end provides a shim between the ApacheDS internal database > interface > and the NetXXX api. It does this using a combination of C++ to talk > directly to the API, and then a swig-generated shim to JNI which in turn is > driven by a simple Java class in the custom back end. > > The top level goal for the NTDS is to 'emulate' AD on NT4. > The idea was to code the winsync part of FDS to speak to > AD alone, and do all the NT4 weirdness on the NT side. > It turns out to be hard/impossible to do that 100% (some schema > is quite different for example). So you will see some 'if (nt4) ... ' > code in FDS winsync, but not a whole lot. -- =========================================== Hartmut Woehrle EMail: hartmut.woehrle at mail.pcom.de
