A Beginners Guide to OpenIDM – Part 4 – Mappings

Overview

Last time we configured a connector to process data from a data source. In this blog we start to bring everything together and will define a mapping that creates objects using the connector.

Mappings define the relationships at the attribute level between data in connector data sources and objects. They also define rules to create attributes where they do not already exist and transform attributes if required.

Mappings

Architecture

In OpenIDM mappings consist of a number of logical components:
  • Properties: Defines attribute mappings between source attributes and target attributes, and scripts to create and transform attribute values. Also defines a link qualifier, required to link a single record in the source to multiple different records in the target. Which might be required in some situations e.g. event based HR data feeds where the same user record may appear multiple times.
  • Association: Queries, record validation scripts and association rules that work together define how a source account is linked to a target account. i.e. how OpenIDM knows that Anne’s account in the target system maps to Anne’s account in the source system, and not Bob’s account.
  • Behaviors: Defines the rules that tell OpenIDM what to do in different situations e.g. if an account doesn’t exist in the target system, then you might configure a behaviour to create it. This is incredibly powerful and we will explore it further.
  • Scheduling: Schedules for reconciliation operations e.g. run the mapping every hour, day, week etc. This is not the same as livesync (which we touched on last time) which will sync changes between systems as they occur.

Mappings Example

Creating the Mapping

As always with this blog, the best way to learn is to work through an example. We will build upon the existing work done in blogs 1-3 so you will need to complete those first.
Log in as administrator (openidm-admin), navigate to Configure then Mappings:
Then New Mapping:
You should see the following:
A mapping requires a source and a target and data will flow from the source to the target.
You can see there are a number of selectable options on this screen that you can assign as either a source or target:
  • Connectors: Any connectors you have configured, e.g. flat file, database, LDAP.
  • Managed Objects: The managed objects defined in OpenIDM.
So for this example, we want to use the CSV connector configured previously to create new managed users in OpenIDM. Effectively using the CSV data to create user identities.
Click Add to Mapping on the UserLoadCSV connector, this is going to be our source.
Similarly, now click Add to Mapping on the User managed object, this is our target.
You should see the following:
You have probably noticed that the CSV connector has a selectable drop down. There are some connectors where you might be interested in mapping more than one type of object e.g. accounts & groups in the case of LDAP. We have only configured the default _ACCOUNT_ object in this example.
 
Click Create Mapping.
 
 
Mapping Name: You can enter a more friendly mapping name if you like.
Linked Mapping: If you are creating two mappings in either direction, you should use this to link your second mapping to your first.
Click OK and the mapping should be created:

Configuring the Mapping

We have a mapping, now we need to configure it.
Navigate to the Properties tab and examine the Attribute Grid.
 
 
Start by clicking Add Missing Required Properties, this will automatically add those target properties which the connector definition or managed object specify must be populated. Make sure you press Save Properties after doing this.
You should see the required attributes for the managed user schema:
Now we need to configure the source attributes for each of the following target attributes.
Select the userName row:
You should see the following popup:
There are a few tabs here worth spending a moment on:
  • Property List: The source property to map from.
  • Transformation Script:  In line or file based scripts to transform attributes, a common use of this is to generate LDAP distinguished names.
  • Conditional Updates: Advanced logic that allows you to define rules for the conditional update of certain properties on sync. Useful if you want to ensure that a particular property is never over wrote.
  • Default Values: Simply set a fixed default value for the target, e.g. “true”, “active”, whatever.
