How to Search Non-Indexed Account Attributes in IDN Rules

Hey Folks!!!

Anyone well versed with IDN Rules will know that there has been some historic limitations on what attributes we can and can’t use for uniqueness search or for other such methods. We were generally tied to “Account ID” and “Account Name” attribute in each source which were indexed in the DB which could be used in rules to do so. 

Workaround till date had been to promote these attributes to an identity attribute and index them (which again had limitations of it own in terms on number of attributes and size of attribute).

Now we have a way to do this. Personally been involved with the product team and engineers in getting this shaped and delivered so a bit proud of this work. It is a great first start and will help you in doing so many use cases much simpler now. 

Lets take a use case and a walkthrough on how you can set this up

Use Case

We want to generate a new email address which must have a unique prefix ([email protected]) by checking against the “mail”, “userPrincipalName”, “proxyAddresses” attributes across 3 x AD connectors. 

Note: Sources don’t have to be AD explicitly and can be virtually any source (AAD, ServiceNow, Okta, Workday etc) 


Now anyone who has worked with rules before would have known that this use case was not very easy to implement. You would have to promote these attributes, index identity attribute and then use it in the rule. Now we can create searchable attributes in the backend via API and use these in the rule. 

High Level Steps are

  • Identify Source ID and attributes
  • Create Searchable Attributes
  • Do an unoptimised aggregation if source already exists (like production tenant) to populate these searchable attributes.
  • Use new methods in rules to search for uniqueness

Identify Source ID and Attributes

Now we have 3 x AD source in our design. For each of them we need to get their sourceID. You can fetch them with an API call


  • {{api-url}}: This is your tenant URL in form of
  • {{source-id}}: This is the number you see in your browser URL when visiting the source via UI

In the response you will get an externalId with a value like 2c9180867745f3b10177469563be7451d

Gather the externalId for all three sources you want to build it for. 

Create Searchable Attributes

Now when you have all the SourceID’s we need to map and create searchable attributes. We will design 3 attributes (one for each – mail, userPrincipalName, proxyAddresses). It takes care of multivalued attributes as well (like proxyAddresses). The below table explains the design 

Search Attribute NameAccount AttributeSource IDSource Name
allMailAddressesmail2c9180867745f3b10177469563be7451dAD Source 1
2c9180867745f3b10177469563be7451eAD Source 2
2c9180867745f3b10177469563be7451fAD Source 3
allProxyAddressesproxyAddresses2c9180867745f3b10177469563be7451dAD Source 1
2c9180867745f3b10177469563be7451eAD Source 2
2c9180867745f3b10177469563be7451fAD Source 3
allUserPrincipalNamesuserPrincipalName2c9180867745f3b10177469563be7451dAD Source 1
2c9180867745f3b10177469563be7451eAD Source 2
2c9180867745f3b10177469563be7451fAD Source 3

Create each of the attribute via Create Search Attribute Config API

Similarly do it for other 2 attributes as well

Once all are created you can do a GET call to check all attributes

You should see all the above listed. 

Populate Searchable Attributes

Now if these are existing sources with accounts in them, simply do a once off unpotimized aggregation of each source via the following API call. 

Once done for all sources, the search attributes get populated in the backend. Currently you can’t check them with the UI or API calls. Any new accounts which get created after this or come as aggregation (delta or full) will automatically keep updating the search attribute. So once set, you don’t have to do anything. Also new account created is populated immediately. So no need of aggregation of it. So if you are creating multiple users in concurrent – uniqueness check will still capture the previous value calculated – no need to wait for aggregation.

Use New Methods in the Rules

Our IDNRuleUtil guide has been updated with few new methods. Two in particular which use these attributes are 

attrSearchCountAccounts(): This will be helpful to use for uniqueness search

attrSearchGetIdentityName(): This will be helpful in say a correlation rule. 

The link above has a bit more technical in-depth on what parameters are required by these methods and what is the return. But I will show you how to use the attrSerachCountAccounts() method in an example of uniqueness search. 

AttributeGenerator Rule

Will short type the logic what I have followed here. 

  • Create a list of 3 attributes with sourceID in them. This is required to pass the list to the new method.
  • Get the firstName and lastName from identity attribute, sanitise it and pass it to generateUniqueEmail() method
  • emailSuffix is also brought from identity attribute. This logic is already done via Transforms on what user email domain or suffix is suppose to be
  • In generateUniqueEmail() create a emailPrefix attribute and call isUnique() method.
  • isUnique() is where the magic happens
    • We are using StartsWith option (there is Equals also available). Reason being all the data coming from AD will be in some form of “[email protected], [email protected]”. We want to match “[email protected]” only as we don’t care about exact match or equals match. Remember both are case-insensitive checks.
    • First check with proxyAddressSources in the idn.attrSearchCountAccounts() call
      • Here we have appended SMTP / SIP to do a startsWith check as we know that these are the known values we need to check in proxy address. We don’t have a contains. Also since its case-insensitive we don’t need to worry about camel casing or other such things. Data normally looks like “smtp:[email protected]” , “SIP:[email protected]”.
      • There are other such prefix found if proxyAddress attribute which we didn’t care about check but if your use case does, just add them and search as above.
      • If return == 0 means nothing is found, thus unique and move on to next check
      • Else isUnique == false and will return that value
    • Else check with upnSources source. Same logic as above
    • Else check with mailSources source. Same logic as above
      • If no account found here, isUnique is set to true and thus isUnique() has passed and the new email address is generated
    • If still a value is found, isUnique is set to false and thus isUnique() failed and new iteration starts
  • Max Iteration is set to 99 and then fail

