We are using Actice Directory User Integration to create new users in IFS.
The FndUserIdentity is taken from &SamAccontName which is in AD an abbreviation of the location and name. In 95% of the users that are created, the abbreviation is used as Identity, but sometimes the FIRSTNAME.LASTNAME is used for the Identity.
I don't understand why the users are created different; we don't see any differences in users in AD.
Does anybody have a clue?
Best answer by Imal Thiunuwan
Hello
Azure AD and Azure AD Domain Services in particular is a little bit special. There are two things to consider. First off, in the case of Azure AD being used for OpenId Connect you will run into issues if the DirectoryId is not set to UserPrincipalName. This is because the tokens issued by Azure AD will always contain the UserPrincipalName.
Second is about the default value of the Identity field being mapped to SAMAccountName. Here you have a bit more options.
The SAMAccountName attribute is constructed from other attributes in such a way to make sure it is unique (Please refer below url for more information).
The reason, it is used for the Identity field in IFS by default. It is also because, it is likely to produce well-formed Oracle Database usernames, which is done during creation. Acting as primary key for the user table and the name of the associated Oracle account is the main purpose of the identity field.
Kindly noted that, the limitations associated with the SamAccountName attribute are imposed by Microsoft and not by IFS. You can concatenate several attributes into a string if you like by using "&GivenName.&Sn" concatenation.
Hope this helps to your question. Kindly noted that this is not a bug.
Cheers!
+16Hello
Could you please let us know if you use Azure AD Domain Services with Active Directory user Integration?
Cheers!
Hi Imal,
Yes, we are using Azure AD Domain Services.
regards,
Camiel
+16Hello
Azure AD and Azure AD Domain Services in particular is a little bit special. There are two things to consider. First off, in the case of Azure AD being used for OpenId Connect you will run into issues if the DirectoryId is not set to UserPrincipalName. This is because the tokens issued by Azure AD will always contain the UserPrincipalName.
Second is about the default value of the Identity field being mapped to SAMAccountName. Here you have a bit more options.
The SAMAccountName attribute is constructed from other attributes in such a way to make sure it is unique (Please refer below url for more information).
The reason, it is used for the Identity field in IFS by default. It is also because, it is likely to produce well-formed Oracle Database usernames, which is done during creation. Acting as primary key for the user table and the name of the associated Oracle account is the main purpose of the identity field.
Kindly noted that, the limitations associated with the SamAccountName attribute are imposed by Microsoft and not by IFS. You can concatenate several attributes into a string if you like by using "&GivenName.&Sn" concatenation.
Hope this helps to your question. Kindly noted that this is not a bug.
Cheers!
Hello
Azure AD and Azure AD Domain Services in particular is a little bit special. There are two things to consider. First off, in the case of Azure AD being used for OpenId Connect you will run into issues if the DirectoryId is not set to UserPrincipalName. This is because the tokens issued by Azure AD will always contain the UserPrincipalName.
Second is about the default value of the Identity field being mapped to SAMAccountName. Here you have a bit more options.
The SAMAccountName attribute is constructed from other attributes in such a way to make sure it is unique (Please refer below url for more information).
The reason, it is used for the Identity field in IFS by default. It is also because, it is likely to produce well-formed Oracle Database usernames, which is done during creation. Acting as primary key for the user table and the name of the associated Oracle account is the main purpose of the identity field.
Kindly noted that, the limitations associated with the SamAccountName attribute are imposed by Microsoft and not by IFS. You can concatenate several attributes into a string if you like by using "&GivenName.&Sn" concatenation.
Hope this helps to your question. Kindly noted that this is not a bug.
Cheers!
Thanks for the explanation. I never thought at is a bug, but just really curious why these names differ.
We also found that LDAPS uses a different SAMaccountName then AD. LDAPS uses the mailNickName as SAMaccountName. And if that is entered wrongly during the creation, there's not much we can do.
We are considering using a different attribute, but we already have 400 users in…
+16
Regarding the “LDAPS uses the mailNickName as SAMaccountName” there is an explanation available in the mentioned url in my previous comment.
Please refer below screenshot.
Cheers!
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
