Updating status - REMOTE INTERACTIVE LOGON vs. INTERACTIVE

[Guest oldemusicke@gmail.com]

XP sp2 assigns you to the special groups REMOTE INTERACTIVE LOGON or

INTERACTIVE (etc.) only at logon. Is there any way to get Remote

Desktop or a session unlock to update this group assignment?

 

Situation 1: You log in at the console. As expected, you're now part

of the special INTERACTIVE group. You lock the session (ctrl-alt-del,

Lock Workstation). Later, you connect via Remote Desktop. This gives

you the existing session. Even though you're now in a remote session,

you're still part of INTERACTIVE, and not part of REMOTE INTERACTIVE

LOGON (confirmed by whoami /groups).

 

Situation 2: The console isn't logged in. You start a Remote Desktop

session. As expected, you're now part of the special REMOTE

INTERACTIVE LOGON. Next, you disconnect (as opposed to logging out).

Later, you visit the console and unlock the session. Even though

you're now logged in at the console, you're still in REMOTE

INTERACTIVE LOGON, but not INTERACTIVE (confirmed by whoami /groups).

 

If Remote Desktop Connection or the session unlock would re-assess

membership in these special groups, it would move you between

INTERACTIVE and REMOTE INTERACTIVE LOGON as appropriate, but

apparently this assessment happens only once at logon.

 

Goal: Allow non-admin users to use Remote Desktop Connection, but make

certain resources accessible only at the console, not over a remote

connection. An ACL entry denying all access to REMOTE INTERACTIVE

LOGON seemed like the way to go, until we discovered that it reflected

conditions of the initial logon, not conditions at the moment.

 

Session timeouts don't really solve the problem, by the way. One,

they'd shrink the window of opportunity but otherwise wouldn't solve

the problem. Two, any arbitrary ending of sessions affects the people

who are working normally too (in INTERACTIVE when they're really

interactive, and in REMOTE INTERACTIVE LOGON when they're really a

remote interactive logon).

 

Thanks.

[Guest TP]

Re: Updating status - REMOTE INTERACTIVE LOGON vs. INTERACTIVE

 

There is no built-in way to have XP automatically update

the user's security token because of a session state change.

I imagine you could program something yourself but it would

be non-trivial.

 

What specific resources/objects are you attempting to secure

based on console versus RDP? Perhaps I can think of another

way to accomplish your goal.

 

-TP

 

oldemusicke@gmail.com wrote:

> XP sp2 assigns you to the special groups REMOTE INTERACTIVE LOGON or

> INTERACTIVE (etc.) only at logon. Is there any way to get Remote

> Desktop or a session unlock to update this group assignment?

>

> Situation 1: You log in at the console. As expected, you're now part

> of the special INTERACTIVE group. You lock the session (ctrl-alt-del,

> Lock Workstation). Later, you connect via Remote Desktop. This gives

> you the existing session. Even though you're now in a remote session,

> you're still part of INTERACTIVE, and not part of REMOTE INTERACTIVE

> LOGON (confirmed by whoami /groups).

>

> Situation 2: The console isn't logged in. You start a Remote Desktop

> session. As expected, you're now part of the special REMOTE

> INTERACTIVE LOGON. Next, you disconnect (as opposed to logging out).

> Later, you visit the console and unlock the session. Even though

> you're now logged in at the console, you're still in REMOTE

> INTERACTIVE LOGON, but not INTERACTIVE (confirmed by whoami /groups).

>

> If Remote Desktop Connection or the session unlock would re-assess

> membership in these special groups, it would move you between

> INTERACTIVE and REMOTE INTERACTIVE LOGON as appropriate, but

> apparently this assessment happens only once at logon.

>

> Goal: Allow non-admin users to use Remote Desktop Connection, but make

> certain resources accessible only at the console, not over a remote

> connection. An ACL entry denying all access to REMOTE INTERACTIVE

> LOGON seemed like the way to go, until we discovered that it reflected

> conditions of the initial logon, not conditions at the moment.

>

