DCOM and Vista - Access denied

Thanks a lot Jesper,

I will try this out on Monday because my Vista machine is at the office.
You are right it could be because of the LAN manager authentication level.
Is there a way to control this setting programmatically? It is possible to
be changed by DCOMCNFG or with the UI. The best way that I found is to
change the registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\lsa
lmcompatibilitylevel

Is there an API function to change this value per process? I do not want to
change the global OS settings. I just want to change this value per my
application only.

There is one more thing that I cannot explain with the LAN manager
authentication level: If the client and the server machines are Vista and XP
it make sense to have Access Denied because XP has
"Send LM & NTLM responses" set by default and Vista default setting is "Send
NTLMv2 response only...". I also mentioned that I tried to use Vista
machines for the client and the server as well and I still got Access
Denied.
If the only reason for the Access Denied was the LAN manager authentication
level in the case of two Vista machines it would be possible to establish
connection (the default settings are the same).
At least this is what I think.

Once again, thanks a lot for your time

Regards
"Jesper" <Jesper@discussions.microsoft.com> wrote in message
news:1A9BC301-2244-4639-B2D0-004FF5A899AA@microsoft.com...

> Which authentication protocols are you permitting in your service? Vista
> does
> not volunteer NTLM or LM by default. If your service requires those you
> would
> get the access denied. You need to make sure your service supports NTLMv2
> to
> permit incoming connections from Vista.
> ---
> Your question may already be answered in Windows Vista Security:
> http://www.amazon.com/gp/product/047...otectyourwi-20
>
>
> "Ivco" wrote:
>

>> Hello
>>
>> I have a DCOM server up and running on a machine with XP. I can connect
>> to this server from another XP machine without any problems (running a
>> DCOM client). I have callbacks working as well. The problem comes when I
>> run the client on a Vista machine and try to connect to the same DCOM
>> server on the XP machine. I tried a lot of settings with DCOMCNFG I also
>> switched off the firewall on both of the machines. The result is always
>> the same "Access denied".
>>
>> The next step was to setup the DCOM server on a Vista machine and to try
>> to access it from XP - again "Access denied".
>>
>> I also tried to access the server on Vista machine from another Vista
>> machine - "Access denied".
>>
>> Next attempt was to leave only TCP as a communication protocol for DCOM
>> on both (client and server) machines. From the Ethereal trace I saw that
>> there is a communication between the two machines, there are RPC packets
>> back and forth but it looks like that the server side always says
>> "Access denied" if there is a Vista machine involved.
>>
>> There must be something else that I do not know or that I am missing
>> while configuring Vista.
>>
>>
>> Any help is highly appreciated
>>
>>

> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\lsa

> lmcompatibilitylevel

That enables the protocols for use, subject to the application actually
using them.

> Is there an API function to change this value per process? I do not want to
> change the global OS settings. I just want to change this value per my
> application only.

I think you would just do it in CoInitializeSecurity(). I'm not really an
expert at RPC but you need to make sure the parameters match on both sides
for asAuthSvc and dwAuthnLevel. It sounds really weird that it should fail
because of this as Windows XP supports inbound NTLMv2, but check if the
server on XP has it set to RPC_C_AUTHN_WINNT. It could be that the XP box
expects only NTLM and Vista sends only NTLMv2, causing the failure. If you
use RPC_C_AUTHN_GSS_NEGOTIATE instead they should negotiate. There may also
be a mismatch in the RPC_C_AUTHN_LEVEL parameters. Take a look at what they
say.

> There is one more thing that I cannot explain with the LAN manager
> authentication level: If the client and the server machines are Vista and XP
> it make sense to have Access Denied because XP has
> "Send LM & NTLM responses" set by default and Vista default setting is "Send
> NTLMv2 response only...".

Not really. XP and Vista will both accept LM, NTLM, and NTLMv2 inbound. The
settings only configure what they send outbound. See
http://www.microsoft.com/technet/tec...SecurityWatch/ for
more info.

> I also mentioned that I tried to use Vista
> machines for the client and the server as well and I still got Access
> Denied.

I missed that. Check the value of the NTLMSSP settings too. The article I
pointed to above has a sidebar on them.

> If the only reason for the Access Denied was the LAN manager authentication
> level in the case of two Vista machines it would be possible to establish
> connection (the default settings are the same).
> At least this is what I think.

The DCOM hardening that came out with Windows XP SP2 made this a fair bit
more complicated. Anything that uses anonymous RPC basically fails with
Access Denied now. This KB article explains it at a basic level:
http://support.microsoft.com/kb/838191

Aah. I see a few things that could be wrong there:

