Re: How to ... 2nd request

From: Glenn LeCheminant (the.only_at_gmail.com)
Date: 10/16/04 

Date: Sat, 16 Oct 2004 02:33:56 -0700

It was painful reading your security requirements.
I had to read it twice to understand what you are after.
There are only 3 ways (that I know of) to restrict what workstations users
and groups may log into.
Paul basically layed it out in his post.

Of the 3 options,
user properties
sec templates for each workstation category,
OUs and GPOs,
I favor OUs and GPOs. Yes it will look ugly and complex to get what you
want. But you will get what you want provided you set it up properly. And
it will be setup for any other desktop managment that may follow.

There are two policies you can set to acheive the desired results.
"Allow logon locally" you could set this up to be inclusive of all groups
that need interactive logon. Don't forget to include administrators and
help desk staff.
Keep in mind applying this policy will overwrite the defaults on the
workstation (so you must include 'administrators' in the policy). Also, the
workstations reads these users and groups as local unless they are prefaced
by domainname\group name.
And yet another caveat to policies under the security node. They are
lingering policies (tattooing). If you unlink it or remove it from the OU,
the workstations will not revert back to their default state.

"Deny logon locally" If you use this one, be sure to include guest (default)
so you don't open up a security hole.

You should not see a performance hit for the workstations on far side of
slow WAN. It only takes a few milisecs for the workstation to identify
where it is and what policies it must apply.
the more policies to apply the longer it takes.

So, move forward, create those OUs and GPOs and get it over with.

Glenn

"Paul Mckenna" <Paul@removeme.arkel.co.uk> wrote in message
news:%23MKz7ZrsEHA.2960@TK2MSFTNGP10.phx.gbl...
> Hi,
>
> I'm not sure if this is what you want.
> But in each OU if select all the users, right click, select properties
click
> account tab you can then select which computers they are allowed to log in
> to.
> Clearly this is going to be a pain setting it up initially but after that
> you can create a template for future users you need to setup.
>
> Other than that I suppose you could create a security template for each
set
> of computers and apply it to them.. I'm not too sure if you have the
option
> to select which users can log in though , I thought it was just who can
log
> in locally.. But I could be wrong. :)
>
>
> "JJ Runnion" <jjrNOSPAM@sinte.edu> wrote in message
> news:e$wCNNrsEHA.2780@TK2MSFTNGP09.phx.gbl...
> >I wonder if i didn't clearly explain the problem last post, so I'm going
to
> >try again. We are looking for the best way to restrict logons to various
> >workstations to specific security groups on our domain.
> >
> > We have several academic and administrative departments and our OU
> > structure basically follows that. However, we also have student labs in
> > many of those OUs, interns, and public access in the library. We need
to
> > restrict logon to computers to only those members of the OUs that should
> > have access to particular machines. I.E.: financial aid computers for
> > only their personnel (staff), open area library computers for public
> > access, lab computers for faculty and students, academic depts. for only
> > those department staff, faculty, interns, etc. One complicating factor
is
> > that in a given department (OU), there may be one or two machines that
> > students must have access to, others that only Faculty should, and yet
> > others that only staff should. In addition, some of the outlying
> > departments have much slower connections than others (and so, I have a
> > certain reluctance to create tiered OUs with multiple GPOs), and some
> > still use win2000 Pro.
> >
> > It has been suggested that we have to use GPOs on the OUs for the
machines
> > and set specific groups to deny (as opposed to allow). Which would mean
> > we will need to break down the OUs into sub OUs for the labs, the intern
> > computers (and sometimes there's only one in an OU that is for interns),
> > etc., etc. This doesn't seem like a very elegant way to do this, so I'm
> > hoping one of you experts can help me if there is a better way, or to
send
> > me to a resource that can delineate one.
> >
> > Your input, advice, and recommendations are appreciated!
> >
> > thanx,
> >
> > jj
> >
> >
> > --
> > jj runnion
> > jjrNOSPAM@sinte.edu
> > (remove NOSPAM to send email to this address)
> >
>
>

Relevant Pages

  • Re: How to ... 2nd request
    ... There are only 3 ways to restrict what workstations users ... There are two policies you can set to acheive the desired results. ... "Allow logon locally" you could set this up to be inclusive of all groups ... And yet another caveat to policies under the security node. ...
    (microsoft.public.windows.server.general)
  • Re: How to ... 2nd request
    ... > OUs and GPOs, ... > There are two policies you can set to acheive the desired results. ... > And yet another caveat to policies under the security node. ... > the workstations will not revert back to their default state. ...
    (microsoft.public.windows.server.general)
  • Re: How to ... 2nd request
    ... > OUs and GPOs, ... > There are two policies you can set to acheive the desired results. ... > And yet another caveat to policies under the security node. ... > the workstations will not revert back to their default state. ...
    (microsoft.public.windows.server.active_directory)
  • RE: Logon access to all PCs but max 1 PC at the time..
    ... to certian systems and make it only one systems. ... Product Support Service Security Team ... Logon access to all PC's but max 1 PC at the time.. ...
    (microsoft.public.win2000.security)
  • Re: Logon Error - Event ID 533
    ... The second is for Workstations, again does not apply in my ... The user cannot logon and no Profile folder is made, ... it causes the system to halt if a security ... or domain account look for the domain or computer name preceding the ...
    (microsoft.public.windowsxp.help_and_support)
Loading