Win32 LogonUser()
Harout K
For three days now I have been trying to use LogonUser() API to login users
and impersonate them but I keep getting an error after the method call.
Error Code: 1314; "A required privilege is not held by the client"; however,
I have assigned the required SE_TCB_NAME (i.e. "Act as part of the OS")
privilege to the calling client but it keeps complaining.
If you have successfully used LogonUser() in any language and/or platform
please tell me how you did it.
Any pointers/help would greatly be appreciated!
Thank you very much!!!!!!
Here is the snipped of code in C++ and C# (VS 7.0)
[C++]
HANDLE token;
LogonUser("bobs", "LAPTOP", "bobs", LOGON32_LOGON_NETWORK,
LOGON32_PROVIDER_DEFAULT, &token);
DWORD error = GetLastError();
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++
[C#]
[assembly:SecurityPermissionAttribute(SecurityAction.RequestMinimum,
UnmanagedCode=true)]
public class Class1
{
[DllImport("C:\\WINNT\\System32\\advapi32.dll")]
public static extern bool LogonUser(String lpszUsername, String
lpszDomain, String lpszPassword, int dwLogonType, int dwLogonProvider, out
int phToken);
[DllImport("C:\\WINNT\\System32\\Kernel32.dll")]
public static extern int GetLastError();
public static void Main(string[] args)
{
int token;
bool isLoggedin = LogonUser("bobs", "LAPTOP", "bobs", 3, 0, out
token);
int error = GetLastError();
}
}
Willy Denoyette [MVP]
If the user is a domain user, take care that Domain wide Group policies aren't effective.
A few remarks about the code:
> [DllImport("C:\\WINNT\\System32\\advapi32.dll")]
> public static extern bool LogonUser(String lpszUsername, String
> lpszDomain, String lpszPassword, int dwLogonType, int dwLogonProvider, out
> int phToken);
should better look like:
[DllImport("advapi32.dll")] public static extern int LogonUser(String lpszUsername, String lpszDomain, String
lpszPassword, int dwLogonType, int dwLogonProvider, out IntPtr phToken);
Only call GetLastError when the return value of LogonUser is 0.
if(LogonUser(.....) == 0)
GetLastError();
...
Logonuser will always set LastError to a non zero value even when the call succeeded.
Willy.
"Harout K" <haro...@hotmail.com> wrote in message news:#OqYkcg4BHA.2716@tkmsftngp04...
NETMaster
AdjustTokenPrivileges()
I had to do this for shutting down windows, see
http://groups.google.com/groups?hl=en&selm=elE4tZXsBHA.2208%40tkmsftngp05
like C++ (not directly related)
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q259301
"Willy Denoyette [MVP]" <willy.d...@pandora.be> wrote in message news:eNu1fXh4BHA.2132@tkmsftngp02...
> > HANDLE token;
> > LogonUser("bobs", "LAPTOP", "bobs", LOGON32_LOGON_NETWORK,
> > LOGON32_PROVIDER_DEFAULT, &token);
> >
> > DWORD error = GetLastError();
Willy Denoyette [MVP]
<Platform sdk quote>
Windows 2000: The process calling LogonUser requires the SE_TCB_NAME privilege. The privilege does not need to be enabled. The
LogonUser function enables the privilege as necessary. If the calling process does not have this privilege, LogonUser fails and
GetLastError returns ERROR_PRIVILEGE_NOT_HELD.
<End quote>
Willy.
"NETMaster" <spam.ne...@swissonline.ch> wrote in message news:uNMtgnh4BHA.2424@tkmsftngp04...
Sergiy Mesropyan
Microsoft STRONGLY advised against giving 'act as part of the OS' privilege
to the IIS under any circumstances.
I had this program a while ago and solved it differently. My solution was
based on two MS articles:
PRB: LogonUser Fails in ISAPI Extensions (Q232513)
PRB: Access Denied Error When You Call LogonUser API (Q223334)
Please read the articles above. You can write a managed C++ extension to
implement this technique.
The idea in short is:
When you RevertToSelf() Function IIS will revert to the SYSTEM account when
you do logon and receive impersonation token. ALWAYS call RevertToSelf()
again to restore original IIS security blanket.
If you have any questions e-mail me:
mesr...@clickcommerce.com
"Willy Denoyette [MVP]" <willy.d...@pandora.be> wrote in message
news:OwIW1#h4BHA.2484@tkmsftngp07...
Jon Davies
1. It is a very bad idea to give a user account the "Act as Operation
System" privilege. Think about moving the login functions to a service.
2. Keep in mind that privileges are not active until you log out and back in
again. So even if you gave the calling process the SE_TCB_NAME privilege it
wont be active until the token is recreated at the next login.
These wont affect the api call but they are something to keep in mind.
3. In your DllImport you are getting the token as an int. This will work
just fine but in keeping with .NET use a IntPtr
4. You don't show a DllImport for or a call to CloseHandle() remember to
clean up once your done.
Jon Davies
Harout K
the LogonUser will activate the privilege for me as long as it exists.
"NETMaster" <spam.ne...@swissonline.ch> wrote in message
news:uNMtgnh4BHA.2424@tkmsftngp04...
Harout K
I have not given the IIS process the SE_TCB_NAME privilage and I do not
intend to. My program is a stand alone component that runs under a principal
specifically made for the job.
"Sergiy Mesropyan" <ser...@comteknet.com> wrote in message
news:#Y$Tg3l4BHA.1812@tkmsftngp02...
Sergiy Mesropyan
"Harout K" <haro...@hotmail.com> wrote in message
news:OfFIkDm4BHA.1660@tkmsftngp05...
Willy Denoyette [MVP]
Inline ***
Willy.
"Jon Davies" <nospams...@inet-pro.com> wrote in message news:O$FFW7l4BHA.2524@tkmsftngp07...
> Ok, a few things.
>
> 1. It is a very bad idea to give a user account the "Act as Operation
> System" privilege. Think about moving the login functions to a service.
*** Agreed, it is a bad idea to give 'ASPNET' the SE_TCB_NAME privilege, that's why MS has lifted this requirement (onXP and
Windows .NET Server this privilege is no longer required to call LogonUser).
When running W2K and you do care about security, it's better to handle Logon functions outside aspnet_wp.exe, in a service like you
suggest, or in a Server type COM+ application where you can add role based security to control who's calling the privileged
function.
But did you notice the number of people suggesting to run run ASP.NET as SYSTEM, and I'm affraid a lot of ASP.NET applications will
run in the TCB, not to mention the number of people running asp.net on a DC, which requires the worker process to run as SYSTEM.
Willy Denoyette [MVP]
The articles you are referring to, only apply to IIS /ASP for in-proc applications where ReverToSelft puts the caller in the TCB,
this is not a solution for ASP.NET.
ASP.NET applications run in a process aspnet_wp.exe as an unprivileged account ASPNET, calling ReverToSelf (which makes only sense
when impersonating) has the effect of running as APSPNET, so you can't call LogonUser.
A solution for ASP.NET on W2K is to handle these kind of privileged functions in an out-proc COM+ server (running with the SYSTEM
account identity).
Willy.
"Sergiy Mesropyan" <ser...@comteknet.com> wrote in message news:#Y$Tg3l4BHA.1812@tkmsftngp02...
Mike Jenne [MS]
a user?
This API does NOT require the same priviledges as LogonUser
--
Mike Jenne
Atlanta, GA
This posting is provided "AS IS" with no warranties, and confers no rights.
"Jon Davies" <nospams...@inet-pro.com> wrote in message
news:O$FFW7l4BHA.2524@tkmsftngp07...
Willy Denoyette [MVP]
But they serve different purposes, CreateProcessWithLogon creates a new process, the other creates a new logon session and returns a
session token.
I guess the original poster wants to call LogonUser to obtain a session token and use this token to impersonate.
If the purpose is only to validate credentials, one could call NetChangePassword, without changing the Password, but then you need
the SeChangeNotifyPrivilege.
Willy.
"Mike Jenne [MS]" <mje...@online.microsoft.com> wrote in message news:3cb79f31$1...@news.microsoft.com...
Sergiy Mesropyan
> You don't have to give this privilege to IIS, because IIS runs as SYSTEM,
so runs in the TCB and as such has this privilege.
ASP. (The solution that I proposed relies on IIS running as SYSTEM :)
>
> The articles you are referring to, only apply to IIS /ASP for in-proc
applications where ReverToSelft puts the caller in the TCB,
> this is not a solution for ASP.NET.
> ASP.NET applications run in a process aspnet_wp.exe as an unprivileged
account ASPNET, calling ReverToSelf (which makes only sense
> when impersonating) has the effect of running as APSPNET, so you can't
call LogonUser.
>
> A solution for ASP.NET on W2K is to handle these kind of privileged
functions in an out-proc COM+ server (running with the SYSTEM
> account identity).
You are absolutly right.
Willy Denoyette [MVP]
The process/security model of asp and asp.net are indeed somewhat different, that's why some people are getting confused.
ASP is always impersonating the anonymous internet user or authenticated user when executing an asp page, so calling "RevertToSelf'
will rejoin the TCB temporarily when running in Low isolation mode (IIS).
In ASP.NET, impersonation is configurable and the worker process, aspnet_wp.exe, runs with a configurable identity, so there is a
way to simulate the IIS/ASP behavior, that is, set the worker process to run as SYSTEM and set impersonate to "true" in your
web.config file, when calling "ReverToSelf" in this context has the same effect as running ASP with isolation level Low. However,
this method has the same security issues as running ASP in-proc on IIS, and is more dangerous than granting the 'Act as part of the
OS' privilege to aspnet (on w2k), because:
- The SYSTEM pseudo account has far more privileges than ASPNET, is has full control of all Kernel objects, unlimited access to
the File system, and other resources and has Network credentials (as from W2K onwards).
- The aspnet account has no network credentials and very limited user configurable FS and other resources access.
Don't get me wrong I'm not promoting the aspnet 'Act as part of the OS' privilege, but if one needs this privilege, it's better to
grant it, than to run the worker process as System like some have suggested on these NG's.
Willy.
"Sergiy Mesropyan" <ser...@comteknet.com> wrote in message news:uD#LL2L5BHA.2488@tkmsftngp04...
Sergiy Mesropyan
> - The SYSTEM pseudo account has far more privileges than ASPNET, is
has full control of all Kernel objects, unlimited access to
> the File system, and other resources and has Network credentials (as from
W2K onwards).
> - The aspnet account has no network credentials and very limited user
configurable FS and other resources access.
>
> Don't get me wrong I'm not promoting the aspnet 'Act as part of the OS'
privilege, but if one needs this privilege, it's better to
> grant it, than to run the worker process as System like some have
suggested on these NG's.
Willy,
If you revert to system and then restore credentials it is not as dangerous
as constantly running with 'Act as part of the OS'.
Here is why:
In the first case YOU control the code. So you can be 100% sure that your
code ALWAYS restores processes' security blanket. If your process runs with
'Act as part of the OS' then you can (by MS
doc:http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gp/525.
asp)
"Of even more concern is that the calling process can build an anonymous
token that can provide any and all accesses. Additionally, the anonymous
token does not provide a primary identity for tracking events in the audit
log.
Processes that require this privilege should use the LocalSystem account,
which already includes this privilege, rather than using a separate user
account with this privilege specially assigned."
So as I also disagree with granting worker processe's 'SYSTEM' account I
think that solution you outlined before : Run as 'SYSTEM'. IMPERSONATE as
IIS_USER OR ASP.NET or Create a COM+ package put only ONE object in it and
run it AS SYSTEM so you can be sure that ONLY TRUSTED code is executed with
required privilege.
Willy Denoyette [MVP]
I'm sorry, but I tend to disagree, when you are promoting the following, :
Run aspnet_wp.exe worker process as SYSTEM , set impersonation to true (so always impersonating), and call 'ReverToSelf' to enter
the TCB, well this is really bad, I'm sorry, that's exactly why MSFT changed the default identity from SYSTEM (Beta2) into ASPNET
(V1).
Never heard of Hijacking a process running in the System logon session while impersonating?
Do you really believe YOU are under full control of your code when running a public web applications?
You know what the bad guys are trying to do first ... they call ..... "ReverToSelf" and hope your process runs in the System logon
session, once they are in the TCB they can do all they want, and that's exactly why MS invented the isolation levels Medium and High
for classic ASP applications - to prevent applications to enter the TCB when impersonating (the default in ASP) when configured
correctly.
If you don't want your ASP.NET worker process to run with ' Act as part ....', that's ok, I also don't like this, but once again,
this requirement is lifted as from XP on, so this is only a problem running W2K.
If you really care about security in an asp.net context (on a public web), I would say, don't ever run code that requires special
privileges inside the ASP.NET context, don't ever give access to resources like WMI, AD, corporate Databases etc. to aspnet and the
anonymous user account, move these functions to COM+ and use the security services offered by this infrastructure.
Willy.
"Sergiy Mesropyan" <ser...@comteknet.com> wrote in message news:ux15isY5BHA.2296@tkmsftngp05...
Sergiy Mesropyan
> Sergiy,
> I'm sorry, but I tend to disagree, when you are promoting the following, :
> Run aspnet_wp.exe worker process as SYSTEM , set impersonation to true
(so always impersonating), and call 'ReverToSelf' to enter
> the TCB, well this is really bad, I'm sorry, that's exactly why MSFT
changed the default identity from SYSTEM (Beta2) into ASPNET
> (V1).
> Never heard of Hijacking a process running in the System logon session
while impersonating?
it so if you have any publicly available material on how to do that I wouuld
apriciate a link.
Again, I know it can be done, just curiouse how.
> Do you really believe YOU are under full control of your code when running
a public web applications?
That's good question. And you got me there.
> You know what the bad guys are trying to do first ... they call .....
"ReverToSelf" and hope your process runs in the System logon
> session, once they are in the TCB they can do all they want, and that's
exactly why MS invented the isolation levels Medium and High
> for classic ASP applications - to prevent applications to enter the TCB
when impersonating (the default in ASP) when configured
> correctly.
You are right.
>
> If you don't want your ASP.NET worker process to run with ' Act as part
....', that's ok, I also don't like this, but once again,
> this requirement is lifted as from XP on, so this is only a problem
running W2K.
> If you really care about security in an asp.net context (on a public web),
I would say, don't ever run code that requires special
> privileges inside the ASP.NET context, don't ever give access to resources
like WMI, AD, corporate Databases etc. to aspnet and the
> anonymous user account, move these functions to COM+ and use the security
services offered by this infrastructure.
Agreed! :)
Serge.
Marcus Kinch
I´m having the same problem as Harout. The reson I have for doing an
impersonation in my c#-code is to enable a thread to refresh my caches
from my backend servers. I can´t run this thread as ASPNET as this
user have no acces to network resources. So now lets leave the "why"
of the problem behind us and concentrate on the "how".
The only way I can get the LogonUser call to work is to run ASP.NET as
the local systems account (userName="SYSTEM" in machine.config). This
is NOT a good soloution. I´ve tried to enable "Act as part of
operating system" in local security policies on the webserver. Even
after a restart of the webserver this doesn´t work.
The webserver is a win2000 server runing in a network with a win2000
domain controler with active directory. I suspect that what happens is
that in some way the domain controler overrides the setting in "local
security policy" on the webserver. As I´m new to active directory I´m
at loss on how to solve this problem. My suspicion of the domain
controler is based on that the same code runns without any problem on
a win2000 server in a network with a nt4 domain controler.
As always, any ideas, pointers or example-code is welcome.
Thanks,
Marcus Kinch
Willy Denoyette [MVP]
What error code do you get when calling LogonUser? and who did you grant this privilege.
It's possible that the group policies overule the 'Act as ....' privilege, but this is very unlikely as it has to be setup
explicitely, and I'm not sure, but if Group policy applies you can't change this privilege (grayed out) in the local policy editor.
Willy.
"Marcus Kinch" <d93...@d.kth.se> wrote in message news:a2ff484f.0204...@posting.google.com...
> Hi all,
>
> I惴 having the same problem as Harout. The reson I have for doing an
> impersonation in my c#-code is to enable a thread to refresh my caches
> from my backend servers. I can愒 run this thread as ASPNET as this
> user have no acces to network resources. So now lets leave the "why"
> of the problem behind us and concentrate on the "how".
>
> The only way I can get the LogonUser call to work is to run ASP.NET as
> the local systems account (userName="SYSTEM" in machine.config). This
> is NOT a good soloution. I扉e tried to enable "Act as part of
> operating system" in local security policies on the webserver. Even
> after a restart of the webserver this doesn愒 work.
>
> The webserver is a win2000 server runing in a network with a win2000
> domain controler with active directory. I suspect that what happens is
> that in some way the domain controler overrides the setting in "local
> security policy" on the webserver. As I惴 new to active directory I惴
Sergiy Mesropyan
RefreshCache.
Register this class in COM+ as a separate application. Do not put anything
else in COM+ package. Mark the package to run under SYSTEM account.
This way COM+ will take care of impersonation when RefreshCache method is
called.
PS. You are right PDC can (and often does) overrides 'Act as part of
operating system'
"Marcus Kinch" <d93...@d.kth.se> wrote in message
news:a2ff484f.0204...@posting.google.com...
> Hi all,
>
> I惴 having the same problem as Harout. The reson I have for doing an
> impersonation in my c#-code is to enable a thread to refresh my caches
> from my backend servers. I can愒 run this thread as ASPNET as this
> user have no acces to network resources. So now lets leave the "why"
> of the problem behind us and concentrate on the "how".
>
> The only way I can get the LogonUser call to work is to run ASP.NET as
> the local systems account (userName="SYSTEM" in machine.config). This
> is NOT a good soloution. I扉e tried to enable "Act as part of
> operating system" in local security policies on the webserver. Even
> after a restart of the webserver this doesn愒 work.
>
> The webserver is a win2000 server runing in a network with a win2000
> domain controler with active directory. I suspect that what happens is
> that in some way the domain controler overrides the setting in "local
> security policy" on the webserver. As I惴 new to active directory I惴
deligentman
This is my personal experience and after doing so, read an article (sorry !
I can not find it now)
in win2k if you specify IIS to control IUserMachinename /anonymous account
and it is in guests group,
then logonuser api deosnot work if a web user imperonates
IUserMachinename/anonymous user account.
To make it work , put it in a privilidge group, change password sync options
in IIS and may be more other properties for IUserMachineName account. (still
the login will be treated as
a user logged on to the IIS box locally)
if I give more power to anonymous user then I will be a opening security
risk/hole in my site as we all knows.
thanks.
Del.
"Harout K" <haro...@hotmail.com> wrote in message
news:#OqYkcg4BHA.2716@tkmsftngp04...
Roman Gallauner
no more need for the tcb-privilege
works fine here at my site
greets
roman
"deligentman" <em...@spam.com> wrote in message
news:undRCOuECHA.1892@tkmsftngp03...