> Session timeouts don't really solve the problem, by the way. One,

> they'd shrink the window of opportunity but otherwise wouldn't solve

> the problem. Two, any arbitrary ending of sessions affects the people

> who are working normally too (in INTERACTIVE when they're really

> interactive, and in REMOTE INTERACTIVE LOGON when they're really a

> remote interactive logon).

>

> Thanks.

[Guest oldemusicke@gmail.com]

Re: Updating status - REMOTE INTERACTIVE LOGON vs. INTERACTIVE

 

The other catch with programming something ourselves is that it

probably needs to be privileged, which means it'll probably have to

run as a service (vs. an app executed by a non-privileged user).

Kernel-touching apps are also the apps most likely to break each time

you update Windows.

 

We want to secure the full contents of a particular local drive

against remote access. The intended approach had been to add to the

ACL for the root folder of that volume with a Deny for REMOTE

INTERACTIVE LOGON.

 

One workaround we'd rather avoid is to give each person two usernames,

one that's a member of Remote Desktop Users but that has no access to

the restricted drive (denied by ACL), and one that has access to the

restricted drive but isn't in Remote Desktop Users. We want to avoid

that approach because it requires users to remember two passwords

instead of one, to switch personas each time they change what they're

working on, etc.

 

We want to keep the user hassles to a minimum because the bigger the

hassle, the more likely it is that users will bypass the security

setup for the sake of convenience. They're basically trusted

individuals, but people are still people. We want the right thing to

be easier to do than the wrong thing.

 

On Sep 24, 1:50 pm, "TP" <tperson.knowsp...@mailandnews.com> wrote:

> There is no built-in way to have XP automatically update

> the user's security token because of a session state change.

> I imagine you could program something yourself but it would

> be non-trivial.

>

> What specific resources/objects are you attempting to secure

> based on console versus RDP? Perhaps I can think of another

> way to accomplish your goal.

>

> -TP

>

>

>

> oldemusi...@gmail.com wrote:

> > XP sp2 assigns you to the special groups REMOTE INTERACTIVE LOGON or

> > INTERACTIVE (etc.) only at logon. Is there any way to get Remote

> > Desktop or a session unlock to update this group assignment?

>

> > Situation 1: You log in at the console. As expected, you're now part

> > of the special INTERACTIVE group. You lock the session (ctrl-alt-del,

> > Lock Workstation). Later, you connect via Remote Desktop. This gives

> > you the existing session. Even though you're now in a remote session,

> > you're still part of INTERACTIVE, and not part of REMOTE INTERACTIVE

> > LOGON (confirmed by whoami /groups).

>

> > Situation 2: The console isn't logged in. You start a Remote Desktop

> > session. As expected, you're now part of the special REMOTE

> > INTERACTIVE LOGON. Next, you disconnect (as opposed to logging out).

> > Later, you visit the console and unlock the session. Even though

> > you're now logged in at the console, you're still in REMOTE

> > INTERACTIVE LOGON, but not INTERACTIVE (confirmed by whoami /groups).

>

> > If Remote Desktop Connection or the session unlock would re-assess

> > membership in these special groups, it would move you between

> > INTERACTIVE and REMOTE INTERACTIVE LOGON as appropriate, but

> > apparently this assessment happens only once at logon.

>

> > Goal: Allow non-admin users to use Remote Desktop Connection, but make

> > certain resources accessible only at the console, not over a remote

> > connection. An ACL entry denying all access to REMOTE INTERACTIVE

> > LOGON seemed like the way to go, until we discovered that it reflected

> > conditions of the initial logon, not conditions at the moment.

>

> > Session timeouts don't really solve the problem, by the way. One,

> > they'd shrink the window of opportunity but otherwise wouldn't solve

> > the problem. Two, any arbitrary ending of sessions affects the people

> > who are working normally too (in INTERACTIVE when they're really

> > interactive, and in REMOTE INTERACTIVE LOGON when they're really a

> > remote interactive logon).

>

> > Thanks.- Hide quoted text -

>

> - Show quoted text -