1. The reason you are getting an access denied is because you are trying to
connect to the XP machine with the admin account from the Vista machine. Look
at the trace, it is clearly using specifying the account domain as
ivco-vista. That won't work because that account does not have any rights on
XP. You need to specify the name of an account that does have permissions on
XP. Further, why are you using the Administrator account on the Vista
machine? That doesn't work so well because that account is normally disabled
under Vista and should not be used.
2. You have let COM chose the auth-service. That does seem to work, but it
might be better to force it.
3. You have trned off the authentication levels. Why is that? Why not use
RPC_C_AUTHN_LEVEL_DEFAULT and let the system figure it out?
4. Same with impersonation level. Why not just use default?


---
Your question may already be answered in Windows Vista Security:
http://www.amazon.com/gp/product/047...otectyourwi-20


"Ivco" wrote:

> Thanks for all the info that you gave me, Jasper.
>
>
> I tried to set the Local Security Policy to use only NTLMv2 on both
> machines(Vista and XP) - the result was Access Denied again.
>
> My current configuration is:
> 1. The client is running on Vista, the server on XP.
> 2. I am calling CoInitializeSecurity on the client and on
> the server side like this:
> hr = CoInitializeSecurity( NULL, -1, NULL, NULL,
> RPC_C_AUTHN_LEVEL_NONE,
> RPC_C_IMP_LEVEL_IDENTIFY, NULL, EOAC_NONE, NULL );
>
> 3. The Local Security Policy is set to use only NTLMv2 on both machines(Vista and XP).
>
> I took the trace while trying to establish a connection and here it is:
>
> No Source Dest. Protocol Info
> 1 client server TCP 60682 > epmap [SYN] Seq=0 Ack=0 Win=8192 Len=0 MSS=1460 WS=8
> 2 server client TCP epmap > 60682 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1460 WS=0
> 3 client server TCP 60682 > epmap [ACK] Seq=1 Ack=1 Win=65536 Len=0
> 4 client server DCERPC Bind: call_id: 1, 2 context items, 1st UUID: IOXIDResolver
> 5 server client DCERPC Bind_ack: call_id: 1 Provider rejection, reason: Proposed transfer syntaxes not supported
> 6 client server IOXIDResolver ServerAlive2 request
> 7 server client IOXIDResolver ServerAlive2 response
> 8 client server TCP 60683 > epmap [SYN] Seq=0 Ack=0 Win=8192 Len=0 MSS=1460 WS=8
> 9 server client TCP epmap > 60683 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1460 WS=0
> 10 client server TCP 60683 > epmap [ACK] Seq=1 Ack=1 Win=65536 Len=0
> 11 client server DCERPC Bind: call_id: 2 UUID: ISystemActivator, NTLMSSP_NEGOTIATE
> 12 server client DCERPC Bind_ack: call_id: 2, NTLMSSP_CHALLENGE accept max_xmit: 5840 max_recv: 5840
> 13 client server DCERPC AUTH3: call_id: 2, NTLMSSP_AUTH, User: Ivco-VISTA\Administrator
> 14 client server ISystemActivator RemoteCreateInstance request
> 15 server client TCP epmap > 60683 [ACK] Seq=183 Ack=1347 Win=62894 Len=0
> 16 server client DCERPC Fault: call_id: 2 ctx_id: 1 status: nca_s_fault_access_denied
> 17 client server TCP 60683 > epmap [FIN, ACK] Seq=1347 Ack=215 Win=65280 Len=0
> 18 server client TCP epmap > 60683 [FIN, ACK] Seq=215 Ack=1347 Win=62894 Len=0
> 19 server client TCP epmap > 60683 [ACK] Seq=216 Ack=1348 Win=62894 Len=0
> 20 client server TCP 60683 > epmap [ACK] Seq=1348 Ack=216 Win=65280 Len=0
> 21 client server TCP 60684 > epmap [SYN] Seq=0 Ack=0 Win=8192 Len=0 MSS=1460 WS=8
> 22 server client TCP epmap > 60684 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1460 WS=0
> 23 client server TCP 60684 > epmap [ACK] Seq=1 Ack=1 Win=65536 Len=0
> 24 client server DCERPC Bind: call_id: 3 UUID: ISystemActivator
> 25 server client DCERPC Bind_ack: call_id: 3 accept max_xmit: 5840 max_recv: 5840
> 26 client server ISystemActivator RemoteCreateInstance request
> 27 server client DCERPC Fault: call_id: 3 ctx_id: 1 status: nca_s_fault_access_denied
> 28 server client TCP epmap > 60684 [FIN, ACK] Seq=93 Ack=897 Win=63344 Len=0
> 29 client server TCP 60684 > epmap [FIN, ACK] Seq=897 Ack=93 Win=65536 Len=0
> 30 client server TCP 60684 > epmap [ACK] Seq=898 Ack=94 Win=65536 Len=0
> 31 server client TCP epmap > 60684 [ACK] Seq=94 Ack=898 Win=63344 Len=0
> 32 client server TCP 60682 > epmap [ACK] Seq=141 Ack=217 Win=65280 Len=0
>
> I do not like packets number 5 and 16. There is one more fault on line 27 but I think that it
> is a second attempt to establish the connection.
>
> I tried to set EnableAuthEpResolution to 0 on the XP box(in fact this key was not there, so I created it). According to the doc-s that I read even if the EnableAuthEpResolution is not in the registry
> its default value is 1.
>
>
> Any help is appreciated
>
> Jesper wrote:

