日本で所得格差が生まれる・広がる原因 現在、世界的に議論の的となっているのが、格差の問題です。 Amazon.co.jpがおすすめするギフトを、贈る相手の趣味や興味に合わせて幅広くご紹介。現時点ではこのメニューの読み込みに問題があります。

複数台のAD FSにおいて冗長化を行う場合、AD FSファームを構成して冗長化を行います。今回は、運用中においてサーバの障害やメンテナンスなどでAD FSファームのスイッチオーバーが必要になる際の手順などについて書きたいと思います。まずは、おさらいとしてAD FSファームについて記載します。AD FSは、1台のプライマリAD FSサーバと複数台のセカンダリAD FSから構成されるAD FSファームを構成できます。AD FSファームを構成すると、セカンダリは自身のデータベースに対する直接の書き込み（設定変更）を禁止し、指定したプライマリサーバからその情報を同期します。デフォルトでは、300秒（5分）に1度その設定をポーリングします。Windows Server 2012 R2のAD FSファームは、証明書利用者信頼（Relying Party trusts）が5以下の場合は最大10台、それ以上の証明書利用者信頼の場合は最大5台のAD FSサーバでの構成がサポートされます。Office 365のみを利用する環境であれば、「Device Registration Service」「Microsoft Office 365 Identity Platform」の2つが証明書利用者信頼として登録されることになりますので、10台で構成すれば10万を越えるような大規模な環境でも理論上は構成できることになります。（実際の環境では、DR環境にある別のデータセンタのAD FSサーバの台数も含めての台数になるので、もう少し収容ユーザー数は少なりますが）また、構成可能なオブジェクト数は要求プロバイダー信頼と証明書利用者信頼で最大100がサポートされています。実環境としては使い切ることは無さそうですね。さて、こんなケースを考えてみます。プライマリ AD FSのfs01が故障しました。復旧までにはかなり時間がかかる見込みです。この状態でも、ユーザーからfs02への認証要求は通常通り継続できますので問題は無いのですが、fs02はセカンダリなので設定変更などのオペレーションを実施することができません。AD FSの設定変更を可能にするために、fs02をプライマリに昇格させようと思います。fs02をプライマリに昇格させるには、fs02でPowerShellを起動して、以下のコマンドを実行します。前述の通り、クラスターなどとは違ってAD FSファームのプライマリやセカンダリはDBの同期のためだけに利用されている物になりますので、これだけで完了します。続いて、fs03など更に別のセカンダリが存在している場合は、今までfs01に向けてポーリングしていた物をfs02からポーリングするように設定する必要があります。fs03などでプライマリのFQDNを指定した以下のコマンドを実行してポーリング先を変更します。これで、fs02へのプライマリの役割のスイッチオーバーが完了です。さて、この状態でようやくfs01の故障対応が完了してサーバが立ち上がってきたとします。fs01の設定は以前のままになりますので、立ち上がってきた状態は以下の感じになります。このままスイッチバックをすると、fs01は故障発生前の古い情報のままになってしまいますので、まずはfs02のセカンダリとして設定して情報が同期されるのを待ちます。最後に、fs01に再度スイッチバックを行います。AD FSファームの仕組み（静的なDB同期）が分かってしまえば挙動については比較的単純なのでご理解頂けると思います。Windows Server 2012 R2に搭載されているAD FS 3.0も、だいぶ導入が増えてきたように思えます。最初の方に導入された方は導入から1年経過してSSL証明書の更新などを迎えられているユーザーもいらっしゃるかと思います。今回は、あまり公開されている情報も無く、トラブルも多く聞かれているので、AD FS 3.0のSSL証明書更新についてまとめていきたいと思います。（なお、こちら基本的には以前勉強会で実施したLT「まずは、AD FSならびにWeb Application Proxyの各サーバに新しい証明書をインポートします。Windows Server 2012 R2から、AD FSの動作にはIISは利用されなくなったので必要に応じて別の環境で作成してエクスポートした物を利用します。基本的にはローカルコンピュータにインポートして、インポート先を自動的に証明書ストアを選択するとしておけば、MMCで確認すると[証明書（ローカルコンピュータ）]-[個人]-[証明書]に表示されると思います。これで準備は完了です。 AD FS#1（AD FSファームを構成しているプライマリ機をAD FS#1と便宜上表記します）において、PowerShellを起動します。まず、新しい証明書のThumbprintを取得します。調査方法は色々ありますが、オフィシャルで案内されている証明書管理ツールからだとスペースが入ったりして面倒なので、dir（これはGet-ChileItemのエイリアスです）コマンドで表示してしまうのが一番楽です。有効期限や発行元などの情報を元に、新しい証明書を特定してThumbprintをメモ帳などにコピーします。続いて、こちらの情報を指定してSet-AdfsSslCertificateコマンドレットを実行します。このコマンドは、主にAD FS管理ツールによって実施されない2つのことを実施しています。特に後者の方は手動でやると面倒なので、コマンド 1発で済ませられるのは便利ですね。いきなり証明書を切り替えるのには若干違和感はありますが、1番の工程より先に3番の工程を実施した場合、セカンダリ側のAD FSで秘密鍵へのアクセス権限の問題でAD FSの133番のエラーが出ます。同様の操作を、AD FS#2（#3や#4などがある場合はそちらも）についても行います。続いて、AD FSのサービス通信証明書を変更します。従来でいうSSL証明書の入れ替えの作業の工程です。GUIから実施してもいいですが、せっかくWindows Server 2012 R2の環境なのでPowerShellから実施してみます。ファーム内の各サーバでAD FSサービスを再起動するように指示がありますので、順に行います。最初にプライマリを実施します。続いてセカンダリ。セカンダリは5分おきにプライマリに設定変更をポーリングしてますので、念のため5分程度待ってから実施します。これで基本的な項目は完了です。Lync MobileなどからAD FS接続ができないという問題（コマンドは最初に設定した際と同じくnetshコマンドで行いますが、上書きができないので削除～再指定を行います。AD FSのAppidは確認した限りでは固定の様ですが、エラーが出たら上記のKBをご確認いただき適宜修正下さい。続いて、WAP（旧AD FS Proxy）側に移ります。こちらもまずは各コンピュータのSSL証明書の差し替えから入ります。コマンドレット名が変わりますが基本的には同じです。7番と同様です。Web Application Proxyで公開されているアプリケーション（通常はAD FSのみになりますが）について、外部証明書として設定されている証明書を差し替えます。Set-WebApplicationProxyApplicationに必要な引数はGUIDで入力が面倒なので、Get-WebApplicationProxyApplicationしたものをそのままパイプしてしまう方が楽ですね。6番と同様の工程をWAP側でも実施します。 という訳で、今回はAD FS 3.0のSSL証明書の入れ替えについてご紹介しました。IISが無くなった分、AD FS 2.0と比較して少し面倒ですが、手順さえ確立できれば後は作業です。関連記事：  このサイトならびにコミュニティ等における発言は個人としての意見であり、所属する会社・団体の正式な見解・コメントではございません。