You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@manifoldcf.apache.org by Shinichiro Abe <sh...@gmail.com> on 2011/04/11 11:00:36 UTC
Authority Connection
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' Admin@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' Admin@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: Admin@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.Admin@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
Re: Authority Connection
Posted by Karl Wright <da...@gmail.com>.
Hmm. The systems I tested this against were (I thought) unmodified -
but they were based on VMs that had been put together by someone else.
Nevertheless, the following page indicates that what I saw work
before *should* work for you:
http://www.forumeasy.com/forums/thread.jsp?tid=115170863235&fid=ldapprof5&highlight=Why+DIGEST-MD5+Authentication+Does+Work
Look for the section on "AD2003".
I also vaguely recalled initial experimentation to figure out what
modes to use. Unfortunately I went back and looked at the history of
the connector through its various moves, and found that the
connector's initial commit back in April 2010 also used "DIGEST-MD5
GSSAPI". So no record of my initial experiments there. I recall
testing it against both Windows 2003 and Windows 2000 domain
controllers at that time, and vaguely recall needing to tinker with
the authentication modes to get both to work using the same ones.
Beyond that I have no records.
Karl
On Thu, Apr 14, 2011 at 1:41 AM, Shinichiro Abe
<sh...@gmail.com> wrote:
> Hi.
> I tested connection woking by your suggestion, but occurred error:
>
> Windows 2008:
> Threw exception: 'Authentication problem authenticating admin user 'Admin': [LDAP: error code 49 - 8009030C: LdapErr: DSID-0C0904D0, comment: AcceptSecurityContext error, data 52e, v1db0�]'
>
> Windows 2003:
> Threw exception: 'Authentication problem authenticating admin user 'Admin': [LDAP: error code 49 - 80090303: LdapErr: DSID-0C090420, comment: The digest-uri does not match any LDAP SPN's registered for this server., data 0, vece�]'
>
> Do you know how to enable DIGEST-MD5 authentication on Windows server side?(Domain security policy?)
>
> Regards,
> Shinichiro Abe
>
>
> On 2011/04/13, at 19:42, Karl Wright wrote:
>
>> 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 (@mcf.org) does not usually work with this mode.
>>
>> Karl
>>
>> On Wed, Apr 13, 2011 at 5:13 AM, Shinichiro Abe
>> <sh...@gmail.com> wrote:
>>> Hello.
>>>
>>> Thank you for your answers.
>>> Today, I tried the following.
>>>
>>> 1)I changed the source of Authentication.
>>> ActiveDirectoryAuthority.getSession()
>>> Context.SECURITY_AUTHENTICATION "DIGEST-MD5 GSSAPI" --> "simple"
>>> 2)Rebuild and register authority connection in crawler-ui.
>>> --> connection working.
>>> Windows 2003 Server And Windows 2008 R2 did work!
>>> username: Both "Admin@mcf.org" and "Admin@mcf" login successfully.
>>> password: "P@ssw0rd" login successfully.
>>> 3)Post and get SID.
>>> http://ManifoldCFHost:8345/mcf-authority-service/UserACLs?username=user1@mcf.org
>>> --> 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 error.
>>>
>>> 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 directory.
>>>
>>> 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 <da...@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 <da...@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
>>>>>> <sh...@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' Admin@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' Admin@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: Admin@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.Admin@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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>>>
>
>
Re: Authority Connection
Posted by Shinichiro Abe <sh...@gmail.com>.
Hi.
I tested connection woking by your suggestion, but occurred error:
Windows 2008:
Threw exception: 'Authentication problem authenticating admin user 'Admin': [LDAP: error code 49 - 8009030C: LdapErr: DSID-0C0904D0, comment: AcceptSecurityContext error, data 52e, v1db0�]'
Windows 2003:
Threw exception: 'Authentication problem authenticating admin user 'Admin': [LDAP: error code 49 - 80090303: LdapErr: DSID-0C090420, comment: The digest-uri does not match any LDAP SPN's registered for this server., data 0, vece�]'
Do you know how to enable DIGEST-MD5 authentication on Windows server side?(Domain security policy?)
Regards,
Shinichiro Abe
On 2011/04/13, at 19:42, Karl Wright wrote:
> 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 (@mcf.org) does not usually work with this mode.
>
> Karl
>
> On Wed, Apr 13, 2011 at 5:13 AM, Shinichiro Abe
> <sh...@gmail.com> wrote:
>> Hello.
>>
>> Thank you for your answers.
>> Today, I tried the following.
>>
>> 1)I changed the source of Authentication.
>> ActiveDirectoryAuthority.getSession()
>> Context.SECURITY_AUTHENTICATION "DIGEST-MD5 GSSAPI" --> "simple"
>> 2)Rebuild and register authority connection in crawler-ui.
>> --> connection working.
>> Windows 2003 Server And Windows 2008 R2 did work!
>> username: Both "Admin@mcf.org" and "Admin@mcf" login successfully.
>> password: "P@ssw0rd" login successfully.
>> 3)Post and get SID.
>> http://ManifoldCFHost:8345/mcf-authority-service/UserACLs?username=user1@mcf.org
>> --> 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 error.
>>
>> 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 directory.
>>
>> 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 <da...@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 <da...@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
>>>>> <sh...@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' Admin@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' Admin@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: Admin@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.Admin@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
>>>>>>
>>>>>>
>>>>>
>>>>
>>
>>
Re: Authority Connection
Posted by Karl Wright <da...@gmail.com>.
I agree that this would be useful to have.
Karl
On Fri, Apr 15, 2011 at 11:31 PM, Koji Sekiguchi <ko...@r.email.ne.jp> wrote:
> (11/04/13 19:42), Karl Wright wrote:
>>
>> I believe "simple" transmits the credentials in plain text, which is
>> why I did not use that.
>
> Right. But I think users should be able to change it to simple via admin gui
> or somewhere else for testing purpose, for example.
>
> In ActiveDirectoryAuthority.java, I see:
>
> env.put(Context.SECURITY_AUTHENTICATION,"DIGEST-MD5 GSSAPI");
>
> Users may want to change the constant string.
>
> Abe-san, open a jira ticket and try out a patch, if you would like.
>
> Koji
> --
> http://www.rondhuit.com/en/
>
>>
>> With DIGEST-MD5 GSSAPI, did you try:
>>
>> Username: "Admin"
>> Password: "P@ssw0rd"
>>
>> The domain qualification (@mcf.org) does not usually work with this mode.
>>
>> Karl
>>
>> On Wed, Apr 13, 2011 at 5:13 AM, Shinichiro Abe
>> <sh...@gmail.com> wrote:
>>>
>>> Hello.
>>>
>>> Thank you for your answers.
>>> Today, I tried the following.
>>>
>>> 1)I changed the source of Authentication.
>>> ActiveDirectoryAuthority.getSession()
>>> Context.SECURITY_AUTHENTICATION "DIGEST-MD5 GSSAPI" --> "simple"
>>> 2)Rebuild and register authority connection in crawler-ui.
>>> --> connection working.
>>> Windows 2003 Server And Windows 2008 R2 did work!
>>> username: Both "Admin@mcf.org" and "Admin@mcf" login successfully.
>>> password: "P@ssw0rd" login successfully.
>>> 3)Post and get SID.
>>>
>>> http://ManifoldCFHost:8345/mcf-authority-service/UserACLs?username=user1@mcf.org
>>> --> 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 error.
>>>
>>> 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 directory.
>>>
>>> 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<da...@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<da...@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
>>>>>> <sh...@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'
>>>>>>> Admin@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'
>>>>>>> Admin@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: Admin@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.Admin@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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>>>
>>
>
>
>
Re: Authority Connection
Posted by Koji Sekiguchi <ko...@r.email.ne.jp>.
(11/04/13 19:42), Karl Wright wrote:
> I believe "simple" transmits the credentials in plain text, which is
> why I did not use that.
Right. But I think users should be able to change it to simple via admin gui
or somewhere else for testing purpose, for example.
In ActiveDirectoryAuthority.java, I see:
env.put(Context.SECURITY_AUTHENTICATION,"DIGEST-MD5 GSSAPI");
Users may want to change the constant string.
Abe-san, open a jira ticket and try out a patch, if you would like.
Koji
--
http://www.rondhuit.com/en/
>
> With DIGEST-MD5 GSSAPI, did you try:
>
> Username: "Admin"
> Password: "P@ssw0rd"
>
> The domain qualification (@mcf.org) does not usually work with this mode.
>
> Karl
>
> On Wed, Apr 13, 2011 at 5:13 AM, Shinichiro Abe
> <sh...@gmail.com> wrote:
>> Hello.
>>
>> Thank you for your answers.
>> Today, I tried the following.
>>
>> 1)I changed the source of Authentication.
>> ActiveDirectoryAuthority.getSession()
>> Context.SECURITY_AUTHENTICATION "DIGEST-MD5 GSSAPI" --> "simple"
>> 2)Rebuild and register authority connection in crawler-ui.
>> --> connection working.
>> Windows 2003 Server And Windows 2008 R2 did work!
>> username: Both "Admin@mcf.org" and "Admin@mcf" login successfully.
>> password: "P@ssw0rd" login successfully.
>> 3)Post and get SID.
>> http://ManifoldCFHost:8345/mcf-authority-service/UserACLs?username=user1@mcf.org
>> --> 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 error.
>>
>> 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 directory.
>>
>> 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<da...@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<da...@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
>>>>> <sh...@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' Admin@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' Admin@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: Admin@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.Admin@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
>>>>>>
>>>>>>
>>>>>
>>>>
>>
>>
>
Re: Authority Connection
Posted by Karl Wright <da...@gmail.com>.
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 (@mcf.org) does not usually work with this mode.
Karl
On Wed, Apr 13, 2011 at 5:13 AM, Shinichiro Abe
<sh...@gmail.com> wrote:
> Hello.
>
> Thank you for your answers.
> Today, I tried the following.
>
> 1)I changed the source of Authentication.
> ActiveDirectoryAuthority.getSession()
> Context.SECURITY_AUTHENTICATION "DIGEST-MD5 GSSAPI" --> "simple"
> 2)Rebuild and register authority connection in crawler-ui.
> --> connection working.
> Windows 2003 Server And Windows 2008 R2 did work!
> username: Both "Admin@mcf.org" and "Admin@mcf" login successfully.
> password: "P@ssw0rd" login successfully.
> 3)Post and get SID.
> http://ManifoldCFHost:8345/mcf-authority-service/UserACLs?username=user1@mcf.org
> --> 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 error.
>
> 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 directory.
>
> 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 <da...@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 <da...@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
>>>> <sh...@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' Admin@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' Admin@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: Admin@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.Admin@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
>>>>>
>>>>>
>>>>
>>>
>
>
Re: Authority Connection
Posted by Shinichiro Abe <sh...@gmail.com>.
Hello.
Thank you for your answers.
Today, I tried the following.
1)I changed the source of Authentication.
ActiveDirectoryAuthority.getSession()
Context.SECURITY_AUTHENTICATION "DIGEST-MD5 GSSAPI" --> "simple"
2)Rebuild and register authority connection in crawler-ui.
--> connection working.
Windows 2003 Server And Windows 2008 R2 did work!
username: Both "Admin@mcf.org" and "Admin@mcf" login successfully.
password: "P@ssw0rd" login successfully.
3)Post and get SID.
http://ManifoldCFHost:8345/mcf-authority-service/UserACLs?username=user1@mcf.org
--> 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 error.
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 directory.
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 <da...@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 <da...@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
>>> <sh...@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' Admin@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' Admin@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: Admin@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.Admin@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
>>>>
>>>>
>>>
>>
Re: Authority Connection
Posted by Karl Wright <da...@gmail.com>.
Hi - did you have any luck with this?
Karl
On Mon, Apr 11, 2011 at 5:50 AM, Karl Wright <da...@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 <da...@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
>> <sh...@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' Admin@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' Admin@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: Admin@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.Admin@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
>>>
>>>
>>
>
Re: Authority Connection
Posted by Karl Wright <da...@gmail.com>.
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 <da...@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
> <sh...@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' Admin@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' Admin@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: Admin@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.Admin@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
>>
>>
>
Re: Authority Connection
Posted by Karl Wright <da...@gmail.com>.
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
<sh...@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' Admin@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' Admin@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: Admin@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.Admin@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
>
>