MSTSC on DC Server without admin rights

In addition to the "Remote Desktop Users Group", User2 needs to have the "Allow logon locally" User Right, applied using a GPO linked to the Domain Controllers OU. Don't add the user object, though; create a domain local group "AllowLogonLocallyDC" (or something like that), give this group the "Allow logon locally" User Right, and add the user to this group.
The setting is in

Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\User Rights Assignment.

Select allOpen in new window

i ll agree to oBdA suggestion above, User2 should have allow logon locally permissions applied from Group Policies.

BTW, it you only want to administer the 'server' and not the domain, you can add the user to the Builtin\Administrators group using the ADUC console. This Administrators group will NOT have Domain admin rights but it is the equivalent to a local Administrators group on a member or standalone server.

I have to ask the question, why would you allow anyone but your domain admins to log on to a domain controller. I see no point in doing this. The RSAT features on a remote server/workstation should allow the users to do whatever they need to do.

BTW, it you only want to administer the 'server' and not the domain, you can add the user to the Builtin\Administrators group using the ADUC console.

No. The Active Directory builtin\administrators group is not a group you put someone in to administrator a server. Unless you're talking about member servers, then sure, their local SAM Administrators group is fine. The builtin\administrators account in Active Directory is one of the most powerfull groups there are and should be protected. A snippet from Microsoft.

Administrators: This group has complete control over all domain controllers and all directory content stored in the domain, and it can change the membership of all administrative groups in the domain. It is the most powerful service administrative group.

Putting someone in this group means giving up the keys to the kingdom.

Peter,
sorry, but that is utterly incorrect. A 'local' administrator is a de facto Domain Administrator. He can do whatever he wants on the DCs and in Active Directory. The only thing he doesn't have (yet) is administrative access to domain members, but nothing keeps him from getting this permission as well by adding himself to the Domain Admins group.

PS C:\> Get-ADUser LocalAdmin -Properties memberOf | select -ExpandProperty memberOf | % {$_ -replace ',DC=.*'}
CN=Users,CN=Builtin
CN=Administrators,CN=Builtin
PS C:\> Add-ADPrincipalGroupMembership -Identity LocalAdmin -MemberOf 'Domain Admins'
PS C:\> Get-ADUser LocalAdmin -Properties memberOf | select -ExpandProperty memberOf | % {$_ -replace ',DC=.*'}
CN=Domain Admins,CN=Users
CN=Users,CN=Builtin
CN=Administrators,CN=Builtin

Select allOpen in new window

Hum , looks like you are correct. Best of using the Local Security Policy to give permissions to normal users rather than use these Builtin groups.

Allow Log on locally - allow logon to serve.r
Log on as a batch job - useful for rights to run tasks in Task Scheduler
Log on as a server - useful for rights for some services
Shut down the system - useful for reboot or shutdown system rights

Hello oBdA

I am trying to implement oBdA solution but I do not know where do I find user rights assignement

Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\User Rights Assignment.

Could you be more explicit how to make this change and which utility should I use to give this user Rights ?

THank yo very much

If you have to ask how to implement a GPO, then you should read up on it before continuing: https://www.google.com/search?q=group%20policy%20management
The following should be done in a test AD first until you feel comfortable with group policies.
You start the Group Policy Management Console on the DC, expand Forest/Domains/<your.domain>/Group Policy Objects, edit the "Default Domain Controllers Policy", add the group to the "Allow Logon Locally" User Right in the location I described.
If you want to create your own GPO (which is usually recommended) for this instead of editing the Default Domain Controllers Policy, make sure you add ALL of the accounts found in this setting in the Default Domain Controllers Policy, not only the new group. This setting is not additive when applied by multiple GPOs. When you link it to the Domain Controllers OU, make sure it has a higher priority (lower Link Order) than the Default Domain Controllers Policy).
Default:

• NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS
• BUILTIN\Print Operators
• BUILTIN\Server Operators
• BUILTIN\Account Operators
• BUILTIN\Backup Operators
• BUILTIN\Administrators

I would go at it more along the lines of WHY does that user need to login to the DC? There isn't a lot that you can't do remotely through the RSAT tools and/or powershell.. I'd be looking to give them access to the particular functionality they need, or even creating a constrained powershell remoting endpoint for the user.

Coralon