Navigate to the Property List tab and select __NAME__. If you recall this corresponds to the connector we defined in the last blog. Now press Update.
Do the same with the rest of the mappings as below, then press Save Properties. You should end up with something like the below.
We can quickly check if this makes sense before we synchronize, look at Sample source, set the Link Qualifier to default and try entering one of the user ID’s in the CSV:
You should see a preview of the mapping result for whichever user you entered.
Next, we need to configure an Association Rule. Navigate to Association then look at Association Rules. Select Correlation Queries
Then Add Correlation Query:
Set the Link Qualifier to default, and look at Expression Builder.
 
 
Press + and select userName:
 
 
Then press Submit, and Save.
Select Save and Reconcile.
You should see the following:
Expand out In Progress, to see the results of reconciliation:
You can see there were 100 Absent results, you can examine the tooltip to see what this means but briefly it means that the source object has no matching target, i.e. there is no managed user record for all 100s lines in the CSV file. Which makes sense, as this is the first time we have run the reconciliation.
You might have expected that those managed users will now have been created, navigate to Manage, then User:
You should see No Data:
Which might not be what we expected, however lets navigate back to Configure, Mappings and look at the Behaviors tab of our mapping again. Look at Current Policy.
By default, new mapping are set up only to read data and not actually perform any operations, such as user creates.
Look at the policy table:
Now change the Current Policy to Default Actions, and note how the table changes:
Note that the actions have all changed, examine the tooltips to understand what is going on here. I plan to revisit Policies in a later blog because they are incredibly powerful.
For now note that Absent has now changed to Create. So for our situation earlier, we would now expect those 100 Absent users to result in Create operations.
Make sure you press Save before moving on.
Finally, press Reconcile Now to run another reconciliation:
You should see the same results as before, but lets check out our Users again under Manage, User.
 
If we have done everything correctly, you should now see all of the users from the CSV file created as OpenIDM managed users.
That’s all for this blog. Thanks.
 

This blog post was first published @ http://identity-implementation.blogspot.no/, included here with permission from the author.

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.

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.

This blog post was first published @ http://authntoz.blogspot.no/, included here with permission from the author.

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.

This blog post was first published @ http://authntoz.blogspot.no/, included here with permission from the author.

Identity Disorder Podcast, Episode 3

Episode 3: It’s All About The Context

identity-disorder-speakers-ep003

In this episode of the podcast, Daniel and Chris are joined by Andy Hall and Simon Moffatt from ForgeRock product management. Topics include how and why context is important in identity, the recent ForgeRock Identity Summit and Unconference in Australia, the Olympic medal counts, and how Daniel gets into his Australian accent by saying “Bondi Beach.”

Episode Links:

ForgeRock Smart City video
https://vimeo.com/153044373

ForgeRock Privacy video
https://vimeo.com/157651841

DevOps Unleashed webinar replay:
https://go.forgerock.com/DevOps-Unleashed-Webinar_OnDemand.html

ForgeRock Identity Summit in London and Paris
https://summits.forgerock.com/

All upcoming ForgeRock events:
https://www.forgerock.com/about-us/events/

OpenAM Security Advisory #201605

Security vulnerabilities have been discovered in OpenAM components. These issues may be present in versions of OpenAM including 13.0.x, 12.0.x, 11.0.x, 10.1.0-Xpress, 10.0.x, 9.x, and possibly previous versions.

This advisory provides guidance on how to ensure your deployments can be secured. Workarounds or patches are available for all of the issues.

The maximum severity of issues in this advisory is Critical. Deployers should take steps as outlined in this advisory and apply the relevant update(s) at the earliest opportunity.

The recommendation is to deploy the relevant patches. Patch bundles are available for the following versions (in accordance with ForgeRock’s Maintenance and Patch availability policy):

  • 11.0.3
  • 12.0.2-12.0.3
  • 13.0.0

Customers can obtain these patch bundles from BackStage.

Issue #201605-01: Credential Forgery

Product: OpenAM
Affected versions: 11.0.0-11.0.3, 12.0.0-12.0.3, 13.0.0
Fixed versions: 13.5.0
Component: Core Server, Server Only
Severity: Critical

The Persistent Cookie authentication module is vulnerable to credential forgery. In some configurations this may allow an attacker unauthorized access to the system as any user.

Workaround:
Disable Persistent Cookie authentication module instances and require manual authentication, or combine the module with a mandatory second factor.

Resolution:
Update/upgrade to a fixed version or deploy the relevant patch bundle.

Issue #201605-02: Insufficient Authorization

Product: OpenAM
Affected versions: 13.0.0
Fixed versions: 13.5.0
Component: Core Server, Server Only
Severity: Critical

