Hi - did you have any luck with this? Karl
On Mon, Apr 11, 2011 at 5:50 AM, Karl Wright <daddy...@gmail.com> wrote: > Looking up your specific errors, for Server2008R2, you might want to > consult with this page: > > http://social.technet.microsoft.com/Forums/pl-PL/winserverDS/thread/517cfc7c-2a4e-47f9-80bf-0d5d7e2cd4ac > > It seems that it is possible that your server is misconfigured in this case. > > The second error, DSID-0C09043E, seems to occur to others online > because the proper form of the user name is security protocol > dependent. But since you tried so many combinations this explanation > also seems unlikely. (You probably don't need to try hand-encoding > the password either.) One combination you haven't apparently tried > though is the user name without the domain qualifier, e.g. just "mcf" > alone. The online documentation recommends this: "Note that the > "Administrative user name" field usually requires no domain suffix, > but depending on the details of how the domain controller is > configured, may sometimes only accept the "name@domain" format." > > Good luck, and let us know what you find! > > Karl > > On Mon, Apr 11, 2011 at 5:30 AM, Karl Wright <daddy...@gmail.com> wrote: >> Some answers, but no solutions. >> >> (1) The Active Directory authority was tested against various >> incarnations of Windows 2003 Server. I have not researched whether >> Windows2008R2 still supports the same authentication protocols. But I >> do know that Windows 2003 Server did work. Unfortunately, I no longer >> have a Windows 2003 Server setup available to me at this time, so I >> will not be able to confirm this today. >> >> (2) Windows is highly configurable. If it is possible that your >> domain controllers have been modified to restrict the protocols that >> they accept, then it is possible that the Active Directory authority >> might not work properly for that reason. But if your Windows 2003 >> Server is "out of the box" that's an unlikely explanation. >> >> (3) If you are concerned about encoding issues (and I would be, given >> that your passwords have @'s in them), I would try to confirm that is >> the problem by providing credentials that do not have potential >> problems of this kind. Try creating an AD user with very >> straightforward credentials and see if you get to "Connection working" >> that way. If you do, we'll have to figure out what encoding is needed >> and where it should be done. The authority connector uses the >> standard Sun library for LDAP communication, so I would think this >> would not be a problem. >> >> (4) In ManifoldCF In Action, I do not presume the user has access to >> anything that's not open-source. So of course I don't actually point >> the Active Directory authority at a real domain controller. But if >> you do not get "Connection working" back in the Crawler UI, the >> authority will not work to find real user tokens, that is certain. >> >> (5) The security modes I selected were based on what I read online and >> tested in my environment at the time. You are welcome to experiment >> to see if you can find security protocols that work for you; I would >> be interested to hear if you find something that works in your >> environment. >> >> Karl >> >> On Mon, Apr 11, 2011 at 5:00 AM, Shinichiro Abe >> <shinichiro.ab...@gmail.com> wrote: >>> Hello. >>> >>> I want to connect the repository server through Windows Active Directory, >>> but Registering Authority Connection was not working. >>> Please tell me if you know something. >>> >>> >>> 1) AuthorityConnection error occurs when registering. >>> Connection status was not "Connection Working". >>> >>> At Crawler UI,I specify domain controllers --Windows2008R2 (VM), and save >>> button. >>> >>> Connection status: >>> Threw exception: 'Authentication problem authenticating admin user' >>> ad...@mcf.org ': [LDAP: error code 49 - 8009030C: LdapErr: DSID-0C0904D0, >>> comment: AcceptSecurityContext error, data 52e, v1db0]' >>> >>> "data 52e" is likely to be invalid credentials error. >>> http://www.coderanch.com/t/490367/Security/javax-naming-AuthenticationException-LDAP-error >>> >>> Next, At Crawler UI,I specify domain controllers --Windows2003 (VM), and >>> save button. >>> >>> Connection status: >>> Threw exception: 'Authentication problem authenticating admin user' >>> ad...@mcf.org ': [LDAP: error code 49 - 8009030C: LdapErr: DSID-0C09043E, >>> comment: AcceptSecurityContext error, data 0, vece]' >>> >>> The result code seems to be different (data 52e/data 0) by OS. >>> >>> >>> 2) My environment. I set the same configuration for both OS. >>> >>> Domain Controller: 192.168.11.12 User: ad...@mcf.org Password: P@ssw0rd >>> >>> In Active Directory, Domain is "mcf.org". >>> "Admin"(username) belongs to the Administrators group,and "user1" belongs >>> to the Users group. >>> And I prepared the repository server (WindowsXP).This server belongs to >>> "mcf.org". >>> On the repository server, Admin and user1 can allow to access shared >>> folders. >>> >>> >>> 3)I tried to test for connection. >>> >>> The user tried the following pattern. But the connection failed. >>> 1.ad...@mcf.org >>> 2.mcf.org \ \ Admin >>> 3.mcf \ Admin >>> Password tried the following pattern. But the connection failed. >>> 1.P@ssw0rd >>> 2.P@ssw0rd convert by the URL encoding. P%40ssw0rd >>> 3.MD5-s "P@ssw0rd" convert to set the hash value. >>> >>> Please tell me how to correct registration. >>> (By the way, even in ManifoldCFinAction, on screen image it failed to >>> connect.) >>> >>> >>> 4) I checked the Security Event Log of Windows. >>> Event Log said that the user failed to login (unspecified). >>> On the other hand, When I use LDAPSEARCH(free software tool), I >>> successfully login. >>> http://www.brothersoft.com/ldapsearch-255199.html >>> Comparing between LDAPSEARCH and MCF, authentication process / package >>> seems to be different. >>> In Event Log, MCF(login failed) process / package is "WDIGEST" / "Wdigest". >>> LDAPSEARCH(can login) process / packages is "Advapi" / "Negotiate". >>> >>> ActiveDirectoryAuthority.getSession () set Context.SECURITY_AUTHENTICATION. >>> the SECURITY_AUTHENTICATION defines not "simple" but "DIGEST-MD5 GSSAPI". >>> Does it have any reason? I guess there are any problems in this area. >>> >>> >>> I think it is a difficult problem, but I want to determine whether by my >>> environment or by MCF. >>> Please tell me if you have any ideas, points to be checked. >>> Thank you. >>> >>> Regards, >>> Shinichiro Abe >>> >>> >> >
