Share all details about your problem, including any error messages you may have received.
I need to configure a unique application attribute, userName, which is not a nativeIdentity, during account creation.
Is there a way to search for existing accounts based on an account attribute without using a direct databse query?
For example, I want to search AD accounts based on the sAMAccountName attribute , which is not set as the nativeIdentity. This is to ensure that no account already exists with the same sAMAccountName before assising it.
I am currently looking for an option to achieve this without relying on direct DB query. Any guidance or examples would be appreciated.
This is a common requirement in IIQ when you need to ensure uniqueness of an account attribute (like sAMAccountName) that is not the nativeIdentity.
There are a few approaches you can take in 8.4 without relying on direct database queries:
1. Map it as nativeIdentity (if possible).
If you can make sAMAccountName the nativeIdentity for the AD application, uniqueness will be enforced automatically by IIQ. This is the cleanest option.
2. Pre-provisioning check.
You can add a rule that runs before account creation to query existing Links for AD and check if the same sAMAccountName already exists. If it does, the rule can block the provisioning with a clear error. This prevents duplicates at the provisioning layer.
3. Advanced Policy.
If you want governance visibility, you can create an Advanced Policy that inspects access requests for AD, looks at the sAMAccountName value, and raises a Policy Violation if a duplicate exists. With “Deny on violation,” the request will be blocked.
4. UI-level validation.
As a nice addition, you can mark the field as required on the form and add a validation rule to warn the requester if the value already exists. This improves the user experience, but it shouldn’t be the only control.
Best practice note: if uniqueness is business-critical, making sAMAccountName the nativeIdentity is the most reliable. If that’s not possible, a combination of pre-provisioning check and/or Advanced Policy is the usual way to handle this.