Re: Running a program with elevated priveleges
From: Nicole Calinoiu (calinoiu)
Date: 04/13/05
- Next message: Nicole Calinoiu: "Re: Getting user ID from Web Service credentials"
- Previous message: Nicole Calinoiu: "Re: Cannot open log for source {0}. You may not have write access. (Access right wanish after a while)"
- In reply to: Valery Pryamikov: "Re: Running a program with elevated priveleges"
- Next in thread: Valery Pryamikov: "Re: Running a program with elevated priveleges"
- Reply: Valery Pryamikov: "Re: Running a program with elevated priveleges"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Wed, 13 Apr 2005 06:52:48 -0400
"Valery Pryamikov" <valery@harper.no> wrote in message
news:%23hwxF%233PFHA.204@TK2MSFTNGP15.phx.gbl...
> "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
> news:%23hyXMW3PFHA.3544@TK2MSFTNGP12.phx.gbl...
>> "Valery Pryamikov" <valery@harper.no> wrote in message
>> news:uXTojt2PFHA.1932@tk2msftngp13.phx.gbl...
>> <snip>
>>> Well, "simply" might be a bit of non-understanding <g>. Being able to
>>> change the password is not the same as being able to read the clear text
>>> password. Think of setting COM+ application to use identity of existing
>>> user... Do I need to say any more?...
>>
>> An admin could do something silly like this with an empty COM+
>> application too. An ignorant admin doesn't need developer help to wreak
>> havoc.
>
> And what's your point? Are we talking here about competencies or about the
> facts?
To be honest, I really don't know anymore. I read your point as suggesting
that the alteration of the identity account for an existing COM+ application
could cause exposure of a human user's password. I don't disagree with
this. However, I do find this to be an unlikely activity, particularly if
the application installer and/or documentation discourages it. If an admin
were to do this, it would presumably be due to ignorance and/or incompetence
but, quite frankly, I would expect such an admin to cause all sorts of other
damage before he got around to messing with COM+ application identities.
> I'm just warning that COM+ and DCOM stores password in unencrypted form in
> LSA secret.
Since you've chosen to ignore the response I gave to this issue as raised in
your first post in this thread, I don't know quite what else to say on the
topic. I still think that it's not really a stumbling block for the
particular scenario proposed by the original poster, and that alternate
approaches offer a less generally acceptable security vs useability
trade-off. If you have a better solution in mind, I'd be happy to hear
about it.
> If I remember it correctly COM+/DCOM LSA secrets are named as
> APPID:{APPID_GUID_HERE}. You can use any version of lsadump for that, or
> you can use my very simple PrintSecret utility that I wrote back in 1997
> (you can find PrintSecret together with its source code on my website -
> just following "Relics from DCOM era" link). It is not like "sky is
> falling".... more over - it is not any problem at all if alternative
> credential of COM+ application are used correctly. And that "correct
> using" first of all means a separate account that is not used for normal
> user login (i.e. has "deny logon interactively" right).
IMO, there's an even more compelling reason for using an
application-specific account: least privilege. Even if the passwords were
not exposed, it would still be preferable to restrict the identity account's
permissions to only the resources that are actually used by the application.
Interactive logon is just one of many privileges such an account would not
need.
> BTW: COM+ applications are used for accessing domain resources much more
> often than you probably think ( looking at your arguments in your prev
> post makes me think that you think that .... :-) ).
Then you've badly misinterpreted my previous comments. I've already stated
that I agree with you that a COM+ application running on a client machine
should not use the identity of a domain user (and for reasons that go beyond
potential password exposure). If it seems that I'm trying to steer the
discussion away from the topic of access to network resources, I am <g>, but
only because I'm trying to stay focused on OP's question, which involves
access to local resources only. IMO, this particular scenario is often
poorly handled (often by granting direct access to the resources in question
to too large a user pool), and I believe that it merits separate
consideration.
> Database connections are one of the most usual examples. And another btw:
> during Windows DNA time it was one of the major advises - to use
> Integrated Windows Authentication on Database Server on the back-end; in
> the middle tier - to run COM+ component with account that has necessary
> access rights to the databases (and databases are usually running on
> separate computers).
While this topic has some potentially interesting meat on its bones, it's
getting further (network resources) and further (accessed from another
server) away from the original question in this thread. Given that I've
promised a sample to OP, I'm going to try to defer any off-topic discussion
until after I've actually delivered on that promise... <g>
- Next message: Nicole Calinoiu: "Re: Getting user ID from Web Service credentials"
- Previous message: Nicole Calinoiu: "Re: Cannot open log for source {0}. You may not have write access. (Access right wanish after a while)"
- In reply to: Valery Pryamikov: "Re: Running a program with elevated priveleges"
- Next in thread: Valery Pryamikov: "Re: Running a program with elevated priveleges"
- Reply: Valery Pryamikov: "Re: Running a program with elevated priveleges"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
