|
|
|
date: Thu, 1 May 2008 13:50:49 -0400,
group: microsoft.public.platformsdk.security
back
RE: Non-interactive process launched by DCOM does not have network access
Hi Paul,
I am not a COM/DCOM expert, however, I have seen this problem in other
services such as Asp.net. Yes, I think it is determined by the account that
your DCOM server runs under. Can you tell me what account your DCOM server
service process runs under? Regarding the share files, what account has the
permission to access the share?
I suspect only domain account has the access permission to the network
share, while the DCOM process runs under a build-in service account such as
Network Service, Local System or Local Service. So the DCOM process token
has no permission to access the network share.
Fortunately, the network share is maintained by the LAN session manager
which provides the programming interface to establish a LAN session to the
remote share. What we should do is providing the domain account
username/password pair to the LAN session manager in the DCOM server. Then
the LAN session will help to establish a separate LAN session channel using
the provided credential.
Note: the network share has two levels of permission settings --- 1. Share
level. 2. NTFS level, so the domain account must have both permissions to
pass these two levels.
We have two solutions to establish LAN session:
1. Leveraging the build-in Net.exe tool by calling the "net use" command.
2. Calling LAN session APIs(NetUseAdd) directly.
I provided the detailed sample code and explanation in the link
below(although the code is provided in .Net p/invoke, the logic is easy to
understand and use in C/C++):
http://groups.google.com/group/microsoft.public.platformsdk.security/msg/063
d7b08b29e5642
Hope this helps.
Best regards,
Jeffrey Tan
Microsoft Online Community Support
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msdnmg@microsoft.com.
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
date: Fri, 02 May 2008 02:10:39 GMT
author: (Jeffrey Tan[MSFT])
Re: Non-interactive process launched by DCOM does not have network access
Jeffrey,
When run interactively, the server works fine, because the account is a
domain account that has the permissions it needs to the files in question.
Therefore, running it interactively is a simpler and therefore preferable
solution for me than what you describe. In fact, there are several servers
and shares needed, which complicates your solution further.
This is an out of process server. The DCOM Server Launcher Process, running
under the Local System account, launches the server process. Whether run
interactively or non-interactively, the server process is launched under the
client user account, not the Local System acount, so should have the
permissions it needs. When I ask about "how" it logs in, I mean things like
impersonation and the logon type passed to LogonUser.
Paul
""Jeffrey Tan[MSFT]"" wrote in message
news:t6jLCn$qIHA.1784@TK2MSFTNGHUB02.phx.gbl...
> Hi Paul,
>
> I am not a COM/DCOM expert, however, I have seen this problem in other
> services such as Asp.net. Yes, I think it is determined by the account
> that
> your DCOM server runs under. Can you tell me what account your DCOM server
> service process runs under? Regarding the share files, what account has
> the
> permission to access the share?
>
> I suspect only domain account has the access permission to the network
> share, while the DCOM process runs under a build-in service account such
> as
> Network Service, Local System or Local Service. So the DCOM process token
> has no permission to access the network share.
>
> Fortunately, the network share is maintained by the LAN session manager
> which provides the programming interface to establish a LAN session to the
> remote share. What we should do is providing the domain account
> username/password pair to the LAN session manager in the DCOM server. Then
> the LAN session will help to establish a separate LAN session channel
> using
> the provided credential.
> Note: the network share has two levels of permission settings --- 1. Share
> level. 2. NTFS level, so the domain account must have both permissions to
> pass these two levels.
>
> We have two solutions to establish LAN session:
> 1. Leveraging the build-in Net.exe tool by calling the "net use" command.
> 2. Calling LAN session APIs(NetUseAdd) directly.
>
> I provided the detailed sample code and explanation in the link
> below(although the code is provided in .Net p/invoke, the logic is easy to
> understand and use in C/C++):
> http://groups.google.com/group/microsoft.public.platformsdk.security/msg/063
> d7b08b29e5642
>
> Hope this helps.
>
> Best regards,
> Jeffrey Tan
> Microsoft Online Community Support
>
> Delighting our customers is our #1 priority. We welcome your comments and
> suggestions about how we can improve the support we provide to you. Please
> feel free to let my manager know what you think of the level of service
> provided. You can send feedback directly to my manager at:
> msdnmg@microsoft.com.
>
> ==================================================
> Get notification to my posts through email? Please refer to
> http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
> ications.
>
> Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
> where an initial response from the community or a Microsoft Support
> Engineer within 1 business day is acceptable. Please note that each follow
> up response may take approximately 2 business days as the support
> professional working with you may need further investigation to reach the
> most efficient resolution. The offering is not appropriate for situations
> that require urgent, real-time or phone-based interactions or complex
> project analysis and dump analysis issues. Issues of this nature are best
> handled working with a dedicated Microsoft Support Engineer by contacting
> Microsoft Customer Support Services (CSS) at
> http://msdn.microsoft.com/subscriptions/support/default.aspx.
> ==================================================
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
date: Fri, 2 May 2008 09:24:14 -0400
author: Paul Baker [MVP, Windows Desktop Experience] am
Re: Non-interactive process launched by DCOM does not have network access
Hi Paul,
Thanks for your feedback.
I am not sure if I have understood you completely. Regarding running the
server interactively, do you mean running the DCOM server without hosted in
a Windows Service? If you can run it in the interactive session, this
definitely does not have the problem of Windows Service because it runs in
the interactive logon session. It will even reuse the established LAN
session if the interactive user has done this before.
In the original scenario, does your DCOM server service impersonate the
client domain user account? Then, it should have the credential to
establish LAN session to the share folder. However, if the client is
activating the DCOM server from a remote machine, this may be a problem,
because impersonation can not jump two machines hops.(The second hop will
be identified as Null Session or Machine account) This is called the double
hops scenario. However, without getting more information from your
scenario, it is hard to say it root cause.
Anyway, if you need further help, please feel free to tell me, thanks.
Best regards,
Jeffrey Tan
Microsoft Online Community Support
=========================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msdnmg@microsoft.com.
This posting is provided "AS IS" with no warranties, and confers no rights.
date: Mon, 05 May 2008 02:20:21 GMT
author: (Jeffrey Tan[MSFT])
Re: Non-interactive process launched by DCOM does not have network access
Jeffrey,
I think it is simpler than you are thinking.
The DCOM server is an out of process server. It uses the LocalServer32
registry entry. And which session (window station) it is started in depends
on the behaviour of the DCOM Server Process Launcher behaviour, described
here:
INFO: COM Servers Activation and NT Windows Stations:
http://support.microsoft.com/default.aspx/kb/169321/en-us
I used to configure to run as "The interactive user" and it ran in the
console session without issue.
Now, I configure it to run as "The launching user", so it creates a
non-interactive window station for the user and the issues occur.
It is not a service. It does not use impersonatation. The DCOM Server
Process Launcher starts the process under the user account of the client, so
it seems like it should work.
Paul
""Jeffrey Tan[MSFT]"" wrote in message
news:XhswaalrIHA.1788@TK2MSFTNGHUB02.phx.gbl...
> Hi Paul,
>
> Thanks for your feedback.
>
> I am not sure if I have understood you completely. Regarding running the
> server interactively, do you mean running the DCOM server without hosted
> in
> a Windows Service? If you can run it in the interactive session, this
> definitely does not have the problem of Windows Service because it runs in
> the interactive logon session. It will even reuse the established LAN
> session if the interactive user has done this before.
>
> In the original scenario, does your DCOM server service impersonate the
> client domain user account? Then, it should have the credential to
> establish LAN session to the share folder. However, if the client is
> activating the DCOM server from a remote machine, this may be a problem,
> because impersonation can not jump two machines hops.(The second hop will
> be identified as Null Session or Machine account) This is called the
> double
> hops scenario. However, without getting more information from your
> scenario, it is hard to say it root cause.
>
> Anyway, if you need further help, please feel free to tell me, thanks.
>
> Best regards,
> Jeffrey Tan
> Microsoft Online Community Support
> =========================================
> Delighting our customers is our #1 priority. We welcome your comments and
> suggestions about how we can improve the support we provide to you. Please
> feel free to let my manager know what you think of the level of service
> provided. You can send feedback directly to my manager at:
> msdnmg@microsoft.com.
>
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
date: Mon, 5 May 2008 09:22:13 -0400
author: Paul Baker [MVP, Windows Desktop Experience] am
Re: Non-interactive process launched by DCOM does not have network access
Hi Paul,
Sorry for the late response, I took sick leave yesterday.
Oh, I am confusing "The Interactive User" with "The launching user"; thank
you for clarifying the piont for me.
"The Interactive User" will run using the security context of the user
currently logged onto the server. So it has nothing to do with the client
user and impersonation. This definitely has no double hop permission issue
since we are using the credential on the server. So if the logged user on
the server has permission to access the remote share, the DCOM server
process will work either.
However, there may be one problem with using this option. Based on the KB
below, "If this option is selected and the user is not logged on, then the
application will not start", so we always need an interactive user logged
on the DCOM server machine to get it work. I suspect this may bit us in
future. Anyway, this depends your requirement and background scenario.
"INFO: Using DCOM Config (DCOMCNFG.EXE) on Windows NT"
http://support.microsoft.com/default.aspx/kb/176799
Thanks.
Best regards,
Jeffrey Tan
Microsoft Online Community Support
=========================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msdnmg@microsoft.com.
This posting is provided "AS IS" with no warranties, and confers no rights.
date: Wed, 07 May 2008 03:06:04 GMT
author: (Jeffrey Tan[MSFT])
Re: Non-interactive process launched by DCOM does not have network access
Jeffrey,
Yes, I am aware of this limitation. In fact the user must be logged on to
the console session, I believe. This is one of the reasons I do not want to
use "The interactive user". The other reason is that although the server has
a UI, there are no UI functions that are actually needed and I would rather
isolate the process from the user for better reliability and control.
When I run as "The launching user", it is launched under the client user
account and so why does not not have the network access it should? Are you
saying the only way is to explicitly make a connection to each server
needed, because this is a double hop scenario? This doesn't make sense to
me. The credentials are the same, it's just running in a different window
station.
Thanks,
Paul
""Jeffrey Tan[MSFT]"" wrote in message
news:defFO9%23rIHA.5484@TK2MSFTNGHUB02.phx.gbl...
> Hi Paul,
>
> Sorry for the late response, I took sick leave yesterday.
>
> Oh, I am confusing "The Interactive User" with "The launching user"; thank
> you for clarifying the piont for me.
>
> "The Interactive User" will run using the security context of the user
> currently logged onto the server. So it has nothing to do with the client
> user and impersonation. This definitely has no double hop permission issue
> since we are using the credential on the server. So if the logged user on
> the server has permission to access the remote share, the DCOM server
> process will work either.
>
> However, there may be one problem with using this option. Based on the KB
> below, "If this option is selected and the user is not logged on, then the
> application will not start", so we always need an interactive user logged
> on the DCOM server machine to get it work. I suspect this may bit us in
> future. Anyway, this depends your requirement and background scenario.
>
> "INFO: Using DCOM Config (DCOMCNFG.EXE) on Windows NT"
> http://support.microsoft.com/default.aspx/kb/176799
>
> Thanks.
>
> Best regards,
> Jeffrey Tan
> Microsoft Online Community Support
> =========================================
> Delighting our customers is our #1 priority. We welcome your comments and
> suggestions about how we can improve the support we provide to you. Please
> feel free to let my manager know what you think of the level of service
> provided. You can send feedback directly to my manager at:
> msdnmg@microsoft.com.
>
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
date: Wed, 7 May 2008 09:14:26 -0400
author: Paul Baker [MVP, Windows Desktop Experience] am
Re: Non-interactive process launched by DCOM does not have network access
Hi Paul,
Thanks for your feedback.
When we are using "The launching user", we are using impersonation in DCOM.
The kerboros protocol will help to impersonate the client security context
in the DCOM server process.(dllhost as I know). Yes, this is a security
credential double hop scenario.
It is a security design not to delegate the security credential across two
machines boundary. It is normally insecure to allow the server to use the
client user's identify to access a 3rd machine. The client user has no idea
that if the server process will use his security identify to perform
unauthorized operations. For example, the server may have been compromised.
If Windows does not limit double hop, the malicous user may impersonate
under the client identity to access a secrete database on another
machine(which only the client user account has permission to access).
Actually, some experts even believe impersonation as a bad idea, see the
link below:
http://www.wintellect.com/cs/blogs/pmehner/archive/2007/12/23/security-impli
cations-of-services-impersonating-callers.aspx
Regarding "The credentials are the same, it's just running in a different
window station", do you mean the client user and the server machine
interactive user are the same domain account? Actually, in the "The
launching user" scenario, the DCOM server will impersonate under the client
user token. However, the server will not cache the credential of the client
user. So, when server tries to access 3rd machine, it has no credential for
authentication. So it will not be considered as the client user on 3rd
machine.
Maybe, you may use the "This User" option and hard-code the client user
account/password in the DCOM server process. This will give the credential
on the DCOM server process. Thanks.
Best regards,
Jeffrey Tan
Microsoft Online Community Support
=========================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msdnmg@microsoft.com.
This posting is provided "AS IS" with no warranties, and confers no rights.
date: Thu, 08 May 2008 03:21:52 GMT
author: (Jeffrey Tan[MSFT])
Re: Non-interactive process launched by DCOM does not have network access
Jeffrey,
This is getting into an area I do not know much about, but I think I
understand well enough.
I tried configuring the server to run as "This user", and (on server2) it
launched okay, and was able to access network resources, but
CoCreateInstanceEx returned E_ACCESSDENIED.
There is too much going on here. I am going to run as "The interactive user"
for now.
Paul
""Jeffrey Tan[MSFT]"" wrote in message
news:0tQ%23wqLsIHA.1788@TK2MSFTNGHUB02.phx.gbl...
> Hi Paul,
>
> Thanks for your feedback.
>
> When we are using "The launching user", we are using impersonation in
> DCOM.
> The kerboros protocol will help to impersonate the client security context
> in the DCOM server process.(dllhost as I know). Yes, this is a security
> credential double hop scenario.
>
> It is a security design not to delegate the security credential across two
> machines boundary. It is normally insecure to allow the server to use the
> client user's identify to access a 3rd machine. The client user has no
> idea
> that if the server process will use his security identify to perform
> unauthorized operations. For example, the server may have been
> compromised.
> If Windows does not limit double hop, the malicous user may impersonate
> under the client identity to access a secrete database on another
> machine(which only the client user account has permission to access).
> Actually, some experts even believe impersonation as a bad idea, see the
> link below:
> http://www.wintellect.com/cs/blogs/pmehner/archive/2007/12/23/security-impli
> cations-of-services-impersonating-callers.aspx
>
> Regarding "The credentials are the same, it's just running in a different
> window station", do you mean the client user and the server machine
> interactive user are the same domain account? Actually, in the "The
> launching user" scenario, the DCOM server will impersonate under the
> client
> user token. However, the server will not cache the credential of the
> client
> user. So, when server tries to access 3rd machine, it has no credential
> for
> authentication. So it will not be considered as the client user on 3rd
> machine.
>
> Maybe, you may use the "This User" option and hard-code the client user
> account/password in the DCOM server process. This will give the credential
> on the DCOM server process. Thanks.
>
> Best regards,
> Jeffrey Tan
> Microsoft Online Community Support
> =========================================
> Delighting our customers is our #1 priority. We welcome your comments and
> suggestions about how we can improve the support we provide to you. Please
> feel free to let my manager know what you think of the level of service
> provided. You can send feedback directly to my manager at:
> msdnmg@microsoft.com.
>
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
date: Thu, 8 May 2008 12:59:31 -0400
author: Paul Baker [MVP, Windows Desktop Experience] am
|
|