Hi Team,
We’re working one of the client where they have all attributes values (firstname, lastname, department, Org unit path) have special characters as below. Will identitynow allow Ad account creation with this OU path? Will this encoding supported by Identitynow and IQservice. Will these values not treated as different
CN=Tik Radviliškio traukinių paruošimas,OU=Radviliškio traukinių paruošimas,OU=Traukinių valdymas,OU=Paslaugų teikimas,OU=,OU=Employees,OU=,DC=,DC=***
Hi @seemarani. For Active Directory account creation, it is best practice to convert all diacritic/Umlaut characters to their English equivalent, as some of these characters are not valid for email addresses. We have an out of the box transform that can convert most diacritic characters. However, it won’t catch all as some are special characters that will need to be replaced with a custom lookup transform. The converted values are then used to build provisioning attributes that are compatible with downstream applications.
@colin_mckibben Thanks for the update. Our implementation should support Latin language (IdentityNow supports UTF-8). All attribute values, which is in Latin language, should provision as is to AD. If we only change the Latin characters for email is fine?. Will it impact AD account updates/ creation. I’ll add logic for email separately to remove those characters as you mentioned
You are correct; IDN and Active Directory support UTF-8, but you might see some unexpected behavior in Active Directory and other sources if you don’t convert diacritic characters in commonly used provisioning attributes, like user name and email. One approach you can take is to add additional identity attributes to hold transformed values of attributes that are commonly used in provisioning on sources. For example, firstName can be pulled straight from your authoritative source without any transformation, but you might want to create another identity attribute called preferredName that applies the diacritic transform to the firstName field, which you can then use in any sources that don’t support UTF-8. The same strategy can be used for email. You can create a second attribute called preferredEmail that is transformed.
I spoke to a member of Professional Services, and they suggest building distinguished, displayname, and email address in the Active Directory provisioning profile using transformed values so outlook address book renders them correctly. Ultimately, though, you can attempt to see how active directory will handle non-transformed values before committing your provisioning profile to production.
@colin_mckibben Thanks for the suggestion. All application using the same UTF-8 characters, so does it mean we are good to proceed without removing diacritic marks (Except email and sAMAccountName)
I would test in a staging environment first if possible, just to make sure. Let us know how it goes!
{
"attributes": {
"input": {
"attributes": {
"name": "Rule_Name"
},
"type": "rule"
},
"table": {
"'": "",
",": "",
"-": "",
"_": "",
"~": "",
"À": "a",
"Á": "a",
"Â": "a",
"Ã": "a",
"Ä": "a",
"Å": "a",
"Æ": "a",
"Ç": "c",
"È": "e",
"É": "e",
"Ê": "e",
"Ë": "e",
"Ì": "i",
"Í": "i",
"Î": "i",
"Ï": "i",
"Ð": "d",
"Ñ": "n",
"Ò": "o",
"Ó": "o",
"Ô": "o",
"Õ": "o",
"Ö": "o",
"Ø": "o",
"Ù": "u",
"Ú": "u",
"Û": "u",
"Ü": "u",
"Ý": "y",
"Þ": "y",
"ß": "b",
"à": "a",
"á": "a",
"â": "a",
"ã": "a",
"ä": "a",
"å": "a",
"æ": "a",
"ç": "c",
"è": "e",
"é": "e",
"ê": "e",
"ë": "e",
"ì": "i",
"í": "i",
"î": "i",
"ï": "i",
"ñ": "n",
"ò": "o",
"ó": "o",
"ô": "o",
"õ": "o",
"ö": "o",
"ø": "o",
"ù": "u",
"ú": "u",
"û": "u",
"ü": "u",
"ý": "y",
"ÿ": "y",
"–": "",
"—": ""
}
},
"id": "Eliminate_Special_Chars",
"type": "replaceAll"
}
{attributes=com.sailpoint.seaspray.transform.ConcatTransform@1e55313f}
That is my output when I try to use the in built transform: See below.
Any idea why this is going wrong? I’ve tried wrapping the concat in a static field but no change
"name": "TEST",
"type": "decomposeDiacriticalMarks",
"attributes": {
"input": {
"attributes": {
"type": "concat",
"attributes": {
"values": [
{
"type": "identityAttribute",
"attributes": {
"name": "preferredFirstName"
}
},
" ",
{
"type": "identityAttribute",
"attributes": {
"name": "lastname"
}
}
]
}
}
}
}
I believe there is an extra “attributes” declaration in your transform definition. Try taking out the highlighted line:
Brilliant. Thank you so much. That was driving me crazy