If you would like to read the other parts in this article series please go to:
- Windows Server 2012 R2 and BYOD (Part 1)
- Windows Server 2012 R2 and BYOD (Part 2)
- Windows Server 2012 R2 and BYOD (Part 4)
- Windows Server 2012 R2 and BYOD (Part 5)
- Windows Server 2012 R2 and BYOD (Part 6)
- Windows Server 2012 R2 and BYOD (Part 7)
- Windows Server 2012 R2 and BYOD (Part 8)
- Windows Server 2012 R2 and BYOD (Part 9)
In the previous article in this series, I explained a little bit about the lab setup that we were going to be using to facilitate workplace join. I also showed you how to configure your domain controller so that it would also function as an enterprise certificate authority. In a production environment there is a lot more care and planning that needs to go into the creation of an enterprise certificate authority, but for lab purposes, what we have done will suffice.
With that said, the next thing that we need to do is to set up some user accounts that we can use for testing purposes once we get everything up and running. Microsoft’s established best practices have long stated that permissions should be applied to groups rather than to users. That being the case, we will create a group and then add a user account to it.
For our purposes, I am going to create a fictitious user named John Doe. We will pretend that John Doe works in the Marketing department, so I will also create a group named Marketing and add John Doe to that group, as shown in Figure A.
Figure A: I have created a user named John Doe and added the user to a group named Marketing.
Creating a Service Account
The next step in the process is to create a service account. In the past this meant creating a user account that would then be assigned special permissions to facilitate the task at hand. In this case however, we need to create a special type of service account called a Globally Managed Service Account or GSMA. The reason why we have to create this service account is because the workplace join feature is dependent upon the Active Directory Federation Service, which in turn requires a service account.
The service account must be created through Windows PowerShell. The actual commands that you will enter depends upon your own unique configuration, but the commands will look something like this:
Add-KdsRootKey –EffectiveTime (Get-Date).AddHours(-10)
New-ADServiceAccount FsGmsa -DNSHostName ADFS.BYOD-Lab.com -ServicePrincipalNames http/ADFS.BYOD-Lab.com
As you can see above, there are two commands that you have to type. The first command can be entered into PowerShell exactly as you see here. The second command will have to be modified to reflect the DNS naming conventions used in your own organization. Both the DNSHostName and the ServicePrincipalNames must be unique to your own environment. You can see what these commands look like in action in Figure B.
Figure B: You must create a service account that can be used by the Active Directory Federation Service.
Configuring the Active Directory Federation Service Server
In the previous article, we installed Windows Server 2012 R2 to a virtual machine named ADFS and then joined that virtual machine to our BYOD-Lab.com domain. So far we haven’t done anything else with that virtual machine, but this is about to change. We need to assign an SSL certificate to the ADFS server and we then need to apply the ADFS server role.
As you may recall, we previously configured our domain controller to double as an enterprise certificate authority. We will use this certificate authority to issue the required SSL certificate.
We need to request an SSL certificate and download it to the ADFS server’s certificate store. When we set up the enterprise certificate authority in the previous article, we configured it to support Web enrollment. Our certificate authority is actually hosting a Web site that you can use to request a certificate.
The problem is that by default the certificate authority’s Web site is not protected with SSL encryption. Although the Web site is accessible, you won’t be able to complete a certificate request unless your session is SSL encrypted. We therefore need to adjust the site’s bindings so as to enable SSL encryption.
To do so, open Server Manager on your domain controller / certificate authority, and then click on the Tools menu. Next, choose Internet Information Services (IIS) Manager from the list of tools.
When the Internet Information Services (IIS) Manager opens, navigate through the console tree to DC | Sites | Default Web Site, as shown in Figure C. Now, click on the Bindings option that is displayed in the Actions pane.
Figure C: Select the Default Web site and then click on the Bindings link.
When the Bindings dialog box appears, click on the Add button. This will cause Windows to open the Add Site Bindings dialog box. Select HTTPS from the Type drop down list, and then choose the appropriate certificate from the SSL Certificate drop down list, as shown in Figure D. Click OK, followed by Close to complete the process.
Figure D: Set the type to HTTPS and then choose an SSL certificate.
Requesting a Certificate
Now you will need to open the certificate authority Web site from the browser on your ADFS virtual machine. If you have been following the instructions in this article series verbatim then you can access the certificate services web site at: http://DC.BYOD-Lab.com/CertSrv Otherwise, substitute your enterprise certificate authority’s FQDN for the one shown here. It is worth noting that you must enter the URL as HTTPS rather than HTTP. Otherwise the certificate request will fail. It is also worth noting that you must use a FQDN in the URL. If you try to use an IP address instead, you will receive a certificate error.
When you arrive at the Microsoft Active Directory Certificate Services Web site, you will be prompted to log in. You must use an account with domain admin permissions. You will then be taken to the screen shown in Figure E.
Figure E: This is the Microsoft Active Directory Certificate Services Web site.
At this point, you will need to click on the Request a Certificate link, followed by the Advanced Certificate Request link. On the following screen, click the option to Create and Submit a Request to this CA. You may see a prompt asking if you want to allow the operation. If you receive this prompt, click Yes.
On the following screen, select the Web Server option from the Certificate Template drop down list. You must populate the Name field with the fully qualified domain name of your ADFS server. In my case, the name will be ADFS.BYOD-Lab.com. In case you are wondering, the name that you assign here will be the certificate’s subject name.
You can enter anything that you want for the remaining Identifying Information. You should leave the default settings in place in the Key Options section, as shown in Figure F.
Figure F: The Name field must reflect your ADFS server’s fully qualified domain name.
Now, scroll down to the Additional Options section. You can keep the default values for the request format and for the hash algorithm. However, you must populate the Attributes section with the subject alternate name information. This certificate will require two subject alternate names:
- Subject Alternative Name (DNS): ADFS.BYOD-Lab.com
- Subject Alternative Name (DNS): enterpriseregistration.BYOD-Lab.com
The subject alternate names must be entered in a special format. Again, you will need to use values that reflect the naming conventions that you have used in your own organization. If you are using the same naming conventions that I am, then the attributes will look like this:
san:dns=ADFS.BYOD-Lab.com&dns=enterpriseregistration.BYOD-Lab.com
You can see what this looks like in Figure G.
Figure G: You must populate the Attributes field with SAN certificate information.
Click Submit and the certificate request will be generated. Assuming that the request was successful, the following page will ask you if you want to install the certificate. Click on the Install this Certificate link. After a moment, you should see a message stating that the certificate has been successfully installed.
If you want to verify the certificate, enter certmgr.msc at the server’s Run prompt to launch the Certificate Manager. Navigate through the console tree to Certificates | Personal | Certificates. The certificate that was just issued should appear in the details pane, as shown in Figure H. You can double click on the certificate to examine its details if you want.
Figure H: This is the certificate that has been issued.
Conclusion
As you can see, there is quite a bit of work involved in provisioning the ADFS server with the required certificate. Now that the certificate is in place however, we can begin configuring the ADFS server.
If you would like to read the other parts in this article series please go to:
- Windows Server 2012 R2 and BYOD (Part 1)
- Windows Server 2012 R2 and BYOD (Part 2)
- Windows Server 2012 R2 and BYOD (Part 4)
- Windows Server 2012 R2 and BYOD (Part 5)
- Windows Server 2012 R2 and BYOD (Part 6)
- Windows Server 2012 R2 and BYOD (Part 7)
- Windows Server 2012 R2 and BYOD (Part 8)
- Windows Server 2012 R2 and BYOD (Part 9)
