Setting up an Active Directory domain for evaluating the ForgeRock stack
By the end of the walk through, you should have:
- A Windows Active Directory domain
- An Active Directory DNS server
- An Active Directory LDAP service, running on SSL
- Active Directory Certificate Services – a CA.
- A kerberos realm.
- A vaguely realistic directory layout with sample users.
- PowerShell scripts for configuring the above.
- OpenAM – Active directory authentication, DataStores, self service features and behera password policy support.
- OpenAM – Integrated Windows Authentication (Which for some reason we call Windows Desktop SSO in ForgeRock)
- OpenAM – SmartCard authentication
- OpenAM – ADFS federation with WSFED, SAML2 and OIDC.
- OpenIDM – Password Synchronisation
This post will follow the following high level steps:
- Setup a Windows VM or cloud instance.
- Give the computer an appropriate hostname
- Run Windows Update.
- Install Active Directory Domain Services (ADDS, also known as “promotion to a domain controller”)
- Install Active Directory Certificate Services (ADCS). Amongst other things this is a quick way of installing a certificate on the LDAPS port of a Windows domain controller.
- Allow all users to log on locally.
- Creating a sample AD structure in PowerShell
Set up a Windows Machine
Setting up a VM and automating it
IE ESC: disabled
Using a cloud instance
Choose your weapon – server manager or PowerShell
The fourth icon is good old windows explorer, which gives you access to the file system.
Run Windows Update
To access the Windows Update settings in server manager, navigate to Local Server > Windows Update.
Give the computer an appropriate hostname
Rename-Computer -NewName svr1
Install Active Directory Domain Services
In the following steps, the following will be configured:
- A brand new active directory forest containing a single domain called windom.example.com
- A single domain controller, running an active directory DNS server and LDAP service.
- A Kerberos realm called windom.example.com
ADDS Using Server Manager
- Open up Server Manager and select “Add roles and Features”
- Click Next
- You aren’t doing a RDS installation, so just click Next.
- The local server should be selected, so click next.
- Select the “Active Directory Domain Services” role. This will pop up a dialogue asking you to add some features. Go with the defaults, making sure to install the management tools, then click next. Important: Don’t install certificate services at this point, this should be done AFTER domain services has been installed.
- You probably don’t want to install any other features right now, so click next.
- There is some general info here about ADDS. Click next.
- You can click install at the confirmation stage.
- Now the service has been installed, you have to configure it. Note that you can export an XML file here which contains the options you have specified so far. This is useful if you want to script an unattended deployment. Click “promote this server to a domain controller” to continue with configuration.
- As we’re just creating an AD setup for test and evaluation, “click add a new forest”. Specify a domain name. If you are testing, make sure you either use a domain that you own or a valid test domain, such as example.com, example.org or example.net. It’s bad practice to use a publicly available DNS domain for Active Directory, so choose a sub domain, such as windom.example.com
- Use the default forest and domain functional levels and make sure that you are installing a DNS server. Specify the DSRM password – this is only needed if there is a serious problem with your domain controller that prevents it from booting.
- Don’t worry about DNS delegation, you are using a locally installed DNS server.
- Use the default netBIOS domain name.
- Use the default filesystem locations.
- You can now review what you have done before you start the configuration. Note that you can export a pre-made PowerShell script at this point containing what you have configured.
- The pre-requisites check should pass with some warnings about default security settings and DNS. This build is just for evaluation, so click install.
- After a couple of minutes the machine will reboot.
ADDS Using PowerShell
Install-WindowsFeature -ConfigurationFilePath .ADDS-DeploymentConfigTemplate.xml Import-Module ADDSDeployment Install-ADDSForest ` -CreateDnsDelegation:$false ` -DatabasePath "C:WindowsNTDS" ` -DomainMode "Win2012R2" ` -DomainName "windom.example.com" ` -DomainNetbiosName "WINDOM" ` -ForestMode "Win2012R2" ` -InstallDns:$true ` -LogPath "C:WindowsNTDS" ` -NoRebootOnCompletion:$false ` -SysvolPath "C:WindowsSYSVOL" ` -Force:$true
Installing Active Directory Certificate Services
One nice thing about ADCS is that if you install it on a domain controller, it will automatically issue a certificate for LDAPS and configure the domain controller to use it. The default policy that is enabled on Active Directory prevents changes to any object from occuring over plain text LDAP. Therefore, if you want products like OpenAM and OpenIDM to write anything to active directory, for example when using self service or account provisioning, then you need to be using LDAPS.
ADCS Using Server Manager
- Open server manager again and select “add roles and features”. Select “Active Directory Certificate Services”, accept the suggested features and management tools, then click next.
- You don’t need any other features right now, so click next.
- There is some useful information here.
- For now, just install the certificate authority. You can come back and install further services later on if you wish.
- Once again, it’s time to install the service. Just like with domain services, you can export an XML file for automating these steps.
- Once installed, click “configure active directory certificate services” to begin the configuration process.
- For our testing, using the default domain administrator account is fine.
- Select certificate authority and click next.
- We want our CA to be integrated with Active Directory so that it can automatically issue certificates to services like LDAP. Select Enterprise CA and click next.
- Create and new private key.
- I’ve increased the default hashing algorithm here from SAH1 to SHA256, as many applications consider SHA1 to be obsolete.
- The distinguished name and CN for the CA are set here. These can not be changed, so you may want to consider what they should be for your testing. For my testing with the ForgeRock stack, the defaults are sufficient.
- You can increase the certificate validity period here if you wish.
- For testing, stick with the default file system locations.
- Now it’s time to apply the configuration. Unlike installing services like ADDS and ADFS, there is no option here to generate a PowerShell script of your options. I have created a PowerShell command with these options in the next section.
- The installation should complete successfully. Now reboot your server. On the next boot you’ll find that you can connect to your active directory server using LDAPS on port 636.
ADCS Using PowerShell
Install-WindowsFeature -ConfigurationFilePath .ADCS-DeploymentConfigTemplate.xml Install-AdcsCertificationAuthority ` -AllowAdministratorInteraction ` -CAType EnterpriseRootCA ` -HashAlgorithmName SHA256 ` -KeyLength 2048 ` -ValidityPeriod Years ` -ValidityPeriodUnits 10
Allow all users to logon locally
By default, Windows server allows two simultaneous sessions from different users without having to enable the full remote desktop services service. That means you can log on to the machine as the administrator and remote desktop in as another user for testing purposes. Windows server usually runs regular desktop applications just fine (it has to for RDS) so it can make it ideal for testing services such as Office 365.
Creating a sample AD structure in PowerShell
This blog post was first published @ http://authntoz.blogspot.no/, included here with permission from the author.