If I remember correctly the username and passwords for COM+ apps are held as
secrets in the SAM, only available to the local computer account. This is
same place that the uid/pwd for services are held.

Also, just an idea, use LogonUser & co APIs, but put the component that uses
them in a seperate COM+ app, configured with a local account that has "Act
as part of the OS" privilege.

-----Original Message-----
From: Tahsin Alam [mailto:tahsinalamYAHOO.COM]
Sent: 03 October 2001 21:31
To: DCOMDISCUSS.MICROSOFT.COM
Subject: Re: Using COM+ to control security: architectural issues

1) Yes - the fact that a vbs script running on the local machine can access
the userid and password in plain text is a security hole.
See:
http://msdn.microsoft.com/msdnmag/issues/0700/websecure2/websecure2.asp,
"it's usually safest to use a local account for a server's identity unless
you absolutely need something different. Anyone with administrative access
to the metabase can read this user name and password, so leaving this as a
local account severely restricts the damage that can be done if the machine
is compromised and the password disclosed."
The article is talking about the IWAM user's identity, but I assume it
applies to COM+ App Identity in general because under high isolation, IWAM
user is the App Identity of the ASP engine's COM+ App.
2) Impersonating in ASP:
This was another _big_ disappointment with IIS/COM+/AD security
architecture. All of COM+ role based security is based on the caller's
identity. However, IIS does not provide a native authentication method that
impersonates the user and is usable on the Internet. You can use Basic, but
that's not very secure, requires SSL, and is not very user friendly (users
are much more used to form fields than ugly popups). You can use Integrated
Windows, but that requires IE and hence is not cross browser.
So, we went with Basic Auth/SSL to start with, but now we have switched to
using making raw SSP calls to simulate a logging in of the user. With .NET
forms based authentication, this problem will go away.
The other option was to use "LogonUser", and "ImpersonateLoggedOnUser" API
calls. But that requires the IWAM user to have "Act as part of operating
system" privilege - try to get _that_ past security audit at your client!
tahsin
  "Weiss, Mike" <Mike.WeissPRICESYSTEMS.COM> wrote: What makes the uid/pwd
for the COM+ identity insure? The fact that the COM+
catalog settings for your application is storing that info somewhere locally
on the PC?

How are you impersonating the clients on the PC? IIS authentication (basic?
integrated?)?
Are the clients NT logins on their PCs the same identities as the identity
IIS impersonates for them?

-----Original Message-----
From: Tahsin Alam [mailto:tahsinalamYAHOO.COM]
Sent: Wednesday, October 03, 2001 8:57 AM
To: DCOMDISCUSS.MICROSOFT.COM
Subject: Using COM+ to control security: architectural issues

Hi all:

I am continuing to struggle with coming up with a good application
architecture based on COM+/IIS/Active Directory security, and I keep on
running into architectural shortcomings in COM+ security. Here is my
latest...

I have the following situation:

ASP(impersonating the caller) -----calls-----> [Roles] COM+ Server
Application ("BSL")
------calls-----> [Roles] COM+ Library Application ("BO")

All three logical tiers (BSL=Business Service Layer, BO=Business Objects)
are on the same physical machine. COM+ security is turned on in all
applications. ASP impersonates the logged in user before making any COM+
calls. All users have domain accounts in Active Directory.

The users are in Active Directory groups, and I make the COM+ roles contain
the AD groups. This centralizes user administration.

We would like to enforce some business rules in the business objects based
on the role of the original caller. That means, we need to know the role of
the original caller 2 calls away from ASP, i.e. in the BO.

At first I tried IsCallerInRole in the BO. That didn't work as
"IsCallerInRole" checks only the direct caller and at the BO level, the
direct caller is the identity of the BSL Application.

Then I tried "IsUserInRole(user,role)" passing in the original callers SID
as the "user" parameter. That didn't work till I applied Win2k SP2.

-----> PROBLEM: Then I set the identity of the BSL application to a local
user (it was the interactive user before), and voila - "IsUserInRole"
stopped working! Seems like for IsUserInRole to work, you need the COM+
identity to be a domain user. However, setting the COM+ identity to a domain
user makes the machine quite vulnerable - the userid/pwd is pretty easily
available to any hacker who can hack into the machine and run scripts.
Compromising a domain account is not a good idea.

-----> ARCHITECTURAL ISSUE: So, how do I use COM+ roles and check the roles
across multiple COM+ applications? I can't combine ti all into one large
com+ app for other reasons (easy of sharing the BO's across multiple apps,
deployment ease, etc.).

Has anyone successfully architectected based on COM+ security? What was the
architecture like?

tahsin

---------------------------------
Do You Yahoo!?
Listen to your Yahoo! Mail messages from any phone with Yahoo! by Phone.

----------------------------------------------------------------
Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html .
To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

----------------------------------------------------------------
Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html .
To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

---------------------------------
Do You Yahoo!?
NEW from Yahoo! GeoCities - quick and easy web site hosting, just
$8.95/month. Yahoo! by Phone.

----------------------------------------------------------------
Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html .
To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

THIS E-MAIL CONTAINS INFORMATION WHICH IS CONFIDENTIAL AND
INTENDED FOR THE USE OF THE ADDRESSEE ONLY. IF YOU ARE NOT
THE ADDRESSEE YOU MUST NOT DISCLOSE, DISTRIBUTE OR COPY THIS
TRANSMISSION. UNAUTHORISED RECIPIENTS ARE REQUESTED TO
ADVISE THE SENDER IMMEDIATELY BY TELEPHONE (TELEPHONE NO:
01462 426800) OR E-MAIL OF ANY ERROR OR MISDIRECTION IN
TRANSMISSION.

National Mutual Life Assurance Society
Registered in England at the Priory, Hitchin, Herts, SG5 2DW
Registered No. 48949C. Regulated by the Personal Investment Authority

----------------------------------------------------------------
Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html .
To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]