Authentication problem for roles based

[Chris Gatto]

Hi,

I'm having what should be a minor problem but has turned into a 2 day slug
fest with ASP.Net. I am simply attempting to authenticate my asp.net
application users against users in an AD group set up on our domain. It
seems to me I am missing something very simple and obvious, but none of the
MSDN articles I have read are indicating what this might be.

My setup is ASP.Net running on a Windows 2003/IIS 6 server. IIS security
settings are set to Integrated Windows Authentication only.

My web.config details are:

<authentication mode="Windows" />
<authorization>
<allow roles="domainname\groupname" />
<deny users="*" />
</authorization>
<identity impersonate="true" />

The problem is that:
1) the application is challenging for a login id/password, and
2) will not authenticate the user even though the credentials supplied
coorespond to an existing user in the specified AD group;

BTW: providing an allow users="domainname\username" works just fine.

Thanks in advance for the help.

 

[Jason]

I've been having the same issue in one of our in-house web application as
well: Yes it shows your proper AD credentials on the application but when
the server passes these credentials to the AD controller, that's where it
gets confused.

From the articles I've found it appears this is a classic double-hop issue
when the iis 6 server tries to pass on your credentials to the ad domain
controller. The only workaround we found was to create a very low-security
AD account that we have encrypted the username and password for, and tossed
these credentials into a text file (in the application's directory) for our
application to use.

If you find another solution please share it as I know there are a few
people who'd like to know.

Note: Even nesting AD impersonation with the following code doesn't seem to
alleviate the double-credential hop/passing.

'Impersonate the windows user running the application
Dim impersonationContext As
System.Security.Principal.WindowsImpersonationContext
Dim currentWindowsIdentity As System.Security.Principal.WindowsIdentity
currentWindowsIdentity = CType(User.Identity,
System.Security.Principal.WindowsIdentity)
impersonationContext = currentWindowsIdentity.Impersonate()
Try
'Gather User's username, authentication type and if the user
'is actually authenticated.
Dim p As IPrincipal
Dim i As System.Security.Principal.IIdentity
Dim isAuthenticated As Boolean
Dim authenticationType As String
p = System.Threading.Thread.CurrentPrincipal
i = p.Identity
isAuthenticated = CType(p.Identity.IsAuthenticated, String)
authenticationType = p.Identity.AuthenticationType
ADUserName = p.Identity.Name.Split("\"c)(1)
'Put code here under the current logged-in user
'...
'...
Catch ex As Exception
Response.Write(ex.Message)
End Try

'End impersonation
impersonationContext.Undo()

 

[TK]

If you simply attempt to secure your web application pages in your intRAnet
envirinment, I recommand you to stick up to file level access control rather
than URL level access control. What my understanding from my past
experiences on authentication and authorization mechanism in ASP.NET, is
that the URL level access control feature is a best way for intERnet
clients with Forms Authentication feature. But for intranet clients with
Windows Authentication, URL level access control feature just makes things
complex. You can simply control user and/or group (role) base access rights
by setting NTFS file access permissions.

To use file level access control feature, change your web.config as
following.

<authentication mode="Windows" />
<authorization>
<deny users="?" />
</authorization>
<identity impersonate="true" />

Then change some settings for your web application in IIS admin tool as
followings.

1. Disable "Anonymous Access".
2. Choose only "Windows integrated authentication".

hth
TK

 

[Chris Gatto]

Jason,

Thanks for the reply. After reading your post I began carrying out my own
research on the double-hop issue and eventually came across this KB article
(http://support.microsoft.com/default.aspx?scid=kb;en-us;810572). It
appeared that the issue may have been one of simple deligation permissions
on the client and on the IIS/App server. Seems like even though the client
was being authenticated via Windows Authentication (kerberos) on the IIS
server, the IIS server in turn was not permitted to pass on the user's
credentials to the AD controller server for authentication. As a result the
asp.net worker process using its own identity when attempting to get user
credentials from the AD server and was being rejected (thats more our
therory then actual hard fact). According to the KB article the solution is
to enable delegation permissions on both the client and IIS/App server.
This was not an attractive solution simple due to the number of clients that
would have to be enabled for delegation (maintenance and security
headaches).

In the end I realized there was a better solution all along simply by
accessing the user's Context.User.Identity.IsInRole method and verifying
against the desired AD group - the standard forehead-slapping moment
Now I'm working toward a nice security model using a shared class structure
that each aspx page will access up front.

Regards,
Chris

 

[Guest]

Sure Chris,

But I have to add that code to my page/pages...the bugger I have had is that
THIS USED TO WORK! I just had an application break on me so it has to be tied
to some Windows Update or service pack.

I built the app a long time ago and it has been running. I "allow" a
specified user list, but "my" access is controlled through a role/NT Security
group. They called me with a bug/feature to add and when I hit the site...I
was challenged for security. After an MS support call we figured out how to
grant me acess again (I forgot about the web.config entries) but we could not
explain the change.

I'm confused that this change has not been more clearly noted - or fixed.

Best Regards all,

Mark B