-
A domain controller is a special type of server that DOESN'T CONTAIN any local accounts or local groups.
You would have to put the user in the DOMAIN group for domain.local/Builtin/Remote Desktop Users group
I'm pretty confident [can't recall 100%] that even if they are part of this, they CAN'T log in to a domain controller if they are not a domain administrator
2 found this helpful thumb_up thumb_down -
I suggest not doing this at all. What is the purpose of having a non-privileged user connecting to a DC via RDP? Yes, it can be done, but probably shouldn't.
Even with a domain admin credential, I rarely logon directly to a DC. Remote administration is done via my workstation [via alternate administrative credentials], or a jump station that has the tools loaded.
Was this post helpful? thumb_up thumb_down -
I think Adam is correct that what you're asking is not possible.
What's your end goal here? Maybe it's something that can be done with RSAT and rights delegation?
-
I didn't see a why in your post.
So I'll bite - why does a user need access to a DC of all things?
-
Directly add the new security group to BUILTIN\Remote Desktop Users via ADUC rather than a preference.
-
You also need to allow them "Log on Locally" on the DC, however that is not recommended.
Was this post helpful? thumb_up thumb_down
kevinmhsieh wrote:
I suggest not doing this at all. What is the purpose of having a non-privileged user connecting to a DC via RDP? Yes, it can be done, but probably shouldn't.
Even with a domain admin credential, I rarely logon directly to a DC. Remote administration is done via my workstation [via alternate administrative credentials], or a jump station that has the tools loaded.
Ditto. Why would a user need access to a DC? If he just needs a terminal session spin up a member server if you are using VMs.
Slyldawg wrote:
kevinmhsieh wrote:
I suggest not doing this at all. What is the purpose of having a non-privileged user connecting to a DC via RDP? Yes, it can be done, but probably shouldn't.
Even with a domain admin credential, I rarely logon directly to a DC. Remote administration is done via my workstation [via alternate administrative credentials], or a jump station that has the tools loaded.
Ditto. Why would a user need access to a DC? If he just needs a terminal session spin up a member server if you are using VMs.
Speaking of... unless the user is going to be doing administrative tasks on the DC, this would violate the EULA. Doing non-admin tasks on Windows Server requires RDS licensing.
Was this post helpful? thumb_up thumb_down
the entire question is silly. is this a joke?
are you phishing us to see who bites?
1 found this helpful thumb_up thumb_down
Don't do it.
Was this post helpful? thumb_up thumb_down
just do not do it...
Was this post helpful? thumb_up thumb_down
I mean everyone has essentially said the same thing here - you should never let a non-domain admin have direct access to a DC...apart from any technical issues the security issues it could raise are massive. What is the end goal....maybe if we knew that we could help more.
Was this post helpful? thumb_up thumb_down
I'm just guessing that you would be doing this to allow the user to make changes to user details, for example, HR. You can try creating a customised MMC: //social.technet.microsoft.com/Forums/ie/en-US/2d846b28-24fc-4422-ac69-ff4fac7d7cb4/customized...
Then they would not need to access the server at all.
Joining the choir here. This is totally not best practice and potentially dangerous. What's the need for it if the user is NOT an admin?
NOOOOOOOOOOOO!!!!!!!!!!!!!!!!!!!!! Why?
Without know why, it's a hard to provide a solution. I once had need for a non-admin user to change passwords and add user to groups, we set up delegation for them.
"I want to give an end-user access to the DC".
What could go wrong? /s
Bad bad bad, no no no.
andrewnewell2 any update/info you want to add?
NECRO!
For anyone wondering "why do this?" I have a legitimate [I think] use case involving DPAPI encryption of PoSh credential objects. I have a service account running a script as scheduled task, with bare minimum permissions [not Domain Admin]. Task is running on the DC because it's AD related, and in order to set up the DPAPI encryption you have to create it logged in as the account on the machine it will be decrypted, because DPAPI is not portable.
I had to temporarily grant the service account domain admin in order to RDP in. Adding it to the list of users "allowed to RDP into this computer" and the RDP builtin group were not sufficient.
LanceHarmstrong wrote:
NECRO!
For anyone wondering "why do this?" I have a legitimate [I think] use case involving DPAPI encryption of PoSh credential objects. I have a service account running a script as scheduled task, with bare minimum permissions [not Domain Admin]. Task is running on the DC because it's AD related, and in order to set up the DPAPI encryption you have to create it logged in as the account on the machine it will be decrypted, because DPAPI is not portable.
I had to temporarily grant the service account domain admin in order to RDP in. Adding it to the list of users "allowed to RDP into this computer" and the RDP builtin group were not sufficient.
Sounds more like a case for running the script on a member server and installing the RSAT/PowerShell tools for ADDS.
Was this post helpful? thumb_up thumb_down