Impersonation headaches with ASP.NET 2.0 -- help!

[cider123]

From what I have read, my best guess is the LogOnUser method of
Win32API is the culprit here.

An article I ran across talked about:

- - -
On the Windows NT and Windows 2000 platforms, the account under which a
program is running requires the Windows SE_TCB_NAME privilege to call
LogonUser in order to obtain an access token. Without this privilege,
calls to LogonUser fail and calling GetLastError returns the code
ERROR_PRIVILEGE_NOT_HELD (value 1314). To grant an account the
SE_TCB_NAME privilege, you must configure the local security policy to
allow the account to "Act as part of the operating system." This highly
trusted privilege allows the account to create access tokens that
represent any user or permission set. You should only grant this
permission to accounts created specifically to run your software; never
grant this permission to user accounts.
- - -

Another article I ran across, from Microsoft, talks about not assigning
the "ASP.NET" account to the "Act as part of the Operating System"
role.

Another article I read mentioned the User you want to Impersonate does
not go under the "Act as part of the Operating System" role.

I'm at a total loss here.

I've tried adding the Impersonation data to the web.config file.
(<identity impersonate="true" userName="domain\account"
password="xxxxxx" /> )
I've tried the "LogOnUser" API call.
I've tried adding the User Account to the "Act as part of the Operating
System role", despite what documentation I ran across saying that's not
how you do it.

Every single time I've attempted to Impersonate the account, it returns
with value 1314 on the GetLastError API call.

The Web Service (ASP.NET 2.0) is running on a Windows 2000 Server box.

In the "Act as part of the Operating System role", the Account I added
(the one I want to Impersonate) has 2 checkboxes in this dialog. The
first one is checked off ("Local Policy Setting") and the second one is
greyed out ("Effective Policy Setting") and it won't let me check it
off. I don't know if this means it's restricted at the Domain level,
or if I don't have access to authorize the Impersonation (by checking
the box). Not really a Server Admin, but learning what I can as time
requires it.

My objective is to receive parameters (account info) in this Web
Service which will then be used for Impersonation for the right
security hooks into existing network shares.

I've run across a few articles talking about Membership and Role
Manager APIs, but I've never used them and don't know if that is what I
need.

I'm using the mode="Windows" authentication method for this Web
Service.

All I know is this is driving me nuts. I hope someone can clarify and
maybe link some articles with more info on a "how-to" type of
reference.

 

[Rahul Soni]

Try this out...

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/paght000023.asp

--
Thanks,
Rahul Soni

--->The secret to creativity is knowing how to hide your sources<---

 

[cider123]

Thanks. I actually ran across that web site also.

I ended up moving the Web Service to a Windows 2003 box and it runs
fine now.

Apparently, based on everything I read, the account running the Web
Service needs to have Admin rights in a Windows 2000 environment to
make the Impersonation requests. That would be the ASPNET account, and
that's the last thing our Admins want to do is give those rights to
that account.

You don't have the same restrictions though in XP or Server 2003+
systems.

Thanks for the attempt in helping though, much appreciated.