Re: LogonUser call fails for NetworkService account on XP x64 insi
- From: "Larry Smith" <no_spam@xxxxxxxxxxx>
- Date: Tue, 18 Sep 2007 10:11:03 -0400
Hi Larry,
thanks for this tip, but unfortunately i later use this token with managed
code (something like WindowsIdentity.Impersonate(token)) and .Net Remoting
and the the System account seems not to be able to correctly impersonate
as
computer via IIS then.
I have this problem already with W2k (see
http://msdn.microsoft.com/newsgroups/default.aspx?query=impersonate+as+computer&dg=&cat=en-us-msdn&lang=en&cr=US&pt=&catlist=774F24A2-F71F-425F-AC2B-DC48AB0DA5C9&dglist=&ptlist=&exp=&sloc=en-us).
The NetWorkService account seems to be better supported by this than the
system account.
So currently i really need a solution to get the NetworkService token.
This is also an issue because the software works fine with all other OS's
and special handling of an OS is always more maintenace and test effort.
Regards,
First, have you tried turning on "Audit account logon events" under "Local
Policies\Audit Policy" in the "secpol.msc" snap-in. This will usually write
a message to the security event log telling you why "LogonUser()" failed. In
any case, it's obviously a little more tricky to diagnose things given your
"unique" situation (running under WOW64). I wouldn't normally think it
should make any difference however, especially since it works under the
other OSs you mentioned. I'm actually perplexed that things don't work under
the System account directly though. It should in theory. In any case, I see
you're using "NetworkService" and not "Network Service" (with a space) given
that MSFT declares it that way. I assume your example is just a typo? Also
note that since you're passing LOGON32_LOGON_SERVICE then the "Network
Service" account will require this right on your machine ("Log on as a
service"). It normally has it by default but you should check it just in
case (though you're not getting the usual error if this really were the
problem). As a further test though, try logging on using
LOGON32_LOGON_NETWORK instead, just to see if it works. This right is
granted automatically as I recall (you need not explicitly set it) and it
also returns an impersonation token instead of a primary token. This might
(therefore) eliminate the problem if SE_CREATE_TOKEN_NAME is really the
cause, as discussed below (read on). The only thing I can therefore think of
at this stage is that under WOW64 the "Service" account has perhaps been
stripped of some necessary privilege (I'd be surprised) or the privilege
itself is disabled (and must be explicitly enabled even though most are
enabled by default under the Service account). "LogonUser()" makes little
explicit mention of these privileges but a quick check in general and I see
SE_CREATE_TOKEN_NAME for instance. I'm not sure if this is really required
however since on my machine it's not even showing as active for any account
under "Local Policies\User Rights Assignment" (in the "secpol.msc" snap-in).
Since this privilege is required for primary tokens however (according to
the docs), then again, try LOGON32_LOGON_NETWORK as a test since it returns
an impersonation token as noted (so the privilege wouldn't be required in
theory).
.
- Follow-Ups:
- References:
- Prev by Date: Re: PLAP provider
- Next by Date: How to tell if authenticated against cached Windows credentials?
- Previous by thread: Re: LogonUser call fails for NetworkService account on XP x64 insi
- Next by thread: Re: LogonUser call fails for NetworkService account on XP x64 insi
- Index(es):
Relevant Pages
|
