このトピックでは、Identity as a Service (IDaaS) を Active Directory (AD) に接続する方法と、実行できる一般的な操作について説明します。
AD について
概要
AD は、Microsoft Windows Server 上で実行されるディレクトリサービスです。 AD を使用すると、管理者は、中規模および大規模ネットワーク環境のドメイン内で、コンピューター、ユーザーサービス、ネットワークリソース、および権限を一元的に管理できます。
ネットワークエンドポイント 機能を使用すると、パブリックポートを開くことなく、AD からデータを同期し、AD に認証を委任できます。
手順
IDaaS コンソールにログオンします。 EIAM ページで、必要なインスタンスをクリックします。 左側のナビゲーションペインで、[クイックスタート] または [idp] をクリックします。 表示されるページで、[AD のバインド] をクリックします。
ステップ 1:AD への接続ステップでパラメーターを設定する
IDaaS で次のパラメーターを設定します。
ニックネーム:ユーザーが IDaaS にログオンして使用するときにユーザーに表示される名前。
ネットワークアクセスエンドポイント:IDaaS インスタンスのネットワークエンドポイント。 IDaaS のみが AD サーバーにアクセスできるようにするには、ネットワークエンドポイントを AD サーバーの IP アドレスホワイトリストに追加します。 IDaaS インスタンスが共有エンドポイントを使用する場合、IDaaS インスタンスには、共有の固定パブリックアウトバウンド IP アドレスが提供されます。 IDaaS インスタンスが専用エンドポイントを使用する場合、IDaaS インスタンスには、専用のプライベートアウトバウンド IP アドレスとパブリックアウトバウンド IP アドレスが提供されます。 専用エンドポイントで設定された IDaaS インスタンスは、専用エンドポイントを使用して Alibaba Cloud 仮想プライベートクラウド (VPC) にアクセスできます。 この方法で、パブリックポートを開くことなく、IDaaS インスタンスが AD にアクセスできるようにすることができます。 詳細については、「エンドポイント」をご参照ください。
サーバーアドレス:AD が存在するサーバーのアドレス。 例:127.0.0.1:389。 デフォルトでは、ポート 389 が AD に使用されます。 LDAPS または StartTLS が有効になっている場合は、ポート 636 が使用されます。
StartTLS を有効にする:StartTLS を有効にするかどうかを指定します。 接続のセキュリティを向上させるために、LDAPS または StartTLS を有効にすることをお勧めします。 LDAPS または StartTLS を有効にする方法の詳細については、このトピックのAD セキュリティ設定セクションをご参照ください。
管理者アカウント:IDaaS がデータ同期または委任認証のために AD 情報を読み取るために使用する AD 管理者アカウント。 アカウントには、少なくとも読み取り権限が必要です。 example@example.com などのユーザー プリンシパル名 (UPN) 形式、または cn=admin, ou=technical department, dc=example, dc=com などの識別名 (DN) 形式で値を入力します。
管理者パスワード:管理者アカウントのログオンパスワード。
ステップ 2:シナリオの選択ステップでパラメーターを設定する
このステップでは、使用する機能を設定します。
機能
同期方向:ソースコードとして選択された AD ユーザーまたは組織のデータが IDaaS の宛先ノードにインポートされます。 AD ノードの DN をソースノードとして入力します。 AD ルートノードの DN は dc=example, dc=com(あなたのドメイン)です。
AD から IDaaS への同期のみがサポートされています。 IDaaS から AD への同期はサポートされていません。
増分同期:IDaaS は AD ユーザーまたは組織のデータをリッスンし、変更されたデータを 10 分ごとに AD から IDaaS に同期します。 1 回の同期に大量のデータが関係する場合、遅延が発生する可能性があります。 AD と IDaaS 間のデータの整合性を確保するために、定期的に完全データ同期を実行することをお勧めします。
IDaaS アカウントのフィールドマッピングステップで、マッピング識別子を AD ユーザーのフィールドに設定できます。 たとえば、IDaaS アカウントの携帯電話番号フィールドを AD ユーザーの携帯電話番号フィールドと照合できます。 照合が成功し、AD ユーザーが更新されると、IDaaS アカウントも AD ユーザーから更新されます。 照合に失敗した場合、AD ユーザーの情報を使用して IDaaS アカウントが作成されます。
増分同期が初めて実行されると、完全データ同期が自動的に実行されます。
単一のデータエントリのインポートに失敗しても、他のデータエントリのインポートには影響しません。
失敗情報は同期ログで確認できます。
AD で削除イベントに関するメッセージを受信するには、ADのごみ箱を有効にする必要があります。 この機能を有効にする方法の詳細については、このトピックの増分同期セクションをご参照ください。
委任認証:この機能が有効になっている場合、ユーザーは AD のユーザー名とパスワードを使用して IDaaS にログオンできます。
自動パスワード更新:ユーザーが AD 委任認証を使用して IDaaS にログオンしようとするときに、IDaaS アカウントのパスワードが空の場合、パスワードは AD ユーザーのパスワードとして自動的に更新されます。 AD パスワードは、IDaaS のパスワードポリシーで指定された要件を満たしている必要があります。 そうしないと、IDaaS パスワードを AD パスワードに自動的に更新できません。
詳細設定
ユーザー/組織
ObjectClass
:ObjectClass
を使用して、オブジェクトのタイプをユーザーまたは組織として定義できます。 たとえば、クエリ結果でObjectClass が user
であるオブジェクトはユーザーと見なされます。 ほとんどの場合、変更は必要ありません。ユーザーサインイン ID:ユーザーが AD 委任認証を使用して IDaaS にログオンしようとすると、IDaaS は属性を使用して AD 内のユーザーをクエリし、パスワードを照合します。 パスワードが正しい場合、ユーザーは IDaaS にログオンできます。 複数の属性をコンマ (,) で区切ることができます。 この場合、これらの属性には OR 関係があります。 つまり、それらのいずれかを使用して IDaaS にログオンできます。 複数の属性が同じ AD ユーザーに対応していることを確認してください。 そうしないと、ユーザーは IDaaS にログオンできません。
ユーザーをフィルタリングするための FILTER ステートメント:特定のユーザーを異なる組織から IDaaS に同期する場合、カスタム
filter
ステートメントを使用してユーザーをフィルタリングできます。 フィルター条件を満たすユーザーのみが IDaaS に同期できます。 デフォルトでは、filter
ステートメントには、AND 関係のObjectClass
条件が含まれています。 [詳細の表示] をクリックして、完全なステートメントを表示できます。 詳細については、このトピックのフィルターセクションをご参照ください。
ステップ 3:フィールドマッピングステップでパラメーターを設定する
IDaaS に既にアカウントまたは組織があり、それらを AD ユーザーまたは組織にマップする場合、または IDaaS アカウントの特定のフィールドを AD ユーザーのフィールドとして使用する場合、フィールドマッピングを設定する必要があります。 たとえば、IDaaS アカウントの名前を AD ユーザーの携帯電話番号として使用する場合、フィールドマッピングを設定する必要があります。
詳細については、「フィールドマッピング」をご参照ください。
AD セキュリティ設定
デフォルトでは、データは AD で暗号化または保護なしでプレーンテキストで送信されます。 これにより、データの盗難が発生する可能性があります。 LDAPS または StartTLS を使用して、データ送信のセキュリティを向上させることができます。 AD で証明書を設定した後、IDaaS で LDAPS または StartTLS を使用できます。 LDAPS または StartTLS を有効にすることをお勧めします。
サーバーマネージャーで、ロールをインストールし、サーバーをドメインサーバーにアップグレードし、証明書を追加し(署名アルゴリズムとして SHA256 を使用)、証明書を設定します。
証明書を設定した後、IDaaS で証明書のフィンガープリントを取得して、AD 証明書に対する IDaaS の信頼を構築できます。 これにより、偽の証明書のリスクが軽減されます。
AD に表示される証明書のフィンガープリントが IDaaS から取得したものと同じかどうかをすばやく確認する必要がある場合は、次のスクリプトを実行します。
openssl s_client -connect server_host:port | openssl x509 -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256
AD カスタム設定
ObjectClass
AD の ObjectClass
は属性のセットです。 各オブジェクトには ObjectClass
が必要です。 ObjectClass
を使用して、オブジェクトをユーザー、組織、またはコンピューターとして定義できます。 たとえば、次の図に示すように、システムは objectclass=person
または objectclass=user
ステートメントを使用してユーザーを見つけることができます。 AD オブジェクトの [属性] で ObjectClass
を表示できます。
ユーザーサインイン ID
ユーザーが AD 委任認証を使用して IDaaS にログオンしようとすると、IDaaS は属性を使用して AD 内のユーザーをクエリし、パスワードを照合します。 パスワードが正しい場合、ユーザーは IDaaS にログオンできます。
userPrincipalName、sAMAccountName、携帯電話番号、メールアドレス、従業員番号などの属性のいずれかを使用して IDaaS にログオンできます。 アイデンティティプロバイダー (IdP) を作成するとき、または委任認証ページで属性を定義できます。 複数の属性を使用する場合は、属性が一意であり、同じ AD ユーザーに対応していることを確認してください。 そうしないと、ユーザーは委任認証を使用できません。
フィルター
ObjectClass
条件と filter
ステートメントの変更は、AD ノードのフィルター条件に影響します。 完全データ同期中に、フィルター条件を満たさない IDaaS アカウントと組織は削除されます。 ObjectClass 条件と filter ステートメントを変更する前に、同期保護設定を調整し、フィルターされた結果が期待どおりであるかどうかを完全にテストすることをお勧めします。 たとえば、別の IDaaS インスタンスを使用してテストを実行できます。
概要
特定のユーザーを異なる組織から IDaaS に同期する場合、カスタム filter
ステートメントを使用してユーザーをフィルタリングできます。 フィルター条件を満たすユーザーのみが IDaaS に同期できます。 デフォルトでは、filter
ステートメントには、AND 関係の ObjectClass
条件が含まれています。 [詳細の表示] をクリックして、完全なステートメントを表示できます。
以下のセクションでは、AD の一般的な演算子と filter
ステートメントについて説明します。
一般的な演算子
演算子 | 説明 | 例 |
= | 等しい | (cn=Alice) |
>= | 以上 | (pwdLastSet>=1319563845000000000) |
<= | 以下 | (sAMAccountName<=a) |
& | AND 関係。すべての条件を満たす必要があることを示します | (&(cn=CN*)(memberOf=cn=Test,ou=HQ,dc=Domain,dc=com)) |
| | OR 関係。少なくとも 1 つの条件を満たす必要があることを示します | (|(cn=Test*)(cn=Admin*)) |
! | NOT 関係。すべての条件を満たさない必要があることを示します | (!(memberOf=cn=Test,ou=HQ,dc=Domain,dc=com)) |
一般的なステートメント
シナリオ | 例 |
ユーザー名が CN で始まるユーザーを選択する | (cn=CN*) |
指定されたメールアドレスを持つユーザーを選択する | (|(proxyAddresses=*:alice@example.com)(mail=alice@example.com)) |
指定されたグループのユーザーを選択する | (memberOf=cn=Test,ou=HQ,dc=Domain,dc=com) |
AD 同期設定
ベース DN を取得する
ベース DN は、AD 内のノードのパス識別子です。 IDaaS は、このノード内でのみクエリやデータ同期などの操作を実行します。 ソースノードのベース DN は、同期方向で設定できます。
DN の形式は ou=organization, dc=example, dc=com です。 ルートノードの DN は dc=example, dc=com(あなたのドメイン)です。 次の図に示すように、AD 管理センターでノードの DN を表示することもできます。
ノードのパスが変更されると、ノードのベース DN も変更されます。 ノードパスの変更によって発生する AD データ同期のエラーを防ぐために、IDaaS は、IDaaS でソースノードのベース DN を設定するときに、ノードの ObjectGuid
をノードフィンガープリントとして使用します。 ノードの変更されたベース DN がノードフィンガープリントと一致しない場合、データ同期は停止します。 ソースノードを再設定した後にデータを同期できます。
増分同期
IDaaS は AD ユーザーまたは組織のデータをリッスンし、変更されたデータを 10 分ごとに AD から IDaaS に同期します。 1 回の同期に大量のデータが関係する場合、遅延が発生する可能性があります。 AD と IDaaS 間のデータの整合性を確保するために、定期的に完全データ同期を実行することをお勧めします。
AD 増分同期の制限により、IDaaS は AD のごみ箱を使用して削除イベントに関するメッセージを取得する必要があります。 [AD 管理センター]でごみ箱機能を有効にします。 この機能は、Windows Server 2012 以降でサポートされています。