CreateProcessWithLogonW and ASP.NET

G

Guest

I am attempting to use CreateProcessWithLogonW from the server-side code of a
web page (yes, I want to create a process on the server) and not having much
luck.

I am attempting to run VPScan, an unsupported command-line virus scanner
from Symantec, to check an uploaded file for viruses. At first, I wrapped
VPScan with a DLL and ran it as a COM+ component and found that it would work
only when someone was logged on and it was set to run as the interactive
user. This little command-line tool, for some reason, requires that a user
be logged in. It actually needs access to HKEY_CURRENT_USER (I verified this
with regmon).

I then looked into the System.Diagnostics.Process object and found that it
couldn't do a "run as." Then I tried impersonation and DuplicateTokenEx and
found that, since ASP.NET implements impersonation at the thread level and
not the process level, I always got a token for the ASPNET account. Not good.

I thought that CreateProcessWithTokenW would work for me, but the end result
needs to run on Windows XP Pro (development machines), Windows Server 2000
and Windows Server 2003. CreateProcessWithTokenW only works on Windows
Server 2003.

Then I turned my attention to CreateProcessWithLogonW. From what I've read,
this doesn't work with XP SP2 and people are suggesting going back to
LoadUserProfile and CreateProcessAsUser. But I'm reading that in order for
this to work, the creating user context needs the "Act as part of the
operating system" user right. This is definitely not an option for me.

Can anybody tell me definitively that CreateProcessWithLogonW does, in fact,
work from an ASP.NET application and does properly log on the specified user
for the length of time it takes the specified process to execute? Thanks for
the help.

- Dave
 
W

Willy Denoyette [MVP]

David Davidson said:
I am attempting to use CreateProcessWithLogonW from the server-side code of
a
web page (yes, I want to create a process on the server) and not having
much
luck.

I am attempting to run VPScan, an unsupported command-line virus scanner
from Symantec, to check an uploaded file for viruses. At first, I wrapped
VPScan with a DLL and ran it as a COM+ component and found that it would
work
only when someone was logged on and it was set to run as the interactive
user. This little command-line tool, for some reason, requires that a
user
be logged in. It actually needs access to HKEY_CURRENT_USER (I verified
this
with regmon).

I then looked into the System.Diagnostics.Process object and found that it
couldn't do a "run as." Then I tried impersonation and DuplicateTokenEx
and
found that, since ASP.NET implements impersonation at the thread level and
not the process level, I always got a token for the ASPNET account. Not
good.

I thought that CreateProcessWithTokenW would work for me, but the end
result
needs to run on Windows XP Pro (development machines), Windows Server 2000
and Windows Server 2003. CreateProcessWithTokenW only works on Windows
Server 2003.

Then I turned my attention to CreateProcessWithLogonW. From what I've
read,
this doesn't work with XP SP2 and people are suggesting going back to
LoadUserProfile and CreateProcessAsUser. But I'm reading that in order
for
this to work, the creating user context needs the "Act as part of the
operating system" user right. This is definitely not an option for me.

Can anybody tell me definitively that CreateProcessWithLogonW does, in
fact,
work from an ASP.NET application and does properly log on the specified
user
for the length of time it takes the specified process to execute? Thanks
for
the help.

- Dave

CreateProcessWithLogonW requires W2K or higher, only restriction is that
you can't call it from a process running as LocalSystem.

All you need to know about CreateProcessWithLogonW can be found in the
Platform SDK documentation:
http://msdn.microsoft.com/library/d...n-us/dllproc/base/createprocesswithlogonw.asp

Willy.

Willy.
 
G

Guest

Dude, I live in the library when doing P/Invokes. :)

I have an implementation that works fine from a WinForms or a console app,
but doesn't work from a WebForms app. From what I've read in other forums,
this is because CreateProcessWithLogonW is running in the ASPNET's user
context. WinXP SP2 and above added a SecLogon service to handle all "run as"
calls and it disallows the call from ASPNET for security reasons. I've read
this in non-Microsoft forums, so now I'm looking for verification here in the
official Microsoft newsgroups. Anybody know if this is true?

- Dave
 
S

Steven Cheng[MSFT]

Hi Dave,

