DCOM and Vista - Access denied

  • Thread starter Thread starter Ivco
  • Start date Start date
I

Ivco

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
 
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.
 
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\Control\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
 
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\lsa
lmcompatibilitylevel
Click to expand...

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.
Click to expand...

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...".
Click to expand...

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/technetmag/issues/2006/08/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.
Click to expand...

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.
Click to expand...

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/0470101555?ie=UTF8&tag=protectyourwi-20


Ivco said:
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
That enables the protocols for use, subject to the application actually
using them.


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.


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/technetmag/issues/2006/08/SecurityWatch/ for
more info.


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


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
Click to expand...
Click to expand...
 
ivco-vista is my machine name. This is not a domain. Both of the
machines are in the same work-group: Workgroup
Click to expand...

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.
Click to expand...

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-Code-Windows-Vista/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.
Click to expand...

It is, but not the way you think.

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

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.
Click to expand...

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.
Click to expand...

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
 
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
 
There is an RPC_C_IMP_LEVEL_DEFAULT according to the SDK.
That is right but:
Note:
Click to expand...

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.
Click to expand...

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.
What do you mean?
Click to expand...

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!?!?
Click to expand...

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.
Click to expand...

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.
Click to expand...

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.
Click to expand...

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?
Click to expand...

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?
Click to expand...

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

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/0470101555?ie=UTF8&tag=protectyourwi-20


Ivco said:
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
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\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/technetmag/issues/2006/08/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
Click to expand...
Click to expand...
Click to expand...
 
I created the same user on the XP machine (the same name, password and
privileges) and I tried to connect while logged on as this user on both
of the machines - since there is no domain windows trusts only its local
user store (the MSDN says). As expected - Access Denied
 
No, you elevate and change it. That's what UAC is for. Is changing IP
Yes, I do. In fact a lot more.
Click to expand...

In that case, launch a command prompt as an admin. Then write a cmd script
to call netsh and change the IP address that way. You can leave the window
open between the times you change it and you only need to accept one UAC
prompt that way.
 
There is an RPC_C_IMP_LEVEL_DEFAULT according to the SDK.

That is right but:
Note:
Except for RPC_C_AUTHN_LEVEL_DEFAULT, all other default security
constants (such as RPC_C_IMP_LEVEL_DEFAULT) are invalid for use as
CoInitializeSecurity parameters. These other default constants are
defined as placeholders for proxy blanket negotiated settings.

http://msdn2.microsoft.com/en-us/library/ms693736.aspx
Vista pre-pends the domain name (or host name) to the account name,
Click to expand...
and since that user is invalid on XP it fails.

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 is, but not the way you think.
Click to expand...

What do you mean?

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!?!?
The system architect should be good enough to see most of the major
problems and he should do the design accordingly. The design should not
be changed at development time. If there is a change it should not be a
major one.
This is another story. It is nothing to do with the problem that I have.

Regards
 
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.
Click to expand...

Yes, you are right.
No, you elevate and change it. That's what UAC is for. Is changing IP
addresses something you do often?
Click to expand...

Yes, I do. In fact a lot more.

Maybe the project life-cycle at your company is different. We have a
phase called Proof of Concept that is something like a research before
and during the project design time - we believe that spending more time
on the design helps reduce the development effort and time.

It really does not matter, right now.
One option is to pass it in the pAuthList parameter
Click to expand...
of the CoInitializeSecurity call.

I will try to pass authentlist with the CoInitializeSecurity.

Thanks a lot, Jesper
 
Back
Top