Delegation/Basic Authentication - using browsers other than IE

R

Raterus

Hi,

I'd really like to see my intranet asp.net pages with other browsers, but I'm having a problem when it comes to connecting to SQL Server. My intranet site is configured with Integrated Windows Authentication & Basic Authentication; anonymous access is disabled. I only get these problems when I request a page that uses SQL Server, if the page is just a simple asp page, it works great. Let me run through what I'm doing.

I request a page that interfaces with SQL Server, since Integrated windows authentication won't work, it falls back on basic, I enter my credentials (yes I'm entering the right ones!), but get hit with these kind of errors.
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
Incidentally, I have already configured delegation on this webserver, and it works perfectly with Internet Explorer/Integrated Windows Authentication. I would think this would be even easier with another browser/basic authentication, since I have to enter my credentials, that should create a primary authentication token on the server for it to use, right?

My question is, why is my webserver trying to pass "NT AUTHORITY\anonymous logon" on to SQL Server? Both my webserver and my domain account are "Trusted for Delegation"

I've done a little detective work and determined that if I turn off Integrated Windows Authentication, it works like I want it too, unfortunately I can't do this since everyone else uses IE. It's almost as if IIS is not completely falling back onto Basic Authentication. Can someone help me out here!

Thanks for any help!
--Michael
 
J

John Rusk

Michael,

By the way, I saw some information recently saying that Firefox now supports
integrated windows authentication, just as seamlessly as IE does. You have
to manually enable it tho.

As for your specific problem, I don't know sorry. :-(

John
 
R

Raterus

You wouldn't happen to have the link to this would you? I can't find anything on it, and I waded through Firefox 1.0 menu's and didn't see anything about it. That would be pretty nice if it did though! (BTW, I do want to use FireFox with my pages... :) )
 
R

Raterus

Cute, but that isn't exactly Integrated Windows Authentication at it's fullest. It's half the battle, but NTLM is a bit older technology and isn't fully compatible with today's growing intranet applications. My original issue deals with delegation, and you have to authenticate with Kerberos in order to have your credentials delegated to another server past the webserver. This is not possible with NTLM...well not easily anyway. I received this response once for delegation issues "If you are also running a Windows 2003 Domain, then with constrained delegation you can also configure Protocol Transition" Doesn't sound easy to me!
 
J

Joe Kaplan \(MVP - ADSI\)

protocol transition and constrainted delegation are two seperate things,
although both 2003 features.

Constrained delegation allows you to limit what other services a specfic
account can delegate to. In 2000, once you enabled delegation, it was all
or nothing. A service could delegate to anything.

Protocol transition is the ability to switch from non-Kerberos auth to a
Kerberos token. This can be done programmatically by calling LsaLogonUser
or using the .NET WindowsIdentity constructor that takes the single upn
argument. However, Windows can also do protocol transition automatically.
Say for example a user was authenticated via NTLM but now needs to be
delegated. In this case, Windows will do protocol transition automatically
and swtich to using Kerberos so delegation is possible.

There are some really good articles on this stuff that explain it more
thoroughly, but that is the gist.

Joe K.

Cute, but that isn't exactly Integrated Windows Authentication at it's
fullest. It's half the battle, but NTLM is a bit older technology and isn't
fully compatible with today's growing intranet applications. My original
issue deals with delegation, and you have to authenticate with Kerberos in
order to have your credentials delegated to another server past the
webserver. This is not possible with NTLM...well not easily anyway. I
received this response once for delegation issues "If you are also running a
Windows 2003 Domain, then with constrained delegation you can also configure
Protocol Transition" Doesn't sound easy to me!
 
R

Raterus

Thanks Joe, any idea on my original problem?

Joe Kaplan (MVP - ADSI) said:
protocol transition and constrainted delegation are two seperate things,
although both 2003 features.

Constrained delegation allows you to limit what other services a specfic
account can delegate to. In 2000, once you enabled delegation, it was all
or nothing. A service could delegate to anything.

Protocol transition is the ability to switch from non-Kerberos auth to a
Kerberos token. This can be done programmatically by calling LsaLogonUser
or using the .NET WindowsIdentity constructor that takes the single upn
argument. However, Windows can also do protocol transition automatically.
Say for example a user was authenticated via NTLM but now needs to be
delegated. In this case, Windows will do protocol transition automatically
and swtich to using Kerberos so delegation is possible.

There are some really good articles on this stuff that explain it more
thoroughly, but that is the gist.

Joe K.

Cute, but that isn't exactly Integrated Windows Authentication at it's
fullest. It's half the battle, but NTLM is a bit older technology and isn't
fully compatible with today's growing intranet applications. My original
issue deals with delegation, and you have to authenticate with Kerberos in
order to have your credentials delegated to another server past the
webserver. This is not possible with NTLM...well not easily anyway. I
received this response once for delegation issues "If you are also running a
Windows 2003 Domain, then with constrained delegation you can also configure
Protocol Transition" Doesn't sound easy to me!
 
J

Joe Kaplan \(MVP - ADSI\)

Nope! I didn't pipe in because I wasn't sure what the answer was. As I
recall, your scenario was trying to use delegation and WIA, but it wasn't
working, right? Sorry, but I lost the original post.

Joe K.

Thanks Joe, any idea on my original problem?
 
R

Raterus

Here is my original post. I haven't really gotten past this yet. Thanks for any help you might add. I'd imagine this may be easily recreated by anyone by trying another browser besides IE on their ASP/ASP.net pages (using WIA of course)
--

