Directory(AD)属性にどのようにマッピングされるかを示しています。:これはAD内の属性名です。OktaによってADアプリに割り当てられた属性:これは、ADがOkta内でアプリとして設定されている場合に、ネイティブAD属性を呼び出すためにOktaが使用する名前です。この値は、アプリのユーザープロファイルに表示されます。:これはネイティブOkta属性名です。Oktaで必須:Oktaでは、Oktaユーザープロファイルに特定の基本属性が必要です。[Yes(はい)]は、属性がOktaで必須であることを示します。「プロファイルタイプについて」を参照してください。ADからOktaへのマッピング:AD属性に対応するOktaプロパティがあるかどうかを示します。OktaからADへのマッピング:Oktaプロパティに対応するAD属性があるかどうかを示します。はいemailが設定されていない場合にのみ使用します。email、UPN、およびsAMAccountNameと一緒に使用できます。メールのような値を形成します。いいえWorkdayやその他のアプリで取得したマネージャー値があり、その値がADでmangerDNと表示される場合は、managerDnマッピングを使用します。この場合、マネージャーのドメインはユーザーと異なる可能性があります。はいWorkdayやその他のアプリケーションで取得したマネージャー値があり、その値がADでmanagerUPNと表示される場合は、managerUpnマッピングを使用します。このとき、マネージャーとユーザーのドメインが同じになっている必要があります。はい任意のOktaユーザープロファイルとは異なり、ADアプリのユーザープロファイルスキーマには姓名が必要となります。したがって、現在は、Oktaソースのユーザーであれば姓名を使用せずに作成することができますが、姓名のないADユーザーをOktaにインポートすることはできません。Oktaで必須のAD属性がユーザーのプロファイルにない場合、そのユーザーは無視されます。例外はOktaで必須のemail属性です。ADユーザーオブジェクトのemail属性が入力されていない場合は、userPrincipalName値が入力されます。isCriticalSystemObject属性がtrueに設定されている場合、そのユーザーは省略されます。この設定は大半がシステムで使用される内部アカウント用ですが、管理者のような様々な組み込みアカウントも含まれています。required(必須属性)]が選択されている場合)、対応するフィールドがユーザーのADプロファイルに存在しない場合、ユーザーは次のインポート中にデプロビジョニングされます。JITが有効な場合は、ユーザーの次回ログイン時にデプロビジョニングされます。managerUPNまたはmanagerDNを誤ってマッピングすると、マネージャー値のユーザーオブジェクトがADで更新できなくなります。Workdayやその他のアプリケーションで取得したマネージャー値があり、その値がADでmanagerUPNと表示される場合は、managerUpnマッピングを使用します。このとき、マネージャーとユーザーのドメインが同じになっている必要があります。Workdayやその他のアプリで取得したマネージャー値があり、その値がADでmangerDNと表示される場合は、managerDnマッピングを使用します。この場合、マネージャーのドメインはユーザーと異なる可能性があります。次のいずれかの条件を満たす場合、システムでは以前にインポートされたユーザーが削除済みとして処理されます。userAccountControl属性が、ユーザーが非アクティブ化されていることを示している(増分インポートまたはJITサインインによって検出されます)。ユーザーがディレクトリからいなくなる(フルインポートによってのみ検出されます)。上記が発生した場合、対応するOktaユーザー(存在する場合)が非アクティブ化されます。次のフルインポート中にユーザーがOUの選択を解除した場合も、ユーザーは非アクティブ化されます。それぞれの商標は、それぞれの商標所有者に帰属します。