LDAP Command Line Cheat #OpenDJ

I use the command line a lot when interfacing with OpenDJ. One of the issues with this is that I often run into an issue with the BindDN user’s password has an “!” (bang) in it. As this is a special character in Unix/Linux command line, it will typically cause unexpected results.

With ldapsearch you can just leave the password paramater off and you will be prompted to provide the password. I have found that this is not the case with ldapmodify and ldapdelete. So, this can be problematic when trying to delete a user’s record.

Another work-around is to set up a tools.properties file in your user’s home directory. So, if you typically run these commands as a user named “opendj” then you would create the following file, in the opendj user’s home directory:


So, then to delete a user:

Create an ldif file containing the user’s DN and the change type:

ex. vi deleuser.ldif
dn: uid=newuser,ou=People,dc=example,dc=com
changetype: delete

Then run the ldapmodify command:

$ldapmodify -p 1389 -f deluser.ldif

You will be prompted for the password which you can type in and not worry about any conflicts with the OS command line.

OpenIDM: Implementing a custom password policy

OpenIDM 3.1 comes with several password policies enabled by default.  There are often times when you will need to implement additional policies or even modify or extend existing policies.  This is a quick guide that will walk you through the basics of implementing your own password policies.

Let’s talk a little bit about what’s there by default.

Policies are enabled in the openidm/conf/policy.json file.  This file is organized by resources (e.g. managed/user, internal/user, etc).  Each resource in turn has a properties section in which policies are defined for a specific attribute (e.g. userName, password, email, etc).

Here is an example:

The policies that are reference in policy.json are actually defined in:  openidm/bin/defaults/script/policy.js

