It was brought to our attention that the current build of userid creation in NERM is starting to cause issues with critical systems. The issue we are having is that the userid is greater then 10 charters long. We have some older systems that do not support a userid to longer then 10.
What I am struggling with is how to do a duplicate check using advanced search api. I need to do an advanced search if any results are returned then rerun the value build until it finds a unique value.
I did try to mark the attribute as unique and when a duplicate was found would cause the workflow fail. If I remove that flag and use the built in duplicate checker then the user is prompted to select a profile. Which is no ideal as users will not read the message and just select the profile which will cause lots of down stream issues.
So now I am turning to api’s to try and do the behavior we want. We are looking for a quick fix to our issue until we can build out the more stable solution of a cloud rule in IdN which is going to take time build and test. And my goal is to stop the large user ids being created. Any advice is welcome within the constants I currently have.
In your step where you’re checking SailPointID using the advanced search API, you may need to map a temporary variable to one of the returned values if it’s not unique. In the next condition, check whether that temporary variable is present—if it’s not, the ID is unique, and you can use the generated value. If it is present, use “Set Attribute Value” to trigger the value builder again and apply the same condition.
Unfortunately, there’s no way to loop until a unique value is found. So, depending on the potential number of failed uniqueness checks, you may need to add multiple condition checks to account for those scenarios.
Not 100% sure if I have either of these configured correctly. What you described is what I am looking to do. While in testing we have the random number set to 1 so that we can quickly address this issue. Once we can get the behavior we want then we will be increasing it 2 to give a much larger pool of numbers that could be used.
How would you recommend wiring this logic up? Once I have one check working it will be easy to add additional checks to verify.
In the following step, I am checking if this variable is present or not, if its present, then I remove this uniqueness flag and regenerate the username else I use it.
Ok so now that I updated the logic I am now seeing that the api calls are being made as expected. However the issue I am running into now is that the value is always evaluating to true causing every run to trigger the id creation.
I am just repeating the same step over and over again to see if we get an id not in use. While testing I had been using the same user first name and last name. When I change the name to create an id that does not exist already I get the same exact log as if the user id already exist. The idea behind these updates is that if an id can not be found is to stop the workflow and not create the id. Once I have this logic worked out then I will figure out how best to handle these situations.
