Re: I need Ideas on securing a remote Win2k machine

From: Rhynier Myburgh [MSFT] (rhynierm@online.microsoft.com)
Date: 01/31/03 

From: "Rhynier Myburgh [MSFT]" <rhynierm@online.microsoft.com>
Date: Fri, 31 Jan 2003 11:50:05 -0800

OK, so I think I understand what you want and don't know how to solve it.
But, I do have a few suggestions that might help you get your kiosk up and
running.

Firstly, here are the basic concepts that should help you:
    * You can apply user group policy settings on a per machine basis
(loopback processing).
    * You can set security filtering on a group policy object.
    * There are group policy settings to lock down the Start Menu to such an
extent that it is virtually unusable :)
    * You can set a policy to run an application at logon (your kiosk app,
maybe).
    * If all else fails, you can create your own policy to set the registry
key controlling the shell.

Based on this I would suggest the following:
On the kiosk machines:
    1. Remove the "Domain Admins" group as a member of the local
"Administrators" group.
    2. Remember to add your domain account to the local "Administrators"
group. You could also create a special "Kiosk Admins" group in the domain
and rather add it.

In Active Directory:
    1. Create a new Organizational Unit for the kiosk computers and move
them all into that OU.
    4. Create a Group Policy Object linked to this OU and set all the
settings you need to lock down these machines.
      i. You'll have to obviously find the right set of settings that lock
down these machines the way you want.
      ii. You must set "User Configuration" settings on this GPO as we are
trying to apply user settings.
    5. Create another GPO linked to this OU and set the following:
      Computer Configuration\Administrative Templates\System\Group Policy
        "User Group Policy loopback processing mode"
      You can read the description, but what it comes down to is that, for
each machine that this policy applies to, when a user logs in, the group
policy engine will replace or merge the list of GPO's applying to the user
with those applying to the machine. In your case, "Replace" mode should
probably be the one to choose.
      So, what this means is that if user X logs onto one of the kiosk
machines, his normal GPO settings will not apply, but instead, any user side
settings (set under "User Configuration") in the GPO's applying to the
machine will apply to him.
    6. Now, to make sure that you (or the "Kiosk Admins" security group) do
not get these settings, you need to change the ACLs on this GPO so that,
when you log onto a kiosk machine, it will not apply those policies.
      i. Right click on the root node in the Group Policy Object Editor and
click "Properties"
      ii. Go to the "Security" tab.
      iii. Add yourself or the "Kiosk Admins" to the list.
      iv. Change your permissions by checking the "Apply Group Policy" Deny
checkbox.

In short, therefor, you have created a configuration where:
    * A Domain Admin logging onto one of the kiosk machines will only be a
member of Users on the machine ... no administrative priviledges to override
the policies that apply.
    * The kiosk machines use group policy loopback processing to apply a
special set of User Configuration GPO settings to users logging onto those
machines and not their normal GPO settings. In your case these settings are
your special "Kiosk experience" settings.
    * When you log onto one of these machines, these special GPO settings
will not apply to you as you have denied yourself the right to have them
apply. Note that in your case your regular settings will also not apply.

I know that this does not address your problem of restricting who can log
onto these machines, but since everybody except you will have only a kiosk
experience it should not be a problem. There are a few Computer
Configuration policies under Administrative Templates\System\User Profiles
that can be used to manage roaming profiles. Also, you can look under
Computer Configuration\Windows Settings\Security Settings\Local
Policies\User Rights Assignment\Allow log on locally. I have never used this
setting, but from what I understand you can limit the set of users that have
rights to log onto the machine. Some experimentation should reveal what
works and what doesn't.

I hope this helps,
Rhynier 

--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Dirk Gently" <dirknews@nycap.rr_REMOVE_ME.com> wrote in message
news:auej3vs0be922omufo426101fltqm2cddq@4ax.com...
> Hey folks,
>
> I'm trying to put together a type of secure "Kiosk", where remote
> users will be able to run a specific application, and only have access
> to that app.  I would probably setup that application as their shell,
> unless I can find another configureable secure "shell" that will allow
> me to just specify a few apps to run.
>
> Anyway - to the root of my difficulty.  We run in a domain
> environment, and in general - anyone who has an account on that
> domain, can logon to that PC and create a profile.  I want to find a
> way to limit that.  (I personally will be accessing this remote PC via
> PC Anywhere public-key encryption, across our intranet)
>
> I could run the machine as a workstation, not logged into the domain -
> and just remotely administer individual accounts, but I've seen
> recomendations against that, suggesting the domain approach is more
> secure.  (Although it does give domain admins full access to that
> machine, which I also don't really like)
>
> What I'm looking for is ideas on how to control what people can login
> to that machine, so that only domain accounts I "grant" access to, can
> login. I'd also like to entertain ideas on how I can restrict new
> account access to a special shell - while the main admin accounts (me)
> have the normal shell. The investigating I have done has left me with
> few solutions...  gpedit basically would apply to all accounts - and I
> clearly want some accounts to have full access to that machine and
> it's resources.
>
> One thought I had was to replace the default explorer shell, and hence
> all new users created would automatically boot into that program I am
> looking to lock people into.  (And manually set the admin accounts to
> a custom shell - which just happens to be a renamed windows explorer
> shell)
>
> Thanks for reading
>
> Dirk

Relevant Pages

  • Re: GPO Policy wont apply.
    ... The Computer Configuration portion of a Group Policy Object will apply to ... any computer accounts in that OU. ... User Configuration and computer accounts (with the exception of loop back ... nor will any User Configuration settings in a GPO tied to the ...
    (microsoft.public.win2000.active_directory)
  • Re: Group Policy
    ... If you're wondering why the settings get applied to all accounts ... In a workgroup, Local Group Policy is ... >>> administrators. ...
    (microsoft.public.windowsxp.configuration_manage)
  • Re: Group Policy
    ... If you're wondering why the settings get applied to all accounts ... In a workgroup, Local Group Policy is ... >>> administrators. ...
    (microsoft.public.windowsxp.customize)
  • Re: Group Policy
    ... If you're wondering why the settings get applied to all accounts ... In a workgroup, Local Group Policy is ... >>> administrators. ...
    (microsoft.public.windowsxp.help_and_support)
  • RE: Several Problems; how to reset security and troubleshoot serve
    ... On the SBS security settings; I accept your response, ... On the Remote Assistance Issue I have check all of the settings as you ... What started me on the path of security problem was I had a simular problem ... Start the Microsoft Management Console Group Policy snap-in. ...
    (microsoft.public.windows.server.sbs)