Checking the logs on the Client Access server pointed me to look at permissions and it seems like some accounts have disabled the inherited security rights. This is the problem since Exchange can’t access the account information.

To check this you use Active Directory Users and Computers and open the user in question. Open the Security tab and press Advanced. On the open window you should se the “Include inheritable permissions from this object’s parent”. If it’s not selected your Active sync will fail.

Hope this shortens someone’s troubleshooting session.

• Windows Server 2008 Enterprise running HEL-DC1
  • AD DS
  • DHCP
  • DNS
  • AD CS ( Certificate Services Enterprise CA)
• Windows Server 2008 Enterprise running HEL-NAT
  • 2 network interfaces – External and internal
• Windows Vista Business Edition
  • Service Pack 2

If you don’t have access to Microsoft Volume Licensing, a Technet Subscription or a MSDN Subscription you can download the trial versions of the systems above, they are free and you can use them for 180 days. So you’ll have more than enough time to complete this lab. Our setup will look as figure 1 shows.

Figure 1

As you can see we are using private IP:s only and we have not deployed a DNS server on our private little internet because the easier way in a small lab like this is to use the Windows host file.

The ip addresses assigned are as follows,

• hel-dc1 192.168.0.1/24
• hel-cli1 10.0.0.150/8
• vpngw
• Internal Network 192.168.0.254/24
• External Network 10.0.0.1/8

All machines are part of the domain. So before you move the hel-cli1 “laptop” out of the 192.168.0.0 network remember it has to be joined to the domain.

Setting up the VPN Gateway Server

So I’m depending on you to have a working Active Directory from this point on and the Domain Controller should have the Active Directory Certificate Services installed and it should be a Enterprise Certification Authority not a Standalone. Well then, let’s move on.

First of all we need to install the correct roles on our VPN Gateway server. So start up your Server Manager and select Add Roles.

Install Webb server role

To get SSTP-VPN working we need the Web server role. And we will use the IIS management console to get a certificate from the Enterprise Certification Authority (HEL-DC1 in my case). In server manager click Web Server (IIS) and add the required features.

When done select next next.

Role Services

For some reason we need to select every role service under security to be enable to get a certificate from the Enterprise CA. So select every role service under Security.

That’s it. Select next and at the Confirm Installation Selections click install and sit back and relax for a minute. Maybe even grab a cup of coffee if your system is slow enough .

Getting the web server certificate from the Enterprise CA

Next we need to get a certificate to encrypt our sessions and to identify the server. So we want the certificate name to be the same as the external DNS name of the server. In my case it’s the same as the internal DNS name. Open the Server manager again and go to Roles, Web Server, Internet Information Services Manager. Select the server name, VPNGW and select Server Certificates. In the right side Action Pane select  Create Domain Certificate. The most important field is the Common name, this is the field that identifies the server to the clients accessing it from the outside. So be sure to set the Common name to whatever your external server name is. In this case, vpngw.nixadmins.net. As I said in the beginning I’m running this in Virtual PC so I’ll use the host file to set it on the client but in a real world case this is important. Nagged enough? Ok, let’s move on.

After  clicking next you are presented with a dialog to select your Online certification Authority. Since we have our AD CS ( Active Directory Certificate Services ) running on our domain controller we just hit select and pick our Enterprise CA, the HEL-DC1.

Set the friendly name to something descriptive like SSTP Certificate since that’s what we will be using it for. Click finish and you should se the certificate in the list of server certificates.

Setting up Routing and Remote Access

The server also needs to be able to route the requests from the external to the internal network so we need the Routing and Remote Access role. In my case it also works as a router for the internal clients so they can access the external networks. Once again in Server Manager select add role and select Network Policy and Access Services.

Click next until Role Services. We won’t be using NAP quite yet, maybe in a later post if there is an demand for it, so just select the Routing and Remote Access Services.

Confirm the installation and sit back and wait.

Configuring Routing and Remote Access

We now need to activate the Routing and Remote access. In Server manger roles you’ll find the Network Policy and Access, Routing and Remote Access. As you can se it hasn’t yet been activated.