Insufficient authorization on a query endpoint allows a non-privileged user to access details of other users on the system.

Workaround:
No workaround available.

Resolution:
Update/upgrade to a fixed version or deploy the relevant patch bundle.

Issue #201605-03: Authentication Bypass

Product: OpenAM
Affected versions: 9-9.5.5, 10.0.0-10.0.2, 10.1.0-Xpress, 11.0.0-11.0.3, 12.0.0-12.0.3, 13.0.0
Fixed versions: 13.5.0
Component: Core Server, Server Only
Severity: High

In some configurations a user may be able to bypass additional authentication requirements and login with just username and password.

Workaround:
Ensure all authorization mechanisms and policies enforce all chain/module/service/role requirements have been met after authentication, such as by using OpenAM’s “Authenticated by Module Chain”, “Authenticated by Module Instance” or “Authenticated to Realm” environment conditions in conjunction with a policy agent.

Resolution:
Update/upgrade to a fixed version or deploy the relevant patch bundle and apply the workaround.

Issue #201605-04: Cross-Site Request Forgery (CSRF)

Product: OpenAM
Affected versions: 10.1.0-Xpress, 11.0.0-11.0.3, 12.0.0-12.0.3, 13.0.0
Fixed versions: 13.5.0
Component: Core Server, Server Only
Severity: High

The OAuth2 consent page is vulnerable to a CSRF attack.

Workaround:
No workaround available.

Resolution:
Update/upgrade to a fixed version or deploy the relevant patch bundle and update any customized authorize.ftl template files based on the patch.

Issue #201605-05: Cross Site Scripting (XSS)

Product: OpenAM
Affected versions: 9-9.5.5, 10.0.0-10.0.2, 10.1.0-Xpress, 11.0.0-11.0.3, 12.0.0-12.0.3, 13.0.0
Fixed versions: 13.5.0
Component: Core Server, Server Only
Severity: High

OpenAM is vulnerable to cross-site scripting (XSS) attacks which could lead to session hijacking or phishing. The following endpoints are vulnerable:

  • /openam/cdcservlet
  • /openam/SAMLPOSTProfileServlet

Workaround:
Protect the listed endpoints with the container (for example using the mod_security Apache module) or filter external requests until a patch is deployed.

Resolution:
Update/upgrade to a fixed version or deploy the relevant patch bundle.

Issue #201605-06: Credentials appear in CTS access log

Product: OpenAM
Affected versions: 13.0.0
Fixed versions: 13.5.0
Component: Core Server, Server Only
Severity: Medium

OAuth 2 client requests using HTTP Basic authentication may result in the base64-encoded credentials being recorded in the CTS access logs.

Workaround:
Use alternative authentication mechanisms for OAuth2 clients, or protect the OpenDJ access logs for the CTS store.

Resolution:
Update/upgrade to a fixed version or deploy the relevant patch bundle.

Issue #201605-07: Content Spoofing Vulnerability

Product: OpenAM
Affected versions: 9-9.5.5, 10.0.0-10.0.2, 10.1.0-Xpress, 11.0.0-11.0.3, 12.0.0-12.0.3, 13.0.0
Fixed versions: 13.5.0
Component: Core Server, Server Only
Severity: Low

Using a carefully crafted request an attacker can cause an alternative image and title text to be displayed on an admin console page.

Workaround:
Block access to the following endpoint:

  • /openam/ccversion/Version

Resolution:
Update/upgrade to a fixed version or deploy the relevant patch bundle.

If You’re Coming to Our Sydney Unconference…

Our very first Unconference in Australia is happening later today (Wednesday, August 10th) at the Sydney Museum of Contemporary Art Australia. We’re on Level 6, same location as our Identity Summit from yesterday, but today we’re in the Quayside Room, rather than the Harbourside Room.SydneyOperaView

If you haven’t been to a ForgeRock Unconference previously, you might be curious as to what exactly takes place. Basically, it’s a gathering of identity geeks, coming together to share knowledge, demonstrate new ForgeRock features and functions, and discuss the latest industry developments. We’ve got a list of topics for discussion – see below – but the agenda will be determined by the attendees, so we need your participation. ForgeRock product management, customer success and engineering teams will facilitate the day and will share their expertise through hands-on demonstrations (50 minute sessions), technical guidance, and deep dives on design, implementation, provisioning and management.