Use case

Rehire an account who comes back after 5 years with the same AD account. 


Now the account could be sitting as an uncorrelated account in IDN and we want to resurrect it. We can only search against the accountID or accountName as discussed previously and say if the correlating factor is employeeID which is not a part of either of these attributes.

Correlation Rule

  • We create an attribute like above called “allADEmployeeNumbers” and populate that with AD – employeeID (or whatever you may have)
  • We do an unoptimised aggregation to populate the search attribute
  • On an aggregation of an authoritative source, we have a correlation rule attached
    • It grabs the “employeeNumber” coming in from the source
    • Calls attrSearchGetIdentityName() to find that employeeNumber in the searchable attribute.
      • If found it returns an IdentityName of the cube and this can be used to correlate
      • If not found it returns an empty returnMap i.e. creates a new identity.
  • During design we took care of the following scenarios
    • It should return null if it found multiple names or no names. 
    • It should return one identityName even if multiple links were found but single identityName (i.e. say if you had multiple employeeNumbers in links but all are attached to cube). Like in a daisy chain scenario.


You can see the power of these new methods and how you can use them. Some of my thoughts here on possibilities. 

  • We can daisy chain them like above to search for multiple attributes in multiple sources as per your pattern.
  • We can use these for more attributes from accounts without the need to identity attribute creation and hitting limits on indexing.
  • Resurrections with attributes not indexed is also now pretty easy. 

Hope this really help you in your future implementations!!!

Find Multiple Accounts for Sources Redux – Excel Hack

So after doing the last post on how to find multiple accounts from a single source via API, I was asked by few people and one my clients to see if there is an easy way to do this.

I thought of my trusted Excel to find an easier way to do so. Here are the steps

  • Generate Identities Report via Admin -> Identities -> Identity List UI and download CSV

  • Open the CSV in Excel and look at Column “Source Accounts” ( Column P when I generated it). You will see some data like this. In this example I have a duplicate ServiceNow account for this user. He also has 1 x Workday, 1 x IDN cube and 1 x Okta account.
  • Then on another column (Column S in my instance) I created a new header called “ServiceNow [source]” and applied the following formula


  • P2 = The column containing the “Source Accounts” value
  • $S$1 = Column Header “ServiceNow [source]”
  • LOWER() = Used to lowercase both strings as SUBSTITUTE is case sensitive

This will give me count of number of times “ServiceNow [source]” repeats in that line of text.


You can filter and find the rows you are interested in and give you all the users who have multiple accounts for a single source. You can expand this to other sources like I did above and create multiple columns.


How to run SailPoint IIQ on Synology NAS v2 – Slim Edition

So after my previous post I got a lot of queries about it. Thanks for reading it 🙂 

Wanted a slimmer edition which didn’t require all the additional dockers like LDAP etc

So v2 – slim edition

Note: All disclaimers still valid from previous post


This time I am using this git repo:

Only changes to docker-compose.yaml was the path to my own locations. Also ports as current 8080 were used for other containers. Passwords and ports obviously changed 🙂 

Main changes were to Dockerfile under iiq-build folder. The one on the github is not using latest debian and also had issues installing Oracle JDK

Here is the modified version was also modified to use 8.1 version of identityiq tables create script

Finally I had to update few lines in ./identityiq/WEB-INF/database/create_identityiq_tables-8.1.mysql which comes in IIQ package for me to work

That’s it.. Then build the docker


  • Need to change TOMCAT_VERSION to the one available on at the time of build
  • For some reason in my latest build webapps folder was empty. Had to do manual steps from Dockerfile after login to the sail point_iiq-8085 container. Had to run the webapps folder part (IIQ war file and index file deployment) and then restart container. Will try to figure out later what broke it.

After a few runs I got it up and running on latest version (IIQ 8.1 at the time of writing) and with persistent storage.



How to run SailPoint IdentityIQ on Synology NAS

Update: There is a newer slimmer guide for install. Try it out

I have a small home lab setup on which I do various stuff. I am running it on one of most beloved gadget – Synology NAS. It does so much for me like backup, stream, sync, upload, dockers, VM and more.. It just keeps giving!!! Worth having in every home!!!

A small glimpse of my current setup (I do much more than this on the NAS)

Homelab Setup


  • NAS: Synology DS918+
  • RAM: 16GB
  • Disks: 4 x 12GB WD Elements (shucked). Setup in 3 x SHR + 1 standalone for secondary backup
  • SSD Cache: 2 x Samsung 970 EVO 250GB M.2

