Old question but I think it could use a more detailed treatment.
By the way the question is worded and the situation described, it sounds like the OP is modifying the Default Domain Policy. This policy applies to the entire domain across the board. It's best practice to limit modifications to this policy to Default Domain Security Policy Settings:
- Password Policy
- Domain Account Lockout Policy
- Domain Kerberos Policy
The best solution to the problem, then, is to create a new Group Policy Object that defines the settings you need to apply; in this case User Rights Assignment. In Group Policy Management, create a new GPO, name it appropriately, then edit it to add the User Rights Assignment settings you need.
Group Policies apply to Organizational Units in Active Directory (also to sites in AD Sites and Services, but that's not what we're talking about today). You should create a new OU in Active Directory Users and Computers. Name it appropriately and make sure it fits within the logical structure you've outlined for your organization, and then move all of the objects into this container that need the policy settings you're defining applied to it. In this case, move your member servers into this OU.
Then in Group Policy Management, link the new Group Policy Object to the new OU. Computer settings in the GPO will apply to computers within this OU.
A common practice in AD OU structure is to organize OUs into a "tree" format that allows policies to be inherited further down the tree. For example, you might create a "Computers" organizational unit, and beneath that create two more OUs named "Workstations" and "Member Servers". This allows you to create a single policy that applies to all computers at the Computers OU, while separating workstation policies from server policies. How you define your OU structure will depend largely upon the needs of your organization and the policies you define.
The specific User Rights Assignment settings that allow or deny a user access to log on to a computer are Allow log on locally and Deny log on locally respectively. Modifying these settings incorrectly can break stuff. Note that defining Allow log on locally overwrites the default settings, effectively denying access to any account or group not explicitly defined in this setting. Note also that Deny log on locally supercedes Allow log on locally if there's a conflict (e.g. if an account is defined in both settings, access will be denied).
Please note Microsoft's warnings on modifying the Allow log on locally and Deny log on locally Group Policy settings:
