Active Directory属性のOktaプロパティへのマッピング

次の表は、Oktaのプロパティが対応するActive Directory（AD）属性にどのようにマッピングされるかを示しています。

ネイティブActive Directory属性（Native Active Directory attribute） ：これはAD内の属性名です。

OktaによってADアプリに割り当てられた属性（Attribute assigned to the AD app by Okta）：これは、ADがOkta内でアプリとして設定されている場合に、ネイティブAD属性を呼び出すためにOktaが使用する名前です。この値は、アプリのユーザープロファイルに表示されます。

ネイティブOkta属性（Native Okta attribute） ：これはネイティブOkta属性名です。

Oktaで必須（Required by Okta）：Oktaでは、Oktaユーザープロファイルに特定の基本属性が必要です。［Yes（はい）］は、属性がOktaで必須であることを示します。「プロファイルタイプについて」を参照してください。

ADからOktaへのマッピング（Mapping Direction AD to Okta）：AD属性に対応するOktaプロパティがあるかどうかを示します。

OktaからADへのマッピング（Mapping Direction Okta to AD）：Oktaプロパティに対応するAD属性があるかどうかを示します。

• 任意のOktaユーザープロファイルとは異なり、ADアプリのユーザープロファイルスキーマには姓名が必要となります。したがって、現在は、Oktaソースのユーザーであれば姓名を使用せずに作成することができますが、姓名のないADユーザーをOktaにインポートすることはできません。

• Oktaで必須のAD属性がユーザーのプロファイルにない場合、そのユーザーは無視されます。例外はOktaで必須のemail属性です。ADユーザーオブジェクトのemail属性が入力されていない場合は、userPrincipalName値が入力されます。
• isCriticalSystemObject属性がtrueに設定されている場合、そのユーザーは省略されます。この設定は大半がシステムで使用される内部アカウント用ですが、管理者（Administrator）のような様々な組み込みアカウントも含まれています。
• カスタム属性がProfile Editorで必須とマークされていて（つまり、属性を追加（Add Attribute）ダイアログで必須属性（Attribute required）が選択されている場合）、対応するフィールドがユーザーのADプロファイルに存在しない場合、ユーザーは次のインポート中にデプロビジョニングされます。JITが有効な場合は、ユーザーの次回ログイン時にデプロビジョニングされます。
• managerUPNまたはmanagerDNを誤ってマッピングすると、マネージャー値のユーザーオブジェクトがADで更新できなくなります。
  • Workdayやその他のアプリケーションからOktaを通じて取得したマネージャー値があり、その値がADでmanagerUPNと表示される場合は、managerUpnマッピングを使用します。このとき、マネージャーとユーザーのドメインが同じになっている必要があります。
  • Workdayやその他のアプリからOktaを通じて取得したマネージャー値があり、その値がADでmanagerDNと表示される場合は、managerDnマッピングを使用します。この場合、マネージャーのドメインはユーザーと異なる可能性があります。

次のいずれかの条件を満たす場合、システムでは以前にインポートされたユーザーが削除済みとして処理されます。

• userAccountControl属性が、ユーザーが非アクティブ化されていることを示している（増分インポートまたはJITサインインによって検出されます）。

• ユーザーがディレクトリからいなくなる（フルインポートによってのみ検出されます）。

上記が発生した場合、対応するOktaユーザー（存在する場合）が非アクティブ化されます。次のフルインポート中にユーザーがOUの選択を解除した場合も、ユーザーは非アクティブ化されます。