Japan Azure Identity Support Blog https://docs.microsoft.com/archive/blogs/jpazureid/feed.xml 日本マイクロソフトの Azure Active Directory と AD FS に関するサポート情報のブログです。 Wed, 20 Feb 2019 08:15:05 GMT ja hourly 1 入れ子 (ネスト) グループへの権限付与について https://docs.microsoft.com/archive/blogs/jpazureid/nesting-group Wed, 06 Feb 2019 19:11:06 GMT https://blogs.technet.microsoft.com/jpazureid/?p=6065 こんにちは、 Azure Identity の平形です。 今回は Azure AD における入れ子 (ネスト) グループの対応状況についてお伝え致します。     ------------------------------------------------------ 入れ子のグループとは ------------------------------------------------------ そもそも入れ子のグループとは、グループの中にグループを所属させているグループを指します。 以下の図をご覧ください。 この場合はグループ A が入れ子のグループです。 グループ A の中にはグループ B とユーザー B が含まれています。 そしてユーザー A はグループ B に含まれている状態ですが、グループ A に含まれていると考えて良いかが今回のテーマです。   例えば、アクセス権限をグループ A に割り当てた場合、ユーザー A に対してもアクセス権限が割り当てられることが期待されますが、 Azure AD の機能によっては必ずしもそうならず、いくつかの制限事項があります。 ここではよくお問い合わせ頂く制限事項についてご紹介します。     ------------------------------------------------------ Azure AD における入れ子グループの制限 ------------------------------------------------------ 主にお問い合わせ頂く機能の中で、現時点では以下の機能については入れ子グループに対応していません。   ・ グループ ベースのライセンス付与 ・ エンタープライズ アプリケーションのユーザー・グループの割り当て   上記はグループに直接所属しているユーザーにしか付与・割り当ては行われません。 一方、条件付きアクセスの機能でグループを条件として設定した場合、入れ子のグループにも対応しており、上の例でいえばグループ A を対象とした条件付きアクセス ポリシーは、ユーザー A も対象になります。   実際のシナリオを考えてみましょう。 グループ A に対して例えば Office 365 E3 のライセンスを割り当てた場合、先程の図のパターンに当てはめると以下のように表せます。   例 : グループ A に権限を割り当てた場合 ユーザー A はグループ A の直属のメンバーでは無いため、グループ A にライセンスを割り当てても、配下のグループ B に所属しているユーザー A に対してはライセンスが付与されません。ユーザー B はグループ A に直接参加しているため、問題なく権限が割り当てられます。 このシナリオは Office 365 E3 のライセンスを割り当てた場合としましたが、エンタープライズ アプリケーションの割り当ての場合にも同様の動作となります。   - 参考情報 Azure Active Directory のライセンス管理にグループを使用する際のシナリオ、制限、および既知の問題 https://docs.microsoft.com/ja-jp/azure/active-directory/users-groups-roles/licensing-group-advanced   SaaS アプリケーションへのアクセスをグループで管理する https://docs.microsoft.com/ja-jp/azure/active-directory/users-groups-roles/groups-saasapps   - 備考 グループの入れ子については多くのお客様よりフィードバックをいただいており、弊社開発部門も実装を検討しています。 https://feedback.azure.com/forums/169401-azure-active-directory/suggestions/15718164-add-support-for-nested-groups-in-azure-ad-app-acc   上記のフィードバックサイトは開発部門が閲覧しており、フィードバックが多い機能や要望は今後の Azure 機能拡張の参考にしています。 グループの入れ子については、階層が深い場合の処理、グループの入れ子構造がループしている場合の検出など技術的に考慮すべき部分もあって現状はサポートされていないという状況でもあるのですが、グループの入れ子に対応していないことで不便さを感じられている方は、是非上記のフィードバック サイトから投票ください。]]> Azure AD サインイン ログ 取得方法まとめ https://docs.microsoft.com/archive/blogs/jpazureid/signin-log-summary Mon, 04 Feb 2019 16:45:19 GMT https://blogs.technet.microsoft.com/jpazureid/?p=6035 Azure Identity チームの三浦です。今回は Azure AD のサインイン ログ取得方法についてまとめました。 Azure AD のサインイン ログは Azure ポータルで確認するほかに次のような方法で確認することができます。   1. ポータルから CSV 形式のファイルをダウンロード 2. ポータルから取得したスクリプトを利用して CSV 形式のファイルを取得する 3. API を利用して CSV 形式のファイルを取得する 4. データをエクスポートし、 PowerBI で解析する 5. Log Analytics に統合する  
      それぞれ簡単に概要を紹介します。 なお、 Azure ポータルのサインインからログを確認することを含めて Azure AD テナントに Azure AD Premium のライセンスが必要ですのでご注意ください。  

    1. ポータルから CSV 形式のファイルをダウンロード

    Azure のポータルからは CSV 形式でサインイン ログをダウンロードすることができます。ここで注意しなければいけないことが 2 点あります。  

    1) 5000 件までしか取得できない。

    FAQ にもありますが、 5000 件までしか入手できません。  

    2) 日本語環境で文字化けする

    ダウンロードした CSV ファイルには BOM (Byte Order Mark の略で Unicode 判別のために利用する情報) が含まれていません。 そのため、ダウンロードしたファイルをそのまま Excel で開くと文字化けします。 一旦ダウンロードした CSV ファイルを notepad.exe で開き、上書き保存すると BOM が付与されるため、その後は日本語が正しく表示されます。  

    2. ポータルから取得したスクリプトを利用して CSV 形式のファイルを取得する

    ポータルから CSV 形式でファイルを生成するための PowerShell スクリプトを入手することができます。 このスクリプトはカスタマイズ可能ですので、毎回 Azure ポータルにアクセスして CSV をダウンロードしなくともスクリプトの実行によりサインインログを入手できます。 このスクリプトを実行するためには、予め Azure の PowerShell モジュールのインストール (PowerShell を管理者で開き install-module azure の実行でインストール) と Set-ExcecutionPolicy unrestricted を実行してスクリプトの実行制限を解除しておく必要があります。  

    3. API を利用して CSV 形式のファイルを取得する

    2 と同じような目的となりますが、私たちのブログで紹介しているスクリプトでも CSV ファイルとして取得できます。   Microsoft Graph API を利用して Azure AD のサインイン アクティビティ レポートを CSV ファイルで取得する PowerShell スクリプト Azure AD Reporting API を利用して PowerShell より Azure AD のサインイン アクティビティ レポートと監査アクティビティ レポートを CSV ファイルで取得する方法  

    4. データをエクスポートし、 PowerBI で解析する

    PowerBI には Azure AD のサインイン ログを解析するためのコンテンツ パックが用意されています。 このコンテンツ パックを利用することで、簡単に視覚化されたサインインのデータの確認が可能です。具体的な手順については、 Azure Active Directory Power BI コンテンツ パックの使用方法 を参照ください。  

    5. Log Analytics に統合する

    Azure サブスクリプションをお持ちでしたら是非 Log Analytics と Azure AD のサインインログの統合についても検討してみてください。 2019/1 の時点でまだ Public Preview ですが、 Azure Security Center や Application Insights の機能も利用可能です。詳細、具体的な手順については、こちらの公開情報を参照してみてください。   Azure Monitor (プレビュー) を使用して Azure AD のログを Log Analytics と統合する]]>         「エンタープライズアプリケーション」と「アプリの登録」の違いについて https://docs.microsoft.com/archive/blogs/jpazureid/enterprise-applications-app-registrations Fri, 28 Dec 2018 23:14:13 GMT https://blogs.technet.microsoft.com/jpazureid/?p=5995 「エンタープライズアプリケーション」と「アプリの登録」の違い   アプリケーションをテナント (Azure AD) に登録する際に「エンタープライズアプリケーションの登録」と「アプリの登録」それぞれの方法では、登録する目的が異なります。 端的に説明すれば以下のようになります。   「エンタープライズアプリケーション」：既存の SaaS アプリケーション (オンプレミスの環境で提供しているサービスを含む) をテナントに統合する場合に用いる。 「アプリの登録」：開発したアプリケーションの公開、もしくは利用するために用いる。   (ここで、統合が指す意味は、SaaS アプリケーションに対する シングルサインオン (SSO) の構成や、ユーザーのプロビジョニング構成を行うことなどを指します。) それぞれの項目で、アプリケーションの登録を行う場合の目的の違いついて、詳細を説明します。  

    「エンタープライズアプリケーション」からアプリケーションの登録を行う場合

      例えば、GitHub、Salesforce、Slack や G Suite など、Azure Marketplace もしくは、Azure ポータルより [Azure Active Directory] - [エンタープライズアプリケーション] - [+新しいアプリケーション] を選択した際に表示されるページで公開されている、事前に統合された SaaS アプリケーションをテナントに追加して利用するために使用します。 それぞれの SaaS アプリケーションに対する SSO、ユーザーのプロビジョニングの設定方法は以下のチュートリアルを参照ください。   SaaS アプリケーションと Azure Active Directory の統合に関するチュートリアル https://docs.microsoft.com/ja-jp/azure/active-directory/saas-apps/tutorial-list   上記に加えて、オンプレミス環境で利用しているアプリケーションを、外部から Azure AD Application Proxy 経由で利用する場合も、「エンタープライズアプリケーション」より設定を行います。 詳細については、以下の公開情報をご参照ください。   オンプレミス アプリケーションへの安全なリモート アクセスを実現する方法 https://docs.microsoft.com/ja-jp/azure/active-directory/manage-apps/application-proxy    

    「アプリの登録」、「アプリの登録(プレビュー)」からアプリケーションの登録を行う場合

      一般的に自社で開発したアプリケーションの公開、もしくは、自社で開発したテナントの情報にアクセスするためアプリケーションを利用する際に使用します。 また、「アプリの登録」と「アプリの登録(プレビュー)」 の違いは、使用できるエンドポイントが異なることです。 プレビューで登録することができるエンドポイント (v2.0) には、現時点でいくつかの制限事項があるため、「アプリの登録(プレビュー)」よりアプリを登録することを検討している場合は、以下の公開情報をご参照ください。   Azure AD v2.0 エンドポイントと v1.0 エンドポイントの比較 - 制限事項 https://docs.microsoft.com/ja-jp/azure/active-directory/develop/azure-ad-endpoint-comparison#limitations     「エンタープライズアプリケーション」と「アプリの登録」の管理項目の違いについては以上となります。 「アプリの登録」からアプリケーションを登録することは、特に権限が付与されていない一般ユーザーでも行うことができます。 制限を加えることもできますが、既定の状態としておくことを推奨しています。推奨される理由については以下の投稿も併せてご参照ください。   「ユーザーはアプリケーションを登録できる」の設定について https://blogs.technet.microsoft.com/jpazureid/2018/08/17/users-can-register-applications/   ご不明な点がございましたら弊社サポートまでお気軽にお問い合わせください。 上記内容が少しでも皆様の参考となりますと幸いです。 ※本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。]]>         Azure VM 上の AD FS 構成と Azure トラフィック マネージャーとの構成での非推奨設定について https://docs.microsoft.com/archive/blogs/jpazureid/adfstrafficmanager Thu, 27 Dec 2018 17:09:00 GMT https://blogs.technet.microsoft.com/jpazureid/?p=5955 サポート チームの 姚 (ヨウ)です。   Azure VM 上に AD FS を構成し、 Azure トラフィック マネージャーと組み合わせることで WAP サーバーと AD FS サーバーのセットを丸ごと冗長化できるメリットがあります。 この具体的な手順を含む詳細な情報を以下で公開しています。   High availability cross-geographic AD FS deployment in Azure with Azure Traffic Manager https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/active-directory-adfs-in-azure-with-azure-traffic-manager   今回は、この構成を構築する際に注意していただきたい点についてご紹介します。 公開情報では、インターネットからのアクセスに対してトラフィック マネージャーで通信を受け、 WAP と AD FS のそれぞれでロードバランサーを用意しておく構成について図示されています。   ここでロードバランサーの代わりに Azure トラフィック マネージャーを AD FS のロードバランシングにも利用できるのではと考えるようなケースもあるかと思いますが、そのような構成を取ることはできません。 具体的には、トラフィック マネージャーの背後に以下の構成のように AD FS サーバーを直接配置すると問題が発生します。     Azure トラフィック マネージャーは、DNS ベースの負荷分散をおこなうことを特徴としており、背後にある複数のアプリケーション サーバーをインターネット上の仮想エンド ポイントに公開し、トラフィックを分散する機能です。 一般的に以下の図の仕組みのように、インターネットに構成しているエンド ポイントへのトラフィックを背後のアプリケーション サーバーへ分散します。   Azure トラフィック マネージャーは、通常のロードバランサーの場合とは異なり、DNS レイヤーで動作する負荷分散です。 これを AD FS サーバーに対して構成した場合、上記図の "partners.contoso.com" をフェデレーション サービス名に設定する必要があります。 この場合、AD FS サーバーへの認証処理では、フェデレーション サービス名が Traffic Manager の仮想エンド ポイントの URL (contoso.trafficmanager.net) に解決され、この仮想の URL 名で Kerberos 認証を試みますが、実際の接続先と異なるため Kerberos 認証に失敗します。   AD FS サーバーへ認証する際にはフェデレーション サービス名で Kerberos 認証を実施する必要がありますので Azure トラフィック マネージャーを利用した負荷分散を構成することができません。 また、Azure トラフィック マネージャーはインターネット上に仮想エンド ポイントを公開することになりますが、 WAP ではなく AD FS サーバーをインターネットに公開するということは想定された利用方法ではなく、推奨していません。   Azure トラフィック マネージャーを利用する場合には、公開情報にありますように WAP サーバーへのアクセス部分に限定して利用するように構成をお願いいたします。   このブログの情報がお客様の検証や運用のお役に少しでもお役に立てばと思います。   製品動作に関する正式な見解や回答については、お客様環境などを十分に把握したうえでサポート部門より提供させていただきますので、ぜひ弊社サポート サービスをご利用ください。 ※本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。]]> PowerShell にて全ユーザーの最終サインイン日時を一括で取得する方法 https://docs.microsoft.com/archive/blogs/jpazureid/last-signin-reports Wed, 12 Dec 2018 12:46:33 GMT https://blogs.technet.microsoft.com/jpazureid/?p=5935   なお、今回はスクリプトとしてご用意をしたため、Japan Azure ID Support チームの GitHub にアップロードをしましたので、以下サイトをご確認ください。 Get last-sign-in activity reports   今後も、Japan Azure ID Support チームの GitHub には、Azure を利用するにあたり便利なスクリプトをアップロードしてまいります。 ぜひチェックしてみてください！   ご不明な点がございましたら弊社サポートまでお気軽にお問い合わせください。 上記内容が少しでも皆様の参考となりますと幸いです。 ※本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。]]> AD FS クレームルール関連のトラブルシューティング https://docs.microsoft.com/archive/blogs/jpazureid/adfs-crule-ts Fri, 30 Nov 2018 20:22:25 GMT https://blogs.technet.microsoft.com/jpazureid/?p=5815 こんにちは、Azure & Identitiy サポートチームの竹村です。 今回は、AD FS のクレームルールに関連した問題のトラブルシュート方法をご紹介します。  

    エラー画面、エラーイベントの特徴

    AD FS のクレームルールにより認証が失敗している場合、エラー画面やエラーイベントから容易に判断することができます。 ブラウザやモダン認証のアプリケーションからアクセスしている場合には、以下のように 「このサイトにアクセスする権限がありません。」と表示されます。     一部の Office クライアントなどで レガシー認証を使用している場合には、上記のようなブラウザの画面は表示されません。 しかし、クライアントの種類に関係なく、AD FS サーバー側のイベント ログ ( [アプリケーションとサービス ログ] - [AD FS] - [Admin] ) に、以下のようにイベント ID 325、501、1000、364 が記録されます。     上記の ID 325 の内容において、「発信者」(例では TEST122\test01) が認証したユーザーであり、「証明書利用者」(例では urn:federation:MicrosoftOnline) がアクセスを試みようとしたサービス (証明書利用者信頼) になります。 この証明書利用者信頼は、AD FS 管理ツールから確認することができます。 以下のように、信頼を結んでいるサービスのプロパティを開き、[識別子] のタブで確認することができます。(例は、Office 365 のものです。)      

    トラブルシュートの方法

    次に、意図せずクレームルールで認証がブロックされてしまう場合のトラブルシュート方法を紹介します。  

    (1) 該当するイベント ログを探します

    上述の通り、クレームルールによってブロックされている場合には、イベント ID 325、501、1000、364 が記録されます。 最初に、上記例のように、イベント ID 325 の内容を確認して認証したユーザー、サービスとタイムスタンプを突合し、該当するイベント ログを確認します。 レガシー認証などでエラー画面から判断できない場合、このイベントがエラー発生時間帯に記録されているかどうかで、クレームルールによる問題かどうかを判断することができます。   タイムスタンプ、ユーザー、サービスが一致するイベント ID 325 を見つけたら、次にイベント ID 501 を確認しますが、その際に Instance ID を参照します。     一連のイベントはおおよそ同じタイムスタンプに記録されますが、認証要求が多い場合などにはこの ID で判断します。 Instance ID が同じ値となっているイベントは、同一の認証処理内で記録されたイベントになります。     イベント ID 501 には、発行されたクレームとその値が交互に出力されます。 例えば上記の例では、 https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-ip  というクレームの値として、192.168.5.101 がセットされています。 同様に、https://schemas.microsoft.com/2012/01/requestcontext/claims/relyingpartytrustid というクレームの値として、  https://login.microsoftonline.com/login.srf がセットされています。   クレーム 値 クレーム 値 ... という順番で記録されています。   これらは、その量に応じて複数のイベント ID 501 にまたがって記録されます。 どのイベントが該当の処理のものかを判断するために、先述の Instance ID を利用します。  

    (2) クレーム ルールを確認し、イベント ID 501 に記録されているクレームの内容と比較します。

    手順 (1) で、発行されているクレームを確認することができました。 次に、AD FS に設定されているクレーム ルールを確認します。 クレーム ルールは、AD FS プライマリサーバー上で、以下のように Powershell を実行することで確認できます。   ※ Identifier オプションには、先述のイベント ID 325 で確認した対象の証明書利用者信頼の識別子を指定します。   (実行例) > (Get-AdfsRelyingPartyTrust -Identifier "urn:federation:MicrosoftOnline").IssuanceAuthorizationRules   @RuleTemplate = "AllowAllAuthzRule" => issue(Type = "https://schemas.microsoft.com/authorization/claims/permit", Value = "true");   @RuleName = "Test" NOT exists([Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value =~ "\b192\.168\.1\.10\b|\b192\.168\.1\.11\b"]) => issue(Type = "https://schemas.microsoft.com/authorization/claims/deny", Value = "true");   クレームルールの詳細についてはここでは割愛しますが、基本的に以下のいずれかの構成になっています。

     

    (A) ホワイトリスト形式 (許可する条件を羅列する形式)

    @ルール1 条件1 の場合には、アクセスを許可する   @ルール2 条件2 の場合には、アクセスを許可する ... このような書き方の場合、羅列されたいずれかの許可のルール (条件) に合致しない場合、アクセスはブロックされます。  

    (B) ブラックリスト形式 (拒否する条件を羅列する形式)

    @ルール1 すべての条件でアクセスを許可   @ルール2 条件1 の場合には、アクセスをブロックする   @ルール3 条件2 の場合には、アクセスをブロックする ... このような書き方の場合、羅列された拒否のルール (条件) のいずれかに合致した場合、アクセスはブロックされます。   「アクセスを許可する」に該当する記述は、 => issue(Type = "https://schemas.microsoft.com/authorization/claims/permit", Value = "true"); です。   「アクセスを拒否する」に該当する記述は、 => issue(Type = "https://schemas.microsoft.com/authorization/claims/deny", Value = "true"); です。   上記の例ですと、@RuleTemplate = "AllowAllAuthzRule" では、何の条件も指定せずにアクセスを許可しています。 つまり、すべてのアクセスを許可しています。   @RuleName = "Test" では、 https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip というクレームの値として、 "\b192\.168\.1\.10\b|\b192\.168\.1\.11\b" という正規表現にマッチしない場合 (つまり、192.168.1.10 もしくは 192.168.1.11 ではない場合) には、アクセスを拒否しています。   ※ 補足1 Value =~ と記述した場合、正規表現を使用することができます。 Value == と記述した場合には、完全一致になります。   ※ 補足2 exists と記述した場合、そのようなクレームが存在する場合、という意味になります。 NOT exists と記述した場合、そのようなクレームが存在しない場合、という意味になります。   今回の例の場合、イベント ID 501 に記録されているクレームと値を確認すると、 "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip" というクレームに 192.168.1.10 もしくは 192.168.1.11 という値がセットされていないためにアクセスが拒否されていることが分かります。  

    (3) クレーム ルールを修正します。

    例えば、手順 (2) で確認したイベント ID 501 に、以下のような出力があったとします。   https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip 192.168.1.12   このような場合には、192.168.1.10、192.168.1.11 に加えて、192.168.1.12 を許可するように追加します。 (192.168.1.12 が、お客様の環境で許可すべき IP アドレスであることが確認できている前提です。)   クレーム ルールを編集するには、AD FS 管理ツールから該当の証明書利用者信頼を選択し、[要求規則の編集] ウィンドウを開いて [発行承認規則] から該当のルールを選択します。     ※ もし、新しいルールを追加する場合には、この画面で [規則の追加] を行います。   今回の例では、Test というルールを選択して [規則の編集] を行います。     上記のように編集することで、 https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip に 192.168.1.12 がセットされている場合にもアクセスが拒否されないようになります。   よくあるケースとしては、ネットワークのアドレスが変わってしまったり、User Agent の文字列が意図していないものに変わってしまうことで、急に認証が拒否されてしまう場合があります。   いかがでしたでしょうか。 AD FS のクレームルールによって認証に失敗している場合、上記のステップを踏むことで、ある程度機械的に検知、確認、対応が可能です。 上記内容が少しでも参考となりますと幸いです。   製品動作に関する正式な見解や回答については、お客様環境などを十分に把握したうえでサポート部門より提供させていただきますので、ぜひ弊社サポート サービスをご利用ください。 ※本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。  ]]>         Azure AD Connect : ステージング サーバーのすゝめ https://docs.microsoft.com/archive/blogs/jpazureid/aadc_staging Tue, 27 Nov 2018 20:05:18 GMT https://blogs.technet.microsoft.com/jpazureid/?p=5755
  1.  バージョン アップを検討しているけど、いきなりアップしてすでに同期済みのユーザーとかグループに影響はないかな…
  2.  (同期元になるオンプレ AD 側のリプレースなど) 大きく ID 基盤の環境が変わる予定があるけど、 ちゃんと同期済みのユーザーとかグループとの紐づけ状態は維持されるかな…
  3.  そろそろサーバーのリプレースだけど、新規に構築する AADC サーバーは今まで通りに動作するかな…
    4.   そんなお悩みも、Staging サーバーをご用意いただけば多くの課題が解決できます！ 加えて障害復旧の際の復旧までの時間を短縮できる効果も、もちろん期待でき、Active サーバーが障害で停止…といったような [いざ] というときにも安心です。   それでは、そんなメリットが多い Staging サーバーを以下の流れでご紹介させていただきます！
    1. Staging サーバーとは？
    2. Staging サーバーの構成方法
    3. どうやって大きな作業に向けた事前確認で安心できるの？
     

    1. Staging サーバーとは？

    シンプルに言えば [Export (書き込み) を行わない、アイドリング状態のサーバー] です。 以下は Active サーバーと Staging サーバーを並べて構成したイメージとなります。 左が Active サーバー、右が Staging サーバーになります。 見ての通り [Import で最新の情報を取り込み、Sync でデータベースを更新する] ところまでは一緒ですが、最後の Export (書き込み) 処理をしない、というのが Staging サーバーの動作です。 それぞれのコンポーネントに関しては [こちら] の技術情報が参考になるので、ぜひご一読いただければと思います。   Export さえしなければ、既存のオンプレ AD にも AAD にも何も影響を与えることはありませんので、Staging　サーバーを構築することには何もリスクがないことになります！ [こちら] の技術情報にも Staging サーバーの参考情報がございますので、ぜひこちらも併せてご参照ください！   ポイントは [最新のオブジェクト情報の取り込みと学習を行っているため、Export する準備ができた状態のデータを持っている] という点です。  

    2. Staging サーバーの構成方法

    Staging サーバーの構成方法はすこぶる簡単です！ [こちら] の技術情報にも案内がございますが、AADC をカスタム インストールで新規にインストールするウィザードの一番最後の実行直前の画面にて [ステージング モードを有効にする] のチェックを入れるだけです。簡単ですね。 ※ もちろん、Active サーバーと Staging サーバーの [AADC としての設定] は同じである前提のご案内となります。   また、インストール後に Active から Staging へ、もしくはその逆にモードを変更するのも非常に簡単です。 インストール後の環境で Azure AD Connect ウィザード　(C:\Program Files\Microsoft Azure Active Directory Connect\AzureADConnect.exe)　を起動して、追加のタスク画面にて [ステージング モードの構成] メニューを選択するだけです。 ※ [こちら] の Blog でも Staging サーバーの構成手順をご紹介しておりますので、併せて参考にしていただければと思います！ (バージョン 1.2.67.0 の画面です。バージョンによって表示が違う場合があります。)   ウィザードを進めると以下のようなメニューが表示されるので、チェックを入れて進めれば Staging モードに、チェックを外して進めれば Active モードに切り替えられます。   ご注意いただきたいポイントとして [1つの AAD テナントには1台の AADC Active サーバーのみがサポートされるトポロジである] 点です。 前述した [こちら] の技術情報でサポートされる/されないトポロジをご案内していますが、1つの AAD テナントに複数の Active な AADC サーバーから同期を行う構成は取れませんのでご注意ください。 ※ なお、ステージング サーバーは Export 処理を行わないので、複数台構成しても同期処理そのもののスケールアウト/性能向上につながる訳ではない点にもご注意ください。   もし Active な AADC サーバーが障害で停止しても、Staging サーバーがあれば、すかさず AADC のウィザードを再実行し、 Staging の AADC サーバーを Active モードにしてあげれば、ディレクトリ同期処理がすぐに継続再開できるので安心です。 そんなに同期元のオンプレ AD でオブジェクト情報の変更を行う予定が無いから AADC が止まっててもすぐには困らない…という場合もあるかもしれませんが、例えばパスワード ハッシュ同期やパスワード ライトバックのオプションもご利用の場合は、Active な AADC サーバーが稼働していることでパスワードのハイブリッド管理状態が継続できているため、より耐障害性の高さがメリットになるかと思います。  

    3. どうやって大きな作業に向けた事前確認で安心できるの？

    最初に記載したお悩み例を再掲します。  
    • バージョン アップを検討しているけど、いきなりアップしてすでに同期済みのユーザーとかグループに影響はないかな…
    • (同期元になるオンプレ AD 側のリプレースなど) 大きく ID 基盤の環境が変わる予定があるけど、 ちゃんと同期済みのユーザーとかグループとの紐づけ状態は維持されるかな…
    • そろそろサーバーのリプレースだけど、新規に構築する AADC サーバーは今まで通りに動作するかな…
      それぞれに共通したお悩みポイントは、 [同期元オンプレ AD や AADC サーバーそのものに変更があった時に、認証に使用している大事な AAD ユーザーやグループ オブジェクトが影響を受けずに変わらず利用し続けることができるか] に集約されます。   このお悩みを解決する [切り替え後の正常性の事前確認方法] ですが、前述した [こちら] の技術情報にある CSExportAnalyzer を使用した分析がその方法となります。 1. に記述した通り、Staging サーバーは [Export する準備ができた状態のデータを持っている] ので、言い換えると [Export を実行したら現在の AAD のオブジェクトにこんな追加/変更/削除を行うよ！] というデータを持っていることになります。 そのため、Staging サーバーを Active にする前にその追加/変更/削除される予定のデータを確認し、何も変更点が無い、もしくは変更される予定のデータがあっても既存の AAD のオブジェクトとしては影響が無いことが確認できれば、安心して Active モードに変更することができますね。   CSExportAnalyzer を使用した [これから Export する予定のデータを確認する方法] は、技術情報にも記載がありますが改めて以下にご紹介します。  
    1. 事前に最新の情報を学習しておくために、AADC Staging サーバーで同期を行います。すでにインストール終了時に完全同期、以降の定期的な差分同期が実行されているようであれば最新の状態で差分同期することで問題ありません。 もし一度も同期を行っていない、もしくは AADC の同期ルールをカスタムしたり、同期対象 OU の変更を行った後に一度も完全同期をしていない場合は、完全同期を行ってください。  PowerShell を管理者として起動して、以下のコマンドを実行してください。   Start-ADSyncSyncCycle Initial : 完全同期の開始 Start-ADSyncSyncCycle Delta : 差分同期の開始   また、以下のコマンドを実行して AAD 向けコネクターの名前を確認しておくと 2. の手順で利用できて便利です。   Get-ADSyncConnector | fl name /// 出力例 Name : contoso.onmicrosoft.com - AAD : 同期先 AAD テナント向けのコネクター名です。 Name : contoso.local : 同期元オンプレ AD 向けのコネクター名です。  
    2. 最新の情報を学習する同期の終了後、コマンド プロンプトを管理者として起動して以下のコマンドを実行します。C:\Program Files\Microsoft Azure AD Sync\Bin\csexport.exe "contoso.onmicrosoft.com - AAD" C:\temp\AADexport.xml /f:x   引数の AAD テナント向けコネクター名はご利用環境に即したものを指定します。 出力する xml ファイルのパスとファイル名の指定は任意で問題ありません。 /f:x は、このコマンドで出力する対象のデータをフィルターするオプションで、その条件を [Export 待ちになっているデータ] としています。   これで AADC が把握している最新の学習情報より、Export を実行したら追加/変更/削除される予定のデータのみが xml に出力されます。  
    3. そのままでは見づらいので以下のコマンドを実行して解析しやすく整形して csv ファイルとして保存します。C:\Program Files\Microsoft Azure AD Sync\Bin\CSExportAnalyzer.exe C:\temp\AADexport.xml > C:\temp\AADexport.csv  
    4. 出力された csv ファイルを開きます。エクセルで開いてカンマ区切りで表示すると見やすいです。
      新規ユーザーの作成、既存ユーザーの属性値変更、既存ユーザーの削除、の3つのオブジェクトの更新がある状態で取得したサンプルが以下です。 見やすくなるように整形していますが、ポイントになる見方は以下の通りです。
    • OMODT 欄は [オブジェクトに対する処理の種類] です。この欄が add なら新規のオブジェクト追加、update なら既存のオブジェクトへの変更、delete なら既存オブジェクトの削除を意味します。
    • AMODT 欄は [オブジェクトの中の属性に対する処理の種類] です。add なら新規の属性追加、update なら既存の属性値の変更、delete なら既存属性値の削除を意味します。
    • OMODT と AMODT が add なら、それは新規のユーザー等のオブジェクトになります。
    • 属性単位で1行になるので、新規ユーザーを同期しようとしている場合は例のように [DN 値が同じ = 同じオブジェクトに対して追加される属性] ごとに行が記録されます。
    • この例では、既存のユーザーの mail 属性を oldmail@contoso.com から newmail@contoso.com に変更している前提です。
    • 最下部にオブジェクト単位の処理数の集計結果があります。
      なお、サンプル csv の原本も以下からダウンロード可能です。拡張子を .txt から .csv にしてご参照ください。 AADexportSample   この CSV の結果が以下であれば、現在 Staging モードの AADC を Active にしても AAD 側の既存オブジェクトの利用には影響が無い、と判断していただけます。  
    • 何も結果が無い、追加も変更も削除も無い つまり、Staging モードを Active にして Export 処理が行われても、AAD 側の既存オブジェクトには何も変更が生じない、という確証が得られます。
     
    • OMODT が update、AMODT が add もしくは delete になっているが、対象の属性値は AAD 側の既存オブジェクトの利用に対して何も影響が無い これは AADC のバージョン変更や、同期元 AD ドメインの構成変更などで良くあるパターンです。 [こちら] の Blog の下部でもご紹介していますが、AADC はバージョンによって同期対象の属性に違いがある場合があるので、バージョン アップによって AAD 側に Export される属性が増えていると、csv では [OMODT : update、AMODT : add] として対象の属性が全オブジェクトに対して追加される結果が得られます。 もしくは、同期元 AD ドメインのリプレースなどでは、同じ名前のユーザーであっても新旧 AD ドメインのユーザーそれぞれの持つ SID 値や最後のパスワード変更日時など、当然違ってくる属性値があるため、そのような場合は [OMODT : update、AMODT : update] のように差分が出力されます。 いずれの場合も、[構成や前提に対して発生するべくして発生している正しい差分] となるので、何らかの変更予定が出力されていてもそれが予定作業内容に沿ったものであれば問題ない、と事前に確認と判断を行うことができます。
      ここで再度お悩み例と、その解決策を記載します！もう Stagingサーバーを導入しない理由が無いですね。  
    • バージョン アップを検討しているけど、いきなりアップしてすでに同期済みのユーザーとかグループに影響はないかな… ->事前に Staging モードの AADC としてアップ予定のバージョンをインストールし、CSExportAnalyzer の結果をチェックしておけば既存の AAD オブジェクトへの影響有無を確認できる！
     
    • (同期元になるオンプレ AD 側のリプレースなど) 大きく ID 基盤の環境が変わる予定があるけど、 ちゃんと同期済みのユーザーとかグループとの紐づけ状態は維持されるかな… ->事前に Staging モードの AADC を構成し、変更予定のオンプレ AD 環境を同期元にして同期を行い CSExportAnalyzer の結果をチェックしておけば既存の AAD オブジェクトへの影響有無を確認できる！
     
    • そろそろサーバーのリプレースだけど、新規に構築する AADC サーバーは今まで通りに動作するかな… ->事前に Staging モードの AADC としてリプレース先になるサーバーを構成し、CSExportAnalyzer の結果をチェックしておけば既存の AAD オブジェクトへの影響有無を確認できる！
      なお、注意点としてこの事前確認は [AAD にクラウド ユーザーを直接作成して運用している環境に対して、オンプレ AD とのディレクトリ同期を新規に導入し、ソフトマッチにより同期元 AD ユーザーと同期先 AAD ユーザーの紐づけを行う] 場合にはご利用いただけない、という点がございます。 これは、CSExportAnalyzer によるチェック対象のデータは [AADC が把握できているオブジェクト情報] となるのですが、前述の導入シナリオの場合 AAD 側のオブジェクトはクラウド上に直接作成されているため、AAD からの Import 処理時に AADC は [自分の管理対象外のオブジェクト] と認識し Import 対象外として、オブジェクト情報を学習しないためです。 前述の導入シナリオでソフトマッチが期待した通り動作するかを確認される場合は、テスト ユーザーをご用意して正しくマッチ処理が行わるかを確認し、それから同期元 AD オブジェクトの範囲を広げてください。   上記内容が皆様の参考となりますと幸いです。どちら様も素敵な AAD ライフをお過ごしください。   ご不明な点等がありましたら、ぜひ弊社サポート サービスをご利用ください。 ※本情報の内容（リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。]]>         AD FS 証明書認証のトラブルシューティング https://docs.microsoft.com/archive/blogs/jpazureid/adfs-cba-ts Thu, 01 Nov 2018 20:14:12 GMT https://blogs.technet.microsoft.com/jpazureid/?p=5695 こんにちは、Azure & Identitiy サポートチームの竹村です。 今回は、多くのお客様からお問合せをいただく AD FS のクライアント証明書認証の問題について、既知の事例や対応方法をご紹介します。  

    最初に行うこと

      証明書認証の問題は、大きく 2つのパターンに分けられます。  

    (A) クライアントが証明書を送信しないケース

    (B) クライアントから証明書を選択して送信したものの、正常に動作しないケース

      トラブルシューティングを進める際には、まず、どちらのケースに該当するかを確認します。   ※ 注意 証明書認証では、認証を試みる際に証明書を選択するポップアップが表示されます。しかし、 IE には、有効な証明書が 1つしか存在しない場合に、自動的に送信する機能があります。 一見 (A) のケースのように見えていても、実際にはバックグラウンドで自動的に証明書を送信している可能性があります。 インターネット オプションの [セキュリティ] タブで、各ゾーンの [レベルのカスタマイズ] から以下の設定を確認しておきます。 この設定を「無効にする」にしておくことで、有効な証明書が 1つしか無い場合にもポップアップしてユーザーが選択する動作になりますので、確認が容易になります。     ※ 既定では、「ローカル イントラネット」ゾーンのみ有効となっていますが、念のため各ゾーンの設定をご確認ください。   次に、それぞれのケースにおける代表的な問題について説明して行きます。 すでにクライアント側に証明書が表示されている場合には、(A) は飛ばして (B) からご確認ください。

     

    (A) クライアントが証明書を送信しないケース

    このケースの問題は、CTL (Certificate Trust List) に起因していることがほとんどです。 CTL に関する詳細は割愛しますが、簡単に説明しますと、証明書認証では、AD FS / WAP サーバー側が信頼している証明機関のリスト (CTL) をクライアントに送信します。クライアントはそのリストに存在する証明機関から発行された証明書のみをユーザーに表示し、選択させます。 つまり、CTL が正常にクライアントに送信されなかったり、CTL の中にクライアント証明書を発行した証明機関が含まれない場合、クライアント側に証明書が表示されません。 AD FS / WAP では、この CTL を送信する機能が既定で有効です。 以下に、有効な確認ポイントや切り分け方法をいくつかご紹介します。  

    (1) AD FS / WAP で、ローカル コンピューター の「信頼されたルート証明機関」に、クライアント証明書を発行した証明機関の証明書が含まれることを確認します。

    既定でサーバー側 (AD FS / WAP) は CTL に自身の「信頼されたルート証明機関」を含めます。 したがって、「信頼されたルート証明機関」にクライアント証明書を発行した証明機関が含まれていないと、クライアント側では証明書が表示されません。  

    (2) AD FS / WAP で、ローカル コンピューター の「信頼されたルート証明機関」に、「ルート証明書」でないものが含まれていないかどうかを確認します。

    サーバー側で CTL を作成する際に、「信頼されたルート証明機関」に含まれるものをリストしますが、その際に「ルート証明書」以外が存在することを検知すると、CTL を正常に生成できず、結果としてクライアント側で証明書が表示されないケースがあります。 「ルート証明書」は、「発行先(サブジェクト)」 と「発行者」が一致している証明書ですので、それ以外の証明書が信頼されたルート証明機関ストアに含まれていないか確認します。 ルート証明機関のストアは次の手順で確認します。   1. AD FS / WAP サーバーで "ファイル名を指定して実行" から "certlm.msc" を起動します。 2. 左ペインに [証明書 - ローカル コンピューター] と表示されていることを確認の上、 [信頼されたルート証明機関] - [証明書] を展開し、発行先と発行者が一致しないものが含まれないか確認します。  

    (3) CTL の送信を無効にして動作を確認してみます。

    サーバー側の設定で、CTL の送信を無効にすることができます。 もし無効にすることで証明書がクライアントに表示される場合、明らかに CTL の問題に起因していることが確認でき、調査、対応をこの一点にフォーカスさせることができますので、有効な切り分けです。上記の (1) や (2) の確認を実施する前にこの切り分けを実施してしまうのも有効です。 (ただし再起動が必要なのでその点についてはご注意ください)   CTL の送信を無効にするには、サーバー側で以下のレジストリ値を 0 に設定し、再起動します。      レジストリ キー : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel    名前: SendTrustedIssuerList    型: REG_DWORD    値: 0 (無効) / 1 (有効)   なお、複数の AD FS / WAP サーバーが存在する場合、切り分けの際には、hosts ファイルなどで接続先の AD FS / WAP を固定して確認することをお奨めします。 (接続先のサーバーを固定することができない場合には、どのサーバーに接続されるか分かりませんので、すべてのサーバーで設定する必要があります)

     

    (4) CTL ストアの設定を確認したり、固有の CTL ストアを作成します。

    既定 (CTL ストアの設定が null の状態) では、上述のとおり「信頼されたルート証明機関」に含まれる証明機関が CTL にリストされます。 しかし、CTL ストアは個別に設定することも可能です。 CTL ストアの設定状況は、以下の netsh コマンドで確認することができます。   > netsh http show sslcert   管理者権限で上記のコマンドをコマンドプロンプトから実行すると、いくつか SSL のバインドの情報が表示されるかと思います。 その中で、証明書認証に利用する 【フェデレーションサービス名】:49443 の情報を確認します。 (AD FS 2016 以降では、環境によっては 49443 ポートではなく、certauth.【フェデレーションサービス名の FQDN】:443 である可能性もあります。)   以下は、フェデレーションサービス名が sts.test.com である場合の実行結果例です。 > netsh http show sslcert   Hostname:port               : sts.test.com:49443 ★<<< ポート49443 に関する設定です。こちらを確認します。 Certificate Hash             : 47b90e1e818ba8cf431d404fff232f1ba17bf078 ★ <<< SSL サーバー証明書に対して一意で、環境によって異なります。 Application ID               : {5d89a20c-beab-4389-9447-324788eb944a} ★ <<< AD FS サービスを示すもので、全環境で同一です。 Certificate Store Name       : MY Verify Client Certificate Revocation : Enabled Verify Revocation Using Cached Client Certificate Only : Disabled Usage Check                 : Enabled Revocation Freshness Time   : 0 URL Retrieval Timeout       : 0 Ctl Identifier               : (null) Ctl Store Name               : (null) ★<<< 既定では null です。443 ポートど同様に AdfsTrustedDevices などが設定されている場合、null に戻す必要があります。 DS Mapper Usage             : Disabled Negotiate Client Certificate : Enabled   この CTL ストアを個別に指定して、クライアント証明書を発行した証明機関のみを含めることで、他の証明機関の証明書の影響を取り除くことができます。 以下に、設定手順をご紹介します。   1. 管理者権限でコマンドプロンプトを起動し、以下のように実行します。   > certutil -f -addstore <任意の証明書ストア名> <クライアント証明書のルート証明書>   (例) > certutil -f -addstore adfsclient c:\temp\rootca.cer   ※ c:\temp\rootca.cer は、クライアント証明書を発行したルートCA の証明書をエクスポートした .cer ファイルです。 ※ このコマンドにより、adfsclient という名前のストアが作成され、ルートCA の証明書がインポートされます。   2. 続いて以下のコマンドを実行し、作成したストア内にルートCAの証明書が存在することを確認します。   > certutil -store adfsclient   3. 続いて以下のコマンドを実行し、現状の 49443 ポートの SSL バインドを一旦削除します。   > netsh http delete sslcert hostnameport=sts.test.com:49443   ※ hostnameport には、お客様の環境で確認した値を指定します。   4. 続いて以下のコマンドを実行し、CTLストアを作成したものに指定し、SSL バインドを設定します。   > netsh http add sslcert hostnameport=sts.testcom:49443 certhash=47b90e1e818ba8cf431d404fff232f1ba17bf078 appid={5d89a20c-beab-4389-9447-324788eb944a} certstorename=MY sslctlstorename=adfsclient   ※ hostnameport、certhash には、お客様の環境で確認した値を指定します。   5. 続いて以下のコマンドを実行し、CTLストアが更新されていることをご確認ください。 > netsh http show sslcert   Hostname:port               : sts.test.com:49443 Certificate Hash             : 47b90e1e818ba8cf431d404fff232f1ba17bf078 Application ID               : {5d89a20c-beab-4389-9447-324788eb944a} Certificate Store Name       : MY Verify Client Certificate Revocation : Enabled Verify Revocation Using Cached Client Certificate Only : Disabled Usage Check                 : Enabled Revocation Freshness Time   : 0 URL Retrieval Timeout       : 0 Ctl Identifier               : (null) Ctl Store Name               : adfsclient ★<<< 個別に作成したストアが設定されています。 DS Mapper Usage             : Disabled Negotiate Client Certificate : Enabled   クライアント側に証明書が表示されないケースは、上記の対応で解決できることが多いので、参考になれば幸いです。

     

    (B) クライアントから証明書を選択して送信したものの、正常に動作しないケース

    このケースでの原因は、WAP サーバー、あるいは AD FS サーバーで失効確認に失敗しているケースがほとんどですが、それ以外を含めて以下に、いくつか確認のポイントをご紹介します。

     

    (1) 証明書を受信するサーバー (外部接続の場合は WAPサーバー、社内接続の場合は AD FS サーバー) で、49443 ポートが開放されていることを確認します。

    稀に証明書を受信するポートが開放されておらず、ネットワーク的に証明書を受け取れないケースがあります。 念のため、ご確認ください。

     

    (2) 証明書のサブジェクト代替名に認証ユーザーの UPN が設定されていることを確認します。

    AD FS の証明書認証では、サブジェクト代替名に認証ユーザーの UPN が設定されている必要があります。 (サブジェクト代替名に設定が存在しない場合には、サブジェクトに認証ユーザーの DN が設定されている必要があります。Windows ではサブジェクト代替名を優先するので、一般的にはサブジェクト代替名に UPN をセットした証明書を利用します) こちらも、念のためご確認ください。

     

    (3) ルート CA の証明書、中間 CA の証明書 (存在する場合)  が、適切にインポートされていることを確認します。

    AD FS サーバー、WAPサーバー、クライアント端末それぞれで、ローカル コンピューターの「信頼されたルート証明機関」ストアにルート CA の証明書が正しくインポートされていることを確認します。 また、中間 CA が存在する場合には、同様に「中間証明機関」ストアに中間 CA の証明書が正しくインポートされていることを確認してください。 証明書チェーンを正常に検証できる必要があります。 また、AD FS サーバーにおいては、NT Auth ストアにクライアント証明書を発行した CA の証明書 (ルート CA の証明書、もしくは中間 CA から発行している場合には中間 CA の証明書) がインポートされている必要があります。 AD CS のエンタープライズ CA を利用している場合、既定で NT Auth ストアに CA の証明書がインポートされますが、他ドメインの CA や公的な証明機関から発行した証明書を使用する場合、明示的にインポートする必要があります。   NT Auth ストアに証明書をインポートするには、ドメインの管理者権限でコマンドプロンプトを起動し、以下のコマンドを実行します。 AD FS サーバーなど、DC に接続できるサーバー上で実行します。   > certutil -dspublish -f <クライアント証明書を発行した CA の証明書 (xxxx.cer) のフルパス> NTAuthCA   NT Auth ストアにインポートされている証明書を確認する場合には、以下のコマンドを実行します。  

    > certutil -store -enterprise ntauth

     

    (4) AD FS サーバー、WAP サーバーから CDP (失効リスト配布ポイント) にアクセスできることを確認します。

    クライアント証明書の [詳細] タブから、証明書の CDP を確認することができます。     証明書の CDP を確認し、ADFS / WAP サーバー上で IE を起動し、該当の URL にアクセスできるかどうかを確認します。 IE から正常にアクセスできる場合でも、実際の失効確認の動作時には WinHTTP プロキシを経由するため、 winHTTP プロキシが構成されていないことで CDP へのアクセスに失敗している可能性があります。 winHTTP プロキシの設定状況については、次のコマンドで確認が可能です。   実行例: > netsh winhttp show proxy   現在の WinHTTP プロキシ設定:    直接アクセス (プロキシ サーバーなし)。   インターネット接続にプロキシが必要な環境では、適切にプロキシを設定しておく必要があります。 IE のインターネット オプションの設定を合わせるためには、以下のコマンドを実行します。   > netsh winhttp import proxy source=ie   現在の WinHTTP プロキシ設定:    プロキシ サーバー: proxy_address:8080    バイパス一覧     : test.com;*.test.com;sts.federation.com;<local>  
    CDP に HTTP のパスが含まれない場合
    証明機関として Windows の AD CS で構成したエンタープライズ CA を利用している場合、CDP は証明機関の設定で行いますが、既定では AD 上に格納され、LDAP のパスになります。 この既定の状態ですと、AD FS は必ずドメイン メンバーになりますので問題はありませんが、WAP サーバーをドメインに参加させていない構成では、この LDAP のパスにはアクセスすることができません。 WAP サーバーがドメインに参加していない場合には、http でも CDP にアクセスできるように構成しておく必要があります。 具体的には次のとおり、クライアント証明書を発行する証明機関のプロパティの [拡張機能] タブで設定します。     注意点としては、この設定を行う前に発行された証明書には、ここで設定した http の CDP が含まれていません。 設定変更を行った後に、再度クライアント証明書を発行する必要があります。    

    (5) 失効確認を無効化して動作を確認します。

      上記を確認しても動作が変わらない場合、一旦失効確認を無効化することは有効な切り分けです。 もし無効化して動作するようになった場合には、明らかに失効確認が問題であることが確認でき、調査、対応を失効確認の動作に絞ることができます。 特に、AD CS のエンタープライズ CA を利用している場合には WAP サーバーで失効確認が失敗しやすい (3 で紹介のとおり CDP が LDAP パスに設定されているため失敗しているケースが多い) ので、最初に WAP サーバーで無効化することをお奨めします。   (A) の対応でもご紹介しましたが、失効確認は netsh コマンドで確認、無効化 (有効化) することができます。   > netsh http show sslcert   管理者権限で上記のコマンドをコマンドプロンプトから実行すると、いくつか SSL のバインドの情報が表示されるかと思います。 その中で、証明書認証に利用する 【フェデレーションサービス名】:49443 の情報を確認します。 (AD FS 2016 以降では、環境によっては 49443 ポートではなく、certauth.【フェデレーションサービス名の FQDN】:443】である可能性もあります。)   以下は、フェデレーションサービス名が sts.test.com である場合の実行結果例です。 > netsh http show sslcert   Hostname:port               : sts.test.com:49443 ★<<< ポート49443 に関する設定です。こちら確認します。 Certificate Hash             : 47b90e1e818ba8cf431d404fff232f1ba17bf078 ★ <<< SSL サーバー証明書に対して一意で、環境によって異なります。 Application ID               : {5d89a20c-beab-4389-9447-324788eb944a} ★ <<< AD FS サービスを示すもので、全環境で同一です。 Certificate Store Name       : MY Verify Client Certificate Revocation : Enabled ★ <<< 既定では、クライアント証明書の失効確認が有効 (Enabled) になっています。 Verify Revocation Using Cached Client Certificate Only : Disabled Usage Check                 : Enabled Revocation Freshness Time   : 0 URL Retrieval Timeout       : 0 Ctl Identifier               : (null) Ctl Store Name               : (null) DS Mapper Usage             : Disabled Negotiate Client Certificate : Enabled     失効確認を無効化する手順を、以下にご紹介します。   1. 管理者権限でコマンドプロンプトを起動し、現状の 49443 ポートの SSL バインドを一旦削除します。   > netsh http delete sslcert hostnameport=sts.test.com:49443   ※ hostnameport には、お客様の環境で確認した値を指定します。    2. 続いて以下のコマンドを実行し、失効確認を無効化してSSL バインドを設定します。   > netsh http add sslcert hostnameport=sts.testcom:49443 certhash=47b90e1e818ba8cf431d404fff232f1ba17bf078 appid={5d89a20c-beab-4389-9447-324788eb944a} certstorename=MY verifyclientcertrevocation=disable   ※ hostnameport、certhash には、お客様の環境で確認した値を指定します。    3. 続いて以下のコマンドを実行し、クライアント証明書の失効確認が無効化されていることを確認します。 > netsh http show sslcert   Hostname:port               : sts.test.com:49443 Certificate Hash             : 47b90e1e818ba8cf431d404fff232f1ba17bf078 Application ID               : {5d89a20c-beab-4389-9447-324788eb944a} Certificate Store Name       : MY Verify Client Certificate Revocation : Disabled ★ <<< 失効確認が無効化されています。 Verify Revocation Using Cached Client Certificate Only : Disabled Usage Check                 : Enabled Revocation Freshness Time   : 0 URL Retrieval Timeout       : 0 Ctl Identifier               : (null) Ctl Store Name               : (null) DS Mapper Usage             : Disabled Negotiate Client Certificate : Enabled   もしこの状態で証明書認証が動作するようになった場合、サーバーの失効確認に失敗している状況と明確に判断することができます。    

    (6) 失効リストを公開し直し、キャッシュを削除します。

      失効リストの有効期限が切れていたり、サーバー上の CRL キャッシュが古く、正常に動作しないケースがあります。 CDP にアクセスできることを確認している場合には、失効リストの更新、キャッシュの削除をお試しください。 AD CS のエンタープライズ CA では、以下の [失効した証明書] の [すべてのタスク] から公開することができます。     上記手順で CRL を公開しましたら、AD FS、WAP サーバー上で CRL のキャッシュを削除します。 CRL キャッシュには、ストレージ上に保存されるもの、メモリ内に保持されるものの 2 種類があり、それぞれ削除する方法を以下にご紹介します。 ストレージ上のキャッシュを削除するためには、以下の各フォルダ内のファイルを削除してください。 フォルダは削除しないようにしてください。  

    C:\Windows\ServiceProfiles\NetworkService\AppData\LocalLow\Microsoft\CryptnetFlushCache\MetaData

    C:\Windows\ServiceProfiles\NetworkService\AppData\LocalLow\Microsoft\CryptnetUrlCache\Content

    C:\Windows\ServiceProfiles\NetworkService\AppData\LocalLow\Microsoft\CryptnetUrlCache\MetaData

    C:\Windows\System32\config\systemprofile\AppData\LocalLow\Microsoft\CryptnetFlushCache\MetaData

    C:\Windows\System32\config\systemprofile\AppData\LocalLow\Microsoft\CryptnetUrlCache\Content

    C:\Windows\System32\config\systemprofile\AppData\LocalLow\Microsoft\CryptnetUrlCache\MetaData

    C:\Windows\SysWOW64\config\systemprofile\AppData\LocalLow\Microsoft\CryptnetFlushCache\MetaData

      ※ ファイルが存在しない場合、フォルダが存在しない場合は、対応不要です。   次にメモリ内に保持されるキャッシュは、以下のコマンドで削除します。   > certutil -setreg chain\ChainCacheResyncFiletime @now  

    ※ コマンドを実行するためには、ローカル管理者権限が必要です。

    ※ コマンドを実行した後にCertSvc サービスの再起動を求められますが、実際には不要です。サービス再起動の必要はありません。   いかがでしたでしょうか。 AD FS の証明書認証をトラブルシューティングするケースでは、上記のとおり様々な確認観点があり、すべての観点を確認するための資料を一まとめに取得しようとすると、非常に大変です。 今回ご紹介した確認ポイント、切り分けを実施していただくことで、解決に至ったり、調査のポイントを絞り込むことができますので、ぜひ活用いただければ幸いです。   上記内容が少しでも参考となりますと幸いです。 製品動作に関する正式な見解や回答については、お客様環境などを十分に把握したうえでサポート部門より提供させていただきますので、ぜひ弊社サポート サービスをご利用ください。 ※本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。  ]]>         サブスクリプション作成時のエラー「アカウントが Azure サブスクリプションに関連付けられないディレクトリに属しています。別のアカウントでサインインしてください」 https://docs.microsoft.com/archive/blogs/jpazureid/create-subscription-error Thu, 01 Nov 2018 17:20:57 GMT https://blogs.technet.microsoft.com/jpazureid/?p=5615 今回は、Azure におけるサブスクリプション作成時に表示される「アカウントが Azure サブスクリプションに関連付けられないディレクトリに属しています。別のアカウントでサインインしてください」というエラーの発生原因と対処策についてご紹介します。       本エラーは、サブスクリプション作成を試みたユーザー (のメールアドレス) が ”セルフサービス サインアップ テナント” に紐づいている場合に発生します。   ◆ セルフサービス サインアップ テナントとは セルフサービス サインアップ テナントとは、管理者により作成されたテナントではなく、ユーザーが Azure Active Directory(以下、Azure AD ) による認証を必須とするサービスにサインアップした (利用を試みた) 場合に自動で作成されるテナントです。具体的には Power BI などのサービスになりますが、サービスを利用するためにサインアップを試みた際に指定したユーザーのメール アドレスに含まれるドメイン名が Azure AD にまだ登録されていない場合には、自動で Azure AD テナントが作成され、これがセルフサービス サインアップ テナントになります。通常 Azure AD テナントには必ず管理者が存在しますが、このセルフサービス サインアップ テナントには管理者が存在しません。この管理者が存在しないテナントではサブスクリプションを紐づけることができないため、発生しているエラーが今回ご紹介しているエラーメッセージになります。   対処策としては、以下の手順にてテナントの管理者への昇格をする必要があります。   ◆　エラーの対処法 以下手順にて管理者に昇格します。   1.該当のユーザーで、https://www.office.com へログインし、管理を選択します。   2.以下画面が表示されますので、”はい、私が管理者になります”を選択します。   3.ドメインを認証するために、TXT レコードの更新が求められます。 ドメインに指定されたTXT レコードを追加し、”レコードを追加しました”を選択します。 なお、このTXT レコードは、管理者への昇格が終わりましたら削除いただいて構いません。     4.TXT レコードの確認が完了すると、以下が表示されます。 この画面が表示されますと、無事サブスクリプションを作成することができます。     ご不明な点がございましたら弊社サポートまでお気軽にお問い合わせください。 上記内容が少しでも皆様の参考となりますと幸いです。 ※本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。]]> Azure サポート エンジニア説明会+キャリア相談会を 11 月にも開催します https://docs.microsoft.com/archive/blogs/jpazureid/azure-joinus-201811 Wed, 31 Oct 2018 09:13:23 GMT https://blogs.technet.microsoft.com/jpazureid/?p=5555 今年の 5 月、10 月と開催してきた Azure サポート エンジニアの説明会・キャリア相談会ですが、好評のため 11 月にも再度開催させていただくことが決定しましたのでご案内いたします。   Azure のサポート部門ではエンジニアを募集しています。 ポジションとしては、私ども、Azure AD、AD FS、Azure AD Connect などを担当する Azure Identity チームをはじめ、IaaS Networking/Platform でも募集中です。
    募集職種
    • Support Engineer (Azure Identity)
    • Support Engineer (Azure IaaS Networking)
    • Support Engineer (Azure IaaS Platform)
      詳細について説明させていただければと思いまして、2018/11/14 (水) 19:00 から弊社品川オフィスにて、募集職種についての説明会、MS でのキャリアについて相談会を開催します。 興味のある方は下記 リンクより事前にお申し込みの上、ぜひご参加ください。

    > Azure サポート エンジニア 説明会、相談会 申し込みフォーム

    日時: 2018/11/14 (水) 19:00~ 場所: 品川マイクロソフト オフィス (最寄り駅: JR 品川駅)   こちらも見たことない方はぜひ → Azureサポート エンジニアの魅力とやりがいとは？ https://japan.zdnet.com/extra/microsoft_support_201803/35116283/  
    Azure が大好き! という皆さまのご参加・ご応募お待ちしています！
    ]]>