the ramblings of a crazed IT administrator
Active Directory
How to Restrict Access to Terminal Servers
Feb 3rd
After finally completing my Group Policy re-write for Windows 7 this week I have gone back to working on the plans for our migration to Exchange 2010. Currently we do use an Exchange 2003 server but only a few users are on it and it is only there to provide compatibility for a couple of specialised programs that are on our Terminal Servers. With the move to Exchange for all users possibly the biggest change will be that now all users have a Windows user account potentially allowing them access to the Terminal Servers when they shouldn’t have any.
In order to do this you could make use of the builtin group called ‘Remote Desktop Users’ which aslong as your using Windows 2003 R2 should have been setup when you installed the Terminal Servers role and by default has permission to connect remotely to any Terminal Server.
It is also possible to customise which users and groups can connect remotely to a Terminal Server so you make your life easier and reuse existing groups to control access, or setup multiple groups if you wanted to limit certain users from connecting to particular Terminal Servers. To do this you can either edit the Local Security Policy on each Terminal Server or apply the changes via Group Policy, the option you are looking for to set this via Group Policy can be seen below (the Local Policy method is also very similar to this and should be easy enough to find):
Enable the 'Allow log on through Remote Desktop Services' Option
Inside this you can add all the users and groups who should have remote access.
While this may seem like all that is needed and while all the users and groups specified can now logon to the Terminal Servers you apply this to you will likely also find that infact *any* user can still login to the Terminal Servers. To correct this we need to make one final change as by default anyone in the Users group can access the server due to the ‘Allow log on locally option’.
Remove the Users group from the 'Allow log on locally' option
While you might be concerned about the warnings given in the ‘Explain this’ tab advising you to not remove users, if you read the relevant section on the link provided it explains that it is safe to do this aslong as you dont remove important users from the list and aslong as users who should have access are granted permission to do so elsewhere.
Hopefully if this has all worked you now have a Terminal Services environment where only those users explicitly allowed can gain access.
How to check if you are editing GPO’s using a local, or central store
Jan 27th
After my previous posts about preparing to build a new Group Policy for Windows 7 and about setting up the Central Store it occurred to me that it may be useful to actually check that when we edit the GPO that we are actually using the admx files from our Central Store rather than those stored locally. This may not seem important until you think that Windows Vista, Server 2008, Windows 7 and Windows Server 2008 R2 all ship with different versions of the ADMX files so you want to avoid a situation where you are building your GPO and dont realise that you are missing potentially useful options.
Thankfully it is very simple to see if you are using the ADMX files from your Central Store or not:
This shows the ADMX files are being loaded locally
This shows the ADMX files being loaded from the Central Store
Setting up a basic test lab using VMware
Jan 26th
One of my favourite features in VMware Workstation that I have found recently is the ability to create a ‘team’ of virtual machines. What this does is allow you to have one or more virtual machines running on a virtual LAN, essentially allowing you to setup a private test network where you for example run test domain controllers or any network application and as long as you have the network setup correctly there is no way for anything to ‘leak’ out onto your production network.
Ive been using this to run a simple test network with two virtual machines to help develop and test a new Group Policy for our Windows 7 deployment later this year. In one virtual machine I have Windows Server 2003 running as a Domain Controller and as a Router/DHCP Server (this VM effectively becomes our virtual LAN’s gateway for internet access and so needs two network interfaces – one to connect to hosts network and gain internet access and the other to connect to the internal virtual LAN), and in the other I have Windows 7 setup as a member of the test domain.
Once you have your virtual machines ready to go we are ready to create our Team and add the virtual machines to it. In VMware go to File -> New -> Team to launch the New Team Wizard. Give the Team a name and decide where you want to store the configuration file then add the virtual machines you want in the Team (you can always add and remove virtual machines to and from Team at any point). Next you need to add at least one LAN Segment, this is basically the virtual LAN that will connect our Domain Controller to our Windows 7 virtual machine (any any other VM’s you add), you can have multiple segments, all with different network speeds if you want to simulate a larger, multi-site network but for our simple lab it is easiest to just use one segment. Finally you need to which network adaptor connects to which network (virtual or otherwise), this can be a confusing if you are not used to networking and VMware so here is a screenshot of my configuration that you can use as a base.
My VMware Team Network Configuration
The important thing here is to make sure that one network adaptor of the Domain Controller is on the Virtual LAN with the Windows 7 VM (and that if you have already run the network setup wizard after installing the network router/DHCP roles on the Domain Controller you make sure you select the correct adaptor – dont worry, it can always be changed if you get it wrong). Also, assuming you want all the machines in your Team to be able to access the internet then you will need to map the Internet facing adaptor on your Domain Controller to the host machines network, my recommendation is to use NAT here to ensure your Virtual Network remains isolated although aslong as you are careful when you configure the Domain Controller’s routing you can use Bridged networking.
And there we go, you should now have a simple, but very useful Virtual lab environment that you can use like me to test new Group Policy options, or really anything (ive been running the new Sharepoint 2010 beta in another test network), you can even extend the lab with additional LAN Segments to represent remote sites (with simulated packet loss too if you want), the Team options give you a lot of options if you want to expand your lab, the only limitation is how fast your computer is!
How to Create and Edit Group Policy for Vista/Windows 7 PC’s
Jan 25th
Ive spent the better part of the last week or so documenting our existing Group Policy and getting a test environment ready so I can develop and test a new policy for Vista and Windows 7 (well, most likely just Windows 7 as I cant see us ever touching Vista again!). One problem I’ve hit so far is there is no easy guide that explains how to get everything setup, just different guides all pointing to different files (at one point I think I was downloading 3 different versions of the same file because different Microsoft guides said to use different versions).
So, heres what you need to manage GPO’s for Windows 7:
- Windows 7 – Even if all your Domain Controllers are Windows 2003 you can only create/edit Windows 7 GPO’s from a Windows 7/Vista/2008 R2 host. My recommendation is to use a virtual machine for this, if you dont want to buy a license yet you can use the trial version of Windows 7 for 90 days.
- Download and install the Windows 7 Remote System Administrators Tools pack (This will only work for Windows 7, if you are using Windows Vista or 2008 to manage your GPO’s you will need to corresponding RSAT pack).
- By default the Group Policy Management Console isnt enabled so we need to enable it in the Control Panel. Go to Control Panel -> Programs and Features -> Turn Windows features on or off -> Remote Server Administration Tools -> Feature Administration Tools -> Enable Group Policy Management Tools.
- Now we can see all the shiny new Group Policy options that have been added for Windows 7 but we need to make it so that when we create a policy all the other computers that use it make use of the same source admx files, currently GPMC is only looking at the admx files installed locally. To change this we need to copy all our admx and adml files onto a Domain Controller (which will then sync them to all the other DC’s in your network).
- Copy the PolicyDefinitions folder that is in the Windows folder on your Windows 7 PC to your Domain Controller’s sysvol folder, this is normally \\<domain controller>\sysvol\<your domain name>\Policies
There we go, you should now be able to use this Windows 7 PC to create and manage your Group Policy for all Vista/Win7/Win 2008 machines even if your domain controllers all run Windows 2003. Dont forget though, even though you can see these Windows 7 policies in GPMC on Windows 2003, if you edit them there you risk corrupting them and causing yourself a big headache! Only edit Windows 7 GPO’s from a computer running Windows Vista, 7, 2008 or 2008 R2!
