From: David on
Ralph:

Have VC++ 6.0.

However, have to disagree. Knowing C++ and manipulating various OS security
settings and other settings are two VERY different things.

Writing code requires a knowledge of the specific language syntax and
learning which API calls are needed to accomplish your objective.

The OS on the otherhand requires you to understand how MS put all this
together and its inter-relationship (what affects what). This is where I
encounter most of my problems, as either to much or too little documentation
(especially if you don't know what to look for to solve the problem).


"Ralph" <nt_consulting64(a)yahoo.com> wrote in message
news:uL0h4NUkKHA.4772(a)TK2MSFTNGP04.phx.gbl...
> Ralph wrote:
>
>> [Now if anyone feels like flaming me for evangelizing VC. Don't
>> botter. I'm guility.]
>
> Or "bother". <g>
>
> -ralph
>
>


From: Nobody on
"Ralph" <nt_consulting64(a)yahoo.com> wrote in message
news:eOH6uJUkKHA.3792(a)TK2MSFTNGP02.phx.gbl...
> David wrote:
>>
>> I'm starting to get outside my confort zone (need to climb the
>> learning curve on DCOM and OS Security)
>>
>> Any good books or suggestions on "easiest" way to learn this?

I can't see David's post quoted above. Must have been lost in cyber space.
Here is Google copy which doesn't include it:

http://groups.google.com/group/microsoft.public.vb.general.discussion/browse_thread/thread/46ebc61070174321/9f935c6a8051524b


From: Nobody on
"David" <dw85745NOT(a)earthlink.net> wrote in message
news:ekr$kvTkKHA.4912(a)TK2MSFTNGP02.phx.gbl...
> OK. Found this which helps:
>
> Article ID: 268550 - Last Review: July 15, 2004 - Revision: 1.2
> How To Use Dcomcnfg for a Visual Basic DCOM Client/Server Application

Basically, in "Security" tab of the component, you disable Remote Launch and
Activation permissions. The users who you see there are allowed to load the
component. The component could start as a different user, and you can do
that by using the "Identity" tab. In this case, Windows starts the component
using the user that you specify, even if that user has higher privileges
than the user who launched it. This can be used in situations where you want
a standard user to do administrative things, for example.

In your place, I would do it the following way:

- Use DCOM tool to disable Remote Launch and Activation for all listed
users. You don't need to change anything in Identity tab.
- Create a special user using the application name as the name of the user.
Lets call this VBUser. This user should have no groups assigned to it.
- Use Windows Explorer to allow this user permissions for Read&Execute to
critical system folders, such as "C:\Windows" and "C:\Program Files". Do not
change the permissions on "Documents and Settings". Windows does that for
you. There are probably other places to add this user to, like in User
Rights Assignment in Local Security Policy, but the simplest solution is to
make this user a member of the Users group.
- Make a Start.exe that calls CreateProcessWithLogonW(). Use
LOGON_WITH_PROFILE flag. However, to save time, you may want to first create
a shortcut to your app, and use the shortcut Advanced button to run your app
as a different user. I think Windows only allows you to use accounts that
don't have blank passwords. If you need to run your app as SYSTEM, you can't
use this method, and instead, create a task in Task Scheduler(time doesn't
matter), specify SYSTEM as the user name and leave the password blank.
Disable the task, then when you want to run it, right click it and select
Run.

The above so far locks the DLL(and your process) from accessing files
outside the folder that you configured. The DLL can still read the contents
of the OS folders above.

The DLL can still access other applications running on the same desktop or
terminal session as the logged on user by sending messages. However, in
Vista+, if the logged on user has higher privileges than VBUser, the
messages are blocked. In XP/2003 Server and below, messages are not blocked
even when using different accounts. The only thing that is blocked between
different accounts in Windows 2000+ are hooks, such as by SetWindowsHookEx.
If you want to block messages in 2000/XP/2003, then you have to use Jobs. In
this case, when calling CreateProcessWithLogonW(), specify CREATE_SUSPENDED
flag, and call CreateJobObject/AssignProcessToJobObject, followed by
ResumeThread(). This works in Vista+ too.



From: Ralph on

"David" <dw85745NOT(a)earthlink.net> wrote in message
news:%23nE8AeUkKHA.5020(a)TK2MSFTNGP02.phx.gbl...
> Ralph:
>
> Have VC++ 6.0.
>
> However, have to disagree. Knowing C++ and manipulating various OS
security
> settings and other settings are two VERY different things.
>

Agree. Programming Languages and Operating Systems are two different things.

> Writing code requires a knowledge of the specific language syntax and
> learning which API calls are needed to accomplish your objective.
>

True.

> The OS on the otherhand requires you to understand how MS put all this
> together and its inter-relationship (what affects what). This is where I
> encounter most of my problems, as either to much or too little
documentation
> (especially if you don't know what to look for to solve the problem).
>

Again. I would agree. Many of the best Admininstrators and System operators
I have known have been lousy programmers if not essentially illiterate
outside scripting languages (and here they tend to be experts). However,
from a Programmers perspective, you will always need to go deeper, and
deeper means C/C++.

You have presented excellent reasons to ignore my advice to learn C/C++.

-ralph


From: David on
Nobody:

Can't thank you enough for all the effort on my behalf.
..
Will take me a day or two to "digest" all the great info provided.
Will repost this thread when done and/or if additional questions.

Have a nice day.
David

"Nobody" <nobody(a)nobody.com> wrote in message
news:eAl9MqVkKHA.1536(a)TK2MSFTNGP06.phx.gbl...
> "David" <dw85745NOT(a)earthlink.net> wrote in message
> news:ekr$kvTkKHA.4912(a)TK2MSFTNGP02.phx.gbl...
>> OK. Found this which helps:
>>
>> Article ID: 268550 - Last Review: July 15, 2004 - Revision: 1.2
>> How To Use Dcomcnfg for a Visual Basic DCOM Client/Server Application
>
> Basically, in "Security" tab of the component, you disable Remote Launch
> and Activation permissions. The users who you see there are allowed to
> load the component. The component could start as a different user, and you
> can do that by using the "Identity" tab. In this case, Windows starts the
> component using the user that you specify, even if that user has higher
> privileges than the user who launched it. This can be used in situations
> where you want a standard user to do administrative things, for example.
>
> In your place, I would do it the following way:
>
> - Use DCOM tool to disable Remote Launch and Activation for all listed
> users. You don't need to change anything in Identity tab.
> - Create a special user using the application name as the name of the
> user. Lets call this VBUser. This user should have no groups assigned to
> it.
> - Use Windows Explorer to allow this user permissions for Read&Execute to
> critical system folders, such as "C:\Windows" and "C:\Program Files". Do
> not change the permissions on "Documents and Settings". Windows does that
> for you. There are probably other places to add this user to, like in User
> Rights Assignment in Local Security Policy, but the simplest solution is
> to make this user a member of the Users group.
> - Make a Start.exe that calls CreateProcessWithLogonW(). Use
> LOGON_WITH_PROFILE flag. However, to save time, you may want to first
> create a shortcut to your app, and use the shortcut Advanced button to run
> your app as a different user. I think Windows only allows you to use
> accounts that don't have blank passwords. If you need to run your app as
> SYSTEM, you can't use this method, and instead, create a task in Task
> Scheduler(time doesn't matter), specify SYSTEM as the user name and leave
> the password blank. Disable the task, then when you want to run it, right
> click it and select Run.
>
> The above so far locks the DLL(and your process) from accessing files
> outside the folder that you configured. The DLL can still read the
> contents of the OS folders above.
>
> The DLL can still access other applications running on the same desktop or
> terminal session as the logged on user by sending messages. However, in
> Vista+, if the logged on user has higher privileges than VBUser, the
> messages are blocked. In XP/2003 Server and below, messages are not
> blocked even when using different accounts. The only thing that is blocked
> between different accounts in Windows 2000+ are hooks, such as by
> SetWindowsHookEx. If you want to block messages in 2000/XP/2003, then you
> have to use Jobs. In this case, when calling CreateProcessWithLogonW(),
> specify CREATE_SUSPENDED flag, and call
> CreateJobObject/AssignProcessToJobObject, followed by ResumeThread(). This
> works in Vista+ too.
>
>
>


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7
Prev: WMI to use or not to use
Next: VB6 on Windows 7 64-Bit