> >> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\lsa
> >> lmcompatibilitylevel

> >
> > That enables the protocols for use, subject to the application actually
> > using them.
> >

> >> Is there an API function to change this value per process? I do not want to
> >> change the global OS settings. I just want to change this value per my
> >> application only.

> >
> > I think you would just do it in CoInitializeSecurity(). I'm not really an
> > expert at RPC but you need to make sure the parameters match on both sides
> > for asAuthSvc and dwAuthnLevel. It sounds really weird that it should fail
> > because of this as Windows XP supports inbound NTLMv2, but check if the
> > server on XP has it set to RPC_C_AUTHN_WINNT. It could be that the XP box
> > expects only NTLM and Vista sends only NTLMv2, causing the failure. If you
> > use RPC_C_AUTHN_GSS_NEGOTIATE instead they should negotiate. There may also
> > be a mismatch in the RPC_C_AUTHN_LEVEL parameters. Take a look at what they
> > say.
> >

> >> There is one more thing that I cannot explain with the LAN manager
> >> authentication level: If the client and the server machines are Vista and XP
> >> it make sense to have Access Denied because XP has
> >> "Send LM & NTLM responses" set by default and Vista default setting is "Send
> >> NTLMv2 response only...".

> >
> > Not really. XP and Vista will both accept LM, NTLM, and NTLMv2 inbound. The
> > settings only configure what they send outbound. See
> > http://www.microsoft.com/technet/tec...SecurityWatch/ for
> > more info.
> >

> >> I also mentioned that I tried to use Vista
> >> machines for the client and the server as well and I still got Access
> >> Denied.

> >
> > I missed that. Check the value of the NTLMSSP settings too. The article I
> > pointed to above has a sidebar on them.
> >

> >> If the only reason for the Access Denied was the LAN manager authentication
> >> level in the case of two Vista machines it would be possible to establish
> >> connection (the default settings are the same).
> >> At least this is what I think.

> >
> > The DCOM hardening that came out with Windows XP SP2 made this a fair bit
> > more complicated. Anything that uses anonymous RPC basically fails with
> > Access Denied now. This KB article explains it at a basic level:
> > http://support.microsoft.com/kb/838191
> >

>

> ivco-vista is my machine name. This is not a domain. Both of the

> machines are in the same work-group: Workgroup

Yes, I get that. That is an account that has meaning on the ivco-vista but
not on the XP machine. You cannot use that account to connect from the Vista
machine to the XP machine. That is why you get an access denied error. You
must use an account that resides on the XP machine.

> I use Administrator just during the development.

Sorry, but that is BAAAAD!

You should use an account that has whatever privileges your users will have
when they run the app. As they should be standard users all of the time you
should run with a standard user account. That means that they also will have
a filtered token when they connect so if your server requires the connecting
user to be a full administrator on the server you need to rearchitect the app
to modify that requirement.

I would highly recommend you read this book:
http://www.amazon.com/Writing-Secure.../dp/0735623937

It discusses this, among other things.

It is a sure bet that they will not be _the_ Administrator, so do not use
that account at all. It is disabled by default, and should remain that way.

> I really do not want to
> see UAC messages all the time :-). I think that the Administrator
> account is not the real problem.

It is, but not the way you think.

> > 4. Same with impersonation level. Why not just use default?

>
> In the RPCDCE.h there are several options for this parameter:

There is an RPC_C_IMP_LEVEL_DEFAULT according to the SDK.

> I tried the server and the client on the same Vista machine - everything
> is fine.

As it should. You are connecting out with the same user context you have on
the Vista machine and that user context is meaningless on the XP system.
Vista pre-pends the domain name (or host name) to the account name, and since
that user is invalid on XP it fails. You need to figure out how to pass a
different user account. One option is to pass it in the pAuthList parameter
of the CoInitializeSecurity call. You can't just let it default to the user
account you are logged in with though.

> It could be something new introduced with Vista or a setting that is
> different compared to XP. I always have Access Denied when a Vista
> machine is involved.

It is possible, although if my memory serves me right, not the case, that XP
does not include the hostname/domain name in the user account name when it
connects. In that case the connection would work since it would go as
"Administrator" and the server would just map that to the local admin account.