AS for the CreateProcessWithLogonW , based on my research, the main problem
which limited its usage in asp.net web app is that
CreateProcessWithLogonW() internally connects to a service called the
"secondary logon service" via a named pipe. The secondary logon service
secures this pipe with a DACL that grants only members of the local
administrators, local system and the interactive users access; all others
are specifically denied access. Since the ASPNET account has the service
and batch rights in its token, it is denied access to the named pipe. So I
suggest you no use the CreateProcessWithLogonW function in asp.net or other
non-interactive (batch or serivce logon ) service....

Thanks,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)





--------------------
| Thread-Topic: CreateProcessWithLogonW and ASP.NET
| thread-index: AcXZ4pjFWT/QAXfER8KH/6tynIACLA==
| X-WBNR-Posting-Host: 209.218.132.3
| From: "=?Utf-8?B?RGF2aWQgRGF2aWRzb24=?=" <[email protected]>
| References: <[email protected]>
<[email protected]>
| Subject: Re: CreateProcessWithLogonW and ASP.NET
| Date: Tue, 25 Oct 2005 21:06:09 -0700
| Lines: 80
| Message-ID: <[email protected]>
| MIME-Version: 1.0
| Content-Type: text/plain;
| charset="Utf-8"
| Content-Transfer-Encoding: 7bit
| X-Newsreader: Microsoft CDO for Windows 2000
| Content-Class: urn:content-classes:message
| Importance: normal
| Priority: normal
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
| Newsgroups: microsoft.public.dotnet.languages.csharp
| NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.2.250
| Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGXA03.phx.gbl
| Xref: TK2MSFTNGXA01.phx.gbl
microsoft.public.dotnet.languages.csharp:131787
| X-Tomcat-NG: microsoft.public.dotnet.languages.csharp
|
| Dude, I live in the library when doing P/Invokes. :)
|
| I have an implementation that works fine from a WinForms or a console
app,
| but doesn't work from a WebForms app. From what I've read in other
forums,
| this is because CreateProcessWithLogonW is running in the ASPNET's user
| context. WinXP SP2 and above added a SecLogon service to handle all "run
as"
| calls and it disallows the call from ASPNET for security reasons. I've
read
| this in non-Microsoft forums, so now I'm looking for verification here in
the
| official Microsoft newsgroups. Anybody know if this is true?
|
| - Dave
|
|
| "Willy Denoyette [MVP]" wrote:
|
| >
| > | > >I am attempting to use CreateProcessWithLogonW from the server-side
code of
| > >a
| > > web page (yes, I want to create a process on the server) and not
having
| > > much
| > > luck.
| > >
| > > I am attempting to run VPScan, an unsupported command-line virus
scanner
| > > from Symantec, to check an uploaded file for viruses. At first, I
wrapped
| > > VPScan with a DLL and ran it as a COM+ component and found that it
would
| > > work
| > > only when someone was logged on and it was set to run as the
interactive
| > > user. This little command-line tool, for some reason, requires that
a
| > > user
| > > be logged in. It actually needs access to HKEY_CURRENT_USER (I
verified
| > > this
| > > with regmon).
| > >
| > > I then looked into the System.Diagnostics.Process object and found
that it
| > > couldn't do a "run as." Then I tried impersonation and
DuplicateTokenEx
| > > and
| > > found that, since ASP.NET implements impersonation at the thread
level and
| > > not the process level, I always got a token for the ASPNET account.
Not
| > > good.
| > >
| > > I thought that CreateProcessWithTokenW would work for me, but the end
| > > result
| > > needs to run on Windows XP Pro (development machines), Windows Server
2000
| > > and Windows Server 2003. CreateProcessWithTokenW only works on
Windows
| > > Server 2003.
| > >
| > > Then I turned my attention to CreateProcessWithLogonW. From what
I've
| > > read,
| > > this doesn't work with XP SP2 and people are suggesting going back to
| > > LoadUserProfile and CreateProcessAsUser. But I'm reading that in
order
| > > for
| > > this to work, the creating user context needs the "Act as part of the
| > > operating system" user right. This is definitely not an option for
me.
| > >
| > > Can anybody tell me definitively that CreateProcessWithLogonW does,
in
| > > fact,
| > > work from an ASP.NET application and does properly log on the
specified
| > > user
| > > for the length of time it takes the specified process to execute?
Thanks
| > > for
| > > the help.
| > >
| > > - Dave
| > >
| >
| > CreateProcessWithLogonW requires W2K or higher, only restriction is
that
| > you can't call it from a process running as LocalSystem.
| >
| > All you need to know about CreateProcessWithLogonW can be found in the
| > Platform SDK documentation:
| >
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/bas
e/createprocesswithlogonw.asp
| >
| > Willy.
| >
| > Willy.
| >
| >
| >
|
 
