How can I enforce uniqueness of sAMAccountName when it isn’t the nativeIdentity?

IdentityIQ (IIQ) IIQ Discussion and Questions
1

Which IIQ version are you inquiring about?

8.4

How can I enforce uniqueness of sAMAccountName when it isn’t the nativeIdentity?

2

Hi @mnowosielski,

you must deplay a strong logic to calculate the samaccountname to be sure it will be unique. Thare some logics like name.lastnameSEQUETIAL or you can play with the charaters of name\lastname for example: name.l, name.la, name.las…name.lastname. Usually the logic will be decide by the customer.

In every case before the provisioning you can search on IIQ if that samaccouname exists or search directly on AD if in your IIQ are not present all the account of the domain\s with a LDAP call.

3

You could store it in an identity cube attribute that’s searchable. However, I’ve often seen cases where IIQ isn’t configured to scan the entire AD domain. In those situations, some users might not be visible to the system. Because sAMAccountName must be unique across the domain, that gap can lead to additional issues.

So in the end, I prefer to do the unique search in AD.

4

I’ve dealt with this before, and honestly I wouldn’t rely 100% on IIQ to guarantee uniqueness unless you’re absolutely sure your AD aggregation is complete and up to date. If there’s any lag or partial scope, you can still end up with duplicates.

What worked for us was a mix:

  • Generate a predictable sAMAccountName (first.last + sequence if needed).

  • Before Provisioning rule does a quick check in IIQ and a lightweight LDAP query against AD to make sure the candidate value isn’t already taken.

This way you’re covered both in cases where IIQ has the data and in cases where it doesn’t. It’s a bit of extra complexity, but safer than assuming one source alone will always be right.