Developer Forum

Hi,

MSDN web page http://www.yqcomputer.com/
in relation to "DCOM Security Enhancements in Windows XP Service Pack 2 and
Windows Server 2003 Service Pack 1 " that:

"The simplest way to think about these access controls is as an additional
AccessCheck call that is done against a computer-wide access control list
(ACL) on each call, activation, or launch of any COM server on the computer.
If the AccessCheck fails, the call, activation, or launch request is denied.
This is in addition to any AccessCheck that is run against the
server-specific ACLs."

If I understand this correctly, when a request for the launch of a COM
server or for access to one of its methods is received by Windows XP SP2 ,
DCOM applies the *most restrictive* security settings of those assigned to
the machine, and those assigned to the specific COM server. First the
machine-wide security is checked, and only if that is passed, is the server
security checked. Is that a correct interpretation?

The implication of this is that if I require to disable security for just a
single DCOM server installed on the computer, I must effectively disable it
for all servers on the same machine. This is because the security settings
applied to the specific server will not work unless settings that are less
than or equally restrictive are applied to the whole machine. Thus if one
wishes to instal a single server that does not require, for sake of example,
user authentication, one is forced to make all other servers bypass user
authentication. In many cases this reduces, rather than enhances, security.
Or is there a way to make DCOM apply only the specific server security
settings if they are assigned, and neglect the machine-wide settings?

Another aspect that is not clear to me is whether the security settings on
the server machine uniquely determine how DCOM on the the server handles
security checks, or whether there is interaction between the the settings on
the server machine and the settings on the machine hosting the client. If I
have disabled user authentication on the server, must I disable it on the
client computer as well, thereby opening up a large security hole for all
servers installed on my client computer?

The motivation for these queries is that I wish to install a DCOM server and
one or more client applications in a *Workgroup* network. My understanding
is that caller authentication is problematic in a workgroup network due to
the lack of a central user directory. Or can one computer in the workgroup
netwrok be configured to provide user registration and authentication
services for the whole network?

Any clarification would be appreciated.

Enquiring Mind

"Enquiring Mind" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...

Yes


Yes, you need to lower both goal posts.


No


No. There is interaction between both settings, however. The server may say,
"I need to know who is accessing my DCOM server", and the client may say, "I
want to access the server's DCOM server but I don't want him to know who I
am". In this situation, authentication is denied.

In other words, the server sets the low water mark and the client sets the
high water mark. Only if the water marks intersect is authentication
granted.


No, you can't.

Workgroup security is painful to set up and administer. That's why domain
controllers were invented in the first place.

HTH

Brian

think your viewpoint is skewed. The situation is like the
following - machine-wide DCOM security belongs to the
administrator, while server security lies with the developer.
If you require certain level of security, you are asking the
administrator for it. If the administrator says they can't allow
certain unsafe practices, that renders your server unsuitable
for that machine automatically so the machine security isn't
compromised. Your server simply can't work on that machine.
Once you wrap yourself around the idea that the administrator
dictates the security - not you - it should all fall into place.
Specifically what you are describing is a perfect use case
scenario why an administrator should _not_ allow your server
to run. Your server requires a dedicated machine which
when compromised won't compromise other servers as well.
(It should also probably be placed in isolation from the rest
of the network.)

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: XXXX@XXXXX.COM
MVP VC FAQ: http://vcfaq.mvps.org
=====================================

"Enquiring Mind" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...

"Brian Muth" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...

Thank you for your helpful response.

Do you mean that the server-side DCOM adopts the more stringent of the
levels set on the client and server machines?

On a web site I have come across this statement:

"Configuring DCOM to Use Named User Security describes how to provide
security between the client and server negotiated on a dedicated named user
basis. You do not have to be logged in as the named user in order to use
this mechanism; all communications between the client and the server are
performed using the dedicated named user, independently of the user making
the OPC requests. However, the identity used to run the OPC server must be
available on the client machine, and the password of that identity must
match on both machines. "

This seems to suggest that provided the user set up on the server machine to
act as Launch Identity for the server is also registered on the client
machine with identical password, DCOM communication can take place. This
would simplify Workgroup security considerably if it were the case. Is it
for Windows XP SP2?

