Tool to generate the amadmin password hash in OpenAM

There are several ways to change the amadmin password in OpenAM, including using the console and using the ampassword tool, which comes with the OpenAM command line tools.

This is just a quick post to say I have made a tool which generates the amadmin password hash without the need to have OpenAM or the ssoadm tools in place.

You could use this to generate the password hash if you have forgotten the amadmin password, for example.

For more information on how to use the tool and where to find the password hash in the OpenAM configuration directory, see our community bitbucket repo:

https://stash.forgerock.org/projects/COM/repos/amadminpwdgen/browse

OpenAM as an identity provider for Office 365 and Azure (WSFed)

ForgeRock now have an official procedure for setting up OpenAM/AM to be an IDP for Office 365. Please see the following knowledge base article on ForgeRock backstage:

How do I configure OpenAM 13.5.x or AM (All versions) as an Identity Provider for Microsoft Office 365 and Azure?

This blog post is out of date. Refer to the blog post on ForgeRock.com for more information:

https://forum.forgerock.com/2016/09/openam-identity-provider-office-365-wsfed/

This post will run through the step necessary to configure OpenAM 13.5 to be an identity provider for Office 365 and Azure using WS-Federation.

One of the new features in OpenAM 13.5 is support for WS-Federation Active Requestor Profile.  This will enable OpenAM to support a greater range of Office 365 rich clients and Azure authentication scenarios when acting as an IDP.

Why WS-Federation?

Office 365 and Azure support WS-Federation, SAML2 and in some cases OpenID Connect for integration with third party identity providers. While SAML2 (specifically SAML2 ECP) can be used for federation, it is only supported in newer Microsoft rich clients. WS-Federation must be used to support slightly older products such as Lync, Outlook 2011 (Mac) and Office 2010 (Windows). In particular, to support Lync and support adding an email account in Outlook 2010/2011, WS-Federation active requestor profile must be enabled.

 

What Works

Using my completely informal testing procedure on my two laptops, an iPad and a Nexus tablet - I’ve managed to get the following results with the configuration below.

platform	test	result
MacOS 10.11.5	Office 2011 Office setup from Word	ok
	Lync for Mac 2011 SignIn	ok
	Outlook 2011 E-Mail account setup & sign in	ok
	Office 2011 Document Connection	ok
	Office 2016 Sign In	ok
	Chrome web Sign In	ok
	Safari Web Sign In	ok
Windows 8.1	Office 2013 CTR Setup	ok
	Skype For Business Sign In	ok
	Outlook 2013 E-Mail account setup	ok
	OneDrive SignIn	ok
	IE web Sign In	ok
	FireFox web Sign In	ok
	Chrome web Sign In	ok
Apple iPad IOS 9.3.5	Microsoft Word Sign In	ok
	Skype For Business Sign In	ok
	Outlook E-Mail account setup	ok
	OneDrive for business Sign In	ok
	Safari Web Sign In	ok
	Apple Mail, contacts, calendar Account setup & sign in	ok
Nexus Tablet Android 5.3	Microsoft Word Sign In	ok
	Outlook E-Mail account setup	ok
	OneDrive for business Sign In	ok
	Chrome web Sign In	ok
	Gmail, calendar, contacts, device management	ok
	Skype For Business Sign In	ok

Overview of the steps

I’ll go through everything that is needed to configure OpenAM 13.5 to work with Office 365.

1. Configuring a DNS zone for Office 365.
2. Setting up the required DNS records for that zone.
3. Making sure that the active directory domain is properly configured with the right UPN suffixes for the user accounts.
4. Setting up Windows Desktop SSO (Integrated Windows Authentication) to work with OpenAM.
5. Using powershell to configure Office365 to use an external identity provider.
6. Setting up OpenAM with the WS-Federation entities for Office 365.
7. Setting up an account in Office365 and setting it to “federated” mode.

Configuration Overview

In this configuration, our public DNS zone is test365.forgepoc.com and we’ll have users with the email address something@test365.forgepoc.com. They’ll have accounts in an internal Active Directory domain. In common with best practice for Active Directory, the DNS zone of the AD domain in this exercise uses a subdomain of the public DNS zone, test365corp.test365.forgepoc.com.

You don't need Active Directory to make this work, you could use any database such as OpenDJ. But as Office 365 is typically used on Windows desktops in an Active Directory domain, I'm using it here.

