Users created via Active Directory User Integration sometimes get their Identity set to an abbreviated SamAccountName-style value, and other times to a FIRSTNAME.LASTNAME-style value, with no obvious difference visible in AD itself — why is the mapping inconsistent, and what controls it?

All FAQ questions / Security and access

Answer

Two separate things are at play. First, if Azure AD is being used for OpenID Connect authentication, the DirectoryId field specifically needs to be mapped to UserPrincipalName rather than SamAccountName, since tokens issued by Azure AD always carry UserPrincipalName — using SamAccountName for DirectoryId in that scenario causes login problems. Second, for the Identity field itself, IFS defaults to mapping it from SamAccountName specifically because Microsoft's own AD synchronization logic guarantees SamAccountName is unique and tends to produce well-formed Oracle database usernames — but SamAccountName's own internal construction rules (which vary based on how AD itself resolves naming conflicts) are entirely a Microsoft-imposed behavior, not something IFS controls, and can occasionally produce a different-looking value for some accounts than others even without any visible difference in AD. If a more predictable, consistent Identity value is needed instead of relying on SamAccountName's behavior, concatenating specific AD attributes directly (e.g. &GivenName.&Sn) is a supported alternative mapping.

Documentation-based answer. Confirm the product and release before applying it. This answer has not been verified in an IFS environment.

← Browse Security and access questions