Mapping IPC$ doesn't work for DCOM

Mapping IPC$ doesn't work for DCOM
Secure Home | Search | About
Login Password
Register Now! Lost Password?
 Microsoft Applications Security    Post an article   get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content add this group's latest topics to your Google content
Subject Author Date
Mapping IPC$ doesn't work for DCOM Ashutosh Bhawasinka 06-18-2008
Posted by Ashutosh Bhawasinka on June 18, 2008, 6:15 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
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

Posted by Brian Muth on June 18, 2008, 6:59 pm
If you were  Registered and logged in, you could reply and use other advanced thread options

> 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

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.


Posted by Ashutosh Bhawasinka on June 19, 2008, 5:18 am
If you were  Registered and logged in, you could reply and use other advanced thread options
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

Posted by Alexander Nickolov on August 11, 2008, 2:53 pm
If you were  Registered and logged in, you could reply and use other advanced thread options


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
=====================================

> 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



Similar ThreadsPosted
Character Mapping June 15, 2006, 12:17 pm
Kerberos Hostname mapping October 30, 2008, 3:55 pm
mapping LPT1 to network printer November 22, 2005, 5:08 pm
Mapping Drives in Windows Server 2003 HELP! August 1, 2005, 2:57 pm
802.1x authentication logon has Home drive mapping problem February 19, 2008, 11:37 pm
DCOM February 20, 2006, 10:33 am
Disable DCOM? January 11, 2008, 1:07 pm
Dcom Exploit May 16, 2008, 2:14 pm
Search doesn't work August 31, 2005, 3:49 pm
How do you get certificates to work February 2, 2006, 3:07 pm

The site map in XML format XML site map

Contact Us | Privacy Policy