Topics For Discussion

  • Mobile Push Notification
  • Stateless Sessions
  • Policy and Authorisation
  • Pragmatic Application of Advanced Federation
  • Standards 101 + UMA 101
  • Customising Self-Service
  • Social Registration Preview
  • Inside IDM: APIs, Tuning, Object Model
  • Cloud Readiness
  • DevOps
  • Platform Commons: REST, Audit, UI, Scripting
  • All About Authentication, MFA, Biometrics
  • University: Access Mgmt 101
  • University: IDM Mgmt 101
  • University: Identity Gateway 101
  • University: Directory Server 101

Looking forward to seeing you in Sydney!

Setting up an Active Directory domain for evaluating the ForgeRock stack

This post walks through setting up a single Windows machine that you can use for testing various parts of the ForgeRock stack that integrate with Microsoft products. It is aimed at those who are tech-savy but new to Microsoft Active Directory.

By the end of the walk through, you should have:

  1. A Windows Active Directory domain
  2. An Active Directory DNS server
  3. An Active Directory LDAP service, running on SSL
  4. Active Directory Certificate Services – a CA.
  5. A kerberos realm.
  6. A vaguely realistic directory layout with sample users.
  7. PowerShell scripts for configuring the above.
The above items should allow you to test:
  1. OpenAM – Active directory authentication, DataStores, self service features and behera password policy support.
  2. OpenAM – Integrated Windows Authentication (Which for some reason we call Windows Desktop SSO in ForgeRock)
  3. OpenAM – SmartCard authentication
  4. OpenAM – ADFS federation with WSFED, SAML2 and OIDC.
  5. OpenIDM – Password Synchronisation

This post will follow the following high level steps:

  1. Setup a Windows VM or cloud instance.
  2. Give the computer an appropriate hostname
  3. Run Windows Update.
  4. Install Active Directory Domain Services (ADDS, also known as “promotion to a domain controller”)
  5. 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.
  6. Allow all users to log on locally.
  7. Creating a sample AD structure in PowerShell

 

Set up a Windows Machine

To get hold of a Windows Server instance that you can start playing with, you can either build an instance yourself on your local or on-prem virtualisation software, or rent an instance from the likes of AWS and Azure.
At the time of writing, the most up to date edition of Windows server is 2012 R2, which is what I will use for the remainder of this post.
I find it easiest to perform most of my testing on a local VM on my laptop. If you don’t have an MSDN license or a licensed copy of Windows Server to hand, Microsoft give away a fully functional 180 day trial of Windows Server 2012 R2.
For testing, a Windows 2012 R2 server will scrape by on 2GB of RAM, but I would give it at least 4GB if you can. And while it will install happily on a 20GB hard disk, don’t expect there to be much room for Windows updates or any other software you may want to install. Some cloud providers offer 20GB images, I would avoid these if you can afford it. Go with 40GB at least to avoid constantly having to juggle things around.

Setting up a VM and automating it

Install your copy of Windows Server from the ISO file. I won’t detail going through the installation steps on the first few screens, they simply ask for things like localisation, keyboard layout and the password of the administrator account. I find that the data centre edition covers all the features I need.
If you want to skip through all of this, you can set up an autounattend.xml file and add it to the root of your Windows Server ISO image. Here is one that I made which works with the 180 day trial images of server 2012 R2. I made this using the Windows ADK, but you can also use some third party generator websites or just start with another one and manually edit it yourself.
If you choose to use my autounattend.xml, it is set up with the following:

username: administrator
password: Cangetinwin1
hostname: svr1
IE ESC: disabled

I have disabled IE ESC (aka that setting that prevents Internet Explorer from doing anything at all on Windows Server) above for testing purposes, but in production I would avoid doing this.

Using a cloud instance

