Hartmut Wöhrle wrote: Hi, can you post the entire log segment where this shows up please ? Wrong password would just mean that the connection would fail. It wouldn't have any persistent effect. 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. You shouldn't need to reinstall.

Am Mittwoch, 23. November 2005 16:57 schrieb David Boreham: OK, attached is the Error Log (error-loglevel set to Replication debugging) 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. 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. 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 Woehrle EMail: hartmut.woehrle(a)mail.pcom.de

Hell Elliot, Am Dienstag, 29. November 2005 21:27 schrieb Elliot Schlegelmilch: "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? 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. Ok, so now I know what should com out - good. Exactly thats why I switched to the ldapsearch, because it tells me much more at the output as the logfile from Replication Log. 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 Woehrle EMail: hartmut.woehrle(a)mail.pcom.de

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/

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.

Hello dear programmers, one last question to close this question. 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 -- =========================================== Hartmut Woehrle EMail: hartmut.woehrle(a)mail.pcom.de