W

Willy Denoyette [MVP]

Read the message again, it's only disallowed for LocalSystem (that is
SYSTEM) to call this API.
If asp.net runs as "aspnet" or a "networkservice" (W2K3) this should work.

Willy.
 
W

Willy Denoyette [MVP]

Steven,

I have to disagree, first because I'm succesfully using
CreateProcessWithLogonW from Windows Services that run without admin
privileges, second because the problem is not related with named pipe
security.
The problem relates to the "LocalSystem" account and is documented in MSDN,
here is an extract from the docs:
--
Windows XP SP2 and Windows Server 2003: You cannot call
CreateProcessWithLogonW from a process running under the LocalSystem
account. This is because the function uses the logon SID in the caller token
and the token for the LocalSystem account does not contain this SID. As an
alternative, use the CreateProcessAsUser and LogonUser functions.
--
The reason for this (on XP/SP2 and W2K3) is that the API tries to injects
the callers Logon SID in the new process access token, to make it possible
to access the interactive winstation\desktop, and as LocalSystem doesn't
have a Logon SID in his token the call fails.

Now the problem is that some try to use this API to launch processes that
have UI's, (Windows or console style). And as services (or asp.net or
whatever process that's been started from a service) only can access the
interactive desktop (winsta0\default) if they run as LocalSystem, they try
with LocalSystem which fails as described.
Note that calling this API from a Service running as non LocalSystem will
successfully start the other process, but this new process runs in the
Winstation\desktop of the service which is not visible (it's not
winsta0\default).
Conclusion, use this API from services only when you need to launch (console
style) processes that don't require any user interaction, anything else will
fail sooner than later.

Willy.
 
W

Willy Denoyette [MVP]

Oh, I forgot to say that the calling process needs Interactive logon (Logon
locally policy), so if you want aspnet to call this API you'll have to apply
the "Logon Locally" policy.

Willy.
 
S

Steven Cheng[MSFT]

Thanks for your further input Willy,

The things mentioned in my former response describe the problem on windows
2000 server. On XP box, the behavior is different. But at least calling the
API require the interactive logon uesr session(this is due to the
implementation related to the internal namedpipe .....).

By default ASPNET_WP.exe is configured as a batch user and NOT an
interactive user. We can configure ASPNET_WP.exe to run as an interactive
user by doing the following:(impersonation should be turn off)

1. From Local Security Settings->User Rights Assignment, REMOVE the ASPNET
account
from
a. Log on as a batch job
b. Log on as a service
c. Deny Logon Locally.

Add ASPNET to Logon Locally.

2. Restart IIS and rerun the web application.

Though the above is possible, I strongly recommend that we do not change
the ASPNET account's default security schema.
If possible, we can consider writing the code to be a COM (or ActiveX)
component in any language, create a COM+ application, add our component to
the COM+ application and now all we need to do in your ASP.Net page is
instantiate and use that control.

http://msdn.microsoft.com/library/?url=/library/en-us/cossdk/htm/pgcreatinga
pplications_45tf.asp?frame=true

As long as we make the COM+ application "Server Application", we can set
the security context it will run under. Just like an NT Service.Note The
Set Application Identity dialog box appears only if you selected Server
application for the new application's activation type in the COM
Application Install Wizard's preceding dialog box. The identity property is
not used for library applications.

Thanks,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

