Hello Everyone,
it seems as if everyone is syncing with AD but not with an NT PDC.... except of me.
I have a Problem while setting up a connection: I set up winsync at the PDC (not passwordsync up till now) and I try to initiate a first init-replication. Then nothing happens and the FDS says "Loop detected" But at the PDC side I see an entry in the usersync.log with tells me, which "uid=...." I'm using to connect.
Maybe it is because I used the wrong password at the first try (PDC side)? I read in the manual that "After the service is installed and started the first time the password can only be changed via an LDAP modify operation, not the configuration file."
Ldapmodify - where?? PDC or FDS side? But I'm not able to find the place where this PDC information would be stored in the FDS - so I guess ldapmodify at the PDC? Or is uninstall and re-install the only chance to fix it?
See U Hartmut
Hartmut Wöhrle wrote:
I have a Problem while setting up a connection: I set up winsync at the PDC (not passwordsync up till now) and I try to initiate a first init-replication. Then nothing happens and the FDS says "Loop detected"
Hi, can you post the entire log segment where this shows up please ?
But at the PDC side I see an entry in the usersync.log with tells me, which "uid=...." I'm using to connect.
Maybe it is because I used the wrong password at the first try (PDC side)? I read in the manual that
Wrong password would just mean that the connection would fail. It wouldn't have any persistent effect.
"After the service is installed and started the first time the password can only be changed via an LDAP modify operation, not the configuration file."
Ldapmodify - where?? PDC or FDS side?
NTDS side (PDC machine). NTDS uses ApacheDS. ApacheDS stores its password in its database. However originally it always initialized that password to a known value. We were concerned about the security implications of that and made a change to the ApacheDS code such that the password is read from the config file rather than use the default value (which would be the same for all installations). In order to force users to set the password, I believe we refuse to function until it is set in the config file. At least that's how I remember it. I'd need to look at the code to be sure.
Anyway, the ldapmodify operation will be to the userpassword attribute on the ApacheDS root entry. I'll look that up and post the command...
Your problem may be that you haven't set the password in the first place. It should be possible to use ldapsearch to check that your ntds is up and running and answering LDAP searches correctly. Once that's proven, FDS should be able to sync with it ok using the same bind credentials and password.
But I'm not able to find the place where this PDC information would be stored in the FDS - so I guess ldapmodify at the PDC? Or is uninstall and re-install the only chance to fix it?
You shouldn't need to reinstall.
Am Mittwoch, 23. November 2005 16:57 schrieb David Boreham:
Hi, can you post the entire log segment where this shows up please ?
I have to setup the Loglevel to Replication to debug first... hope I can do it tomorrow.
BTW. where can I set the loglevel for the usersync.log? The wrapper.conf entries about loglevels just make the wrapper.log bigger and more informative, but not the usersync.log
Wrong password would just mean that the connection would fail. It wouldn't have any persistent effect.
Hmm, as I understand the "hardcoded" user at the PDC side is cn=admin,ou=system When I started the first time this user didn't exist - of security reasons our Admin is called different (Superroot for example). Does this have any effects?
Anyway, the ldapmodify operation will be to the userpassword attribute on the ApacheDS root entry. I'll look that up and post the command...
Would be nice :)
And where is this ApacheDS? In the usual C:\Program Files\Red Hat Directory Synchronization
You shouldn't need to reinstall.
Ufff....
Thanks
Am Mittwoch, 23. November 2005 16:57 schrieb David Boreham:
Hi, can you post the entire log segment where this shows up please ?
OK, attached is the Error Log (error-loglevel set to Replication debugging)
Wrong password would just mean that the connection would fail. It wouldn't have any persistent effect.
Hmm, I also did a ldapsearch and got the "Invalid Credential" (log at the end) So this means it uses the wrong password. Because I tried a different one than the actual. But when starting the ldapsearch, does it login to the ApacheDS without using PDC data? Or is there a connection? And what should come out.... - the whole PDC tree I think, but I'm not sure.
NTDS side (PDC machine). NTDS uses ApacheDS. ApacheDS stores its password in its database. However originally it always initialized that password to a known value. We were concerned about the security implications of that and made a change to the ApacheDS code such that the password is read from the config file rather than use the default value (which would be the same for all installations). In order to force users to set the password, I believe we refuse to function until it is set in the config file. At least that's how I remember it. I'd need to look at the code to be sure.
But it uses which user? uid=admin,ou=system as default ApacheDS root entry? And what happens, when this User doesn't exist? And the password is set to a value I can not remember? I think the only chance to solve this problem is to reinstall (deinstall deletes the DS - right?) the whole winsync and have - now - the user admin and use its password.
Anyway, the ldapmodify operation will be to the userpassword attribute on the ApacheDS root entry. I'll look that up and post the command...
Your problem may be that you haven't set the password in the first place. It should be possible to use ldapsearch to check that your ntds is up and running and answering LDAP searches correctly. Once that's proven, FDS should be able to sync with it ok using the same bind credentials and password.
ldapsearch works, but (as you can see below) my bind password is wrong (or I can't remember.... :) )
-------------- Begin of LOG ------------------------
[root@fedorads001 slapd-fedorads001]# ldapsearch -v -D "uid=admin,ou=system" -x -w mysecret -h 192.168.1.218 -t "*" ldap_initialize( ldap://192.168.1.218 ) ldap_bind: Invalid credentials (49) additional info: Bind failure: org.apache.ldap.common.exception.LdapAuthenticationException at org.apache.ldap.server.authn.AuthenticationService.process(AuthenticationService.java:297) at org.apache.ldap.server.interceptor.InterceptorChain$3.process(InterceptorChain.java:578) at org.apache.ldap.server.interceptor.BaseInterceptor.process(BaseInterceptor.java:185) at org.apache.ldap.server.normalization.NormalizationService.process(NormalizationService.java:162) at org.apache.ldap.server.interceptor.BaseInterceptor.process(BaseInterceptor.java:101) at org.apache.ldap.server.interceptor.InterceptorChain.process(InterceptorChain.java:478) at org.apache.ldap.server.jndi.JndiProvider.invoke(JndiProvider.java:171) at org.apache.ldap.server.jndi.JndiProvider$PartitionNexusImpl.hasEntry(JndiProvider.java:247) at org.apache.ldap.server.jndi.ServerContext.<init>(ServerContext.java:118) at org.apache.ldap.server.jndi.ServerDirContext.<init>(ServerDirContext.java:61) at org.apache.ldap.server.jndi.ServerLdapContext.<init>(ServerLdapContext.java:56) at org.apache.ldap.server.jndi.JndiProvider.getLdapContext(JndiProvider.java:122) at org.apache.ldap.server.jndi.CoreContextFactory.getInitialContext(CoreContextFactory.java:245) at org.apache.ldap.server.jndi.ServerContextFactory.getInitialContext(ServerContextFactory.java:154) at javax.naming.spi.NamingManager.getInitialContext(Unknown Source) at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source) at javax.naming.InitialContext.init(Unknown Source) at javax.naming.ldap.InitialLdapContext.<init>(Unknown Source) at org.apache.ldap.server.protocol.BindHandler.messageReceived(BindHandler.java:134) at org.apache.mina.protocol.handler.DemuxingProtocolHandler.messageReceived(DemuxingProtocolHandler.java:69) at org.apache.mina.protocol.AbstractProtocolFilterChain$2.messageReceived(AbstractProtocolFilterChain.java:149) at org.apache.mina.protocol.AbstractProtocolFilterChain.callNextMessageReceived(AbstractProtocolFilterChain.java:363) at org.apache.mina.protocol.AbstractProtocolFilterChain.access$1100 (AbstractProtocolFilterChain.java:50) at org.apache.mina.protocol.AbstractProtocolFilterChain$Entry$1.messageReceived(AbstractProtocolFilterChain.java:524) at org.apache.mina.protocol.AbstractProtocolFilterChain$1.messageReceived(AbstractProtocolFilterChain.java:99) at org.apache.mina.protocol.AbstractProtocolFilterChain.callNextMessageReceived(AbstractProtocolFilterChain.java:363) at org.apache.mina.protocol.AbstractProtocolFilterChain.messageReceived(AbstractProtocolFilterChain.java:354) at org.apache.mina.protocol.ProtocolSessionManagerFilterChain$1.messageReceived(ProtocolSessionManagerFilterChain.java:77) at org.apache.mina.protocol.AbstractProtocolFilterChain.callNextMessageReceived(AbstractProtocolFilterChain.java:363) at org.apache.mina.protocol.AbstractProtocolFilterChain.access$1100 (AbstractProtocolFilterChain.java:50) at org.apache.mina.protocol.AbstractProtocolFilterChain$Entry$1.messageReceived(AbstractProtocolFilterChain.java:524) at org.apache.mina.protocol.filter.ProtocolThreadPoolFilter.processEvent(ProtocolThreadPoolFilter.java:96) at org.apache.mina.util.BaseThreadPool$Worker.processEvents(BaseThreadPool.java:340) at org.apache.mina.util.BaseThreadPool$Worker.run(BaseThreadPool.java:279)
BindRequest = org.apache.ldap.common.message.BindRequestImpl@da9067
-------------- End of LOG ------------------------
Btw... It would be nice to find a schema (written or drawn) which tells me (or everyone) how winsync and passwordsync works. The Pictures in the manuals tell me the way which way the servers exchange informations, but within the PDC (or AD) I don't know anything - it is a black box. And .... I didn't find the sources to check by myself - is it closed source?
See U Hartmut
Hartmut Wöhrle wrote:
Hmm, I also did a ldapsearch and got the "Invalid Credential" (log at the end) So this means it uses the wrong password. Because I tried a different one than the actual. But when starting the ldapsearch, does it login to the ApacheDS without using PDC data? Or is there a connection? And what should come out.... - the whole PDC tree I think, but I'm not sure.
I'm a bit confused now. Which password, or which actual? You can ldapsearch using the uid=admin,ou=system account and correct password.
NTDS side (PDC machine). NTDS uses ApacheDS. ApacheDS stores its password in its database. However originally it always initialized that password to a known value. We were concerned about the security implications of that and made a change to the ApacheDS code such that the password is read from the config file rather than use the default value (which would be the same for all installations). In order to force users to set the password, I believe we refuse to function until it is set in the config file. At least that's how I remember it. I'd need to look at the code to be sure.
But it uses which user? uid=admin,ou=system as default ApacheDS root entry? And what happens, when this User doesn't exist? And the password is set to a value I can not remember? I think the only chance to solve this problem is to reinstall (deinstall deletes the DS - right?) the whole winsync and have - now - the user admin and use its password.
Anyway, the ldapmodify operation will be to the userpassword attribute on the ApacheDS root entry. I'll look that up and post the command...
Your problem may be that you haven't set the password in the first place. It should be possible to use ldapsearch to check that your ntds is up and running and answering LDAP searches correctly. Once that's proven, FDS should be able to sync with it ok using the same bind credentials and password.
ldapsearch works, but (as you can see below) my bind password is wrong (or I can't remember.... :) )
I would suggest opening up your c:\program files\fedora directory synchronization\conf\usersync.conf in your favorite editor, and see what password is in it. Try binding as that user. While looking inside that file look for the 'server.db.partition.suffix.usersync field.
Then, with this password and base, try another search.
ldapsearch -v -h 192.168.1.218 -D "uid=admin,ou=system" -w pw -b "dc=home,dc=org" "(objectclass=*)
I'm just guessing the base, but I assume it's something very similar.
You should see something similar to this: # Guest, users, example.com dn: sAMAccountName=Guest,cn=users,dc=example,dc=com memberOf: sAMAccountName=Domain Guests,cn=users,dc=example,dc=com lastLogon: 0 objectGUID: 0105000000000005150000003D725165EB1AB15BC9504D49F5010000 countryCode: 0
Once you can access your PDC from LDAP, there's a lot better chance that your Fedora Directory Server will be able to for replication.
Btw... It would be nice to find a schema (written or drawn) which tells me (or everyone) how winsync and passwordsync works. The Pictures in the manuals tell me the way which way the servers exchange informations, but within the PDC (or AD) I don't know anything - it is a black box. And .... I didn't find the sources to check by myself - is it closed source?
It's not closed source. http://directory.fedora.redhat.com/wiki/Building#Pulling_the_Directory_Serve...
See U Hartmut
Hell Elliot,
Am Dienstag, 29. November 2005 21:27 schrieb Elliot Schlegelmilch:
I'm a bit confused now. Which password, or which actual? You can ldapsearch using the uid=admin,ou=system account and correct password.
"correct password" thats exactly my problem. I think when setting up the system I did something wrong, because the answer is "Invalid Credentials (49)" which means wrong password. Therefore I can not connect, not search, and not modify anything.... so what to do? Uninstall and start from scratch?
ldapsearch works, but (as you can see below) my bind password is wrong (or I can't remember.... :) )
I would suggest opening up your c:\program files\fedora directory synchronization\conf\usersync.conf in your favorite editor, and see what password is in it. Try binding as that user. While looking inside that file look for the 'server.db.partition.suffix.usersync field.
While trying to install I changed this password and now it doesn't fit - or maybe I am too stupid because I can not remember.
Then, with this password and base, try another search.
ldapsearch -v -h 192.168.1.218 -D "uid=admin,ou=system" -w pw -b "dc=home,dc=org" "(objectclass=*)
I'm just guessing the base, but I assume it's something very similar.
You should see something similar to this: # Guest, users, example.com dn: sAMAccountName=Guest,cn=users,dc=example,dc=com memberOf: sAMAccountName=Domain Guests,cn=users,dc=example,dc=com lastLogon: 0 objectGUID: 0105000000000005150000003D725165EB1AB15BC9504D49F5010000 countryCode: 0
Ok, so now I know what should com out - good.
Once you can access your PDC from LDAP, there's a lot better chance that your Fedora Directory Server will be able to for replication.
Exactly thats why I switched to the ldapsearch, because it tells me much more at the output as the logfile from Replication Log.
Btw... It would be nice to find a schema (written or drawn) which tells me (or everyone) how winsync and passwordsync works. The Pictures in the manuals tell me the way which way the servers exchange informations, but within the PDC (or AD) I don't know anything - it is a black box. And .... I didn't find the sources to check by myself - is it closed source?
It's not closed source. http://directory.fedora.redhat.com/wiki/Building#Pulling_the_Directory_Serv er_Source
The Directory Server yes. But I don't see (maybe I'm blind) the sources for the ApacheDS at the PDC (Java based) and the sources for winsync software, which comes as a .msi (Microsoft Installer) File. So is this opensource? And where to find it?
And I think the manual is a little bit too small for the NT Winsync. With AD it is OK, because you use the LDAP Funktion of the AD and synchronise like a replica - more or less. But what exactly happens at the NT PDC??? I learned from this forum that winsync installs an ApacheDS as LDAP Server to connect with. OK what next. How does the ApacheDS connect to the PDC. Which user is used for the login - if any? Does it work like this: FDS --> ApacheDS (uid=admin,ou=system) --> NT PDC (user=?) or FDS --> ApacheDS (uid=admin,ou=system) --> NT PDC (user=admin)
And you need the replication manager (with the acl's to add, modify and delete a user) at the FDS side for the synchronization? So this works like this (push) NT PDC (user=?) --> ApacheDS (uid=admin,ou=system) --> FDS (uid=replmanager,out=users) And how does he know which user at hte FDS to use Or like this (Pull) FDS --> ApacheDS (uid=admin,ou=system) --> NT PDC (user=?)
And how does it work, when I use the Password sync? Is there a layer inbetween windows admintool and PDC that reads the input and sends it to the FDS before handing it to the PDC Directory - but for this it needs an account with administrative rights, which one? You see there are many questions with this challenging tool.
See U Hartmut
Hartmut Wöhrle wrote:
Hell Elliot,
Am Dienstag, 29. November 2005 21:27 schrieb Elliot Schlegelmilch:
I'm a bit confused now. Which password, or which actual? You can ldapsearch using the uid=admin,ou=system account and correct password.
"correct password" thats exactly my problem. I think when setting up the system I did something wrong, because the answer is "Invalid Credentials (49)" which means wrong password. Therefore I can not connect, not search, and not modify anything.... so what to do? Uninstall and start from scratch?
ldapsearch works, but (as you can see below) my bind password is wrong (or I can't remember.... :) )
I would suggest opening up your c:\program files\fedora directory synchronization\conf\usersync.conf in your favorite editor, and see what password is in it. Try binding as that user. While looking inside that file look for the 'server.db.partition.suffix.usersync field.
While trying to install I changed this password and now it doesn't fit - or maybe I am too stupid because I can not remember.
Then, with this password and base, try another search.
ldapsearch -v -h 192.168.1.218 -D "uid=admin,ou=system" -w pw -b "dc=home,dc=org" "(objectclass=*)
I'm just guessing the base, but I assume it's something very similar.
You should see something similar to this: # Guest, users, example.com dn: sAMAccountName=Guest,cn=users,dc=example,dc=com memberOf: sAMAccountName=Domain Guests,cn=users,dc=example,dc=com lastLogon: 0 objectGUID: 0105000000000005150000003D725165EB1AB15BC9504D49F5010000 countryCode: 0
Ok, so now I know what should com out - good.
Once you can access your PDC from LDAP, there's a lot better chance that your Fedora Directory Server will be able to for replication.
Exactly thats why I switched to the ldapsearch, because it tells me much more at the output as the logfile from Replication Log.
Btw... It would be nice to find a schema (written or drawn) which tells me (or everyone) how winsync and passwordsync works. The Pictures in the manuals tell me the way which way the servers exchange informations, but within the PDC (or AD) I don't know anything - it is a black box. And .... I didn't find the sources to check by myself - is it closed source?
It's not closed source. http://directory.fedora.redhat.com/wiki/Building#Pulling_the_Directory_Serv er_Source
The Directory Server yes. But I don't see (maybe I'm blind) the sources for the ApacheDS at the PDC (Java based) and the sources for winsync software, which comes as a .msi (Microsoft Installer) File. So is this opensource? And where to find it?
The ApacheDS source is available at http://directory.apache.org/
The source for the winsync software is in the same source tree as the Directory Server. The PassSync.msi source is in the ldapserver/ldap/synctools directory. The ntds.msi source is in the ldapserver/ldap/servers/ntds directory.
And I think the manual is a little bit too small for the NT Winsync. With AD it is OK, because you use the LDAP Funktion of the AD and synchronise like a replica - more or less. But what exactly happens at the NT PDC??? I learned from this forum that winsync installs an ApacheDS as LDAP Server to connect with. OK what next. How does the ApacheDS connect to the PDC. Which user is used for the login - if any? Does it work like this: FDS --> ApacheDS (uid=admin,ou=system) --> NT PDC (user=?) or FDS --> ApacheDS (uid=admin,ou=system) --> NT PDC (user=admin)
My understanding is that the ApacheDS just serves up an LDAP representation of NTs SAM database. It can access this since it is running as Administrator.
And you need the replication manager (with the acl's to add, modify and delete a user) at the FDS side for the synchronization? So this works like this (push) NT PDC (user=?) --> ApacheDS (uid=admin,ou=system) --> FDS (uid=replmanager,out=users) And how does he know which user at hte FDS to use Or like this (Pull) FDS --> ApacheDS (uid=admin,ou=system) --> NT PDC (user=?)
FDS pulls the data from ApacheDS.
And how does it work, when I use the Password sync? Is there a layer inbetween windows admintool and PDC that reads the input and sends it to the FDS before handing it to the PDC Directory - but for this it needs an account with administrative rights, which one?
The Windows LSA (local security authority) hands password changes off to PassSync. The PassSync service then attempts to push this password change to FDS. You need to setup a user on the FDS side that has permission to update the userPassword attribute for your user entries. It doesn't matter which user as long as they have the proper rights.
-NGK
You see there are many questions with this challenging tool.
See U Hartmut
But what exactly happens at the NT PDC???
This is documented a little in the admin guide: http://www.redhat.com/docs/manuals/dir-server/ag/7.1/sync.html#2859334
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.
Am Donnerstag, 1. Dezember 2005 17:53 schrieb David Boreham:
But what exactly happens at the NT PDC???
This is documented a little in the admin guide:
^^^^^ exactly ;)
http://www.redhat.com/docs/manuals/dir-server/ag/7.1/sync.html#2859334
Yes I know it and it doesn't tell me much about how it works. So I'm messed up a little when dealing with problems. :(
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.
So it is not a login, but a service-to-service-talk. Then the ApacheDS doesn't have to know the account (uid and pw), because it is running as a privileged service - is this right?
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.
Ok thats quite elegant. I see.
So the only uid/pw combination I need to know and to have (create) at the PDC side is in fact the ApacheDS Directory Manager (uid=admin,ou=system) ? And it has nothing to do with any existing account in the windows domain (user or admin)... did I get this right?
Wau, great explanation, thank you... please put something similar to the manual - I think a lot of people will need it, or at least want to know how it works.
See U Hartmut
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.
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 ;)
This is what you're supposed to do. And I think you are correct: it's missing from the documentation. That would certainly make it challenging to configure correctly !
On reading the doc on the web site, I also noticed that there are a few missing images there too.
It's not closed source. http://directory.fedora.redhat.com/wiki/Building#Pulling_the_Directory_Serve...
Specifically, the NTDS source is here: http://cvs.fedora.redhat.com/lxr/dirsec/source/ldapserver/ldap/servers/ntds/
But it uses ApacheDS too, which is here: http://directory.apache.org/
389-users@lists.fedoraproject.org
-
David Boreham -
Elliot Schlegelmilch -
Hartmut Wöhrle -
Nathan Kinder