Re: User Login

1. the three items in my post are alternatives - you only need to do one of them, not all three of them. So, if you chose item #1, you don't need to remove the user accounts from the Domain Users group. However, you are correct, a user can not be removed from their "Primary Group" although the concept of "Primary Group" is mostly irrelevant (it applies only to Apple "Macintosh clients and POSIX-compliant applications"). Add the user account to another group (e.g. the one for e-mail only users) and designate that as the Primary Group.

2. The setting I'm referring to in item #1 is a Computer Configuration setting, so applying a GPO with this setting to an OU that only has User Accounts in it will have no affect whatsoever. The GPO must be applied to an OU that has Computer Accounts in it to be any use. This is a fundamental concept with GPO processing; see for example http://members.shaw.ca/bsanders/WindowsGeneralWeb/HappyGPOs.htm, section 4 "Group Policies" on the page at http://members.shaw.ca/bsanders/WindowsGeneralWeb/GroupsAccountsPermissionsGPOsRules.htm or the section "Computer and User Configuration" (page 9) in the gpintro.doc available at http://www.microsoft.com/windowsserver2003/techinfo/overview/gpintro.mspx.

If you want to, you can specify the user accounts in the GPO setting (Computer Configuration, Windows Settings, Security Settings, Local Policies, User Rights Assignment Deny log on locally), but I suspect it will be easier in the long run to specify a group name here and put the e-mail only user accounts into that group. Then, as e-mail user accounts (Exchange Mailboxes) come and go, you just have to adjust the group membership and not the GPO itself.Role

Although the setting in the end affects users, it is implemented by the computer; at startup, Windows fetches the GPOs that apply to the computer and stores their settings internal (mostly in the Registry, but some Security Settings are stored elsewhere). Later, when a user logs on, the settings currently in effect (default ones and those adjusted by Computer Settings in applied GPOs) are used, in this case to determine whether a user is permitted to logon or not.

--
Bruce Sanderson
http://members.shaw.ca/bsanders

It is perfectly useless to know the right answer to the wrong question.



"tashi" <asd@xxxxxx> wrote in message news:%23g9SWOF$IHA.4124@xxxxxxxxxxxxxxxxxxxxxxx
Bruce Sanderson schrieb:
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).


I got two questions. Why I have to add the "email only" group to the GPO rights. It`s not enough when the GPO is linked to the OU contains the User Accounts?

And I can`t remove the users from the Domain User Group. It tells me:

The primary group cannot be removed. Set another group as primary if you want to remove this one.

.

Relevant Pages

  • Re: Loopback policy enabled, seems to cause login script to run twice
    ... The scope of the Loopback processing setting is the computers to which the GPO containing it applies to, regardless of which actual GPO it is included in. ... the User Configuration settings from any GPO that applies to the computer are applied ... Sounds like you have included the setting that runs the Logon Script so high in the OU hierarchy that that GPO is in scope for both User accounts and Computer accounts. ...
    (microsoft.public.windows.group_policy)
  • Re: HELP IE connection settings tab
    ... takes precedence if settings are defined at multiple levels - local>site>domain>OU. ... a new GPO for the same user/computer. ... I would leave all users as domain users. ... When you create a Group Policy, by default authenticated users have read and apply ...
    (microsoft.public.win2000.group_policy)
  • Re: User GPO not applying unless linked to computers
    ... > If I create a GPO containing only User settings and link it to the OU ... > containing the user accounts, the GPO does not take effect. ... It sounds like you are trying to deploy security setting to your ...
    (microsoft.public.win2000.group_policy)
  • Re: GPO not picking up computer settings
    ... The user accounts are domain user accounts. ... I have removed the GPO that I ... Domain Policy and the Default Domain Controllers Policy. ... the Default Domain Policy so that the password settings are to not Disable ...
    (microsoft.public.windows.server.security)
  • Re: GPO on TCPIP settings?
    ... By default domain users are not able to change that settings. ... Any local admin will be able to change the settings you did. ... Which GPO settings are for this responsible? ...
    (microsoft.public.windows.server.active_directory)
Loading