Re: Problem with Protocol Transition

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.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
"Iain Mcleod" <IainMcleod@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:F2DD7B69-B043-4EBC-A096-C69C99695260@xxxxxxxxxxxxxxxx
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/UserSamples/Details.aspx?SampleGuid=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" wrote:

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.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services
Programming"
http://www.directoryprogramming.net
--
"Iain Mcleod" <IainMcleod@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:A29AA6A0-C8F0-4584-8A02-A63FDA0801D6@xxxxxxxxxxxxxxxx
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
"user@xxxxxxxxxx")

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






.

Relevant Pages

  • Re: Impersonation using WindowsIdentity( upn ) ctor
    ... are using under the hood when you use the WindowsIdentity "UPN" ctor. ... the token returned by the API will either be an Impersonation ... Only accounts with with that privilege can create an ... only the SYSTEM account has ...
    (microsoft.public.dotnet.security)
  • Re: Impersonation using WindowsIdentity( upn ) ctor
    ... are using under the hood when you use the WindowsIdentity "UPN" ctor. ... the token returned by the API will either be an Impersonation ... Only accounts with with that privilege can create an ... only the SYSTEM account has ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: Problem running ASP.NET 2.0 on Win2K domain controller
    ... which is a domain controller running Windows 2000 Server SP4. ... Either a required impersonation level was not provided, ... It appears that since this is a domain controller, the ASPUSER account is ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: How to use DuplicateTokenEx and CreateProcessAsUser (ASP.NET environment)
    ... > I have a question regarding using impersonation in IIS environment. ... 'SecurityDelegation' option so that the process can access network ... > Either a required impersonation level was not provided, ...
    (microsoft.public.dotnet.security)
  • RE: XP SP2, SSPI, Bad Impersonation level Error
    ... This seems to be related to a new security privilege introduced in XP SP2. ... logged on user at the Impersonation or Delegation level. ... privilege, the impersonation level is downgraded to Identify, which will ...
    (microsoft.public.platformsdk.security)