Test Environment Information
Updated: April 9, 2014
Applies To: Windows Server 2012 R2
The test environment used in developing this solution consists of two machines. One is a Windows Server 2012 R2 server and the other is a Windows 8.1 client machine. The server is our domain controller and our AD FS server. AD FS’s use of IIS was removed in Windows Server 2012 R2 and so it is now okay to run AD FS on a domain controller. Our client machine has Visual Studio 2013 with Update 2 CTP 2 installed and will be used for development and testing. The machine names used in this solution are DC1 and CLIENT1. Keep in mind that this is a test environment and doesn’t necessarily reflect best practice. For instance, in production, it would be recommended that the AD FS server was behind a Web Application Proxy.
In this solution, both machines are able to access the internet. This is not so important for DC1, but CLIENT1 does need to be able to access the internet for the following:
NuGet - NuGet is the package manager for the Microsoft development platform including .NET. The NuGet client tools provide the ability to produce and consume packages. The NuGet Gallery is the central package repository used by all package authors and consumers. The packages for our ToDoListService(Web API) are automatically added but for our Windows Store App we will need to manually add the package. For more information see What is NuGet?
Windows Store Application Developer License - If you want to install and test a Windows Store app before you submit it to the Windows Store, you must get a developer license for each machine on which you want to run the app, or your enterprise must sideload the app for you. Sideloading is outside the scope of this documentation. For more information see Get a Developer License.
Hyper V was used to create the test environment. This test environment was initially built on a laptop running Windows Server 2012 R2 and using Hyper-V. A total of 6GB of RAM was allotted to the Hyper-V machines, 2GB to DC1 and 4GB to CLIENT1. A bridged wireless connection was used to provide the Hyper-V machines with network connectivity.
This document assumes that Windows Server 2012 R2 has been installed, that DC1 has had Active Directory Domain Services installed and it has been promoted to a domain controller and that CLIENT1 has been joined to the domain. It also assumes that AD FS has been setup and configured in the environment. The steps for these are outside the scope of this documentation. However, here are some important tips in creating the environment.
This solution will not provide details on building the environment and setting up AD FS. For information on how to install and configure AD FS, see Set up the lab environment for AD FS in Windows Server 2012 R2.
There was no certificate server in the test environment. A certificate was created using makecert for DC1 and the AD FS installation. This certificate is required to install AD FS.
makecert -r -pe -n "CN=adfs.corp.contoso.com" -b 01/01/2010 -e 01/01/2036 -eku 1.3.6.1.5.5.7.3.1 -ss my -sr localMachine -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12
You will need to install the DC1 certificate in the local machines certificate store on CLIENT1. You can use the procedures outlined in Import and Export Certificates Be sure that you are importing it to the Local Machine store and that it is added to the Trusted Root Certificate Authorities container.
When you run (debug) the web API on CLIENT1, IIS Express is used and will create a self-signed certificate to use with https. This certificate also needs to be imported to the Local Machine store on CLIENT1 and added to the Trusted Root Certificate Authorities container.
The Federation Service name used for AD FS is adfs.corp.contoso.com. A DNS A record was created on DC1 for adfs.corp.contoso.com.
Windows Authentication is the primary authentication method used for the intranet. You need to ensure that the SPN is set properly on the AD FS service account for this to work correctly.
You will also need to create a new user account for developing the Windows Store App. By default, a Windows Store App cannot be run as the Administrator. For purposes of this lab, a test user named Britta Simon was created and she was added to the Domain Admins group.