Thanks for all the info that you gave me, Jasper.


I tried to set the Local Security Policy to use only NTLMv2 on both
machines(Vista and XP) - the result was Access Denied again.

My current configuration is:
1. The client is running on Vista, the server on XP.
2. I am calling CoInitializeSecurity on the client and on
the server side like this:
hr = CoInitializeSecurity( NULL, -1, NULL, NULL,
RPC_C_AUTHN_LEVEL_NONE,
RPC_C_IMP_LEVEL_IDENTIFY, NULL, EOAC_NONE, NULL );

3. The Local Security Policy is set to use only NTLMv2 on both machines(Vista and XP).

I took the trace while trying to establish a connection and here it is:

No Source Dest. Protocol Info
1 client server TCP 60682 > epmap [SYN] Seq=0 Ack=0 Win=8192 Len=0 MSS=1460 WS=8
2 server client TCP epmap > 60682 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1460 WS=0
3 client server TCP 60682 > epmap [ACK] Seq=1 Ack=1 Win=65536 Len=0
4 client server DCERPC Bind: call_id: 1, 2 context items, 1st UUID: IOXIDResolver
5 server client DCERPC Bind_ack: call_id: 1 Provider rejection, reason: Proposed transfer syntaxes not supported
6 client server IOXIDResolver ServerAlive2 request
7 server client IOXIDResolver ServerAlive2 response
8 client server TCP 60683 > epmap [SYN] Seq=0 Ack=0 Win=8192 Len=0 MSS=1460 WS=8
9 server client TCP epmap > 60683 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1460 WS=0
10 client server TCP 60683 > epmap [ACK] Seq=1 Ack=1 Win=65536 Len=0
11 client server DCERPC Bind: call_id: 2 UUID: ISystemActivator, NTLMSSP_NEGOTIATE
12 server client DCERPC Bind_ack: call_id: 2, NTLMSSP_CHALLENGE accept max_xmit: 5840 max_recv: 5840
13 client server DCERPC AUTH3: call_id: 2, NTLMSSP_AUTH, User: Ivco-VISTA\Administrator
14 client server ISystemActivator RemoteCreateInstance request
15 server client TCP epmap > 60683 [ACK] Seq=183 Ack=1347 Win=62894 Len=0
16 server client DCERPC Fault: call_id: 2 ctx_id: 1 status: nca_s_fault_access_denied
17 client server TCP 60683 > epmap [FIN, ACK] Seq=1347 Ack=215 Win=65280 Len=0
18 server client TCP epmap > 60683 [FIN, ACK] Seq=215 Ack=1347 Win=62894 Len=0
19 server client TCP epmap > 60683 [ACK] Seq=216 Ack=1348 Win=62894 Len=0
20 client server TCP 60683 > epmap [ACK] Seq=1348 Ack=216 Win=65280 Len=0
21 client server TCP 60684 > epmap [SYN] Seq=0 Ack=0 Win=8192 Len=0 MSS=1460 WS=8
22 server client TCP epmap > 60684 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1460 WS=0
23 client server TCP 60684 > epmap [ACK] Seq=1 Ack=1 Win=65536 Len=0
24 client server DCERPC Bind: call_id: 3 UUID: ISystemActivator
25 server client DCERPC Bind_ack: call_id: 3 accept max_xmit: 5840 max_recv: 5840
26 client server ISystemActivator RemoteCreateInstance request
27 server client DCERPC Fault: call_id: 3 ctx_id: 1 status: nca_s_fault_access_denied
28 server client TCP epmap > 60684 [FIN, ACK] Seq=93 Ack=897 Win=63344 Len=0
29 client server TCP 60684 > epmap [FIN, ACK] Seq=897 Ack=93 Win=65536 Len=0
30 client server TCP 60684 > epmap [ACK] Seq=898 Ack=94 Win=65536 Len=0
31 server client TCP epmap > 60684 [ACK] Seq=94 Ack=898 Win=63344 Len=0
32 client server TCP 60682 > epmap [ACK] Seq=141 Ack=217 Win=65280 Len=0

I do not like packets number 5 and 16. There is one more fault on line 27 but I think that it
is a second attempt to establish the connection.

I tried to set EnableAuthEpResolution to 0 on the XP box(in fact this key was not there, so I created it). According to the doc-s that I read even if the EnableAuthEpResolution is not in the registry
its default value is 1.


Any help is appreciated

Jesper wrote:

>> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\lsa
>> lmcompatibilitylevel

>
> That enables the protocols for use, subject to the application actually
> using them.
>

>> Is there an API function to change this value per process? I do not want to
>> change the global OS settings. I just want to change this value per my
>> application only.

