«

Hello all,

Here is the context of my problem:

We have an ASP.NET 1.1 application that has its own application pool
setup and that runs under the identity of a NT Domain service account
(this is for security reason when accessing databases). We use the
Integrated Windows authentication to authenticate users, and we have
setup the Web.config file to authenticate those users against 3 NT
Domain Global Groups. Everything is working fine (the application is
up and running since 1.5 year already) and security is respecting the
application's security requirements.

We are in the process of moving all of our servers (including this IIS
6.0 server) into AD (Active Directory). This week was this server's
turn to be migrated and everything turns out ok from a migration point
of view. What is not working anymore is is the authentication of
users.

Remember I just said that the application pool is running under a NT
Domain service account? Well since we are moving to AD, we also have
to move the user accounts (and service accounts) into AD. So we are
now using an AD service account to run the application pool. So far so
good, but to our dismay, we are unable to authenticate any users
anymore! It looks like IIS's new Application Pool identity isn't able
to validate against AD properly. Me and the migration team have check
a lot of things, but we must be missing something trivial.

If anyone can point me into some direction, I would appreciate.

And here is and excerp from our Web.config file concerning the
authentication and authorization.

<system.web>
....
<authentication mode="Windows" />
<identity impersonate="false"/>
<authorization>
<allow roles="AD\group1, AD\group2, AD\group3" />
<deny users="*" />
</authorization>
....
</system.web>

And yes, the <identity impersonate="false"/> is correct since we are
using the Application's Pool identity.

Thank you for any help!
P.J

the application pool controls the account the asp.net worker process runs
under. windows authenication is performed by IIS, not asp.net. IIS just
passes the security token to the worker process. check the vdir settings
still have anonymous turned off. also the server must be trusted by the ad.

check that you can logion with an ad account on the webserver.

-- bruce (sqkwork.com)




<> wrote in message
news: ups.com...
> Hello all,
>
> Here is the context of my problem:
>
> We have an ASP.NET 1.1 application that has its own application pool
> setup and that runs under the identity of a NT Domain service account
> (this is for security reason when accessing databases). We use the
> Integrated Windows authentication to authenticate users, and we have
> setup the Web.config file to authenticate those users against 3 NT
> Domain Global Groups. Everything is working fine (the application is
> up and running since 1.5 year already) and security is respecting the
> application's security requirements.
>
> We are in the process of moving all of our servers (including this IIS
> 6.0 server) into AD (Active Directory). This week was this server's
> turn to be migrated and everything turns out ok from a migration point
> of view. What is not working anymore is is the authentication of
> users.
>
> Remember I just said that the application pool is running under a NT
> Domain service account? Well since we are moving to AD, we also have
> to move the user accounts (and service accounts) into AD. So we are
> now using an AD service account to run the application pool. So far so
> good, but to our dismay, we are unable to authenticate any users
> anymore! It looks like IIS's new Application Pool identity isn't able
> to validate against AD properly. Me and the migration team have check
> a lot of things, but we must be missing something trivial.
>
> If anyone can point me into some direction, I would appreciate.
>
> And here is and excerp from our Web.config file concerning the
> authentication and authorization.
>
> <system.web>
> ...
> <authentication mode="Windows" />
> <identity impersonate="false"/>
> <authorization>
> <allow roles="AD\group1, AD\group2, AD\group3" />
> <deny users="*" />
> </authorization>
> ...
> </system.web>
>
> And yes, the <identity impersonate="false"/> is correct since we are
> using the Application's Pool identity.
>
> Thank you for any help!
> P.J
>

After more than two weeks digging in this problem, I have some
interesting things to share in order to help anyone with this kind of
problem.

First, I will point you to a couple of articles that we tackled with
but still with no success.
Next, I will tell you how to replicated the problem if you want to
experiment and try solving it.

This first article describes exactly the problem we have.
Unfortunately, the solution proposed can't be adopted since we have
multiple application pool each running under its own specific domain
account. The workaround proposed is one that we might use in the last
resort because we do not want to rely on NTLM anymore to perform
authentication.
http://support.microsoft.com/kb/871179/en-us

The next article explain why anthentication uses NTLM instead of
Kerberos:
http://technet2.microsoft.com/Window...6e8dd1033.mspx

This one indicates on to configures IIS to support both Kerberos and
NTLM authentication:
http://support.microsoft.com/kb/215383/EN-US/

Another Kerberos article on user belonging to too many groups:
http://support.microsoft.com/?kbid=280830

This last two articles is about delegating authentication and we have
not yet investigate it:
http://www.microsoft.com/technet/pro...a81454cfe.mspx
http://www.microsoft.com/technet/pro...5d2159199.mspx


In order for some of you to replicate the problem we have and to try
their hands on it, follow these lines to create a very simple .NET
application.

1- On a Windows Server 2003, put an ASP.NET 1.1 application (that you
made on your dev station) that does nothing (no lines of code in it)
except maybe printing a message ;

2- In IIS Manager, create a new application pointing to the folder you
just copied you application. Be sure that only Windows integrated
authentication is selected in 'Directory Security'

3- Still in IIS Manager, create a new application pool, and under the
'Identity' tab, click the radio-button 'Configurable' and type in a
service account from your Active Directory and its password; Set your
application to use the new application pool you just created.

4- Add this selected Active Directory account to the local group
IIS_WPG;

5- Add the Read NTFS rights for this Active Directory account on the
folder of your application and the local Users groups too;

6- In the Web.config file of your application, check that these
settings are like those in the <system.web> section:

<authentication mode="Windows" />
<identity impersonate="false" />
<authorization>
<allow users="*" />
</authorization>

7- Try to access your site to your *.aspx page and you should be
prompted to authenticated even though you have the rights to access it.

Well I have no more time to write more at the moment, but I will come
back with news as soon as I have.
Thx!
P.J

Also, the info on David Wang's blog about Kerberos and authentication
error is quite, eh, surprising I must say, since it looks like this was
'common knowledge'.

http://blogs.msdn.com/david.wang/default.aspx
Go on his site and search for 'kerberos' keyword with is search tools,
then do a CTRL+F and look for this string on the resulting page:
401.1 Denied by Invalid User Credentials

The following article from Microsoft finally explain why the problem we
encountered is 'normal':

http://www.microsoft.com/technet/pro...7.mspx?pf=true

Unfortunately for us, we have to rethink some aspect of the application
since we put a lot on using the application pool to heighten the
security and access between services. Too bad our application were
made before moving to AD because we would have change the architecture
some how.

At least, we can make everything work by 'turning on' the NTLM
authentication, but we can't live with this for very long I'm afraid.

I hope that this had help some of you with the same problem, and I do
hope that I help other planned their architure on NOT using specific
identity with their application pool, but to stay with the 'Network
Service' accound since this always work (and for more reason than only
authentication - those of you who have found my previous posting this
year about the worker process recycling not working as expected when
NOT running under Network Service know what I am talking about.

Good Luck people!