Right click Routing and Remote Access and select Configure and Enable Routing and Remote Access. I’m using this server for NAT so the internal clients use it as a gateway so I need to select Virtual Private Network (VPN) access and NAT. Click next and select your external network interface.

Set the IP Address Assignment to Automatically. This way it will use the internal DHCP server to relay the addresses.

Select No, use Routing and Remote Access to authenticate connection requests on the next page.

Finish the setup and wait for it to complete.

That’s it. Once the wizard is done you have Remote Access setup. Tomorrow we’ll go trough how to allow the client to access the network using our new SSTP VPNGW and we will set up our Windows Vista client to connect to our corporate network. Until then, I’ll answer your questions and if you have any requests on special subjects don’t be afraid to ask, I’ll do my best to create them. Se you tomorrow.

As an example, let’s say you have a helpdesk working in your company. For them to work as efficiently as possible they might need to login as Administrators to a client computer to fix various problems. Sometimes (read most times) you don’t want your helpdesk having Domain level Administrative rights because they might, even unknowingly, mess something up in your production domain. To deal with this we use Restricted groups. Restricted groups are provided by Active Directory group policies, they provide us a way to centrally drop in certain Active directory groups to computers local groups, yes computer local groups. They don’t have to administrative groups, they might be anything from backup users to Power Users.

Setting up restricted groups

Let’s take a look at how to set up our Helpdesk scenario. First we need to create the group (unless you already have one). So start up Active Directory Users And Computers and place the group in an Organizational Unit (OU) fitting your needs. I will use the OU HelpDesk. In the OU I will create a Global Security group called HelpDeskAdmins. I also have a user Helmer Help in my OU and he will be, for now, the only member of HelpDeskAdmins.

Now we have a group and a user to test with so let’s get on by creating our Group policy to enforce this setting.

Creating the restricted groups group policy object

If you don’t have Group policy management console installed you can download it from http://www.microsoft.com/DownLoads/details.aspx?FamilyID=0a6d4c24-8cbd-4b35-9272-dd3cbfc81887&displaylang=en

So let’s create a new group policy called HelpDesk Privleges and link it to any existing OU containing the computers you want the helpdesk users to be able to manage. In my lab this is the Sales OU. Now edit the created and linked GPO.  Navigate to Computer Settings\Windows Settings\Security Settings\Restricted Groups.

Right click in the viewer and select Add group. Type or browse for your group, in my case CORP\HelpDeskAdmins

Hit OK and you’ll be presented with the CORP\HelpDeskAdmins Properties window. The tab says Configure Membership for CORP\HelpDeskAdmins. You have to boxes to fill in here. Members of this group and This group is a member of. If you set the Members of this group it will WIPE any other user or group from the defined local group. Simply, if the user/group is not set in the Members of this group it will be removed from the local group also. Wiped, gone, bye.

That’s not what we are out to do here, we simply want to add a group to the client computers Administrators group. So we use the This group is a member of box and enter the local Administrators group named, Administrators by selecting ad and typing the name.

That’s it. Save and check the policy is linked to a OU.

To test the scenario I’m logging in to a Windows Vista client with the Help desk employee Helmer Help, and delete an old local user Mats. If the computer hasn’t updated it’s group policies you can speed it up by running gpupdate /force. If you’re logged in as the same user you want to use as an helpdesk user log out and in again to get the correct permissions.

Check the privileges

Now let’s se if our group has been added to the Local Administrators and I’ll delete the old local account to demonstrate Helmer has administrative privileges. So go to Controll Panel\Administative Tools\Computer Management\Local Users and Groups\Groups. Open  Administrators and behold, CORP\HelpDeskAdmins has been added to Administrators.

And as you can se we also have a Local account called Mats so let’s delete it to try out our new godlike powers.

There you have it. Now Help desk workers are able to work on client computers with administrative privileges without messing up anything else. And since this is according to organizational units you can restrict different help desks to different OU:s.

Conclusion

Restricted groups in Group policies are a simple way of delegating permissions or group membership centrally to any domain computer or server. Using restricted groups it is easier to enforce the lowest possible permissions to any given account.

If you have any comments or questions about using restricted groups don’t hesitate to drop me a line by commenting.