To be able to make informed choices for DCOM settings and fully understand
their security implications, one needs to know the security rules that are
applied by DCOM. As yet, I have not found on the MS websites a unified,
complete definition of the DCOM security rules that are applied by a
specific version of Windows. I have therefore jotted down some assumptions
about what the rules could be, based on the information I have been able to
glean from a disparate collection of web sources. I wonder if anyone could
indicate to what extent the following assumptions are correct:



1.. Client-side DCOM includes in every message initiated by the client
application requesting a server service the client-specified authentication
level and client-specified impersonation level (defined later).
2.. If the client-specified authentication level is "Connect" or above,
the identity of the user that launched the client application ("client
user") is also included in the request message.
3.. The client-specified authentication level is taken to be the more
stringent (i.e. higher) of the following values, where they exist: a) the
machine-wide value recorded in the Registry for the client machine; b) the
client application-specific value recorded in the Registry; and c) the
client application-specific value specified in the client application by a
call to the CoInitializeSecurity API function.
4.. Similarly the client-specified impersonation level is the more
stringent of the following values, where they exist: a) the machine-wide
value recorded in the Registry for the client machine; b) the client
application-specific value recorded in the Registry; and c) the client
application-specific value specified in the client application by a call to
the CoInitializeSecurity API.
5.. If the client application is also registered as a server, for example
in order to enable call-backs, then the client-specific authentication and
impersonation levels may be recorded in the Registry using the Component
Services tool. Otherwise client-specific values can only be set by means of
the CoInitializeSecurity API function.
6.. The server-side DCOM takes as combined authentication level the most
stringent (i.e. highest) of the client-specified

"Alexander Nickolov" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...
Thanks for bringing to my attention that particular security policy. To my
mind it seems to err on the defensive side. But then I am new to the topic
of security, my primary aim being to get a simple client-server application
built on top of DCOM up and running in a Workgroup network (my own, as it
happens!). So the following comments may betray ignorance of what the risks
and threats that the "defensive" security policy is seeking to minimize
really are.

I can see that if the computer administrator, due to a lack of any knowledge
whatsoever about the server application that is installed on his computer,
is not in a position to trust it, he should set the computer wide
restrictions (or, better, the server-specific restrictions) at a stringent
enough level to inhibit the running of malware. However if the server
application is from a trustworthy software source, or from a company
developer, the administrator should be able, in my opinion, to assign to
that specific server more relaxed restrictions that he/she considers
appropriate to the types of functions that the server can actually perform,
thereby overriding more stringent machine-wide restrictions. The situation
seems comparable to that of a firewall. If an application is trusted or not
security-critical, an administrator feels comfortable with including it in
the list of firewall exceptions, thereby relaxing its accessability.

In the particular instance of an administrator faced with installing a new
server application from a new, as yet untrusted, source, if he wishes to
pursue a particularly cautious approach, he could initially install it on a
'quarantine' computer dedicated to testing new servers, and monitor its
behaviour. Once the administrator is satisfied that the server is "safe",
i.e. does not constitute an unacceptable security risk, he should feel
comfortable about moving it to a 'production' computer and applying to it
the security settings that are appropriate to what the server actually can
do, as opposed to what an unknown, untested piece of software could do in a
worst case scenario.

For example, if the server application does not need to access the host
computer's file system, and does not need to know the identity of users that
launch client program instances, because that is not relevant to the
server's functionality, then why specify user authentication, and restrict
launch and access rights to a list of identified users?

In another situation, the security implemented by the operating system may
not be adequate for the client-server application, and the client and server
applications may need to carry out their own security checks (as is common
in database applications and web applications). It is often the role of the
server, rather than of the oeprating system, to maintain a directory of
registered users and their respective roles. In such a case why encumber the
application with additional security that it doesn't need and is not
particularly relevant?

Finally, what the server can and can't do is also dictated by the server
Launch Identity rights. Can these be set so as to ensure that even if an
untrusted server is launched without client user authentication, there is
very little it can do to damage the system?

Regards,

Enquiring Mind


.

erhaps you are looking for .NET? You can't restrict a
DCOM server as to what it can do at the machine it's
runing on - the server can do anything the account it's
running under is allowed.

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: XXXX@XXXXX.COM
MVP VC FAQ: http://vcfaq.mvps.org
=====================================

"Enquiring Mind" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...