Re: How to ... 2nd request
From: Paul Mckenna (Paul_at_removeme.arkel.co.uk)
Date: 10/16/04
- Next message: Drummer9909: "RE: Novell prevent GPO from execution..."
- Previous message: Torgeir Bakken \(MVP\): "Re: limit to joining computers to domain?"
- In reply to: Glenn LeCheminant: "Re: How to ... 2nd request"
- Next in thread: JJ Runnion: "Re: How to ... 2nd request"
- Reply: JJ Runnion: "Re: How to ... 2nd request"
- Messages sorted by: [ date ] [ thread ]
Date: Sat, 16 Oct 2004 23:48:47 +0100
I appreciate your clarification and views on my answer Glenn. :)
I wasn't actually aware these kind of restrictions could be placed at the OU
level..
I just assumed that any computer with these settings via an OU GPO would
just apply to user accounts setup locally on the PC. (I blame it on just
taking the 070-294 exam where there is a strong emphases on where you can
setup up GPOs to affect password policies)
Thanks again
Regards
Paul Mckenna
"Glenn LeCheminant" <the.only@gmail.com> wrote in message
news:O1b9SN2sEHA.3580@TK2MSFTNGP10.phx.gbl...
> 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)
>> >
>>
>>
>
>
- Next message: Drummer9909: "RE: Novell prevent GPO from execution..."
- Previous message: Torgeir Bakken \(MVP\): "Re: limit to joining computers to domain?"
- In reply to: Glenn LeCheminant: "Re: How to ... 2nd request"
- Next in thread: JJ Runnion: "Re: How to ... 2nd request"
- Reply: JJ Runnion: "Re: How to ... 2nd request"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