A windows machine in the cloud will likely boot straight to the desktop, there isn’t much you need to do. Make sure you can remotely access it by remote desktop (tcp port 3389) from your IP address and make sure you have a remote desktop client handy. Windows obviously comes with one (mstsc.exe), there are some great ones for mac and Linux too.

Choose your weapon – server manager or PowerShell

When you first boot to a Windows 2012r2 desktop, you’ll see four icons on the start bar. First is the Windows 8 start menu, which I would avoid.
Second is the server manager. This useful tool provides quick access to almost everything you need to administer Windows server. I will describe using it to access various tools in the remainder of this post.
Thirdly is PowerShell. I’ll also describe how to do most things on this post with PowerShell.

The fourth icon is good old windows explorer, which gives you access to the file system.

Run Windows Update

In production, your Windows updates would be carefully managed via group policy and possibly a private Windows Server Update Services (WSUS) Server. For test and evaluation, it’s up to you whether you want to get updates from Microsoft. For testing, I would run it once and then turn it off.

To access the Windows Update settings in server manager, navigate to Local Server > Windows Update.

Give the computer an appropriate hostname

You can skip this part if you used my autounattend.xml file above, your hostname will be svr1. Otherwise, in server manager, navigate to Local Server > Computer Name
You can also set the computer name with the Rename-Computer cmdlet in PowerShell:
Rename-Computer -NewName svr1

Install Active Directory Domain Services

Installing active directory domain services (used to be known as promotion to a domain controller) is a two step process. First of all, you install the services required for ADDS. Secondly, you configure it. As usual, you can do these with both PowerShell and server manager.

In the following steps, the following will be configured:

  1. A brand new active directory forest containing a single domain called windom.example.com
  2. A single domain controller, running an active directory DNS server and LDAP service.
  3. A Kerberos realm called windom.example.com

ADDS Using Server Manager

This may seem like a lengthy process, but it mostly consists of clicking next in the installation and configuration wizards. If you are familiar with PowerShell, you may wish to skip to the end of this section and use the PowerShell commands which achieve the same thing.
  1. Open up Server Manager and select “Add roles and Features”

  2. Click Next

  3. You aren’t doing a RDS installation, so just click Next.

  4. The local server should be selected, so click next.

  5. 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.
  6. You probably don’t want to install any other features right now, so click next.

  7. There is some general info here about ADDS. Click next.

  8. You can click install at the confirmation stage.

  9. 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.

  10. 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

  11. 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.

  12. Don’t worry about DNS delegation, you are using a locally installed DNS server.

  13. Use the default netBIOS domain name.

  14. Use the default filesystem locations.

  15. 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.

  16. The pre-requisites check should pass with some warnings about default security settings and DNS. This build is just for evaluation, so click install.

  17. After a couple of minutes the machine will reboot.

A this point you should now have a working Active Directory domain controller. You will be able to connect to it using LDAP on port 389, but LDAPS is not available yet.

ADDS Using PowerShell

Here is some PowerShell used to configure everything in the screenshots above. The first command uses an XML file that was generated from the “add roles” wizard above. The second command was generated by the configuration wizard.

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

The following section walks through installing Active Directory Certificate Services (ADCS). This is the enterprise grade PKI infrastructure offering from Microsoft, which you can use to generate certificates for strong authentication, for example when implementing SmartCard authentication.

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

  1. 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.

  2. You don’t need any other features right now, so click next.

  3. There is some useful information here.

  4. For now, just install the certificate authority. You can come back and install further services later on if you wish.

  5. Once again, it’s time to install the service. Just like with domain services, you can export an XML file for automating these steps.

  6. Once installed, click “configure active directory certificate services” to begin the configuration process.

  7. For our testing, using the default domain administrator account is fine.

  8. Select certificate authority and click next.

  9. 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.

  10. Create and new private key.

  11. I’ve increased the default hashing algorithm here from SAH1 to SHA256, as many applications consider SHA1 to be obsolete.

  12. 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.

  13. You can increase the certificate validity period here if you wish.

  14. For testing, stick with the default file system locations.

  15. 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.

  16. 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

