IIS 7.5 basic authentication and Active Directory validation

Question

I'm not an IIS or Active Directory expert by any means so I want to present a scenario here and see if what we want to accomplish is feasible.

We have an application hosted on Windows Server 2008 R2 with a series of web services exposed as an API through IIS. These services will be called by multiple external integration systems. If we configure the IIS services to use Basic authentication, will IIS validate the credentials we pass to it against Active Directory by default, is this a special configuration setting, or is this not possible? We'd like for those credentials to be validated against AD so we receive the token/principal in return, which can be sent to the underlying application on that server.

Thanks in advance. Any help is appreciated.

Solution 1

Basic authentication will work just fine for authenticating against AD - it authenticates against the IIS server's local account database; for a domain member, that includes the Active Directory domains in the forest that it's joined to.

You'll not get any kind of kerberos ticket in return - basic auth simply includes the password in the header of requests sent to the server, and the server does with it what it will - returning either the requested resource or a 401 error.. but if you're looking for user identification within the web application within IIS, then that information (which user/domain they authenticated as) should be available to the code.

Browsers will keep the entered password in memory for the life of the session, so you'll be covered for subsequent requests to that server, but not for any access to other systems or services.

There's information about configuring basic auth, including configuring the default domain and the prompt that users receive, here.

Solution 2

Okay, so an answer's been accepted, but I'm going to say in general:

Don't use Basic.

If there's a question for which Basic-with-domain-credentials seems like it's the right answer, it's almost always not.

Use Integrated Authentication.

Basic allows a malicious web developer to learn a user's AD credentials, and then it's game over.

Integrated allows the user to authenticate that they are who they say they are, and allows the use of Constrained Delegation to limit what a web developer can do with the token. It doesn't directly expose the username and password to interception (if SSL is mis- (i.e. not-) configured, which happens all the freakin' time), and it doesn't allow someone with write access to the web server share to write simple web applications which intercept credentials.

Solution 3

If IIS has the user credentials, those can be used to create a primary token for that user. IIS can use that token and impersonate that user to access resources and applications on other servers.

The IIS machine and application pool identity (service account) would need to be configured for the appropriate level of impersonation or delegation in order to act on behalf of a user with their token, but this scenario is actually quite common in the IIS/ASP.Net world.

If you were to perform constrained delegation - mentioned by Tristan - it is actually possible to create a full delegation-level token for users for access to specific services on specific machines (that's the constrained part), and you do not actually need their password. This is more secure if you have an external authentication mechanism (such as a smart card), and only their identity is passed to the web application. This obviates the need to transmit passwords beyond security boundaries.

Comments

[ravi yarlagadda]

This isn't correct.. Basic auth works just fine for domain users, and even includes an option to set the default login domain so that users don't need to use a UPN or domain\username to log in. It's plaintext over the HTTP channel, but that's what SSL is for.

[adaptr]

...that would completely expose AD credentials on the wire.

[ravi yarlagadda]

If you enter them on an unencrypted link, it certainly would, but it's still an option. Some browsers these days even warn you when you're doing basic auth on an HTTP channel. Again, SSL is the answer to that concern.

[adaptr]

I'm sorry, it's not that I am doubting what you say, but the mere concept of allowing (by nature very secure) Kerberos credentials to be exposed over an HTTP request is.. wow.

[ravi yarlagadda]

Well, there's nothing tying it to a user's kerberos session or anything like that - the only difference from non-domain auth is what the server does with the authentication data, validating against the domain instead of local users. Basic auth over SSL is no less secure than, say, forms authentication via a POST request over an SSL channel (as in, for instance, Exchange's Web Access).

[jturinetti]

Thanks Shane. What exactly is returned from AD after validating credentials using basic auth?

[ravi yarlagadda]

I'm not sure what you mean - returned to where?

[jturinetti]

For example, in the case where a Kerberos ticket is returned from AD to the server's IIS, I think this involves Windows Integrated Auth. In my scenario, a client passes username/password in request to IIS-hosted service. IIS, set up for basic auth, validates those credentials against AD. In the case of basic auth here, does AD return anything to IIS to uniquely identify that user, such as a token of some sort?

[ravi yarlagadda]

It authenticates and builds a limited session on behalf of the user; assuming your application's in the ASP world then it can identify the user via User.Identity.Name - see here.