Active Directory account already exists // IIQ

IdentityIQ (IIQ) IIQ Discussion and Questions
, ,
1

Which IIQ version are you inquiring about?

Version 8.3

Share all details related to your problem, including any error messages you may have received.

There is a big problem in our IIQ integration.

Currently, we are provisioning AD account via provisioning policy form, where all of the data we need is generated.
The main issue here is in the sAMAccountName attribute.
In the form the sAMAccountName using such a template [return “LastName” + “-” + “Initials”;]
That template works fine and creating the account for new employees.

But, as the company policy, we store terminated accounts in the dedicated OU=Terminated Users for a few years and if the user is re-employed in the company this account isn’t getting unblocked and removed from the specified OU, but the new account is creating with the next template [return “LastName”+“-”+“Initials”+n;] (where “n” is the 1, 2, 3, 4… as the quantity of accounts).

So, as the part of integration we need to specify the account creation with the last one template if the user account already exists in the AD. But the error is returned by the IQService and not directly by IIQ and we cannot catch the error before the account provisioning starts.

I know that we could use the Before Provisioning Rule to achieve our goal with the policy, but I couldn’t find any IIQ functions or instruments to use in the rule for catching this error.
Also, I’ve already contacted the Support Team but they don’t have any useful links for this issue…

I would be glad to hear any advice or workarounds for this issue.

Thanks in advance!

2

Hi Danylo,
This is quite common usecase as some attributes in AD needs to be unique across the whole AD universe.

There are at least few options how you can solve this issue - all of them will have some pros and some cons so in the end you have to decide into which direction you’d like to go.

  1. First option is to check in the field value rule for the attributes that needs to be unique if this account does not exist already. You can use for example query options to find previous link of a person who is rehired or in the perfect word this link should anyway be correlated to this identity as it’s not a good practice to have more than one identity for a single person.

Pros:

  • It’s fast
  • Supports most of situations

Cons:

  • Relies on Sailpoint data only that means all data needs to be aggregated first
  1. Second approach is to do the same as point 1 - but instead of checking internaly in sailpoint - execute ldap search to AD to check if this attribute value is free to be used.

Pros:

  • Most reliable - you always check what is in AD

Cons:

  • LDAP connection will be slow
  • You have to have network connectivity between IIQ hosts and AD
  1. Third solution - is to change value generation template in the way it would add some random seed into the attribute.

Pros:

  • Fastest solution
  • Almost transparent for end users

Cons:

  • Non deterministic - in very small amount of cases you may still have conflicts
  • Does not look nice for end users
  1. You can check provisioning status in after provisioning rule and if error occured you can restart provisioning with different values.

Pros:

  • No performance degradation for MOST of users
  • No added logic for MOST of users
  • Fix works only for Affected users

Cons:

  • Extensive effort to retry provisioning and detect it in after provisioning rule
  • Reactive solution

You can use both solutions in either field value rule or before provisioning rule. Decision you make will of course impact end user experiance.

2 Likes
3

Hi Kamil!

Thanks for such a fast response and detailed info.

Probably the best way for us will be to use 4th direction.
Because the AD account provisioning is the part of joiner event (the system hasn’t correlated accounts from AD at this point), direct connection between IIQ and AD is not planned in the architecture and the random seed wouldn’t be accepted by the clients policy.

Is it possible that you know any way to catch the error returned from the IQService at this point?
Previously I’ve found the code like this:

AccountRequest accountRequest : plan.getAccountRequests("Active Directory PH Accounts";
if(accountRequest != null && accountRequest.getResult().getStatus().equalsIgnoreCase("failed"))

Thank you again! I really apreciate your help!

4

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.