The following two commands will apply the above configuration. The first command requires an XML file that was generated from the “add roles and features” wizard.

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

This is something that you should absolutely not do on a production domain controller.

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.

The default policies on a domain controller prevent normal users from logging on. Here, we are going to change that.
Open up server manager and navigate to Local Server > Remote Desktop. This will open the “system” control panel applet (sysdm.cpl), where you can configure remotes desktop.

Creating a sample AD structure in PowerShell

I’ve put together a script which generates a predictable list of any number of users and a fairly typical directory layout. The script is largely based on this one by SharePointRyan, only it does a few extra things.
If you wish to use it, copy the script to your machine (you can use remote desktop to copy files). Then execute it:
You should see output indicating that 200 users have been added (this number is adjustable in the script):
The script evenly distributes the users between three OUs representing world regions. It also creates a fairly common directory layout under the OU “windomcorp” (the script uses netbios name + “corp”).

Conclusion

That’s it. I will use this configuration as a basis for some future blog posts that I have in the works. Next up is integrating OpenAM with Office 365, then I’ll do a technical deep dive look at using supporting Integrated Windows Authentication with OpenAM.

This blog post was first published @ http://authntoz.blogspot.no/, included here with permission from the author.

Data Confidentiality with OpenDJ LDAP Directory Services

FR_plogo_org_FC_openDJ-300x86Directory Servers have been used and continue to be used to store and retrieve identity information, including some data that is sensitive and should be protected. OpenDJ LDAP Directory Services, like many directory servers, has an extensive set of features to protect the data, from securing network connections and communications, authenticating users, to access controls and privileges… However, in the last few years, the way LDAP directory services have been deployed and managed has changed significantly, as they are moving to the “Cloud”. Already many of ForgeRock customers are deploying OpenDJ servers on Amazon or MS Azure, and the requirements for data confidentiality are increasing, especially as the file system and disk management are no longer under their control. For that reason, we’ve recently introduced a new feature in OpenDJ, giving the ability to administrators to encrypt all or part of the directory data before writing to disk.clouddataprotection

The OpenDJ Data Confidentiality feature can be enabled on a per database backend basis to encrypt LDAP entries before being stored to disk. Optionally, indexes can also be protected, individually. An administrator may chose to protect all indexes, or only a few of them, those that contain data that should remain confidential, like cn (common name), sn (surname)… Additionally, the confidentiality of the replication logs can be enabled, and then it’s enabled for all changes of all database backends. Note that if data confidentiality is enabled on an equality index, this index can no longer be used for ordering, and thus for initial substring nor sorted requests.

Example of command to enable data confidentiality for the userRoot backend:

dsconfig set-backend-prop 
 -h opendj.example.com -p 4444 
 -D "cn=Directory Manager" -w secret12 -n -X 
 --backend-name userRoot --set confidentiality-enabled:true

Data confidentiality is a dynamic feature, and can be enabled, disabled without stopping the server. When enabling on a backend, only the updated or created entries will be encrypted. If there is existing data that need confidentiality, it is better to export and reimport the data. With indexes data confidentiality, the behaviour is different. When changing the data confidentiality on an index, you must rebuild the index before it can be used with search requests.

Key Management - Photo adapted from https://www.flickr.com/people/ecossystems/

When enabling data confidentiality, you can select the cipher algorithm and the key length, and again this can be per database backend. The encryption key itself is generated on the server itself and securely distributed to all replicated servers through the replication of the Admin Backend (“cn=admin data”), and thus it’s never exposed to any administrator. Should a key get compromised, we provide a way to mark it so and generate a new key. Also, a backup of an encrypted database backend can be restored on any server with the same configuration, as long as the server still has its configuration and its Admin backend intact. Restoring such backend backup to fresh new server requires that it’s configured for replication first.

The Data Confidentiality feature can be tested with the OpenDJ nightly builds. It is also available to ForgeRock customers as part of our latest update of the ForgeRock Identity Platform.


Filed under: Directory Services Tagged: confidentiality, data-confidentiality, directory-server, encryption, ForgeRock, identity, java, ldap, opendj, opensource, security