Darrell Bennington


I need to enable digest authorization on an HTTP endpoint, because the integration tools for some java code that needs to connect to it does not support NTLM or kerberos - only digest and basic. I setup a test endpoint in order to test only digest authorization (as opposed to the final endpoint which needs both digest and integrated), but I can't even get that to work - when I point my browser to it to see the wsdl it pops up with the login box, but the login always fails.

I have the feeling I'm missing some very minor piece that will just make the whole thing work. Below are some log entries as well as the script to create the test endpoint I'm hitting. Any ideas are very welcome, I've banged my head on this one for far too long.

SQL Server error logs shows a "Error: 26026, Severity: 14, State: 1" entry followed by a "HTTP authentication failed" entry.

Event Log Security entry on the server:

Logon Failure:

Reason: An error occurred during logon

User Name: MyUserName

Domain: mydomain

Logon Type: 3

Logon Process: WDIGEST

Authentication Package: WDigest

Workstation Name: -

Status code: 0xC000006D

Substatus code: 0xC00000FE

Caller User Name: -

Caller Domain: -

Caller Logon ID: -

Caller Process ID: -

Transited Services: -

Source Network Address: -

Source Port: -

Test endpoint script:

CREATE ENDPOINT [DigestTest]

STATE=STARTED

AS HTTP (PATH=N'/DigestTest', PORTS = (CLEAR), AUTHENTICATION = (DIGEST), SITE=N'SRV001',

CLEAR_PORT = 80, AUTH_REALM=N'mydomain', COMPRESSION=DISABLED)

FOR SOAP (

WEBMETHOD 'SimpleTest'( NAME=N'[TestDB].[dbo].[spSimpleTest]'

, SCHEMA=DEFAULT

, FORMAT=ALL_RESULTS),

BATCHES=DISABLED, WSDL=N'[master].[sys].[sp_http_generate_wsdl_defaultcomplexorsimple]',

SESSIONS=DISABLED, SESSION_TIMEOUT=60, DATABASE=N'TestDB', NAMESPACE=N'http://mydomain.com/',

SCHEMA=STANDARD, CHARACTER_SET=XML)




Re: Digest Authorization on HTTP Endpoint

Jimmy Wu - MSFT


SQL Server 2005 endpoint Digest authentication only support MD5-Sess and not MD5. The difference between the two is that MD5-Sess includes a time within the hash, such that if the same MD5 hash is sent to the server after certain period of time, the server will reject the hash; thus providing greater security to prevent playback/replay attacks.

Your endpoint looks correct. Since on Windows Digest requires a domain controller, I assume that your network environment is already setup correctly to support Digest authentication For example, your machine "SRV001" is joined to a domain and the user you are using to retrieve the WSDL document is a domain user. Also note that if the domain controller is running Windows 2000, there may be some incompatibility issues. It is highly recommended to run the domain controller using Windows 2003, which has better support for Digest authentication.

It would greatly help to know the system environment in which you are running this on. Information such as OS version, client application (you mentioned browser, I would have assume Internet Explorer; or is it Firefox ), and network setup would really help us understand and troubleshoot the problem.

HTH,
Jimmy







Re: Digest Authorization on HTTP Endpoint

Darrell Bennington

Since on Windows Digest requires a domain controller, I assume that your network environment is already setup correctly to support Digest authentication

This is something I do not know - when I talked with IT about it before, they told me it was a developer problem and wouldn't look at it any more. This could very well be the piece I'm missing - what is it I could have them look at

The server running the SQL Server is running Windows Server 2003 R2 Enterprise x64 edition, and the SQL Server version is 9.0.2175

Local System: XP Pro SP2, browser I was accessing the wsdl with is IE v6 with all patches updated, and is setup to go through a proxy server. Note that I get the same results if I attempt to create a web reference to it from a project in VS2005, which probably isn't that surprising. I don't have access to the java code that will be accessing the final version, so I was trying go get something working on my end first, before telling the other developer to hit it.

I'm not sure about what version of windows the domain controller is running, I'll have to ask around, but won't know that until tomorrow (anyone I could ask is already gone for the day)






Re: Digest Authorization on HTTP Endpoint

Jimmy Wu - MSFT

Hi Darrell,

Sorry, forgot to mention a couple more things to double check on. Please make sure you've granted connect permissions to the NT user account you are trying to retrieve the WSDL document with. So in your case, it would be something like:
GRANT CONNECT on ENDPOINT::DigestTest to [domain\userName]

Please also make sure the user has Execute permission on the Stored Procedure.
GRANT EXEC on spSimpleTest to [domain\userName]

The other thing you can try before going to the network admins is enabling "NTLM" authentication type on the endpoint. So, the Endpoint syntax would be updated to have:
AUTHENTICATION = (DIGEST, NTLM)

This way, you can double check to make sure the user has all the necessary permissions and the endpoint is setup correctly. Then if setting the Endpoint to DIGEST only is still giving you problems, you can go back to the network admins and ask them what OS version the domain controller is running under and if the network supports Digest.

Jimmy






Re: Digest Authorization on HTTP Endpoint

Darrell Bennington

Yep, it works just fine with NTLM (or integrated) for the users I'm trying to connect with, so connect and view permisions (for the wsdl) are set for the endpoint for the users I'm trying to authenticate, and the user also does have execute priveledges on the stored procedure. The only problem I'm having is with digest.

I'll give the network admin a call and see what I find out.





Re: Digest Authorization on HTTP Endpoint

Darrell Bennington

Looks like this was it. Our domain controller is running Windows 2000 (planned upgrade to 2003 this quarter though), and digest is not enabled - doing so must go through a chain of security people it seems.

Thanks for pointing me in the right direction - it may be a while before it's working yet, but at least I'm off the hook for now.