Mapping IPC$ doesn't work for DCOM

[Guest Ashutosh Bhawasinka]

Whenever I need to access a remote system which requires some

authentication, I preferred to use this command

 

net use \\<remote-system>\IPC$ /user:<remotesystem-login> <password>

 

I have been using this for over 3 years ( I don't know how I learned

about this)

 

It works fine if I want access shared files/foldes. Also if I execute

above mentioned command even pstools form sysinternals.com works (I

don't have to provide the user name and passwords).

 

This doesn't work if I run a DCOM client applicaiton.

 

Say, the DCOM client is on client01 and the DCOM server is on server01

and server01 has user administrator with all the permission and password

as pass@word1. These systems are NOT part of a domain.

 

if I run this on the client01

 

net use \\server01\IPC$ /user:server01\Administrator pass@word1

 

I can then access anything on server01, C$ share, start or stop the

services, shutdown system, anything except DCOM. The DCOM client on

client01 fails to connect.

 

for the DCOM server on server01, I have assigned all permission to

'everyone' & 'users' even then I get access denied error.

 

Any ideas why DCOM is exception to this???

 

Regards,

Ashutosh

[Guest Brian Muth]

"Ashutosh Bhawasinka" <smbs-msdn@nospam.nospam> wrote in message news:edJYMDZ0IHA.704@TK2MSFTNGP05.phx.gbl...<span style="color:blue">

> Whenever I need to access a remote system which requires some authentication, I preferred to use this command

>

> net use \<remote-system>IPC$ /user:<remotesystem-login> <password>

>

> I have been using this for over 3 years ( I don't know how I learned about this)

>

> It works fine if I want access shared files/foldes. Also if I execute above mentioned command even pstools form sysinternals.com

> works (I don't have to provide the user name and passwords).

>

> This doesn't work if I run a DCOM client applicaiton.

>

> Say, the DCOM client is on client01 and the DCOM server is on server01 and server01 has user administrator with all the permission

> and password as pass@word1. These systems are NOT part of a domain.

>

> if I run this on the client01

>

> net use \server01IPC$ /user:server01Administrator pass@word1

>

> I can then access anything on server01, C$ share, start or stop the services, shutdown system, anything except DCOM. The DCOM

> client on client01 fails to connect.

>

> for the DCOM server on server01, I have assigned all permission to 'everyone' & 'users' even then I get access denied error.

>

> Any ideas why DCOM is exception to this???

>

> Regards,

> Ashutosh</span>

 

I'm not surprised. You have configured the DCOM server to permit "everyone" to have access (and I hope have launch rights).

"Everyone" means "everyone who is authenticated". It does not mean "anonymous". Therefore the client must present a known username

and password. Presumably it is presenting the name of the user who has launched the client unless you have overridden this by

filling in the COAUTHIDENTITY struct and passing it to CoCreateInstanceEx(). The IPC$ setting doesn't play a role in this handshake.

 

For remote computers that do not share a domain, this can be accomplished ensuring that you use a local account with matching

passwords on both the client and server machines.

[Guest Ashutosh Bhawasinka]

Hi Brian,

No offense, but what you mentioned, I am already aware of that! I am not

looking for to fix this, but to know how & why it's happening.

 

My point here is, after you map IPC$, the client is already

authenticated to the server by the user name used in IPC$ mapping. This

can be verified by opening the computer management/Shared Folders/Open

Files (on the server). Any thing you access on the server from the

client is done under that user (the one mentioned in IPC$ mapping). This

can also be verified in the even log of the server.

 

So, why does DCOM authenticate with a different credential when the

currently logged on user is already authenticated with the server? Is it

using a different mechanism to communicate/authenticate with the server?

 

Regards,

Ashutosh

[Guest Alexander Nickolov]

Is your DCOM server configured to run as the INTERACTIVE

identity?

 

--

=====================================

Alexander Nickolov

Microsoft MVP [VC], MCSD

email: agnickolov@mvps.org

MVP VC FAQ: http://vcfaq.mvps.org

=====================================

 

"Ashutosh Bhawasinka" <smbs-msdn@nospam.nospam> wrote in message

news:%23bS%23D2e0IHA.4476@TK2MSFTNGP06.phx.gbl...<span style="color:blue">

> Hi Brian,

> No offense, but what you mentioned, I am already aware of that! I am not

> looking for to fix this, but to know how & why it's happening.

>

> My point here is, after you map IPC$, the client is already authenticated

> to the server by the user name used in IPC$ mapping. This can be verified

> by opening the computer management/Shared Folders/Open Files (on the

> server). Any thing you access on the server from the client is done under

> that user (the one mentioned in IPC$ mapping). This can also be verified

> in the even log of the server.

>

> So, why does DCOM authenticate with a different credential when the

> currently logged on user is already authenticated with the server? Is it

> using a different mechanism to communicate/authenticate with the server?

>

> Regards,

> Ashutosh </span>