Windows XP, RDC7, Trusted Publishers, and You

Someone asked me for some help yesterday with a problem they were having at work. At their company they use Windows XP workstations, a 2003 Active Directory infrastructure, and *.rdp files that the employees use to establish remote connections to other servers. XP was pretty nice when it came out, but today it's old and just not exciting anymore. Same goes with Server 2003. I mean Windows 7 and 2008 R2 are both several years old by now and definitely proven technologies... but still, upgrading to a modern OS seems to be at the bottom of almost every company's list. Desktop admins around the globe are still puttering about supporting employees on WinXP, and server admins all over the world are still logging on to Server 2003 (or worse!) servers.

With the release of Windows 7 came the new Remote Desktop Client 7, which adds some nice new features, and supports the new and interesting Group Policies that come with a 2008+ Active Directory. One such Group Policy is "Specify SHA1 thumbprints of certificates representing trusted .rdp publishers." Enabling this setting allows you, as the administrator, to specify a list of SHA1 hashes that represent certificates that are from what are considered trusted sources.  When the recipient of this policy launches an *.rdp file, and it's signed by a trusted certificate whose hash is on the list, the user will not get prompted with a warning. When you locate this setting in the (2008 and above) GPO editor, it plainly states that this policy is for "Windows Vista SP1 and above." The thing is, you can install RDC7 on Windows XP.

Here's the rest of the detail on the GPO settings from Technet:

Furthermore, a signed *.rdp file will have these two lines at the end:

signscope:s:Full Address,Server

The problem is that the aforementioned Group Policy setting doesn't exist on 2003 Domain Controllers.

Nevertheless, the effect of the newer 2008 policy should still work since we've installed the new RDC7 client on the Windows XP machines. In theory. We just have to figure out how to deploy it. As it turns out, you can just navigate yourself to this registry key on the client:

HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\PublisherBypassList

In Windows XP the PublisherBypassList key might not exist. Create it! Your SHA1 hashes go there as 32-bit dwords, no spaces, all caps. (This could be done in either HKLM or HKCU. The hashes in HKCU are just added onto the ones loaded from HKLM... just like the description of the GPO setting says.)

So even though you don't have that GPO Setting in Server 2003 like you do in 2008, you can push generic registry modifications such as this out to clients, thereby achieving the same effect.

And it works!

More Pictures with AD: thumbnailPhoto

In this post I showed you how to automatically update the default "user tile" or logon picture in your domain and force everyone to use it via GPO.

Every user account object in Active Directory has a thumbnailPhoto attribute.  This attribute isn't entirely simple to modify.  That may be because Microsoft discourages AD administrators from bloating their Active Directory databases with pictures, but that's just a guess.  By default, users do have the permission to edit this attribute on their own user account.

The thumbnailPhoto attribute isn't shown on a user's Start Menu or on the logon prompt when you try to RDP to a server.  The thumbnailPhoto attribute is only used by certain applications, such as Outlook 2010 or OCS/Lync.  Each new picture that is added to a user account will increase the size of the Active Directory database and will have to be replicated.  So keep your pictures as small as possible.

The dimensions, format and filesize of the picture you want to use are not very strict.  I was able to use both a .bmp and a .jpg with no issues.  Of course in the end I prefer the .jpg because it's much smaller in size.  An easy way to modify this attribute is through Powershell.  The nice thing about this method is that you could do it programmatically through a script, making large batch operations easier.

Import-Module ActiveDirectory
$photo = [byte[]](Get-Content C:\photo.jpg -Encoding byte)
Set-ADUser user -Replace @{thumbnailPhoto=$photo}

You need the Active Directory module for PowerShell, which comes along with the RSAT.  What the script is doing is first converting the .jpg picture into a string of bytes and storing it to a variable, and then replacing the thumbnailPhoto attribute of the specified user's account object with that string of bytes.

Now just let that data replicate and you will soon see your new picture in Outlook, Office Communicator, Sharepoint, etc.!

Thanks to Oddvar for the hint.

Default Account Pictures via Active Directory

Alright, I need to post this so that I have it written down somewhere, because it was a little bit of a pain in the ass to get just right.

Do you administer a modern Windows domain? Are you tired of seeing the sunflower or the mannequin-like brown man as the account logo that appears whenever you log in to a computer? Sure you can customize it locally on your own workstation, but you still see those annoying defaults any time you connect to a remote server or log in to a new PC on which you haven't configured your profile.


Well here is how I've configured my domain so that all users get a new, customized logon logo.  The first thing to consider is you need a new, customized logo.  Maybe it's your company logo.  It needs to be accessible during logon to all users to which you want the new image to apply.

So first, I'll make a new image:

It's probably best to make it a bitmap (*.bmp) and 128x128 pixels.  You might be able to play around a little with those properties, but that's what the sunflower was so I'm playing it safe.

Now since I want everyone to be able to get at this image during logon, I'm going to put it on a network share.  In this case, the network share is a DFS share and namespace that is on both of my domain controllers for high-availability.  Very much like SYSVOL.

That's a lot of information in one screenshot there, but it's just me putting my 128x128 bitmap of my new logon image on a network share; somewhere where everybody in your domain can access it.

Next, it's time for some group policy work.  Log in to one of your domain controllers.  Fire up Group Policy Management Editor.  Now I went ahead and put this in my Default Domain Policy.  But maybe you want to be a little more scrupulous.  You could create an entirely new GPO for this, apply it only to certain users, etc.  But for my little test domain, the Default Domain GPO will be just fine.

The setting you want to edit is User Configuration -> Preferences -> Windows Settings -> Files.  You want to add a new file and make it look like just what I have here:

It's very important that you choose "Replace," as the other options like Create and Update will tempt you, but will ultimately only end in frustration as you wonder why the $@&# it isn't working.  What we're doing here is assigning every user that is affected by this GPO (which is basically everyone in the domain since it is the default domain GPO,) that they grab the source file from the network share, and replace their local %PROGRAMDATA%\Microsoft\User Account Pictures\user.bmp with it.  That is the local default logon picture for Vista and 2k8/R2 versions.  Shame on you if you're running older OSes anyway.

One last piece is that you could edit that GPO to disallow users from changing the logon picture to something else. That setting is at Computer Configuration -> Policies -> Administrative Templates -> Control Panel -> User Accounts -> Apply the default user logon picture to all users.  If you set that to Enabled, regular users will not be able to change the default user account picture that you have now set for them.

It's also worth noting that yes, you can store images in user account objects within the Active Directory database itself.  Each user account object has a thumbnailPhoto, thumbnailLogo, and jpegPhoto attribute in  the AD database.  You can store images here, and they will be replicated along with all the other database data, and as you would imagine, such activity would quickly bloat your database and complicate AD replication.  Also, these attributes are only used by certain applications such as Outlook 2010, Sharepoint, etc.  This will not affect the "user tile" or Windows logon image as we have done here.

(repadmin /syncall on your domain controller to replicate new changes to other DCs.  gpupdate on your workstation to pull the new changes down from the DC.)

Check out that new sexy default logon picture!  It will now show up by default wherever I login in the domain.