policy.js looks something like this:

 “policies” : [

        {   “policyId” : “required”,

            “policyExec” : “required”,

            “clientValidation”: true,

            “policyRequirements” : [“REQUIRED”]


 policyFunctions.required = function(fullObject, value, params, propName) {

        if (value === undefined) {

            return [ { “policyRequirement” : “REQUIRED” } ];


        return [];


I wouldn’t make changes directly to policy.js as these changes could get overwritten by an updated from ForgeRock.  

So, now to implement your own policies … let’s add in a policy that will enforce a maximum length for passwords.

  • First make a copy of the policy.js file, rename it and save to: /openidm/script/custom-name-policy.js
  • Remove all of the policies, from the new file, that you don’t need
  • Add in your new custom policy 

At the top of the file add in:

var policy1 = {
“policyId” : “maximum-length”,
“policyExec” : “maxLength”,
“clientValidation” : true,
“validateOnlyIfPresent” : true,
“policyRequirements” : [“MAX_LENGTH”]


function maxLength(fullObject, value, params, property) {
var maxLength = params.maxLength;
var val = “”;

if (value != null) {
val = value;

if (val.length > max.length) {
return [ { “policyRequirement” : “ No more than “ + maxLength + characters”, “params” : {“maxLength”:maxLength} } ];
return []

A simple function that checks to make sure that the password length is not longer than the maxLength parameter.

Great, so how do we enable that (and where do we set that maxLength parameter?)

Let’s go back and modify the policy.json file.  Near the top of the file there is a parameter called “additionalFiles”.  Add the path and name of your custom file to that parameter.

“additionalFiles” : [


find the password policy section (in the policy.json file).  Under the “managed/user” resource …

“name” : “password”,
“policies” : [
“policyId” : “notNull”
“policyId” : “atLeastXCapLetters”,
“params” : {
“numCaps” : 1

Now add in a reference to the new policy, that was created in the custom-name-policy.js file.  So policy.json would now look like this:

“name” : “password”,
“policies” : [
“policyId” : “notNull”
“policyId” : “atLeastXCapLetters”,
“params” : {
“numCaps” : 1
“policyId” : “
“params” : {
“maxLength” : 16

Save this file and restart OpenIDM.  Your new new policy should now be enabled and when creating a password for a managed/user object (i.e. user) you will get a policy validation error if the password is longer than 16 characters.

Custom Password Policy Validation in OpenIDM

A customer needed to ensure that passwords contained at least one ‘special character’ when a new password was created in OpenIDM.

I borrowed heavily from the provided samples but had to figure out the correct regexp formatting.

Here is the function that I used to implement this:

function atLeastXSpecialChars(fullObject, value, params, property) {
   isRequired = _.find(this.failedPolicyRequirements, function (fpr) {
       return fpr.policyRequirement === "REQUIRED";
   isNonEmptyString = (typeof(value) === "string" && value.length),
   valuePassesRegexp = (function (v) {
   var testResult = isNonEmptyString ? v.match(/\(|\)|\!|\$|\`|\~|\:|\.|\,|\<|\>|\=|\?|\^|\_|\{|\}/g) : false;
       return testResult;
   if ((isRequired || isNonEmptyString) && !valuePassesRegexp) {
       return [ {"policyRequirement" : "AT_LEAST_X_SPECIAL_CHARS"}];
    return [];

Using a different Oracle schema with OpenIDM’s Scripted SQL Connector

Here is a quick note to help you correctly configure the Scripted SQL Connector when working with different schemas in an Oracle Database.  By default the connector assumes that you are querying the default schema, which can be problematic if you happen to be using a different schema (user).

The default connector file will look something like this:

"configurationProperties" : {
    "host" : "localhost",
    "port" : "3306",
    "database" : "HRDB",
    "autoCommit" : false,
    "reloadScriptOnExecution" : true,
    "createScriptFileName" : "&{launcher.project.location}/tools/CreateScript.groovy",

To query a different schema you can add the attribute “defaultCatalog” to the configurationProperties.  So, if for example your database schema is “myschema” you can add “defaultCatalog” : “myschema”, as shown below:

"configurationProperties" : {
    "host" : "localhost",
    "port" : "3306",
    "database" : "HRDB",
    "defaultCatalog" : "myschema".
    "autoCommit" : false,

Once you save the connector you should be able to query the correct schema.

Resetting Forgotten Passwords with @ForgeRock #OpenAM

Implementing the “Resetting Forgotten Passwords” functionality as described in the OpenAM Developer’s Guide requires some additional custom code.

It’s pretty straight forward to implement this functionality and can be done in 4 steps (per the Developer’s Guide):

  1. Configure the Email Service
  2. Perform an HTTP Post with the user’s id
  3. OpenAM looks up email address (based on user id) and sends an email with a link to reset the password
  4. Intercept the HTTP GET request to this URL when the user clicks the link.

All of this functionality is available out of the box with the exception of #4.  I wrote some really simple javascript that can be deployed to the OpenAM server that will handle this.  This code was written as a proof-of-concept and doesn’t include any data-validation or error handling but that could be added fairly easily.  This script can be deployed to the root directory of your OpenAM deployment.  Just be sure to update the Forgot Password Confirmation Email URL in the OpenAM Console under Configuration > Global > REST Security.

I have made the code available on my GitHub page and you are welcome to use it or modify it.

As described on the README:

  • These files are a proof of concept to extend OpenAM’s REST-based password reset functionalit
  • Add these two files to your OpenAM deployment root (e.g. /tomcat7/webapps/openam
  • Modify the server urls to the appropriate servers in your environmet
  • Change the REST Security settings in the OpenAM console (e.g. http://[AM server and port]/openam/forgotPassword.jsp)

The file resetPassword.jsp is an optional file that will display a field for the user to provide their id and will then POST to /json/users?_action=forgotPassword (Step #2 from the Developer’s Guide).


Thanks to @Aldaris and @ScottHeger for providing advice while I was working on this.

Seeking Senior OpenAM Engineers

A client of mine has asked me to assist them in finding a full-time Senior OpenAM Engineer.  They are a startup, based in Northern, Virginia.  They are working on some pretty cool initiatives with OAUTH2 and SAML and need an experienced engineer to lead this effort. 

If you are interested in this please feel free to reach out to me and I’ll put you in touch.

2014 IDM Conference Season Planning

Looks like it’s time to start planning for the IDM conference season.  There are some great conferences planned and I need to figure out how to start budgeting for some of these.  Let me know if I have missed any conferences that should be listed.







Finally connected the dots …

My son (10) has been asking about VPNs a lot lately. Which I thought was because of all of the news lately about the NSA. I ended up showing him tunnel bear, which he quickly installed on his laptop and iPhone. I complimented my son for his interest in security and gave a wink about sticking it to “the man”.

A few days later my wife and I were chatting about letting the kids have more access to social media and she said, “well I still have the kids convinced that you can see everything they do on our home network”.   A lightbulb immediately went on over my head.

… Apparently I am “the man”.

Cool Open Identity Stack Scripts/Utilities – GitHub Repos #ForgeRock #IDM

I was working on a few scripts to test out some of the new REST APIs in OpenAM 11.  I saved them out to GitHub and you are welcome to have at them.

I thought it might also be cool to share some of the other Repo’s that are related to ForgeRock as well.  There are some really cool scripts available for interacting with OpenAM, OpenIDM and OpenDJ.

These are freely available but not officially supported by ForgeRock or the developers of the scripts.  Just click on the person’s name to go to their GitHub repo.


  • Brad Tumy (AuthNUser, checkEntitlements, listAgents *New API and Legacy API*, updatePolicy)
  • Simon Moffatt (Really cool interactive menu!)


  • Ludo Poitou (Some really handy utilities e.g.: logstat.py & filterstat.py)
  • Chris Ridd (Very handy utils e.g.: slowops: analyzes operation times in access logs)
  • Simon Moffatt


  • Simon Moffatt (Interactive mode menu for calling OpenIDM’s REST APIs)

Full OIS Stack:

  • Warren Strange (Ansible (like puppet) scripts for deploying the OIS stack to Vagrant)

I am sure there are other great repos that I have missed, so feel free to add them in the comments and I can update the post.

Disclaimer: These scripts have been very handy to me but YMMV.


For those about to Rock! … introducing the ForgeRock Identity stack introductory bootstrap “sequester special”

I am offering an introductory special to ForgeRock’s Identity (I3) Stack.  I am calling this the “Sequester Special”. The Federales are cutting back budgets and furloughing the Air Traffic controllers (cough … why not the TSA agents at the airport instead) but this is your chance to capitalize on that.

So what’s this all about?

You get to try out the  ForgeRock Open Identity Stack (**ForgeRock support license required for binaries used in a production environment**) and you get a  reduced rate on professional services … to ease those sequester blues.

Download the information sheet here.

Sequester Special | For those about to ROCK …

ForgeRock Open Identity (I3) Stack Bootstrap Package

Tumy-Tech’s Professional Services team provides services to assist you in successfully and rapidly implementing ForgeRock’s Open Identity (I3) Stack into your environment.  The end result? A working implementation of ForgeRock’s Open Identity Stack designed to introduce you to ForgeRock’s products as well as demonstrate several common configurations requested by your many customers.

The ForgeRock Bootstrap Package Includes:

  • ForgeRock Open Identity (I3) Stack installation 
  • User Identity Reconciliation from enterprise LDAP (or AD)
  • User Provisioning & Single Sign-On (SSO) to Google Apps
  • Just-In-Time (JIT) Provisioning & SSO to Salesforce.com
  • Customized Installation & Configuration Documentation


Components Included:

  • OpenDJ
  • OpenIDM
  • OpenAM

Customer Requirements:

  • Customer provided servers must meet ForgeRock product specifications.
  • Customer must have an existing Google Apps for Business (or Education) account.
  • Customer must have an existing Salesforce.com account (or developer.force.com).
  • Customer installation environment must have internet connection.
  • Cost does not include travel expenses. (Remote installations are recommended; however, we can provide on-site service if you prefer.  All travel expenses will be invoiced to customer.)


Disclaimers (the small print):

  • Use of ForgeRock binaries, in production, require a license and subscription from ForgeRock.
  • Each product will be installed on up to one server in customer’s environment.
  • Tumy-Tech will use the most up-to-date, stable build publicly available.
  • OpenIDM will be configured to reconcile users from one existing LDAP (AD or LDAP) user store with up to 20 attributes mapped.
  • Typical bootstrap setup time: 2-3 days. (Additional requirements / use cases are welcome but may require additional time and cost.)

Call or Email our sales team, today, to schedule (240.215.4825 / info@tumy-tech.com)