I'd really like to see my intranet asp.net pages with other browsers, but I'm having a problem when it comes to connecting to SQL Server. My intranet site is configured with Integrated Windows Authentication & Basic Authentication; anonymous access is disabled. I only get these problems when I request a page that uses SQL Server, if the page is just a simple asp page, it works great. Let me run through what I'm doing.

I request a page that interfaces with SQL Server, since Integrated windows authentication won't work, it falls back on basic, I enter my credentials (yes I'm entering the right ones!), but get hit with these kind of errors.
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
Incidentally, I have already configured delegation on this webserver, and it works perfectly with Internet Explorer/Integrated Windows Authentication. I would think this would be even easier with another browser/basic authentication, since I have to enter my credentials, that should create a primary authentication token on the server for it to use, right?

My question is, why is my webserver trying to pass "NT AUTHORITY\anonymous logon" on to SQL Server? Both my webserver and my domain account are "Trusted for Delegation"

I've done a little detective work and determined that if I turn off Integrated Windows Authentication, it works like I want it too, unfortunately I can't do this since everyone else uses IE. It's almost as if IIS is not completely falling back onto Basic Authentication. Can someone help me out here!
 
J

Joe Kaplan \(MVP - ADSI\)

Yeah, I can't help you here. I have no idea what's going on. It would be
interesting to know what kind of token is getting created for the user on
the server as that might explain what's going on. Basic should create a
primary token that doesn't need delegation, but it looks like that might not
be happening.

Without some deeper understanding of the actual tokens getting created, I
have no idea what to tell you.

Sorry,

Joe K.

Here is my original post. I haven't really gotten past this yet. Thanks
for any help you might add. I'd imagine this may be easily recreated by
anyone by trying another browser besides IE on their ASP/ASP.net pages
(using WIA of course)
--

I'd really like to see my intranet asp.net pages with other browsers, but
I'm having a problem when it comes to connecting to SQL Server. My intranet
site is configured with Integrated Windows Authentication & Basic
Authentication; anonymous access is disabled. I only get these problems
when I request a page that uses SQL Server, if the page is just a simple asp
page, it works great. Let me run through what I'm doing.

I request a page that interfaces with SQL Server, since Integrated windows
authentication won't work, it falls back on basic, I enter my credentials
(yes I'm entering the right ones!), but get hit with these kind of errors.
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
Incidentally, I have already configured delegation on this webserver, and it
works perfectly with Internet Explorer/Integrated Windows Authentication. I
would think this would be even easier with another browser/basic
authentication, since I have to enter my credentials, that should create a
primary authentication token on the server for it to use, right?

My question is, why is my webserver trying to pass "NT AUTHORITY\anonymous
logon" on to SQL Server? Both my webserver and my domain account are
"Trusted for Delegation"

I've done a little detective work and determined that if I turn off
Integrated Windows Authentication, it works like I want it too,
unfortunately I can't do this since everyone else uses IE. It's almost as
if IIS is not completely falling back onto Basic Authentication. Can
someone help me out here!
 
K

Ken Schaefer

Hi,

If basic authentication is truly being used, then IIS has the user's
username and password, and should be able to directly send that to SQL
Server. As you can see, this works when you disable Integrated Windows
Authentication completely.

What I suspect is happening is that NTLM authentication is being used. When
IWA is enabled, IIS actually (by default) sends back two HTTP Authentication
headers:
WWW-Authenticate: Negotiate <- Kerberos
WWW-Authenticate: NTLM <- NTLM
WWW-Authenticate: Basic <- Basic

If your browser supports NTLM (eg later versions of Opera, and
Mozilla/Firefox do as well), then they will pick NTLM. Then you'll run into
delegation problems as IIS doesn't have the user's username/password -and-
you haven't enabled protocol transition.

Now, if you want to verify what's happening, you can use the new IIS
AuthDiag tool which you can download from here:
http://www.microsoft.com/downloads/...77-4a21-4066-bd22-b931f7572e9a&DisplayLang=en

Cheers
Ken


Here is my original post. I haven't really gotten past this yet. Thanks
for any help you might add. I'd imagine this may be easily recreated by
anyone by trying another browser besides IE on their ASP/ASP.net pages
(using WIA of course)
--

I'd really like to see my intranet asp.net pages with other browsers, but
I'm having a problem when it comes to connecting to SQL Server. My intranet
site is configured with Integrated Windows Authentication & Basic
Authentication; anonymous access is disabled. I only get these problems
when I request a page that uses SQL Server, if the page is just a simple asp
page, it works great. Let me run through what I'm doing.

I request a page that interfaces with SQL Server, since Integrated windows
authentication won't work, it falls back on basic, I enter my credentials
(yes I'm entering the right ones!), but get hit with these kind of errors.
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
Incidentally, I have already configured delegation on this webserver, and it
works perfectly with Internet Explorer/Integrated Windows Authentication. I
would think this would be even easier with another browser/basic
authentication, since I have to enter my credentials, that should create a
primary authentication token on the server for it to use, right?

My question is, why is my webserver trying to pass "NT AUTHORITY\anonymous
logon" on to SQL Server? Both my webserver and my domain account are
"Trusted for Delegation"

I've done a little detective work and determined that if I turn off
Integrated Windows Authentication, it works like I want it too,
unfortunately I can't do this since everyone else uses IE. It's almost as
if IIS is not completely falling back onto Basic Authentication. Can
someone help me out here!
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,768
Messages
2,569,575
Members
45,053
Latest member
billing-software

Latest Threads

Top