Problem with Protocol Transition

[Iain Mcleod]

Hi

I'm using protocol transition to create user accounts in an ASP.NET context.
The login seems to be working ok, but I'm getting a nasty security exception
"Attempted to perform an unauthorized operation" (see stacktrace).
I get the same error message in the debugger when I quick watch
httpcontext.current.user.identity, AuthenticationType property (it's a
WindowsIdentity with name=CONTOSO\Administrator and IsAuthenticated=True).


(In the code example, request is a HttpWorkerRequest object and
GetUserName() function returns a username of the form "(e-mail address removed)")

The wierd thing is that there only seems to be a problem with an identity
constructed using protocol transition (i.e. the following):

Dim user as WindowsIdentity = New
WindowsIdentity(GetUserName(request.GetServerVariable("LOGON_USER")))

If I construct the user using NTLM it works perfectly:
Dim user as WindowsIdentity = New WindowsIdentity(request.GetUserToken(),
request.GetServerVariable("AUTH_TYPE"), WindowsAccountType.Normal, True)

Here is the exception I get:

----------------------------------------------------------
Attempted to perform an unauthorized operation.
at System.Security.Principal.WindowsIdentity.get_AuthenticationType()
at System.Web.HttpRequest.CalcDynamicServerVariable(DynamicServerVariable
var)
at System.Web.HttpServerVarsCollectionEntry.GetValue(HttpRequest request)
at System.Web.HttpServerVarsCollection.GetServerVar(Object e)
at System.Web.HttpServerVarsCollection.Get(Int32 index)
at System.Web.HttpServerVarsCollection.GetValues(Int32 index)
at
System.Collections.Specialized.NameValueCollection.Add(NameValueCollection c)
at System.Web.HttpRequest.FillInParamsCollection()
at System.Web.HttpRequest.GetParams()
at System.Web.HttpRequest.get_Params()
----------------------------------------------------------------

Any ideas anyone?

Thanks
Iain Mcleod

 

[Joe Kaplan]

I did a little digging and discovered that this error occurs because an
internal call to the Windows API LsaGetLogonSessionData returns the HRESULT
0xC0000022, which translates to this Windows error message:

# for hex 0xc0000022 / decimal -1073741790 :
STATUS_ACCESS_DENIED ntstatus.h
# {Access Denied}
# A process has requested access to an object, but has not
# been granted those access rights.

I don't know why that would be the case for an S4U logon token though. Are
you impersonating the token when that happens? It might be some weird
artifact of S4U. Also, is the S4U token generated with Impersonate or
Identity level?

Joe K.

 

[Iain Mcleod]

Thanks Joe

No, I'm not impersonating the token when I get that error.
I'm just setting httpcontext.current.user to be a new WindowsIdentity object.
I don't actually do anything with it until I need to obtain a network
credential (I do a quick impersonate, grab the credentials and then do an
immediate undo of impersonation context).

If you need further information on my code, I've a mixed authentication
setup based on the following example:

http://www.gotdotnet.com/Community/...mpleGuid=a12e9f53-695f-452f-87d0-abbe9f12351e

(Except of course I'm using S4U instead of defaulting to GenericIdentity).


How can I find out which level the token is being generated with?
I'm just using the overloaded constructor for WindowsIdentity that takes
username as a string. Can't seem to see any params relating to Impersonate
or Identity level...

Cheers
Iain

 

[Joe Kaplan]

The token impersonation level is determined by whether the calling process
has the "act as part of the operating system" privilege. If that privilege
is held, then the token is impersonation level. Otherwise, the token is
identify level. Only an impersonation level token can be used to access
local objects.

Normally, only the Local System account has that privilege, so if your code
is calling the WindowsIdentity constructor in process from the web app
itself, you likely won't have this privilege if you are running as the
default Network Service account.

I'm not sure if that is relevant to the problem or not, but it is worth
being aware of if you are using S4U.

Joe K.

 

[Iain Mcleod]

Thanks Joe, that makes sense...

I'll have a go this weekend at changing the process privs as you suggest and
let you know how I get on...

Cheers
Iain

 

[Iain Mcleod]

OK, this is now officially a really nasty problem...

Sorry about the delay, I got derailed on another project.

I set up a domain account called DPool and gave it act as part of the
operating system (TCB privs) and then created a separate application pool
within IIS to use this account exactly as per the instructions in the
following article:
http://msdn2.microsoft.com/en-us/library/aa480585.aspx

It still gives me the security exception.

When I quick watch System.Security.Principal.WindowsIdentity.GetCurrent()
I get Name: "CONTOSO\DPool", IsAuthenticated: True, IsGuest: False,
IsSystem: False. Should I not get IsSystem: True if I've got TCB privs?

I take it it's nothing to do with the fact that the webserver I'm testing
this on is a virtual server which is configured as a domain controller?

Very confused... Any assistance would be greatly appreciated.

Thanks
Iain

 

[Iain Mcleod]

Oh, one other thing that may help identify the problem...
I've just noticed that the problem goes away if I impersonate the user.
Unfortunately, I don't want to impersonate if I can help it as other parts of
my app rely on me not impersonating...


Cheers
Iain

 

[Pom]

what is the OS (2000 or 2003) because windowsidentity react a little bit
differently on the 2 OS. Are you running asp.net 1.1 or 2.0. What is the
identity of your application pool? Network service or a service account. Did
you have a look at:
http://msdn2.microsoft.com/en-us/library/ms998355(d=printer).aspx ?