Re: User Login
- From: "Bruce Sanderson" <bsanders@xxxxxxxxxxxxxxxxx>
- Date: Wed, 13 Aug 2008 22:54:05 -0700
First, see my reply to tashi (9:29 PM today).
Next, you don't say exactly what adjustment you made using Security Filtering. For example, if you removed "Authenticated Users" (Allow, Apply Group Policy) and DID NOT add a group that contains computer accounts, then the GPO will not be applied to any computer accounts and thus will not have any affect. The gpresult command (or RSOP) will tell you if you have suppressed the application of the GPO using Security Filtering.
The group "Authenticated Users" includes all computer accounts and the setting in my item #1 is a Computer Configuration setting; thus only applies to computer accounts, not user accounts.
I suggest you try:
1. delete the GPO (rather than attempting to reset the default permissions)
2. create a new GPO and link it to the OU containing the computer accounts for the computers you want to affect (or the entire Domain if you want to - test it first on an OU!)
3. Enable the setting
Computer Configuration
Windows Settings
Security Settings
Local Policies
User Rights Assignment
Deny log on locally (and optionally Deny log on through Terminal Services) and add the group containing the user accounts you don't want to be able to logon
4. DO NOT adjust the permissions (Delegation, Security Filtering) in any way
5. either restart one (or all) of the computer in the OU to which the GPO is linked (or applied to via inheritance) or run the gpudate command on them
I tested this again this evening in a Windows Server 2008 and a Windows Server 2003 R2 domain with both an XP and a Vista client and it works as expected.
---------------------------------------------------------------------------------------------
From reading through this and related newsgroups, I suspect that GPOSecurity Filtering is one of the least understood and over used features relating to GPOs. Remember that you can not force a GPO to be applied using Security Filtering - you can only stop it being applied to users or computers to which it would otherwise be applied.
In most cases, there is no need to adjust the permissions (i.e. use the Security Filtering feature) to create the desired result. If there is an appropriate OU structure (hierarchy), linking the GPO to the appropriate OU is all that is required. Reserve the use of Security Filtering for those rare cases that it there is no other way to achieve the desired objective. The classic case of this is when User Loopback Processing is enabled in a GPO that applies to some computer accounts, and you don't want User Configuration settings (in GPOs applied to the OU with the computer accounts) to be applied to a specific set of users (e.g. administrators of a Terminal Server).
--
Bruce Sanderson
http://members.shaw.ca/bsanders
It is perfectly useless to know the right answer to the wrong question.
"Neil" <Neil@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:CE0A5B5D-14AF-4DED-95D5-D4760B7CA464@xxxxxxxxxxxxxxxx
Hi Bruce,
Thanks for the information, it was very useful and made me understand some
additional concepts. Unfortunately, I did try the steps given below as you
had said, and I removed Domain Users from the local computer group, applied
policy through group policy where only those accounts will be authenticated
to the computers. But, it looks like that it is still allowing the users who
is not supposed to logon to the computer. Not sure anything I am missing. The
only thing I have done is, added this particular group in GPO security
filtering so that only this group gets the deny logon locally privilegs.
Appreciate, further input from your end, but your last input was fantastic.
"Bruce Sanderson" wrote:
For a domain user account to be used to logon at a domain member, that user
account must have the "logon locally" right.
Members of the local Administrators, Power Users and Users groups get this
right automatically.
By default, the domain group called Domain Users is a member of the local
Users group on all computers; this is usually why any domain user can logon
at any domin member computer.
So, to prevent a domain user account from being used to logon at a domain
member you have some choices:
1. put those user accounts into domain group and apply a GPO to the OU
containing the computer accounts that denies the "logon locally" right to
that group
Computer Configuration, Windows Settings, Security Settings, Local
Policies, User Rights Assignment, Deny log on locally - add the group
containing the "email only" user accounts.
2. remove the "email only" user accounts from the Domain User group and any
group that is a member of Domain Users. Note that when a new domain user
account is created, it gets automatically added to the Domain Users group,
so you need remove this group from the Member of list for any "email only"
user accounts created in the future.
3. remove the Domain Users group from the local Users group on the
workstation computers and add a group containing all the user accounts that
should be able to logon locally (essentially all users except the "email
only" user accouts). You can set the membership of local user groups on
domain member computers with a GPO using Restricted Groups (Computer
Configuration, Windows Settings, Security Settings, Restricted Groups).
--
Bruce Sanderson
http://members.shaw.ca/bsanders
It is perfectly useless to know the right answer to the wrong question.
"Neil" <Neil@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:409F25D3-423D-4182-88A1-9791458FB9E9@xxxxxxxxxxxxxxxx
> The accounts are currently disabled, but they will be enabled when they
> link
> it to the Email system. So, the purpose of these accounts that are > enabled
> is
> for email login only (As, I said earlier, we are not using Exchange) > and
> it
> is using its own ldap to sync with AD and the accounts.
>
> Hope this helps!
>
> "Meinolf Weber" wrote:
>
>> Hello Neil,
>>
>> See inline.
>>
>> Best regards
>>
>> Meinolf Weber
>> Disclaimer: This posting is provided "AS IS" with no warranties, and
>> confers
>> no rights.
>> ** Please do NOT email, only reply to Newsgroups
>> ** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm
>>
>> > We have several inactive accounts, and these users use their
>> > departmental login to logon to the domain.
>>
>> Are the accounts disabled or in use? This statement is not clear for >> me.
>>
>> > We plan to activate these
>> > accounts for them to logon to their email (not exchange). So, if we
>> > activate their accounts, they will be able to logon to any computers
>> > which we do not want to and we would like to restrict these group of
>> > users not to logon with their own credentials to the domain or to >> > the
>> > local computer.
>>
>> If you not allow them to logon to the domain, they can not reach the >> mail
>> server of the domain.
>>
>> > Instead only use this for email login purpose. I hope
>> > I am clear in this.
>> >
>> > thanks again for you earlier response.
>> >
>> > "Meinolf Weber" wrote:
>> >
>> >> Hello Neil,
>> >>
>> >> If i got you correct, they should only be aible to logon to the
>> >> domain and not to the local machine without the domain? Create and
>> >> link a GPO to the OU, move the computers there and set:
>> >>
>> >> Computer configuration, windows settings, security settings, local
>> >> policies, security options, in the right pane choose "Interactive
>> >> logon: Number of previous logons to cache" and set it to "0", so it
>> >> is disabled.
>> >>
>> >> Best regards
>> >>
>> >> Meinolf Weber
>> >> Disclaimer: This posting is provided "AS IS" with no warranties, >> >> and
>> >> confers
>> >> no rights.
>> >> ** Please do NOT email, only reply to Newsgroups
>> >> ** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm
>> >>> I am looking to add a set off users in AD to a separate group and
>> >>> want to restrict these users not to logon to computers since they
>> >>> logon with departmental login credentials. How can I go about >> >>> doing
>> >>> it.
>> >>>
>> >>> thanks in advance!
>> >>>
>>
>>
>>
.
- References:
- User Login
- From: Neil
- Re: User Login
- From: Meinolf Weber
- Re: User Login
- From: Neil
- Re: User Login
- From: Meinolf Weber
- Re: User Login
- From: Neil
- Re: User Login
- From: Bruce Sanderson
- Re: User Login
- From: Neil
- User Login
- Prev by Date: Re: User Login
- Next by Date: Re: access rights
- Previous by thread: Re: User Login
- Next by thread: Re: User Login
- Index(es):
Relevant Pages
|