Windows and Basic Authentication and Delegation.

[Jerry C]

I am having trouble with reading Active Directory from my aspx page.

IIS 6.0 is set for Windows and basic autentication for the application.
The IIS 6.0 Windows 2003 server is set for trust for delegation at the
domain server.
The user is set for trust for delegation at the domain server.
There is a identity impersonate= "true" in the config file.

Users are loggin OK but when the server code gets to the line:

srUserCol = dsUser.FindAll()

There is a COMException(0x80072020) error

This code works when I remove Intergrated Windows authentication from IIS 6.0
It also works when I am logged on to the IIS server machine. I am sure the
code is OK but there is some problem with delegation. Also the code does not
work when I user Firefox This problem is addressed in a Thread:
http://forums.asp.net/thread/619114.asxp
I tried all those fixes and others in the readme first still no luck.

Thank you

 

[Joe Kaplan]

A couple of things:

Delegation settings on the user don't matter unless you have set the user
account to be "sensitive and cannot be delegated". Other than that,
delegation settings matter only for the service accounts in question.

If you want this to work with integrated auth (IWA) with the browser, web
server and AD all being different machines, then you do need to get Kerberos
delegation working.

If I had to guess why this isn't working with IWA right now, I'd say that
you probably aren't getting a successful Kerberos authentication to the web
server from the browser. It is failing over to use NTLM. This is usually
because the servicePrincipalName for the web app is not correct in some way.
If IWA fails over to NTLM, then you can't do Kerberos delegation UNLESS you
are using protocol transition.

You can get a clue as to what is going on by auditing logon events on the
web server and looking at the info in the security event log for the logon
event for the browser. It will tell you which security package was used.
It should say Kerberos if you want Kerberos, not NTLM.

I'm guessing this doesn't work with Firefox for similar reasons, but I'm not
certain if the IWA support in FF support Kerberos or just NTLM. You need
Kerberos.

If you don't want to rely on getting Kerberos authentication between the
browser and the web server, you need to use protocol transition. Given that
you have IIS 6 and it looks like you've also got 2003 AD, this should be a
supported feature (unless your AD admins haven't raised the forest
functional level to 2003 for AD yet). To get this to work, you need to
change the "allowed to delegate" setting to use "allowed to delegate with an
protocol" and then specify which services you want to delegate to in the
list (constrained delegation). Protocol transition logon requires that you
also use constrained delegation.

Sometimes it is easier to get pure Kerberos auth working with IE first by
fixing the SPN issues on the web server before going into protocol
transition, as it adds a lot of variables.

In some cases, the issue with NTLM vs. Kerberos is not with the SPNs on the
web server, but the fact that the IIS metabase has been changed to always
ask for NTLM auth instead of doing NEGOTIATE. This can be fixed by changing
the appropriate metabase setting. Some versions of SharePoint did this
during install, although I'm not sure exactly which. You can figure out if
this is the problem by getting a header viewer tool like FireFox live
headers or ieHttpHeaders and checking to see what string is provided by the
server in 401 challenge in the WWW-Authenticate header.

Another thing to consider might be to give up on the delegation, disable
impersonation and just use the process identity to access the directory.
This may or may not work for you, depending on what you are trying to do.

Best of luck!

Joe K.

 

[Steven Cheng[MSFT]]

Hello Jerry,

As Joe has suggested, you can check whether the client-side is correctly
communicate with the ASP.NET application through kerberos protocol. You can
either use netmon (or other network utility ) to trace the http messages or
print out the ASP.NET application's user identity AuthenticationType for
reference.
======
protected void Page_Load(object sender, EventArgs e)
{
Response.Write("<br/>current user authtype: " +
Context.User.Identity.AuthenticationType);
=========

Here are some additional knowledge base articles that helps on
troubleshooting kerberos delegation issues:

#Kerberos authentication and troubleshooting delegation issues
http://support.microsoft.com/kb/907272/en-us

#How to troubleshoot Kerberos-related issues in IIS
http://support.microsoft.com/kb/326985/en-us

#TechNet Support WebCast: Troubleshooting Kerberos authentication with
secure Web applications and Microsoft SQL Server
http://support.microsoft.com/kb/842861/en-us

Hope this also helps.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead



==================================================

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.



Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.

==================================================



This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Dominick Baier]

well - the authentication type will say "Negotiate" with integrated windows
auth - this will still give you no clue if Kerberos is used.

A good way is to look at the security log on the server - look for authentication
events and if the "Kerberos" authentication package is used...

 

[Steven Cheng[MSFT]]

Thanks for Dominick's input.

The "AuthenticationType" will display "NTLM" if Negotiate is not even
enabled in IIS, this is what we can still rely on this value.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Dominick Baier]

The OP said:

"IIS 6.0 is set for Windows and basic autentication for the application."

If you log in to a server with Basic authentication - the authentication
type will say "Basic".
If you log in to a server with IWA - the authentication type will say "Negotiate".

Under which conditions does the authentication type say "NTLM" ??

 

[Dominick Baier]

ah - ant btw - you can easily test that:

http://www.leastprivilege.com/ASPNETSecurityContextTroubleshootingTool.aspx

 

[Dominick Baier]

Hi Steven,

I see - thanks!

 

[Steven Cheng[MSFT]]

Hi Dominick,

I mean the following setting:

#How to configure IIS to support both the Kerberos protocol and the NTLM
protocol for network authentication
http://support.microsoft.com/kb/215383/en-us

It is possible that the IIS site only allow NTLM, then, any windows
authentication is done through NTLM protocol. The will result to obvious
difference in the "AuthenticationType" value. BTW, in the context here, I
never include other authtype except NTLM and kerberos.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Steven Cheng[MSFT]]

Hi Jerry,

How are you doing on this issue, have you got any further progress or does
the suggestion in previous messages help some?

If there is anything else we can help, please feel free to post here.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Jerry C]

Steven,

I used another way for AD access.
The lines:

Dim strADuser As String = "myuser"
Dim strADpwd As String = "mypwd"
Dim dirEntUser As New DirectoryEntry(strDomPath, strADuser, strADpwd,
AuthenticationTypes.Secure)

Dim dsUser As New DirectorySearcher(dirEntUser, "(objectCategory=user)")
Dim srUserCol As SearchResultCollection
srUserCol = dsUser.FindAll()

This worked also some users that use this code may not come from Micorsoft
machines they may be mac users. This would add another layer of problems.

Thank all for their posts.

 

[Steven Cheng[MSFT]]

Thanks for your reply Jerry,

I'm glad that you've got progress on this. If you mee any further problem
or anything we can help, please feel free to post here.

Have a good day!

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead