Best practices say that you should avoid using an Administrator account.
This creates a problem whereby administrators invariably logon to a domain controller using a domain admin account because their ‘ordinary’ account does not have the necessary rights to log on locally to a server.
This article explains how to allow those non-admin user accounts assigned to administrators for everyday use, to connect to a domain controller, helping to enforce the ‘least privilege’ philosophy by encouraging administrators to use elevated accounts only when they need to.
We also manage servers on our internal network using Remote Desktop. Again, by default ordinary non-admin accounts do not have the necessary rights to access a domain controller using RDP.
We operate a two account system for our domain administrators.
One account has minimal privileges and is a non-admin account; the other has admin privileges.
The admin accounts are created without any ‘bells and whistles’. They are members of a minimal number of groups and are not mail-enabled, nor do they have roaming profiles. Folders such as My Documents are not redirected. The idea is to create an environment where they can use their everyday accounts most of the time, and only use elevated accounts when necessary.
Using Group Policy combined with security group membership we have implemented a system where administrators can log on to a domain controller (either locally or via Remote Desktop) using their everyday account and then elevate to their admin account when performing specific administrative tasks, such as creating an account or modifying group membership.
Our OU Structure
In AD, we have created the following OUs:
Admins OU – This is where we create the accounts which are members of the Domain Admins group.
This allows us to manage them and easily exclude them from other GPOs, for example, one which locks down the desktops for non-admin company employees and disables access to regedit, etc.
People OU – This is where we create non-admin user accounts.
Groups OU – This is where we create groups
In the Admins OU, create a user account and make it a member of the Domain Admins group.
Follow your naming convention, but append _admin to the user logon name. For example, if the naming convention is <First Initial><Surname>, for John Smith create an account called jsmith_admin.
In the People OU, follow your naming convention to create a non-admin user account if you do not have one. For example, if the naming convention is <First Initial><Surname>, for John Smith create an account called jsmith.
In the Groups OU, Create a Global Security Group called DC-LogonLocally.
Creating The GPO
On your Domain Controller, Open Group Policy Management. Expand the Forest node, the Domains node, your Domain node and right click Group Policy Objects and click New. Give the policy a meaningful name. In this example, we’ll use DC-LogonLocally.
Under Group Policy Objects node, right click DC-LogonLocally and Edit.
Expand the following:
Computer Configuration > Policies > Windows Settings > Security Settings >Local Policies >User Rights Assignment > Allow log on locally.
Open Allow log on locally, tick Define these policy settings: and add the following groups:
Administrators
<YourDomain>\DC-LogonLocally
<YourDomain>\Domain Admins
Click OK
Next, expand the following:
Computer Configuration > Policies > Windows Settings > Security Settings >Local Policies >User Rights Assignment > Allow log on through Remote Desktop Services
Open Allow log on through Remote Desktop Services, tick Define these policy settings: and add the following groups:
Administrators
<YourDomain>\Administrator
<YourDomain>\DC-LogonLocally
<YourDomain>\Domain Admins
Click Ok
Next, expand the following:
Computer Configuration > Policies > Windows Settings > Security Settings > Restricted Groups.
Right click Restricted Groups > Add Group… >Browse.
Type the name of the security group Remote Desktop Users, click Check Names, and then OK and OK again to add the group. In the Remote Desktop Users Properties, click Add.. (the top button) to add Members of this group.
In the Add Member box, click Browse… and type the name of the security group <YourDomain>\DC-LogonLocally, click Check Names, and then OK to add the group. In the Add Member box, click OK and then Apply before clicking OK.
The Restricted Groups node should display Remote Desktop Users in the Group Name column and <YourDomain>\DC-LogonLocally in the Members column.
Next, expand the following:
Computer Configuration -> Policies -> Administrative Templates > Network > Network Connections > Windows Firewall > Domain Profile > Windows Firewall: Allow inbound remote administration exception. Click The Enabled button and in the Options under Allow unsolicited incoming messages from these IP addresses: add your subnet to the above entry, ie 192.168.1.0/24.
Click OK
Close the Group Policy Management Editor.
Click DC-LogonLocally . Click the Scope tab.
Then do the following:
Security Filtering > Add… > Object Types… > tick Computers > OK . Under Enter the Object name to select:, type the names of the Domain Controllers to which you want this policy to apply, separating each server with a semi-colon. Click Check Names, and then OK.
Find the Domain Controllers node > right click > Link an Existing GPO… > Under Group Policy objects: select DC-LogonLocally and click OK.
Now in the Scope tab of the policy, under Location, the Domain Controllers OU should be listed. In the Security Filtering section, the Domain Controller computers should be listed.
Click Authenticated Users and click Remove
In Active Directory Users and Computers, add the non-admin accounts of the administrators to the DC-LogonLocally group.
Refresh the group policy on the domain controller(s).
Gpupdate /target:computer /force.
Launch an RDP session and connect to the DC.
Supply the credentials of a non-admin account which is a member of the DC-LogonLocally group.
You should be able to connect and see a desktop.
Now, if you wish you can start Active Directory Users and Computers and supply your admin credentials to use the elevated privileges.
Some reasons when this does not work so well
Mostly, problems arise when you have to save something. For example, if you export the contents of an OU to My Documents, it will be the elevated admin account’s My Documents by default. Similarly, the behaviour is the same when you’re working with the Security and Analysis tools.
About RDP
Some organisations allow RDP connections directly across the Internet. For Domain Controllers, we do not (We use other tools for remote administration, or connect via VPN). Please bear this is mind when setting the Allow inbound remote administration policy and restricting it to your local network. I haven’t tested it by trying to connect from outside of my own LAN.
miketois 