--------------------
| From: "Willy Denoyette [MVP]" <[email protected]>
| References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
| Subject: Re: CreateProcessWithLogonW and ASP.NET
| Date: Wed, 26 Oct 2005 21:19:47 +0200
| Lines: 224
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2900.2670
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
| X-RFC2646: Format=Flowed; Response
| Message-ID: <[email protected]>
| Newsgroups: microsoft.public.dotnet.languages.csharp
| NNTP-Posting-Host: dd5766e14.access.telenet.be 213.118.110.20
| Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP09.phx.gbl
| Xref: TK2MSFTNGXA01.phx.gbl
microsoft.public.dotnet.languages.csharp:132025
| X-Tomcat-NG: microsoft.public.dotnet.languages.csharp
|
| Oh, I forgot to say that the calling process needs Interactive logon
(Logon
| locally policy), so if you want aspnet to call this API you'll have to
apply
| the "Logon Locally" policy.
|
| Willy.
|
| | > Steven,
| >
| > I have to disagree, first because I'm succesfully using
| > CreateProcessWithLogonW from Windows Services that run without admin
| > privileges, second because the problem is not related with named pipe
| > security.
| > The problem relates to the "LocalSystem" account and is documented in
| > MSDN, here is an extract from the docs:
| > --
| > Windows XP SP2 and Windows Server 2003: You cannot call
| > CreateProcessWithLogonW from a process running under the LocalSystem
| > account. This is because the function uses the logon SID in the caller
| > token and the token for the LocalSystem account does not contain this
SID.
| > As an alternative, use the CreateProcessAsUser and LogonUser functions.
| > --
| > The reason for this (on XP/SP2 and W2K3) is that the API tries to
injects
| > the callers Logon SID in the new process access token, to make it
possible
| > to access the interactive winstation\desktop, and as LocalSystem
doesn't
| > have a Logon SID in his token the call fails.
| >
| > Now the problem is that some try to use this API to launch processes
that
| > have UI's, (Windows or console style). And as services (or asp.net or
| > whatever process that's been started from a service) only can access
the
| > interactive desktop (winsta0\default) if they run as LocalSystem, they
try
| > with LocalSystem which fails as described.
| > Note that calling this API from a Service running as non LocalSystem
will
| > successfully start the other process, but this new process runs in the
| > Winstation\desktop of the service which is not visible (it's not
| > winsta0\default).
| > Conclusion, use this API from services only when you need to launch
| > (console style) processes that don't require any user interaction,
| > anything else will fail sooner than later.
| >
| > Willy.
| >
| > | >> Hi Dave,
| >>
| >> AS for the CreateProcessWithLogonW , based on my research, the main
| >> problem
| >> which limited its usage in asp.net web app is that
| >> CreateProcessWithLogonW() internally connects to a service called the
| >> "secondary logon service" via a named pipe. The secondary logon
service
| >> secures this pipe with a DACL that grants only members of the local
| >> administrators, local system and the interactive users access; all
others
| >> are specifically denied access. Since the ASPNET account has the
service
| >> and batch rights in its token, it is denied access to the named pipe.
So
| >> I
| >> suggest you no use the CreateProcessWithLogonW function in asp.net or
| >> other
| >> non-interactive (batch or serivce logon ) service....
| >>
| >> Thanks,
| >>
| >> Steven Cheng
| >> Microsoft Online Support
| >>
| >> Get Secure! www.microsoft.com/security
| >> (This posting is provided "AS IS", with no warranties, and confers no
| >> rights.)
| >>
| >>
| >>
| >>
| >>
| >> --------------------
| >> | Thread-Topic: CreateProcessWithLogonW and ASP.NET
| >> | thread-index: AcXZ4pjFWT/QAXfER8KH/6tynIACLA==
| >> | X-WBNR-Posting-Host: 209.218.132.3
| >> | From: "=?Utf-8?B?RGF2aWQgRGF2aWRzb24=?="
| >> <[email protected]>
| >> | References: <[email protected]>
| >> <[email protected]>
| >> | Subject: Re: CreateProcessWithLogonW and ASP.NET
| >> | Date: Tue, 25 Oct 2005 21:06:09 -0700
| >> | Lines: 80
| >> | Message-ID: <[email protected]>
| >> | MIME-Version: 1.0
| >> | Content-Type: text/plain;
| >> | charset="Utf-8"
| >> | Content-Transfer-Encoding: 7bit
| >> | X-Newsreader: Microsoft CDO for Windows 2000
| >> | Content-Class: urn:content-classes:message
| >> | Importance: normal
| >> | Priority: normal
| >> | X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
| >> | Newsgroups: microsoft.public.dotnet.languages.csharp
| >> | NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.2.250
| >> | Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGXA03.phx.gbl
| >> | Xref: TK2MSFTNGXA01.phx.gbl
| >> microsoft.public.dotnet.languages.csharp:131787
| >> | X-Tomcat-NG: microsoft.public.dotnet.languages.csharp
| >> |
| >> | Dude, I live in the library when doing P/Invokes. :)
| >> |
| >> | I have an implementation that works fine from a WinForms or a console
| >> app,
| >> | but doesn't work from a WebForms app. From what I've read in other
| >> forums,
| >> | this is because CreateProcessWithLogonW is running in the ASPNET's
user
| >> | context. WinXP SP2 and above added a SecLogon service to handle all
| >> "run
| >> as"
| >> | calls and it disallows the call from ASPNET for security reasons.
I've
| >> read
| >> | this in non-Microsoft forums, so now I'm looking for verification
here
| >> in
| >> the
| >> | official Microsoft newsgroups. Anybody know if this is true?
| >> |
| >> | - Dave
| >> |
| >> |
| >> | "Willy Denoyette [MVP]" wrote:
| >> |
| >> | >
| >> | > | >> | > >I am attempting to use CreateProcessWithLogonW from the
server-side
| >> code of
| >> | > >a
| >> | > > web page (yes, I want to create a process on the server) and not
| >> having
| >> | > > much
| >> | > > luck.
| >> | > >
| >> | > > I am attempting to run VPScan, an unsupported command-line virus
| >> scanner
| >> | > > from Symantec, to check an uploaded file for viruses. At first,
I
| >> wrapped
| >> | > > VPScan with a DLL and ran it as a COM+ component and found that
it
| >> would
| >> | > > work
| >> | > > only when someone was logged on and it was set to run as the
| >> interactive
| >> | > > user. This little command-line tool, for some reason, requires
| >> that
| >> a
| >> | > > user
| >> | > > be logged in. It actually needs access to HKEY_CURRENT_USER (I
| >> verified
| >> | > > this
| >> | > > with regmon).
| >> | > >
| >> | > > I then looked into the System.Diagnostics.Process object and
found
| >> that it
| >> | > > couldn't do a "run as." Then I tried impersonation and
| >> DuplicateTokenEx
| >> | > > and
| >> | > > found that, since ASP.NET implements impersonation at the thread
| >> level and
| >> | > > not the process level, I always got a token for the ASPNET
account.
| >> Not
| >> | > > good.
| >> | > >
| >> | > > I thought that CreateProcessWithTokenW would work for me, but
the
| >> end
| >> | > > result
| >> | > > needs to run on Windows XP Pro (development machines), Windows
| >> Server
| >> 2000
| >> | > > and Windows Server 2003. CreateProcessWithTokenW only works on
| >> Windows
| >> | > > Server 2003.
| >> | > >
| >> | > > Then I turned my attention to CreateProcessWithLogonW. From what
| >> I've
| >> | > > read,
| >> | > > this doesn't work with XP SP2 and people are suggesting going
back
| >> to
| >> | > > LoadUserProfile and CreateProcessAsUser. But I'm reading that in
| >> order
| >> | > > for
| >> | > > this to work, the creating user context needs the "Act as part
of
| >> the
| >> | > > operating system" user right. This is definitely not an option
for
| >> me.
| >> | > >
| >> | > > Can anybody tell me definitively that CreateProcessWithLogonW
does,
| >> in
| >> | > > fact,
| >> | > > work from an ASP.NET application and does properly log on the
| >> specified
| >> | > > user
| >> | > > for the length of time it takes the specified process to execute?
| >> Thanks
| >> | > > for
| >> | > > the help.
| >> | > >
| >> | > > - Dave
| >> | > >
| >> | >
| >> | > CreateProcessWithLogonW requires W2K or higher, only restriction
is
| >> that
| >> | > you can't call it from a process running as LocalSystem.
| >> | >
| >> | > All you need to know about CreateProcessWithLogonW can be found
in
| >> the
| >> | > Platform SDK documentation:
| >> | >
| >>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/bas
| >> e/createprocesswithlogonw.asp
| >> | >
| >> | > Willy.
| >> | >
| >> | > Willy.
| >> | >
| >> | >
| >> | >
| >> |
| >>
| >
| >
|
|
|
 
W

Willy Denoyette [MVP]

Steven,

See inline.

Willy.

Steven Cheng said:
Thanks for your further input Willy,

The things mentioned in my former response describe the problem on
windows
2000 server. On XP box, the behavior is different. But at least calling
the
API require the interactive logon uesr session(this is due to the
implementation related to the internal namedpipe .....).

Well, seems like we are talking about different issues, I was talking about
W2K3 and XP SP2, who behaves differently from W2K and XP pre SP2.
Pre SP2 and W2K3 "CreateProcessWithLogonW" used to change the DACL of the
callers winstation\desktop to allow the newly created process to access it,
it's obvious this wasn't very secure. So the API was changed (not on W2K
though) such that it leaves the ACL alone, but instead injects the Logon SID
in the process token, this way you prevent a child process to access the
Winstation\desktop of a parent process that runs in the TCB (SYSTEM or
LocalUser).

But still I have to disagree with you about the interactive logon user and
the named pipe issue. You are right that calling this API with
LOGON_WITH_PROFILE as "non-interactive user" will fail at the API level,
simply because a LOGON_WITH_PROFILE expects an interactive user, however,
calling the API using LOGON_NETCREDENTIALS_ONLY from a "non interactive"
session succeeds.

Say you have:
- a Service running as user "Bob" which has "Logon as Service" and "Batch
Job" logon rights, but is denied "Logon Local" privileges.
- suppose this service calls CreateProcessWithLogonW with "Alice" as user
name, and LOGON_NETCREDENTIALS_ONLY as logonflags, in order to launch
"cmd.exe"

