[Fedora-directory-users] Winsync Problem with NT4

[Hartmut Wöhrle]

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