manifoldcf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Wright <>
Subject Re: Authority Connection
Date Wed, 13 Apr 2011 10:42:29 GMT
I believe "simple" transmits the credentials in plain text, which is
why I did not use that.

With DIGEST-MD5 GSSAPI, did you try:

Username: "Admin"
Password: "P@ssw0rd"

The domain qualification ( does not usually work with this mode.


On Wed, Apr 13, 2011 at 5:13 AM, Shinichiro Abe
<> wrote:
> Hello.
> Thank you for your answers.
> Today, I tried the following.
> 1)I changed the source of Authentication.
>  ActiveDirectoryAuthority.getSession()
> 2)Rebuild and register authority connection in crawler-ui.
>  --> connection working.
>    Windows 2003 Server And Windows 2008 R2 did work!
>    username: Both "" and "Admin@mcf" login successfully.
>    password: "P@ssw0rd" login successfully.
> 3)Post and get SID.
> http://ManifoldCFHost:8345/mcf-authority-service/UserACLs?
>  --> I could obtain the SID of user1.
> I installed windows server normally and did not set special configuration,
> so this is not "out of the box".
> AuthenticationException caused in my environment was very authentication error, not credential
> One question,is simple authentication usually standard configuration?
> In "simple" case, password is posted by plain text, perhaps.
> I'm looking for the settings to allow "DIGEST-MD5 GSSAPI" authentication in windows active
> Regards,
> Shinichiro Abe
> On 2011/04/13, at 16:15, Karl Wright wrote:
>> Hi - did you have any luck with this?
>> Karl
>> On Mon, Apr 11, 2011 at 5:50 AM, Karl Wright <> wrote:
>>> Looking up your specific errors, for Server2008R2, you might want to
>>> consult with this page:
>>> 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 <> 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
>>>> <> 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'
': [LDAP: error code 49 - 8009030C: LdapErr: DSID-0C0904D0, comment: AcceptSecurityContext
error, data 52e, v1db0]'
>>>>> "data 52e" is likely to be invalid credentials error.
>>>>> Next, At Crawler UI,I specify domain controllers --Windows2003 (VM),
and save button.
>>>>> Connection status:
>>>>> Threw exception: 'Authentication problem authenticating admin user'
': [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: User: Password: P@ssw0rd
>>>>> In Active Directory, Domain is "".
>>>>> "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 "".
>>>>> On the repository server, Admin and user1 can allow to access shared
>>>>> 3)I tried to test for connection.
>>>>> The user tried the following pattern. But the connection failed.
>>>>> \ \ 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
>>>>> 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
>>>>> 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

View raw message