In this case, the API call succeeds and 'seclogon' starts the process
(cmd.exe) running as "Bob" in the non-default desktop.
cmd.exe uses Bob's token to access local resources but will use Alice's
credentials to access the network.
Note that, as I said before, that the launched process should in no way
interact with the user as it's running in a sandboxed desktop (not visible),
and beware the cmd shell is designed to run in the interactive desktop!!.

By default ASPNET_WP.exe is configured as a batch user and NOT an
interactive user. We can configure ASPNET_WP.exe to run as an interactive
user by doing the following:(impersonation should be turn off)

1. From Local Security Settings->User Rights Assignment, REMOVE the ASPNET
account
from
a. Log on as a batch job
b. Log on as a service
c. Deny Logon Locally.

Add ASPNET to Logon Locally.

2. Restart IIS and rerun the web application.

Though the above is possible, I strongly recommend that we do not change
the ASPNET account's default security schema.
Agreed.

If possible, we can consider writing the code to be a COM (or ActiveX)
component in any language, create a COM+ application, add our component to
the COM+ application and now all we need to do in your ASP.Net page is
instantiate and use that control.

http://msdn.microsoft.com/library/?url=/library/en-us/cossdk/htm/pgcreatinga
pplications_45tf.asp?frame=true

As long as we make the COM+ application "Server Application", we can set
the security context it will run under. Just like an NT Service.Note The
Set Application Identity dialog box appears only if you selected Server
application for the new application's activation type in the COM
Application Install Wizard's preceding dialog box. The identity property
is
not used for library applications.

Agreed, but again, the problem is that some are using
"CreateProcessWithLogonW" to launch interactive applications from non
interactive processes like windows services (and asp/asp.net), using COM+ to
run such an app. is just as bad as running it from a service, both COM+
(server applications) and Services are designed to run even when there is
no interactive session.

Willy.
 
S

Steven Cheng[MSFT]

Well, thanks again for your detailed explanation.

I think you're right on the LOGON_NETCREDENTIALS_ONLY option. Anyway, since
David need to create sub process under specific user and load profile as
well, CreateProcessWithLogonW + LOGON_WITH_PROFILE may cause some pain in
ASP.NET application.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

