Windows Server 2012 R2のADFSを使う10（+1）の理由

Posted on by • Posted in Office365, Work, シングルサインオンとディレクトリ同期 • Leave a comment

このblogはOffice 365 Advent Calendarに参加しています。

Windows Server 2012 R2がリリースされて1年が経ちました。Windows Server 2008 R2などでAD FS環境を作られている方も多いかと思いますが、今日は、Windows Server 2012 R2のAD FS環境に乗り換えるメリットや注意点などを簡単にまとめてみたいと思います。

  1. 最新のソフトウェアバージョンであるから
    • Office 365を利用する上で、それと連携する環境はたとえServer OSであっても随時バージョンアップし、新しい物に追従していく必要があります
    • Windows Server 2008 R2のAD FSは、現在はサポート範囲には入ってますが、既に新機能は提供されておらず、次期Server OSが公開されるといずれサポート外になってしまいます
  2. デバイス認証(DRS)が利用できるから
    • 利用できるクライアント環境には制限があるものの、新機能であるWorkplace Joinを利用すると、Active Directoryに所属していないデバイスを登録し、デバイス認証によるログインを実施することができるようになります
    • デバイス認証の要否もAD FSのクレームルールとして記載できますので、より柔軟なアクセス制御が実施出来るようになります
  3. 多要素認証が利用できるから
    • AD FS自体がアドインの多要素認証を意識した設計になりました
    • 従来は、AD FSの処理の外（PhoneFactorであれば、AD FS ProxyのIISのフォーム認証の部分）で追加認証を実施してましたが、AD FSの処理の内部で利用することにより、ある条件下のみでの多要素認証の要求など、柔軟な処理が実施できるようになります
  4. AD FSサービス用のユーザーアカウントが不要だから
    • グループの管理されたサービスアカウント（gMSA）というサービス実行専用の特殊アカウントが利用できるようになりました。これにより、AD FSサービスの実行用に特別な管理者アカウントの管理は不要です
    • 管理権限を保有し、実効上パスワードの無期限化が必要、かつAD FS Proxy経由の無差別攻撃などでロックアウトし、AD FSがサービス停止する危険性など、従来の運用上のリスクから開放されます
  5. パッシブフェデレーションでも接続情報を取得できるから
    • 従来、ブラウザからのアクセス（パッシブフェデレーション）ではアクセス元のIPやクライアント種別などの情報が取得できませんでしたが、これが取得できるようになったことで、より外部アクセスに関しての細かなアクセス制御が実施できるようになりました
  6. 外部アクセスへのアカウントロックアウトの対応ができるから
    • Exchange OnlineのアクセスにAD FSを利用している場合、外部から攻撃を受けたり、パスワード変更後に設定未変更のスマートフォンなどの端末からのアクセスでオンプレミスのActive Directoryアカウントがロックアウトすることがありました
    • AD FS Proxy経由でのアクセスについてAD FSの処理でロックアウトを実施することができるようになりました。これでアタックをうけてもActive Directoryアカウントには影響を与えません
  7. リバースProxy機能を持つWAPが利用できるから
    • Windows Server 2008 R2のAD FS Proxyは、AD FSへの要求をフォワードすることしかできませんでした
    • Windows Server 2012 R2はWeb Application Proxy(WAP)として新たに構成され、AD FS以外にもより汎用的に各種社内Webアプリケーションをインターネットに公開（もちろん、AD FSを利用して認証させることもできます）できるようになりました
  8. サインイン画面がカスタマイズできるから
    • 標準機能としてサインイン画面に会社名やロゴを入れたり、問い合わせ先などのリンクを入れたりできるようになりました
  9. 内部/外部の認証方式の方式をカスタマイズできるから
    • 従来はweb.configなどをいじって対応する必要のあった認証方式の変更がGUIから簡単に実施できるようになりました
    • 例えば、イントラからの認証をWindows認証からAD FS Proxyと同じフォーム認証に変更できます。イントラ内に複数のADフォレストが存在する環境や、PCのログインユーザーとOffice365へのログインユーザーの情報が異なる場合などに活用できそうです。
  10. AlternateLoginIDが利用できるから
    • 従来、認証で利用する情報はUPNに固定されていました。このため、contoso.local をActive Directoryのドメインとして利用している場合などは各ユーザーのUPNを変更する必要がありました
    • AlternateLoginIDの設定の有効化により、ログイン要求が来てそのUPNが見つからなかった場合、指定したUPN以外の一意な項目（例えばmailなど）をキーとしてユーザーを検索し、そのユーザーへの認証要求として取り扱えるようになりました
  11. カリスマトレーナーによるトレーニングがあるから

良い事ばかり並べましたが、勿論新しいバージョンになったことで新たに考慮しなくてはならなくなったことや運用上の注意点なども出てきてます。この辺は後日またまとめてみたいと思います。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です