0 comments

The Case Of The Remote Desktop Users Group’s Evil Twin

Published on Friday, September 17, 2010 in ,

Today I got an issue which got me pretty frustrated. I’m definitely not going to admit how long it took me to get this one solved. Some background information: in the project I’m currently participating in we have several lab environments. One for the Exchange guys, one for the SCCM boys and one for AD/FIM/SCOM. Besides that we got also an acceptance environment before we hit production with our stuff. One thing off having multiple environments is you have to keep them in sync. One of the things to sync is the GPO’s. Yesterday we did a refresh in our acceptance environment by deleting all policies over there and running our PowerShell script which creates, links and imports the settings.

The consequence: today they asked me if something had been changed, remote desktop to the virtual Windows 7 clients no longer seemed to work. Euh, changed? anything? Oh, we might have done something to the GPO’s, but would that be related? Of course it was :) Here is a screenshot of what we were seeing (The connection was denied because the user account is not authorized for remote login):

clip_image002

Fixing remote desktop, now that would be a quicky:

  1. Is the remote desktop enabled? yes
  2. Is the firewall allowing remote desktop? yes
  3. Is the user trying to use RDP member of the Remote Desktop Users? yes (at least Domain Users are, so …)

So all seemed fine. But I didn’t start to despair, I verified

  1. The GPO which adds the “Domain Users” to the Remote Desktop Users
  2. RSOP.msc
  3. Secpol.ms
  4. GPresult /R
  5. Rebooted
  6. Rejoined the client to the domain

And then, 5 minutes before I had to leave for my train, I finally saw it:

image

image

Notice anything funny? The Remote Desktop Users Group has gotten an evil twin brother! Now this makes our GPO look suspicious. Especially with the “Built-in” which is in the group name, that’s not supposed to be there… So off to our group policy preference which configures this. I simply deleted the entry and recreated it. Now the proper group was being updated…

This is how we transfer GPO’s: we first take a backup of all GPO’s in the source domain using the GPMC, and then we use the following PowerShell cmdlets, an example:

import-gpo -backupgponame "GPO_C_Workstation Settings_v1.0" -targetname "GPO_C_Workstation Settings_v1.0" -path "$rundir" -createifneeded
$gpoName = "GPO_C_Workstation Settings_v1.0"
new-gplink -name "$gpoName" -target "ou=computers,$departmentDN" | set-gplink -order 1

What was happening is that when using the import-gpo cmdlet, it used the “Remote Desktop Users (built-in)” as a string for a new group, in stead of detecting it as a well known group. Because the description was not set using GPO, my attention never got drawn to the original “Remote Desktop Users” group…

Related Posts

No Response to "The Case Of The Remote Desktop Users Group’s Evil Twin"

Add Your Comment