--------------------
| From: "Willy Denoyette [MVP]" <[email protected]>
| References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<sAcg#[email protected]>
| Subject: Re: CreateProcessWithLogonW and ASP.NET
| Date: Thu, 27 Oct 2005 11:26:00 +0200
| Lines: 99
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2900.2670
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
| X-RFC2646: Format=Flowed; Original
| Message-ID: <eET#[email protected]>
| Newsgroups: microsoft.public.dotnet.languages.csharp
| NNTP-Posting-Host: dd5766e14.access.telenet.be 213.118.110.20
| Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP12.phx.gbl
| Xref: TK2MSFTNGXA01.phx.gbl
microsoft.public.dotnet.languages.csharp:132137
| X-Tomcat-NG: microsoft.public.dotnet.languages.csharp
|
| Steven,
|
| See inline.
|
| Willy.
|
| | > Thanks for your further input Willy,
| >
| > The things mentioned in my former response describe the problem on
| > windows
| > 2000 server. On XP box, the behavior is different. But at least calling
| > the
| > API require the interactive logon uesr session(this is due to the
| > implementation related to the internal namedpipe .....).
| >
|
| Well, seems like we are talking about different issues, I was talking
about
| W2K3 and XP SP2, who behaves differently from W2K and XP pre SP2.
| Pre SP2 and W2K3 "CreateProcessWithLogonW" used to change the DACL of the
| callers winstation\desktop to allow the newly created process to access
it,
| it's obvious this wasn't very secure. So the API was changed (not on W2K
| though) such that it leaves the ACL alone, but instead injects the Logon
SID
| in the process token, this way you prevent a child process to access the
| Winstation\desktop of a parent process that runs in the TCB (SYSTEM or
| LocalUser).
|
| But still I have to disagree with you about the interactive logon user
and
| the named pipe issue. You are right that calling this API with
| LOGON_WITH_PROFILE as "non-interactive user" will fail at the API level,
| simply because a LOGON_WITH_PROFILE expects an interactive user, however,
| calling the API using LOGON_NETCREDENTIALS_ONLY from a "non interactive"
| session succeeds.
|
| Say you have:
| - a Service running as user "Bob" which has "Logon as Service" and "Batch
| Job" logon rights, but is denied "Logon Local" privileges.
| - suppose this service calls CreateProcessWithLogonW with "Alice" as
user
| name, and LOGON_NETCREDENTIALS_ONLY as logonflags, in order to launch
| "cmd.exe"
|
| In this case, the API call succeeds and 'seclogon' starts the process
| (cmd.exe) running as "Bob" in the non-default desktop.
| cmd.exe uses Bob's token to access local resources but will use Alice's
| credentials to access the network.
| Note that, as I said before, that the launched process should in no way
| interact with the user as it's running in a sandboxed desktop (not
visible),
| and beware the cmd shell is designed to run in the interactive desktop!!.
|
|
| > By default ASPNET_WP.exe is configured as a batch user and NOT an
| > interactive user. We can configure ASPNET_WP.exe to run as an
interactive
| > user by doing the following:(impersonation should be turn off)
| >
| > 1. From Local Security Settings->User Rights Assignment, REMOVE the
ASPNET
| > account
| > from
| > a. Log on as a batch job
| > b. Log on as a service
| > c. Deny Logon Locally.
| >
| > Add ASPNET to Logon Locally.
| >
| > 2. Restart IIS and rerun the web application.
| >
| > Though the above is possible, I strongly recommend that we do not change
| > the ASPNET account's default security schema.
|
| Agreed.
|
| > If possible, we can consider writing the code to be a COM (or ActiveX)
| > component in any language, create a COM+ application, add our component
to
| > the COM+ application and now all we need to do in your ASP.Net page is
| > instantiate and use that control.
| >
| >
http://msdn.microsoft.com/library/?url=/library/en-us/cossdk/htm/pgcreatinga
| > pplications_45tf.asp?frame=true
| >
| > As long as we make the COM+ application "Server Application", we can
set
| > the security context it will run under. Just like an NT Service.Note
The
| > Set Application Identity dialog box appears only if you selected Server
| > application for the new application's activation type in the COM
| > Application Install Wizard's preceding dialog box. The identity
property
| > is
| > not used for library applications.
| >
|
| Agreed, but again, the problem is that some are using
| "CreateProcessWithLogonW" to launch interactive applications from non
| interactive processes like windows services (and asp/asp.net), using COM+
to
| run such an app. is just as bad as running it from a service, both COM+
| (server applications) and Services are designed to run even when there
is
| no interactive session.
|
| Willy.
|
|
|
|
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top