>
> I think you would just do it in CoInitializeSecurity(). I'm not really an
> expert at RPC but you need to make sure the parameters match on both sides
> for asAuthSvc and dwAuthnLevel. It sounds really weird that it should fail
> because of this as Windows XP supports inbound NTLMv2, but check if the
> server on XP has it set to RPC_C_AUTHN_WINNT. It could be that the XP box
> expects only NTLM and Vista sends only NTLMv2, causing the failure. If you
> use RPC_C_AUTHN_GSS_NEGOTIATE instead they should negotiate. There may also
> be a mismatch in the RPC_C_AUTHN_LEVEL parameters. Take a look at what they
> say.
>

>> There is one more thing that I cannot explain with the LAN manager
>> authentication level: If the client and the server machines are Vista and XP
>> it make sense to have Access Denied because XP has
>> "Send LM & NTLM responses" set by default and Vista default setting is "Send
>> NTLMv2 response only...".

>
> Not really. XP and Vista will both accept LM, NTLM, and NTLMv2 inbound. The
> settings only configure what they send outbound. See
> http://www.microsoft.com/technet/tec...SecurityWatch/ for
> more info.
>

>> I also mentioned that I tried to use Vista
>> machines for the client and the server as well and I still got Access
>> Denied.

>
> I missed that. Check the value of the NTLMSSP settings too. The article I
> pointed to above has a sidebar on them.
>

>> If the only reason for the Access Denied was the LAN manager authentication
>> level in the case of two Vista machines it would be possible to establish
>> connection (the default settings are the same).
>> At least this is what I think.

>
> The DCOM hardening that came out with Windows XP SP2 made this a fair bit
> more complicated. Anything that uses anonymous RPC basically fails with
> Access Denied now. This KB article explains it at a basic level:
> http://support.microsoft.com/kb/838191
>

Thanks for all the info that you gave me, Jesper.


I tried to set the Local Security Policy to use only NTLMv2 on both
machines(Vista and XP) - the result was Access Denied again.

My current configuration is:
1. The client is running on Vista, the server on XP.
2. I am calling CoInitializeSecurity on the client and on
the server side like this:
hr = CoInitializeSecurity( NULL, -1, NULL, NULL,
RPC_C_AUTHN_LEVEL_NONE,
RPC_C_IMP_LEVEL_IDENTIFY, NULL, EOAC_NONE, NULL );

3. The Local Security Policy is set to use only NTLMv2 on both machines(Vista and XP).

I took the trace while trying to establish a connection and here it is:

No Source Dest. Protocol Info
1 client server TCP 60682 > epmap [SYN] Seq=0 Ack=0 Win=8192 Len=0 MSS=1460 WS=8
2 server client TCP epmap > 60682 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1460 WS=0
3 client server TCP 60682 > epmap [ACK] Seq=1 Ack=1 Win=65536 Len=0
4 client server DCERPC Bind: call_id: 1, 2 context items, 1st UUID: IOXIDResolver
5 server client DCERPC Bind_ack: call_id: 1 Provider rejection, reason: Proposed transfer syntaxes not supported
6 client server IOXIDResolver ServerAlive2 request
7 server client IOXIDResolver ServerAlive2 response
8 client server TCP 60683 > epmap [SYN] Seq=0 Ack=0 Win=8192 Len=0 MSS=1460 WS=8
9 server client TCP epmap > 60683 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1460 WS=0
10 client server TCP 60683 > epmap [ACK] Seq=1 Ack=1 Win=65536 Len=0
11 client server DCERPC Bind: call_id: 2 UUID: ISystemActivator, NTLMSSP_NEGOTIATE
12 server client DCERPC Bind_ack: call_id: 2, NTLMSSP_CHALLENGE accept max_xmit: 5840 max_recv: 5840
13 client server DCERPC AUTH3: call_id: 2, NTLMSSP_AUTH, User: Ivco-VISTA\Administrator
14 client server ISystemActivator RemoteCreateInstance request
15 server client TCP epmap > 60683 [ACK] Seq=183 Ack=1347 Win=62894 Len=0
16 server client DCERPC Fault: call_id: 2 ctx_id: 1 status: nca_s_fault_access_denied
17 client server TCP 60683 > epmap [FIN, ACK] Seq=1347 Ack=215 Win=65280 Len=0
18 server client TCP epmap > 60683 [FIN, ACK] Seq=215 Ack=1347 Win=62894 Len=0
19 server client TCP epmap > 60683 [ACK] Seq=216 Ack=1348 Win=62894 Len=0
20 client server TCP 60683 > epmap [ACK] Seq=1348 Ack=216 Win=65280 Len=0
21 client server TCP 60684 > epmap [SYN] Seq=0 Ack=0 Win=8192 Len=0 MSS=1460 WS=8
22 server client TCP epmap > 60684 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1460 WS=0
23 client server TCP 60684 > epmap [ACK] Seq=1 Ack=1 Win=65536 Len=0
24 client server DCERPC Bind: call_id: 3 UUID: ISystemActivator
25 server client DCERPC Bind_ack: call_id: 3 accept max_xmit: 5840 max_recv: 5840
26 client server ISystemActivator RemoteCreateInstance request
27 server client DCERPC Fault: call_id: 3 ctx_id: 1 status: nca_s_fault_access_denied
28 server client TCP epmap > 60684 [FIN, ACK] Seq=93 Ack=897 Win=63344 Len=0
29 client server TCP 60684 > epmap [FIN, ACK] Seq=897 Ack=93 Win=65536 Len=0
30 client server TCP 60684 > epmap [ACK] Seq=898 Ack=94 Win=65536 Len=0
31 server client TCP epmap > 60684 [ACK] Seq=94 Ack=898 Win=63344 Len=0
32 client server TCP 60682 > epmap [ACK] Seq=141 Ack=217 Win=65280 Len=0