Docker Setup

Various containers running like

  • Pi-Hole – Excellent DNS for whole home to block ads
  • Home Assistant – Home Automation
  • Unifi SDN – For my home network hardware
  • SpeedTest – To keep a constant and historical graph of my internet and catch ISPs in a lie if they say “nothing changed – speed is good” – I slap the graph on the face (and have got money back from ISPs for compensation as well)
  • And many more like Grafana, Chronograf, Watchtower etc etc etc…

IdentityNow Setup

Running on the Virtual Machine Manager on the NAS

  • 1 x Windows Server running AD, IQService etc. To Install certificate for TLS, see my article.
  • 1 x Linux Server running OpenLDAP and other possible connectors
  • 1 x Standard VA deployment for my always on IDN


Now I wanted to tinker a bit with IdentityIQ due to various reasons and didn’t want to do the classic install (and why not – wanted a challenge). So I started to google and ask around and found that some people have actually dockerised the product – sweet. But couldn’t find a single guide on how to do it on my existing Synology hardware. So this became a weekend mission (in between actual work and COVID-19 lockdown).


  • You need to have a license with SailPoint to run your own IIQ Instance
  • The guide doesn’t contain ANY proprietary code
  • Not responsible for breaking your NAS or setup
  • This is not a supported setup by SailPoint or anyone else (including me). This is just for the enthusiasts.



As said earlier, you need to have license from SailPoint and access to the download page. At the time of writing this guide, v8.1 is the latest version. Go to the download page and download

Unzip it and grab the identityiq.war file for later use. Upload both the zip and war file to your NAS in a folder of your liking.


I found many different ways to build the docker but I decided to go with the one done by IdentityWorks. They have their own git repo containing everything you need to do the works. 

They have various options there to build but I used the full stack method. Although I already had many of the requirements running as individual dockers due to other projects (traefik, ldap, mysql etc) but I thought to keep it simple and just do the whole build separately. Just in case I break anything.

NAS Customisation

Now If you run the guide as is then it will build it for you straight up from scratch in a new docker environment. But because I am running it on my NAS with existing dockers I came across various issues

  • Some build script commands don’t exist on Synology NAS
  • Some ports are already in use due to NAS UI / other dockers.

Build Script

In the script I found couple things which didn’t exist on my NAS

  • git command
  • unzip command
  • ant command
  • java package

To fix do the following

  • unzip command replacement

Replace the unzip with 7z command in the script

  • ant command

Install the package by adding a new repo in the package center. Follow the guide at

  • git command
  • java package

Install the packages which are available from Synology repo in package center

You should be now able to check if the above commands exist in the terminal

Docker Compose File

Since I am doing this setup on my existing docker, many of the ports were already in use. So I edited the file to change some default ports

Build It!!!

That’s it guys.. Hard work done. Do the deployment in the following steps

  1. Download Identity IIQ binaries
  2. Install additional packages on the NAS
  3. Login to the NAS and get root access
  4. Download the repo
  5. Upload the and identityiq.war downloaded previously to the sailpoint-docker folder
  6. Edit the and docker-compose.yaml file as mentioned above.
  7. Run the rest of the commands

And you see the nice logs

Took around 30 min (apart from couple of hours of research) for the whole build to download various images and create containers and start them up. I kept an eye on the docker logs to see the status

(not the full list above – few more there)

And finally once everything was running and settled I tried going to the IIQ home page

I didn’t test the full extent of it. But I was able to create a source and test connection which was external to the docker and running on my VMM on the NAS itself.

Till the next time!!! 


AD Home Lab LDAPS Setup for SailPoint IDN TLS Connection

Welcome 2020 (Or not)!!! 

Really this year needs to end. Period. Hope everyone is keeping safe and indoors as much as possible.

Been a while I haven’t written something.

Anyways I had a local VM for Active Directory running for my home lab for SailPoint IDN. Now I wanted to setup TLS connection for it. So I thought easy

  1. Create a csr request in AD
  2. Generate a crt
  3. Import the cert in AD
  4. Test Connection via ldp or IDN.

I didn’t want to go through installing a AD CA role for this one process. So I thought I will use OpenSSL which was installed on my Mac. There are many excellent guides on how to enable LDAPS in AD by generating a self signed certificate. By far the easiest I found was this one

But what I found was that the cert being generated didn’t contain the SAN. Found many such issues linked online with openssl command. This is how I fixed it.

Followed the guide till where v3ext.txt is being generated. But used my own as below

The IP Address and additional DNS is just an example. My domain name in example is “abc.local” and DC name is “”. You can add additional DNS entries as per your requirements

And modified the command to execute this file

Rest is all the same in guide. You will get the certificate generated with SAN and imported into your DC. LDAPS will work and IDN and IQService will connect via TLS. And forget about it for 10 years 😛 

Aah the green box of approval from IDN!!! Gods are happy & everything is good in world again!!! 

Hope it helps someone setup their own AD lab at home for AD LDAPS TLS connection without a CA server. Of course this will not be a problem in an enterprise deployment.


%d bloggers like this: