ADFS2.0プロキシサーバーとADFSサーバーを公開する
O365を使用したSSO用のADFSの展開に取り組んでいます。
ファイアウォール構成を処理するコンサルティング会社があります。
今日、ADFSプロキシサーバーをインストールするためにDMZをセットアップするように依頼している間、コンサルタントは、ADFSサーバーに対して直接ポート443を開くように説得しようとしました。プロキシをまったく使用しないこと。彼は、そのような構成が現在の標準的な方法であると私に言いました。
当社の事業の性質上、内部サーバーを外部に開放しないなど、非常に厳しいセキュリティ要件があります。
私が持っている質問は、彼が怠惰でDMZを構成したくなかったので、彼はただ煙を吹いているのか、それとも彼には正当なポイントがあるのかということです。
そんなバカな！
プライマリADFSサーバーをインターネットに配置しないでください。
プロキシの役割が発明された特定の理由があり、プライマリADFSボックスをインターネット上に配置することは賢明なアイデアではありません。主な理由は、プライマリサーバーがデフォルトでWindowsベースの認証のみを許可するように構成されているためです。つまり、誰でもリクエストを送信してブルートフォース攻撃を試みることができます。さらに悪いことに、パスワードを取得すると、ドメインに有効なユーザー名とパスワードが設定されます。最悪の種類の痛み。
ただし、プロキシはWebフォームベースのアプローチを使用して、企業ファイアウォールの外側にいるユーザーにWebフォーム経由でのログインを強制することで脅威を軽減します。合格すると、信頼できるサービス（O365を参照）が使用するCookieまたはリダイレクトトークンのいずれかが返されます。
いずれにせよ、これはMicrosoftが推奨する設定に直接違反し、セキュリティ監査の検証に合格しないことは確かです。さらに、ポート80と443のトラフィックのみをプロキシに公開しているため、特定のIPを介してこれら2つのポートのみをプロキシ（または負荷分散プロキシ）に単純にポート転送することはそれほど難しくありません。とにかく、特に他の公に面したサービスがある場合は、a DMZが賢明です。
ただし、このコンサルタントが何をしているかによって異なります。 ADFSサーバーの前にあるファイアウォールをTMGなどで処理する場合、内部ADFS 2.0の443に直接穴を開ける代わりに、プロキシの役割を実行してWebフォーム認証を外部クライアントに提示できます。サーバ。
私は同じ側にいて、内部ADFSサーバーをインターネットに直接公開していません。誰かが私にそれをどれほど安全に伝えようとしても、あなたはまだドメインに参加しているサーバーをパブリックインターネットに直接公開することについて話している。
プロキシサーバーをドメインに参加させる必要はありません。それらを使用するもう1つの利点。
-E