I do not like packets number 5 and 16. There is one more fault on line 27 but I think that it
is a second attempt to establish the connection.

I tried to set EnableAuthEpResolution to 0 on the XP box(in fact this key was not there, so I created it). According to the doc-s that I read even if the EnableAuthEpResolution is not in the registry
its default value is 1.


Any help is appreciated

Jesper wrote:

>> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\lsa
>> lmcompatibilitylevel

>
> That enables the protocols for use, subject to the application actually
> using them.
>

>> Is there an API function to change this value per process? I do not want to
>> change the global OS settings. I just want to change this value per my
>> application only.

>
> I think you would just do it in CoInitializeSecurity(). I'm not really an
> expert at RPC but you need to make sure the parameters match on both sides
> for asAuthSvc and dwAuthnLevel. It sounds really weird that it should fail
> because of this as Windows XP supports inbound NTLMv2, but check if the
> server on XP has it set to RPC_C_AUTHN_WINNT. It could be that the XP box
> expects only NTLM and Vista sends only NTLMv2, causing the failure. If you
> use RPC_C_AUTHN_GSS_NEGOTIATE instead they should negotiate. There may also
> be a mismatch in the RPC_C_AUTHN_LEVEL parameters. Take a look at what they
> say.
>

>> There is one more thing that I cannot explain with the LAN manager
>> authentication level: If the client and the server machines are Vista and XP
>> it make sense to have Access Denied because XP has
>> "Send LM & NTLM responses" set by default and Vista default setting is "Send
>> NTLMv2 response only...".

>
> Not really. XP and Vista will both accept LM, NTLM, and NTLMv2 inbound. The
> settings only configure what they send outbound. See
> http://www.microsoft.com/technet/tec...SecurityWatch/ for
> more info.
>

>> I also mentioned that I tried to use Vista
>> machines for the client and the server as well and I still got Access
>> Denied.

>
> I missed that. Check the value of the NTLMSSP settings too. The article I
> pointed to above has a sidebar on them.
>

>> If the only reason for the Access Denied was the LAN manager authentication
>> level in the case of two Vista machines it would be possible to establish
>> connection (the default settings are the same).
>> At least this is what I think.

>
> The DCOM hardening that came out with Windows XP SP2 made this a fair bit
> more complicated. Anything that uses anonymous RPC basically fails with
> Access Denied now. This KB article explains it at a basic level:
> http://support.microsoft.com/kb/838191
>

> > There is an RPC_C_IMP_LEVEL_DEFAULT according to the SDK.

>
> That is right but:
> Note:

Aah, yes. OK.

> It could be this as well but I changed the server settings such that in
> the Launch and Activation Permissions there is Everyone with full access
> and in the Access Permissions there is again Everyone with full access.
> So, even if the user is meaningless on the XP box it should not be a
> problem, I guess, but I have again Access Denied.

It does not matter what the permission are. You don't even get to that
point. The client tries to authenticate and fails at it. The access check is
done after the authentication but as that never succeeds the access check
does not happen.

> >> I think that the Administrator account is not the real problem.

> > It is, but not the way you think.

>
> What do you mean?

It is because it is invalid on the server.

> Maybe you are right it is not the best to use the Administrator but to
> use an account with the same privileges as the real user during the
> development is not the best either. Imagine you want to change your IP
> to test something - you do what? logout, login, change IP, logout,
> login!?!?

No, you elevate and change it. That's what UAC is for. Is changing IP
addresses something you do often?

I really appreciate your help, Jesper. It is good to know that someone
is trying to help you out-there.

> it is clearly using specifying the account domain as ivco-vista.

ivco-vista is my machine name. This is not a domain. Both of the
machines are in the same work-group: Workgroup

why are you using the Administrator account on the Vista

> machine? That doesn't work so well because that account is normally