The reverse proxy will be configured with a public trusted SSL certificate (required for WS-Federation active requestor profile to work with Office 365) and act as an SSL termination point for OpenAM. The host will be called login.test365.forgepoc.com.

You don't need a proxy in order to use OpenAM as an IDP for Office 365, but it is highly recommended.

Requirements

1. A Windows Active Directory domain (see my blog post on setting up one of these). 
2. An OpenAM instance on any supported operating system, configured to use Active Directory for authentication and profile attributes (see my blog post here on setting up and active directory dataStore). OpenAM should be setup with SSL internally.
3. A reverse proxy in between OpenAM and the internet, capable of supporting SSL termination (I'm using NginX). 
4. A Windows Active Directory domain configured with network connectivity to the OpenAM instance. 
5. A business Office 365 subscription capable of federating with third party identity providers. in this example, I used a business premium subscription. 
6. An SSL certificate issued from a public trusted certificate authority such as goddaddy. 
7. A public DNS zone which you can configure with the DNS records required for use with Office 365. 
8. Windows machines and devices for testing.

Note: Currently WSFed Active Requestor profile is only supported in the top level realm in OpenAM. There is an open issue for this here. Alternatively you can set up OpenAM to federate with office 365 using SAML2 ECP, but this only works with newer MS rich clients. 

Configuring a DNS zone for Office 365

Microsoft make this extremely easy using the admin section of the Office 365 dashboard. Here I’m choosing to set this up myself because I already own the domain forgepoc.com and I have other stuff on it. However, it is much easier to allow Office 365 to act as your DNS service. Doing so automatically configures the required DNS records.

To do it the manual way, log in to your Office 365 subscription and select the admin center:

From the left hand menu select settings > Domains.

Click "add a domain" and enter your domain name.

In common with obtaining SSL certificates, you have to verify ownership of your DNS domain by adding a specific TXT record to it.

Now add the required DNS records. It’s important that these are accurate, but luckily Microsoft provide a test tool to verify they are set correctly. Here is a screenshot of the records for my DNS Zone test365.forgepoc.com from my DNS provider:

CNAME Records
Host Name               Points To    
lyncdiscover            webdir.online.lync.com    
msoid                   clientconfig.microsoftonline-p.net    
sip                     sipdir.online.lync.com    
enterpriseregistration  enterpriseregistration.windows.net    
enterpriseenrollment    enterpriseenrollment.manage.microsoft.com    
autodiscover            autodiscover.outlook.com    
                             
MX Records                
Host Name               Points To                                           Priority    
@                       test365-forgepoc-com.mail.protection.outlook.com    0    
                              
SRV Records
Host Name               Points To                                           Port    Weight    Priority    
_sip._tls               sipdir.online.lync.com                              443     1        100    
_sipfederationtls._tcp  sipfed.online.lync.com                              5061    1        100    
                               
TXT Records
Host Name               Value    
@                       v=spf1 include:spf.protection.outlook.com -all

Configuring your proxy

A proxy is not required to get Office 365 up and running with OpenAM, but it is recommended. You'll need some sort of proxy configuration if you plan to use multiple OpenAM servers in a HA deployment behind a load balancer.

For WSFED to work correctly behind a proxy, we need to set the host header on the proxy. Here is my NginX site configuration:

location / {
    proxy_set_header X-Forwarded-Server $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Host $host:$server_port;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header Host $host;
    proxy_pass https://login.test365corp.o365.forgepoc.com:8443;
    proxy_redirect default;
}

In the apache web server, you can achieve the same thing by setting the proxy_pass, proxy_pass reverse and ProxyPreserveHost directives.

<VirtualHost *:443>
    ServerName login.test365.forgepoc.com:443
 ProxyRequests off
 ProxyPass / https://login.test365corp.test365.forgepoc.com:8443/
 ProxyPassReverse / https://login.test365corp.test365.forgepoc.com:8443/
 ProxyPreserveHost On

    ...

</VirtualHost>

Configuring Active Directory UPN suffixes - optional, but recommended

If you have an existing Active Directory domain then it is likely that this will be configured already and you can skip this section. However, if you’ve set up an AD domain to do some basic tests and integration work, then read on.

Let's say I make a user in active directory for Charlie Brown. I use the wizard in Active Directory users and computers and give him first name Charlie, last name Brown, username charlie.brown. Charlie will then be able to put in any of the following into the username prompt when logging on to a domain joined machine:

samAccountName: charlie.brown

cn: charlie brown

dn: CN=charlie brown,OU=user accounts,OU=test365corp,DC=test365corp,DC=o365,DC=forgepoc,DC=com
UPN: charlie.brown@test365corp.test365.forgepoc.com

Active Directory has a concept of user principal names (UPN) - a means of allowing a user account to be referenced by an email address style username that can have a different domain part to the DNS domain of the active directory domain. A UPN consists of the samAccountName and a DNS domain specified by an administrator. 

Now let's say mike wants to log on to his laptop with his email address, charlie.brown@test365.forgepoc.com. To do that, the Windows sysadmin needs to define an additional UPN suffix in the domain.

In office 365, if users authenticate to services directly with office 365 (WSFed active profile) then the user has to authenticate with their UPN. Therefore it makes sense to set the user's active directory UPN to be the same as their office 365 UPN, which would normally be their email address. That way, users only need to remember one username.

In this example, we’ll configure a UPN suffix for the external DNS domain test365.forgepoc.com. Open Active Directory Domains and Trusts (domain.msc) and right click on the root node in the left pane:

Add the UPN suffix:

Quickstart OpenAM configuration using ssoadm batch commands

If you know OpenAM well, here are some ssoadm batch commands that will get you setup quickly. Use the metadata files from below and skip the remaining sections on configuring OpenAM.

create-datastore -e / -m ActiveDirectory -t LDAPv3ForAD -a "sun-idrepo-ldapv3-config-ldap-server=svr1.test365corp.test365.forgepoc.com:636" "sun-idrepo-ldapv3-config-authid=CN=ldapUser,CN=Users,DC=test365corp,DC=test365,DC=forgepoc,DC=com" "sun-idrepo-ldapv3-config-authpw=SOMEPASSWORD" "sun-idrepo-ldapv3-config-connection-mode=LDAPS" "sun-idrepo-ldapv3-config-organization_name=DC=test365corp,DC=test365,DC=forgepoc,DC=com" "sun-idrepo-ldapv3-config-people-container-name=ou" "sun-idrepo-ldapv3-config-people-container-value=test365corp" "sun-idrepo-ldapv3-config-psearchbase=CDC=test365corp,DC=test365,DC=forgepoc,DC=com"
create-auth-instance -e / -t AD -m ActiveDirectoryModule
update-auth-instance -e / -m ActiveDirectoryModule -a "iplanet-am-auth-ldap-bind-dn=cn=ldapAuth,cn=users,DC=test365corp,DC=test365,DC=forgepoc,DC=com" "iplanet-am-auth-ldap-bind-passwd=SOMEPASSSWORD" "iplanet-am-auth-ldap-server=svr1.test365corp.test365.forgepoc.com:636" "openam-auth-ldap-connection-mode=LDAPS" "iplanet-am-auth-ldap-user-naming-attribute=cn" "iplanet-am-auth-ldap-base-dn=DC=test365corp,DC=test365,DC=forgepoc,DC=com" "iplanet-am-auth-ldap-user-search-attributes=mail" "iplanet-am-auth-ldap-user-search-attributes=cn" "iplanet-am-auth-ldap-return-user-dn=true"
create-auth-cfg -e / -m employeeChain
update-auth-cfg-entr -e / -m employeeChain -a "ActiveDirectoryModule|REQUIRED"
set-realm-svc-attrs -e / -s iPlanetAMAuthService -a "iplanet-am-auth-org-config=employeeChain"
import-entity -e / -c wsfed -m /home/centos/idpMeta.xml -x /home/centos/idpMetaExtended.xml
import-entity -e / -c wsfed -m /home/centos/spMeta.xml -x /home/centos/spMetaExtended.xml
create-site -s site1 -i https://login.test365.forgepoc.com:443/openam
add-site-members -s site1 -e https://login.test365corp.test365.forgepoc.com:8443/openam

Configure OpenAM to work behind a proxy

Use the deployment menu in OpenAM 13.5 to add a site to the deployment. Make the site URL the URL of your proxy. Once done, add your OpenAM server(s) to that site.

Configuring OpenAM authentication services

I'm assuming here that you've already got an Active Directory dataStore setup in the top level realm. 

Head over to authentication and create an Active Directory authentication module. Make sure to configure this as described here, it is required for WS-Federation active requestor profile to work later on.

Set up the module as described below. Below, I've allowed users to log on with mail as well as their usual login method, assuming that the mail attribute in the user account matches the UPN of the account setup in office 365.

However, if you have UPN sufixes setup in your AD domain (as described in my instructions above) you'll probably want to use userPrincipalName instead of mail:

Add this module to a chain and set it to be the default organisation login chain for your realm:

Create your WS-Federation hosted IDP and Remote SP

Manually creating WSFED entities in OpenAM is a bit tedious so I’ve provided some ready made entities for you to use here. I am assuming these will be added to the top level realm - you’ll need to adjust your endpoints to match your realm if you’ve used something different. I am also assuming that we’ll use the default OpenAM test certificate for token signing. You should use something different in production.

Go to the Federation section in OpenAM and create a circle of trust called cot:

Import these entities using the import entity button, making sure to add them to the correct realm:

You should now have a list of entities that looks something like this:

Set up your Azure tenant using PowerShell

If you haven’t done it already, install the Azure Powershell cmdlets on a Windows machine that you have access to.

Authenticate using Connect-MsolService:

Then use the Set-MsolDomainAuthentication cmdlet to setup your domain and make sure to set the signing certificate to the cert you are signing your assertions with:

$BrandName   = "ForgeRock test365"
$dom         = "test365.forgepoc.com"

$IssuerUri   = "urn:uri:test365forgepocemployeestlr"
$PassiveUri  = "https://login.test365.forgepoc.com:443/openam/WSFederationServlet/metaAlias/wsidp"
$ActiveUri   = "https://login.test365.forgepoc.com:443/openam/WSFederationServlet/sts/metaAlias/wsidp"
$MexUri      = "https://login.test365.forgepoc.com:443/openam/WSFederationServlet/ws-trust/mex/metaAlias/wsidp"

$Protocol    = "WsFed"

$SigningCert = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"

Set-MsolDomainAuthentication `
-Authentication Managed `
-DomainName $dom

Set-MsolDomainAuthentication `
-Authentication Federated `
-DomainName $dom `
-FederationBrandName $BrandName `
-PassiveLogOnUri $PassiveUri `
-ActiveLogOnUri $ActiveUri `
-MetadataExchangeUri $MexUri `
-SigningCertificate $SigningCert `
-IssuerUri $IssuerUri `
-LogOffUri $PassiveUri `
-PreferredAuthenticationProtocol $Protocol

Enabling "modern authentication" on the Azure Exchange and Skype services

Until recently, I had all Windows, MacOS, IOS and Android rich clients working, apart from one: Skype for business for Android. I was about to start analysing the network traffic, when my colleague Peter Major directed my to a community forum question from the user Steven Van Geel.

Even though Steven's question was related to using Android Skype for business with OpenAM as a an Office 365 IDP using SAML2 ECP, the fix he describes also corrects the behaviour with the android app with a WsFed Active profile IDP. Turning on Microsoft "modern authentication" on the Skype for business online tenant allows the Skype client to authenticate.

I have not had a chance to had a look at why this is and why it only affects the Android Skype client. I will update this blog post when I find out. It is highly possible that this may be required for other clients in future as Microsoft gradually move services onto their "Modern Authentication" standard. Note that modern authentication can be turned on for Skype and for Exchange (Outlook).

For now, here are some brief instructions for enabling this. These are pretty similar to the steps for setting up the Azure online domain. First you need to install the Skype for Business PowerShell management cmdlets.

Then run the following to authenticate to your Skype Online (aka Lync Online) tenant:

$credential = Get-Credential
$session = New-CsOnlineSession -Credential $credential
Import-PSSession $session
Get-Module

Then turn on Modern Authentication as described in this article:

Set-CsOAuthConfiguration -ClientAdalAuthOverride Allowed

Setting up your first user

All that is left to do now is to configure a user to sign on to Office 365. Office 365 requires that accounts which federate with Office 365 also have an account entry set up in Office 365 itself. Certain properties have to be set on that account, such as the UPN and what licenses are assigned to the user.

Microsoft provide the tools DirSync and Azure AD Connect that automatically synchronise on-prem Active Directory with Office 365. These are cut down versions of their identity Management Solution, "ForeFront Identity Manager" (FFIM - now EOL). ForgeRock have an Identity Management product, OpenIDM which has a powerful PowerShell connector. This can be configured to automatically provision accounts to Office 365 (see example scripts here and the IDM trunk docs here), but this is outside the scope of this post.

Here, I’ll show how to manually set up an account.

Assuming you have the following user in Active Directory:

The following PowerShell will set up that user in office 365 by copying the attributes from the same user in Active Directory. 

$user = Get-ADUser charlie.brown
MSOnlineExtended\New-MsolUser `
-DisplayName $user.Name `
-FirstName $user.GivenName `
-ImmutableId ([System.Convert]::ToBase64String(($user.ObjectGUID).ToByteArray())) `
-LastName $user.Surname `
-LicenseAssignment (Get-MsolAccountSku | select -ExpandProperty AccountSkuId) `
-UsageLocation GB `
-UserPrincipalName $user.UserPrincipalName 

So how does this PowerShell work? We get the charlie.brown user from AD then pass the properties from it to the New-MsolUser method. We use the Get-MsolAccountSku method to find the SKU of the license we need to assign to the user. We also convert the Active Directory ObjectGUID property into the base64 format expected in Office 365.

Note: If the UPN of your user doesn't match the name that they may fill in on something like the email account setup in Outlook, then you may want to change the userPrincipalName to use the mail attribute instead.

Conclusion

You should now be able to log on to Office 365 using all of the methods described above. There are some issues that you may encounter with this approach which you can track our progress on here.

What next? You may want to look at integrating this with with Integrated Windows Authentication (aka Kerberos, Windows Desktop SSO). I've done a blog post on that.

In a future blog post, I'll look at doing the same thing with SAML2 ECP and the pros/cons of using that instead.

OpenAM Windows Desktop SSO deep dive - part 1

This post will walk you through the necessary steps to configure OpenAM to authenticate users automatically using Windows Desktop SSO (Integrated Windows Authentication). The OpenAM configuration is quite straightforward, but there are a number of things that need to be in place on the Windows side for everything to work correctly.

Overview of Steps

1. Set up the required forward and reverse lookup DNS records for OpenAM.
2. Make a Kerberos principal and keytab file in Active Directory using the ktpass command.
3. Configure OpenAM for Windows Desktop SSO.
4. Configure your web browser.
5. Make sure profiles can be loaded from the Active Directory dataStore.
6. Configure OpenAM to fallback to a username and password when Windows Desktop SSO fails.

Prerequisites

This guide assumes the following prerequisites are in place:

1. An OpenAM deployment (I'm using OpenAM 13.5 here) set up on the hostname openam.windom.example.com. 
2. A Windows Active Directory domain controller with Active Directory certificate services installed (this automatically enables LDAPS on port 636).
3. This server has the hostname: svr1.windom.example.com, using the windows domain windom.example.com.
4. OpenAM setup with an Active Directory dataStore, with users being able to log on using a username and password.
5. A test Windows Desktop or a separate session on your test domain controller.

I've previously written blog posts on setting up a test Active Directory domain and setting up an Active Directory dataStore. I've used these as a starting point for the steps in this post.

Setting up DNS

1. A user may access OpenAM via a given hostname, which would often point to a load balancer.
2. The user must be able to resolve the OpenAM IP address from a DNS forward lookup on the hostname.
3. The hostname returned from a reverse DNS lookup on the OpenAM IP must match the hostname used in the forward lookup. 
4. A keytab file should be generated with a Kerberos principal name, which consists of a hostname and a realm name. The hostname in the principal name must match the hostname by which the user can access OpenAM, even if that is the external load balancer hostname.
5. The principal name configured in the OpenAM Windows Desktop SSO module must match the principal name of your key in your keytab file. 

My steps below will show how to configure the required DNS records an Active Directory DNS service. If this is anything more than a test Active Directory instance, you'll want your friendly Windows SysAdmin to carry out these steps for you.

For Windows Desktop SSO to work, the URL accessed by the user must resolve on a forward AND a reverse DNS lookup with the same IP address and host. This is part of the Kerberos Spec.

If you don’t have a reverse lookup zone configured on a DNS server in your active directory domain (isn’t set up by default), you’ll need to set one up in DNS Management (dnsmgmt.msc):











Now it's time to specify the subnet for your reverse lookup zone. Note that as part of the DNS standard, only class A, B and C blocks are supported.

The subnet here should contain what is seen to be the IP address of OpenAM from the user's point of view. This is probably the subnet containing your load balancer address.







Now create a reverse DNS record for OpenAM. If OpenAM is behind a load balancer, use the IP address of the load balancer. If you don't already have a forward lookup record ('A' record) then you can create both a forward reverse lookup record at the same time when creating an 'A' record by selecting "create associated pointer record":





If you already have an 'A' record for OpenAM, you can assign a PTR record (reverse lookup record) to OpenAM by right clicking on your reverse lookup zone and selecting "New Pointer (PTR)..."



Now that everything is in place, you should be able to perform a forward and reverse DNS lookup on OpenAM and get matching results, like in the following screenshot:

Create an account in active directory for your Kerberos principal

Create an account in Active Directory Users and Computers (dsa.msc) to use as your Kerberos principal. Don’t worry about what the password is, you are about to change it in the next step.

Note that I have set the password never expires flag here. What option you choose is up to you (and your security policy) but remember that when the account password expires, the Kerberos key in your keytab file will need reissuing.

OpenAM uses the GSS API for Kerberos which supports the full 256bit strength of Kerberos encryption, as long as the Java unlimited strength cryptography policy is installed. Select the option to ensure the account supports 256 bit Kerberos encryption in the the account tab:

Creating a KeyTab file

Next you will create a Kerberos keytab file. KeyTab is short for key table. A keytab file is a table of keys that map to Kerberos principals. The keys can be used to authenticate to a Kerberos realm. Keytabs are designed to allow services, applications and scripts to authenticate to a Kerberos realm without human interaction using the key(s) stored in the keytab file. This is part of the Kerberos standard and is not unique to Active Directory.

OpenAM uses the keytab to authenticate to the Active Directory Kerberos realm. Once authenticated, OpenAM verifies the owner of the Kerberos ticket which is supplied in the SPNEGO process from the user's web browser. I will cover this in more detail in part two of this blog post, where I will examine the Kerberos communication with a network analyser.

In Active Directory, you generate keytab files using the ktpass command. This creates a key for an account in AD (a principal) which is derived from the user's password. If the password on the account changes, the key becomes invalid.

The ktpass command also writes a number of attributes to the user account and it can manage transition between two keys. I will cover how this works in the second part of this blog post.

The  following is an example of running the ktpass command on an active directory domain controller. The +rndpass and /maxpass options set a random 256 character password on the account which is then used to derive the key in the Kerberos principal.

ktpass -out fileName.keytab -princ HTTP/hostname.of.openam@KERBEROS.REALM.NAME -pass +rndPass -maxPass 256 -mapuser <userAccount> -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -kvno 0

As it is case sensitive, make sure that the principal name is in exactly the following format:

HTTP/openam.windom.example.com@MYDOMAIN.EXAMPLE.COM

…where, openam.windom.example.com is the host name of OpenAM. If OpenAM is behind a load balancer, make this the hostname of the load balancer. MYDOMAIN.EXAMPLE.COM is the name of the Kerberos realm - the FQDN of the Active Directory domain.

In the domain we’ve been building so far, the command will look like the below:

You should now have a keytab file:



This file contains sensitive authentication keys. You should store it in a protected file system location, in a similar way to protecting private SSL keys.

Setting up Windows Desktop SSO in OpenAM

Copy your keytab file to a secured location on your OpenAM server(s) and set up a Windows Desktop SSO module. If you have based your configuration on my blog post for setting up an Active Directory DataStore, then you'll want to take the following steps in your employees realm:

Again, make sure the principal name is typed correctly, matching the case below.

Once that is complete, you can make a chain in your realm to begin testing the new authentication module.



For now, I've made a chain that only contains the Windows Desktop SSO module in order to observe any error messages that may occur.

Configuring the web browser

On a Windows Desktop, Internet Explorer, Edge and Google Chrome take a number of browser security settings from "Internet Options" on the Windows control panel. By default, these settings cause a user to re-enter their Windows domain credentials before the browser will submit a Kerberos ticket as part of SPNEGO (aka Integrated Windows Authentication).

Authentication should still succeed, but it's not a very user friendly experience.

The security zones' default settings permit automatic submission of a Kerberos ticket to sites in the Intranet Zone. If you add OpenAM's URL to this zone, the user will automatically be signed on with their Windows credentials.

Again, if you are setting this up on anything more than a test active directory instance, you will want  your friendly Windows SysAdmin to change your internet options, as these settings will most likely be controlled by group policy.

You can find Internet Options on the Windows control panel, but my favourite way to open it (because this works on all versions of Windows since 95) is to run inetcpl.cpl from the command line or the Windows run box (WinKey+R):

 

This is likely the only configuration required in the browser settings. However, if you are having problems with IE or Edge specifically, check that "Enable Windows Integrated Authentication" is selected on the advanced tab:

Also check that the security settings for the intranet zone are set to "automatic logon only in intranet zone".

Now try authenticating using the "wdsso" chain:

http://openam.windom.example.com:8000/am1350/XUI/#login/employees&service=wdsso

Make sure your dataStore can load a profile after authentication

You may find that Windows Desktop SSO appears to work correctly now. However, this may apply solely to accounts where the CN matches the Windows account name, such as the domain administrator account.

Once OpenAM has authenticated a user using one or more authentication modules, it is normally configured to retrieve a profile from a dataStore - in your case this is Active Directory. In order to retrieve the profile, the authentication modules obtain a name that will be used to lookup the user. The Windows Desktop SSO module provides the windows account name (without the domain component) for this, but the Active Directory type of dataStore is by default configured to search for a user based on the CN, not the "sAMAccountName" attribute, which contains the Windows account name. If the CN does not match the sAMAccountName, as is usually the case in Active Directory, then the profile will not load after authentication. When that happens, you will see the error, "User Requires Profile to Login".

If you have followed my previous blog posts on setting up an Active Directory Domain and setting up an Active Directory dataStore in OpenAM, this error will occur.  In order to rectify, you need to change your dataStore to retrieve the profile using the sAMAccountName attribute:

If you also wish to use the dataStore authentication module and allow users to login with that username, you can change the "authentication naming attribute" in your dataStore.

At this point, you should now be able to authenticate using Windows Desktop SSO. But what happens when the user isn't using a domain-joined computer?

Configuring fallback to the dataStore module

Now that your Windows Desktop SSO module is working and the user profile is retrieved, you will configure an extra module in the chain to allow a username and password prompt to be supplied if the user's browser is not configured for Kerberos authentication.

Below I've set the "wdsso" chain to attempt Kerberos authentication using the Windows Desktop SSO module. Because it is set to "sufficient", it will only proceed to authentication via the dataStore module if authentication via Kerberos fails.

Note: Versions of OpenAM prior to v.13.0.0 required a custom error page to be implemented, allowing a failed login on the Windows Desktop SSO module to progress to the next module in the chain. This is no longer required.

UPDATE: That's not quite always true. The change in OpenAM 13 allows the WDSSO module to fall back to another module if the browser has negotiate support turned off, for example as it is by default in Safari and FireFox. However, this won't prevent the login dialog (shown above) from appearing if negotiate support is turned on in the browser, as it is by default in IE. I'll look into this in more detail in my next blog post.

That's it!

Windows Desktop SSO should now authenticate users who are logged in on a domain-joined computer to OpenAM.

Part 2 of this blog post will look at the mechanics behind Kerberos authentication by analysing the network traffic and will also address common scenarios that can cause Windows Desktop SSO to fail.

Setting up an Active Directory DataStore in OpenAM

In this post, I've going to set up an Active Directory DataStore in OpenAM 13.5. If you are familiar with OpenAM's authentication and profile store facilities but struggle with the Windows side of things, then this post is for you.

Overview of Steps

1. Get OpenAM to trust the certificate on an Active Directory LDAPS service.
2. Create an account in the Windows domain for OpenAM to lookup accounts with (You aren't using the domain admin account, are you?! ).
3. Configure a DataStore in a new realm in OpenAM.
4. Testing login with the default DataStore module

Prerequisites

You'll need these things in place before you can follow the steps below:

1. An OpenAM deployment (I'm using OpenAM 13.5 here) set up on the hostname openam.windom.example.com. 
2. A Windows Active directory domain controller with active directory certificate services installed (this automatically enables LDAPS on port 636). 
3. This server has the hostname: svr1.windom.example.com, using the windows domain windom.example.com.

I've previously written a blog post on setting up a test active directory domain, including the full installation steps and a script for generating test data. I've used this setup as a basis for the steps in this post.

Trusting Active Directory LDAPS certificates

If we want OpenAM to use LDAPS to connect to active directory, then it needs to trust the public SSL certificate for the connection. If you followed my blog post on setting up an active directory domain, then this certificate will have been issued by active directory certificate services. So to get OpenAM to trust that certificate, we can get it to trust the certificate services CA.

First, let's use certutil on our Windows domain controller to export the public CA certificate from certificate services:

certutil -ca.cert -f ca.cer

Then import the certificate into the java cacerts truststore on each of the OpenAM servers in your deployment. On CENTOS 7, that command would look like this:

sudo keytool -import -trustcacerts -file ~/ca.cer -alias windom-ca -keystore /etc/pki/java/cacerts

Create an account in your Active Directory domain

The account we are creating here is used by OpenAM for authentication operations and profile manipulation. If you are using something more established than a simple test Active Directory domain, ask your Windows SysAdmin to do this for you.

In this example, the user is called openamLdap and it is located in an OU called "Service Accounts". This OU is put in place by the sample data script from my blog post on setting up active directory.

Use “Active Directory Users and Computers” to do add the openamLdap account (dsa.msc):

Note that I have set the password never expires flag here. What you choose to do here is up to you (and your security policy) but remember if you choose not to do this, you will need to keep track of password changes for this account.

Once you’ve done that, delegate some admin rights to that account using the active directory delegate control wizard. Below, I'm delegating control of the "User Accounts" OU to the user I've just created. Right click on the OU and select delegate control:

Above we are allowing openamLdap to manipulate users in our User Accounts OU. What you choose to do in your setup is up to you.

Once you’ve done that, enable advance view in active directory users and computers:

Then edit your new account, go to the attribute editor tab and scroll down to distinguished name. Copy this value, you’ll need it in a minute for the OpenAM setup:

Creating a DataStore in OpenAM

In OpenAM, create a realm in the top level realm called employees. In the employees realm, remove the default dataStore and add a new active directory dataStore:

Add the hostname(s) of AD servers with the port number, and add the DN of the user you created earlier. You can use the end of the user DN to get the LDAP base DN of the domain.

In this example, LDAPS is used (this is required if you want to change properties of accounts in AD). LDAPS is not enabled by default in AD. If you don’t have it setup, note that a quick way of enabling it is to install the Active Directory Certificate Services role and reboot. After having done that, you need to add the public cert of the Windows CA to the java cacerts file on your OpenAM server.

You may wish to alter the User and Groups OUs in the DataStore configuration. By default both of these point to the Users container in active directory, but this is usually not used in production active directory services because you cannot create OUs underneath this container. If you choose to alter the default search filters, remember that Active Directory does not support LDAP extensible match rules.

In my setup, I have set the LDAP organisation DN to point to my windomcorp OU, OpenAM is not concerned with anything outside of this. I've changed the default people container naming attribute to OU and my people container value to "User Accounts". This matches "OU=User Accounts,OU=windomcorp,DC=windom,DC=example,DC=com", the location of my regular user accounts which were set up by the script from my previous blog post.





I've done the same thing in the group configuration. The groups configuration must point to a valid LDAP entry that is accessible from our LDAP user account, otherwise OpenAM will fail to load the profile of a user after authentication.



Set the root DN for persistent search:

Now scroll to the top and hit save. Once you head back to the realm options, you should be able to see your users in the subjects tab. If you don’t go back and double check your settings and also look for any exceptions (..and "caused by" exceptions) in the "idrepo" debug log.

If you log out of OpenAM, you should be able to log in as a Windows user from the login page of the customers realm:

http://openam.windom.example.com:8000/am1350/XUI/#login/employees

What next?

In the steps above, we hardly touched on OpenAM's powerful authentication capabilities - we simply used the "DataStore" authentication module that is available by default. If we want our user to logon with something other than the CN, the best option is to use the Active Directory authentication module, which allows you login with different usernames. For example, you could specify sAMaccountName and mail as usernames.

The active directory authentication module also supports the LDAPv3 behera standard, which allows OpenAM to respond to situations such as account lockouts, expired passwords and passwords that must be changed.

In my next blog post, I'll go through the steps to configure this OpenAM deployment to authenticate users with Windows Desktop SSO - the Kerberos part of what is commonly referred to as Integrated Windows Authentication.