Mappages d'attributs Active Directory avec les propriétés Okta
Le tableau suivant présente la façon dont les propriétés Okta sont mappées avec les attributs Active Directory (AD) correspondants.
Attribut natif Active Directory : il s'agit du nom de l'attribut dans AD.
Attribut affecté à l'application AD par Okta : il s'agit du nom utilisé par Okta pour appeler les attributs AD natifs lorsque AD est défini comme une application au sein d'Okta. Cette valeur apparaît dans le profil utilisateur sur l'application.
Attribut Okta natif : il s'agit du nom de l'attribut Okta natif.
Obligatoires par Okta : Okta requiert la présence de certains attributs de base dans un profil utilisateur Okta. "Oui" indique que l'attribut est obligatoire par Okta. Consultez Types de profil.
Direction de mappage AD dans Okta : indique s'il existe une propriété Okta correspondant à l'attribut AD.
Direction de mappage Okta vers AD : indique s'il existe un attribut Okta correspondant à la propriété AD.
|
Attribut Active Directory natif |
Attribut affecté à AD par Okta |
Attribut Okta natif |
Obligatoire par Okta |
Mappage : AD dans Okta |
Mappage : Okta vers AD | Remarques |
|---|---|---|---|---|---|---|
| distinguishedName | dn | dn | Oui | Oui | Oui | |
| givenName | firstName | firstName | Oui | Oui | Oui | |
| Oui | Oui | Oui | ||||
| objectGUID | externalId | externalId | Oui | Oui | Oui | |
| objectSid | objectSid | objectSid | Oui | Oui | Oui | |
| primaryGroupID | primaryGroupID | primaryGroupID | Oui | Oui | Oui | |
| userPrincipalName* | userName | userName, email, login | Oui | Non | Oui |
Utilisé uniquement si l'e-mail n'est pas défini. Disponible en tant que préférence de nom d'utilisateur Okta, avec e-mail, UPN, et sAMAccountName. S'il est sélectionné, le nom d'utilisateur Okta est créé via la combinaison du sAMAccountName et du nom de domaine AD (contexte du nommage) afin de constituer une valeur similaire à un e-mail. |
| sn | lastName | lastName | Oui | Oui | Oui | |
| SAMaccountName | SAMaccountName | substringBefore(user.login, \"@\") | Non | Non | Oui | |
| c | countryCode | countryCode | Non | Oui | Oui | |
| cn | cn | user.firstName + \" \" + user.lastName | Non | Non | Oui | |
| co | co | co | Non | Oui | Oui | |
| countryCode | adCountryCode | countryCode | Non | Oui | Oui | |
| département | département | département | Non | Oui | Oui | |
| departmentNumber | departmentNumber | departmentNumber | Non | Oui | Oui | |
| displayName | displayName | displayName | Non | Oui | Oui | |
| division | division | division | Non | Oui | Oui | |
| employeeID | employeeID | employeeID | Non | Oui | Oui | |
| employeeNumber | employeeNumber | employeeNumber | Non | Oui | Oui | |
| generationQualifier | honorificPrefix | honorificPrefix | Non | Oui | Oui | |
| l | ville | ville | Non | Oui | Oui | |
| managerDN | managerDN | managerDN | Non |
S'il existe une valeur de responsable issue de Workday ou de toute autre application dans Okta, et que cette valeur peut être représentée comme managerDN dans AD, utilisez le mappage managerDN. Dans ce cas, le responsable peut être situé sur un autre domaine que l'utilisateur. |
||
| managerUPN | managerUpn | managerUpn | Non | Oui | Oui |
S'il existe une valeur de responsable issue de Workday ou de toute autre application dans Okta, et que cette valeur peut être représentée comme managerUPN dans AD, utilisez le mappage managerUpn. Dans ce cas, le responsable doit être situé sur le même domaine que l'utilisateur. |
| middleName | middleName | middleName | Non | Oui | Oui | |
| mobile | mobilePhone | mobilePhone | Non | Oui | Oui | |
| personalTitle | honorificSuffix | honorificSuffix | Non | Oui | Oui | Certaines instances AD sont susceptibles d'utiliser l'attribut honorificSuffix au lieu de personalTitle, qui apparaissent dans Okta sous la forme active_directory.honorificSuffix. Il s'agit d'un comportement attendu lorsque vous travaillez avec des intégrations AD créées avant octobre 2019. |
| postalCode | postalCode | zipCode | Non | Oui | Oui | |
| preferredLanguage | preferredLanguage | preferredLanguage | Non | Oui | Oui | |
| st | état | état | Non | Oui | Oui | |
| streetAddress | streetAddress | streetAddress | Non | Oui | Oui | |
| telephoneNumber | telephoneNumber | telephoneNumber | Non | Oui | Oui | |
| title | title | title | Non | Oui | Oui |
-
Remarque : le schéma de profil utilisateur sur l'application AD nécessite un nom de famille et un prénom, contrairement au profil utilisateur Okta, sur lequel cela est facultatif. De cette façon, vous pouvez créer un utilisateur sourcé depuis Okta sans prénom ni nom de famille, mais vous ne pourrez importer un utilisateur AD sur Okta sans prénom ni nom de famille aujourd'hui.
- Si un attribut AD obligatoire par Okta n'est pas inclus sur un profil utilisateur, l'utilisateur sera ignoré. Fait exception l'attribut e-mail d'Okta, qui est obligatoire. Si l'attribut d'e-mail d'un objet utilisateur AD n'est pas renseigné, il le sera avec la valeur userPrincipalName.
- Si l'attribut isCriticalSystemObject est défini sur true (vrai), l'utilisateur est omis. Ce paramètre est principalement dédié aux comptes internes utilisés par le système. Il inclut également divers comptes intégrés tels que Administrator (Administrateur).
- Si un attribut personnalisé est indiqué comme obligatoire sur le Profile Editor (en d'autres termes, la mention Attribut requis est sélectionnée dans la boîte de dialogue Ajouter un attribut, et qu'aucun champ correspondant n'existe sur le profil AD de l'utilisateur, l'utilisateur ne sera plus approvisionné à la prochaine importation, ou si JIT est activé, à la prochaine connexion de l'utilisateur.
- Mapper managerUPN ou managerDN de façon erronée pourrait entraîner l'échec de la mise à jour de l'objet utilisateur sur AD via la valeur du responsable.
- S'il existe une valeur de responsable issue de Workday ou de toute autre application dans Okta, et que cette valeur peut être représentée comme managerUPN dans AD, utilisez le mappage managerUpn. Dans ce cas, le responsable doit être situé sur le même domaine que l'utilisateur.
- S'il existe une valeur de responsable issue de Workday ou de toute autre application dans Okta, et que cette valeur peut être représentée comme managerDN dans AD, utilisez le mappage managerDN. Dans ce cas, le responsable peut être situé sur un autre domaine que l'utilisateur.
Le système considère les utilisateurs précédemment importés comme supprimés si n'importe laquelle des conditions suivantes est vraie :
-
L'attribut userAccountControl indique que l'utilisateur a été désactivé. (Détection via une importation incrémentielle ou une connexion JIT)
-
L'utilisateur n'existe plus dans le répertoire. (Détection via une importation complète uniquement)
Si cela se produit, l'utilisateur Okta correspondant sera, le cas échéant, désactivé. Les utilisateurs sont aussi désactivés lorsqu'ils ne sont pas inclus dans la sélection d'une OU durant la prochaine importation complète.