disabled

> under Vista and should not be used.

I use Administrator just during the development. I really do not want to
see UAC messages all the time :-). I think that the Administrator
account is not the real problem. Nevertheless I tried to establish
connection using an user with administrative privileges - as expected
Access Denied.

> 2. You have let COM chose the auth-service. That does seem to work,

but it

> might be better to force it.

I use this CoInitializeSecurity with these parameters because I've seen
this in several COM/DCOM books as a method to lower the security as much
as possible. At least at this point I want to avoid problems caused by
incorrect security settings - if possible.

> 3. You have trned off the authentication levels. Why is that? Why not

use

> RPC_C_AUTHN_LEVEL_DEFAULT and let the system figure it out?

I tried RPC_C_AUTHN_LEVEL_DEFAULT - on XP machines works fine. On Vista
- Access Denied again

> 4. Same with impersonation level. Why not just use default?

In the RPCDCE.h there are several options for this parameter:

#define RPC_C_IMP_LEVEL_ANONYMOUS 1
#define RPC_C_IMP_LEVEL_IDENTIFY 2
#define RPC_C_IMP_LEVEL_IMPERSONATE 3
#define RPC_C_IMP_LEVEL_DELEGATE 4

There is no DEFAULT.


I tried the server and the client on the same Vista machine - everything
is fine.
It could be something new introduced with Vista or a setting that is
different compared to XP. I always have Access Denied when a Vista
machine is involved.

Regards


Jesper wrote:

> Aah. I see a few things that could be wrong there:
>
> 1. The reason you are getting an access denied is because you are trying to
> connect to the XP machine with the admin account from the Vista machine. Look
> at the trace, it is clearly using specifying the account domain as
> ivco-vista. That won't work because that account does not have any rights on
> XP. You need to specify the name of an account that does have permissions on
> XP. Further, why are you using the Administrator account on the Vista
> machine? That doesn't work so well because that account is normally disabled
> under Vista and should not be used.
> 2. You have let COM chose the auth-service. That does seem to work, but it
> might be better to force it.
> 3. You have trned off the authentication levels. Why is that? Why not use
> RPC_C_AUTHN_LEVEL_DEFAULT and let the system figure it out?
> 4. Same with impersonation level. Why not just use default?
>
>
> ---
> Your question may already be answered in Windows Vista Security:
> http://www.amazon.com/gp/product/047...otectyourwi-20
>
>
> "Ivco" wrote:
>

