Updating status - REMOTE INTERACTIVE LOGON vs. INTERACTIVE

  • Thread starter Thread starter oldemusicke@gmail.com
  • Start date Start date
O

oldemusicke@gmail.com

Guest
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.
 
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.
 
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 -
 
Back
Top