>> Thanks for all the info that you gave me, Jasper.
>>
>>
>> I tried to set the Local Security Policy to use only NTLMv2 on both
>> machines(Vista and XP) - the result was Access Denied again.
>>
>> My current configuration is:
>> 1. The client is running on Vista, the server on XP.
>> 2. I am calling CoInitializeSecurity on the client and on
>> the server side like this:
>> hr = CoInitializeSecurity( NULL, -1, NULL, NULL,
>> RPC_C_AUTHN_LEVEL_NONE,
>> RPC_C_IMP_LEVEL_IDENTIFY, NULL, EOAC_NONE, NULL );
>>
>> 3. The Local Security Policy is set to use only NTLMv2 on both machines(Vista and XP).
>>
>> I took the trace while trying to establish a connection and here it is:
>>
>> No Source Dest. Protocol Info
>> 1 client server TCP 60682 > epmap [SYN] Seq=0 Ack=0 Win=8192 Len=0 MSS=1460 WS=8
>> 2 server client TCP epmap > 60682 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1460 WS=0
>> 3 client server TCP 60682 > epmap [ACK] Seq=1 Ack=1 Win=65536 Len=0
>> 4 client server DCERPC Bind: call_id: 1, 2 context items, 1st UUID: IOXIDResolver
>> 5 server client DCERPC Bind_ack: call_id: 1 Provider rejection, reason: Proposed transfer syntaxes not supported
>> 6 client server IOXIDResolver ServerAlive2 request
>> 7 server client IOXIDResolver ServerAlive2 response
>> 8 client server TCP 60683 > epmap [SYN] Seq=0 Ack=0 Win=8192 Len=0 MSS=1460 WS=8
>> 9 server client TCP epmap > 60683 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1460 WS=0
>> 10 client server TCP 60683 > epmap [ACK] Seq=1 Ack=1 Win=65536 Len=0
>> 11 client server DCERPC Bind: call_id: 2 UUID: ISystemActivator, NTLMSSP_NEGOTIATE
>> 12 server client DCERPC Bind_ack: call_id: 2, NTLMSSP_CHALLENGE accept max_xmit: 5840 max_recv: 5840
>> 13 client server DCERPC AUTH3: call_id: 2, NTLMSSP_AUTH, User: Ivco-VISTA\Administrator
>> 14 client server ISystemActivator RemoteCreateInstance request
>> 15 server client TCP epmap > 60683 [ACK] Seq=183 Ack=1347 Win=62894 Len=0
>> 16 server client DCERPC Fault: call_id: 2 ctx_id: 1 status: nca_s_fault_access_denied
>> 17 client server TCP 60683 > epmap [FIN, ACK] Seq=1347 Ack=215 Win=65280 Len=0
>> 18 server client TCP epmap > 60683 [FIN, ACK] Seq=215 Ack=1347 Win=62894 Len=0
>> 19 server client TCP epmap > 60683 [ACK] Seq=216 Ack=1348 Win=62894 Len=0
>> 20 client server TCP 60683 > epmap [ACK] Seq=1348 Ack=216 Win=65280 Len=0
>> 21 client server TCP 60684 > epmap [SYN] Seq=0 Ack=0 Win=8192 Len=0 MSS=1460 WS=8
>> 22 server client TCP epmap > 60684 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1460 WS=0
>> 23 client server TCP 60684 > epmap [ACK] Seq=1 Ack=1 Win=65536 Len=0
>> 24 client server DCERPC Bind: call_id: 3 UUID: ISystemActivator
>> 25 server client DCERPC Bind_ack: call_id: 3 accept max_xmit: 5840 max_recv: 5840
>> 26 client server ISystemActivator RemoteCreateInstance request
>> 27 server client DCERPC Fault: call_id: 3 ctx_id: 1 status: nca_s_fault_access_denied
>> 28 server client TCP epmap > 60684 [FIN, ACK] Seq=93 Ack=897 Win=63344 Len=0
>> 29 client server TCP 60684 > epmap [FIN, ACK] Seq=897 Ack=93 Win=65536 Len=0
>> 30 client server TCP 60684 > epmap [ACK] Seq=898 Ack=94 Win=65536 Len=0
>> 31 server client TCP epmap > 60684 [ACK] Seq=94 Ack=898 Win=63344 Len=0
>> 32 client server TCP 60682 > epmap [ACK] Seq=141 Ack=217 Win=65280 Len=0
>>
>> I do not like packets number 5 and 16. There is one more fault on line 27 but I think that it
>> is a second attempt to establish the connection.
>>
>> I tried to set EnableAuthEpResolution to 0 on the XP box(in fact this key was not there, so I created it). According to the doc-s that I read even if the EnableAuthEpResolution is not in the registry
>> its default value is 1.
>>
>>
>> Any help is appreciated
>>
>> Jesper wrote:

>>>> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\lsa
>>>> lmcompatibilitylevel
>>> That enables the protocols for use, subject to the application actually
>>> using them.
>>>
>>>> Is there an API function to change this value per process? I do not want to
>>>> change the global OS settings. I just want to change this value per my
>>>> application only.
>>> I think you would just do it in CoInitializeSecurity(). I'm not really an
>>> expert at RPC but you need to make sure the parameters match on both sides
>>> for asAuthSvc and dwAuthnLevel. It sounds really weird that it should fail
>>> because of this as Windows XP supports inbound NTLMv2, but check if the
>>> server on XP has it set to RPC_C_AUTHN_WINNT. It could be that the XP box
>>> expects only NTLM and Vista sends only NTLMv2, causing the failure. If you
>>> use RPC_C_AUTHN_GSS_NEGOTIATE instead they should negotiate. There may also
>>> be a mismatch in the RPC_C_AUTHN_LEVEL parameters. Take a look at what they
>>> say.
>>>
>>>> There is one more thing that I cannot explain with the LAN manager
>>>> authentication level: If the client and the server machines are Vista and XP
>>>> it make sense to have Access Denied because XP has
>>>> "Send LM & NTLM responses" set by default and Vista default setting is "Send
>>>> NTLMv2 response only...".
>>> Not really. XP and Vista will both accept LM, NTLM, and NTLMv2 inbound. The
>>> settings only configure what they send outbound. See
>>> http://www.microsoft.com/technet/tec...SecurityWatch/ for
>>> more info.
>>>
>>>> I also mentioned that I tried to use Vista
>>>> machines for the client and the server as well and I still got Access
>>>> Denied.
>>> I missed that. Check the value of the NTLMSSP settings too. The article I
>>> pointed to above has a sidebar on them.
>>>
>>>> If the only reason for the Access Denied was the LAN manager authentication
>>>> level in the case of two Vista machines it would be possible to establish
>>>> connection (the default settings are the same).
>>>> At least this is what I think.
>>> The DCOM hardening that came out with Windows XP SP2 made this a fair bit
>>> more complicated. Anything that uses anonymous RPC basically fails with
>>> Access Denied now. This KB article explains it at a basic level:
>>> http://support.microsoft.com/kb/838191
>>>