代替ADFS 2.0ポートを構成するためのクエスト

ADFSの構成を始めたとき、頭の中では考えがちらつきました。「すべてがうまくいけば、Habréについての記事を書きます。招待が消えるのがわかります」。 しかし、数日間の大騒ぎの後、私は行き詰まり、問題を解決することができませんでした。より経験豊富な誰かがまだこの問題を解決するか、議論プロセスで解決策が見つかることを期待して、この記事を書くことにしました。 しかし、それは昨日でした。夢の中で私は問題を熟考し、今ではADFSをどのように破ったかについての記事を書きました。



ここで独創的なことは何もありません(解決の過程で、多くの問題に「浮かんでいる」ことに気付きました)、それにもかかわらず、この解決策はGoogleには見つかりませんでした。 それはすべて、当社がLync Onlineの実装を決定したという事実から始まりました。 実装プロセスについては説明しませんが、すでに説明があります。 実装は成功しましたが、いくつかの問題がありました。



最初の問題


問題はADFSサーバー上の証明書にありました-内部CAによって発行されました。 ドメイン内のコンピューターの場合、グループポリシーによるCAの証明書は信頼されたルート証明機関にインストールされているため、これは問題を引き起こしませんでした。 ドメインに入力されていないコンピューターの場合、手動で追加することで問題が解決されましたが、これは既にあまり便利ではありませんでした。 また、AD CDの証明書にHTTP CDPを追加して、これらのコンピューターのCAを構成する必要がありました。 しかし、モバイルデバイスでは、信頼できるルート認証局に証明書を追加することは簡単ではないため、問題はその潜在能力を最大限に発揮しています。



Go Daddyからの既存の証明書を* .contoso.ruという名前で配置することが決定されました。私の信頼ドメインがcorp.contoso.ruであり、ADFSサーバーの名前がfs.corp.contoso.ruであり、この証明書が無効であることがわかりました。 しかし、証明書とサーバー名を置き換えることは問題ではなく、その後サーバーがfs.contoso.ruと呼ばれるようになり、証明書の問題は解決されたことが判明しました。



第二の問題


実際、それがこの記事を書く理由でした。 ADFSが企業ネットワークの外部で機能するために、ADFSプロキシを実装することにしました。 その動作のために、ポート443をADFSプロキシサーバー上の企業ネットワークに転送する必要があります。 しかし、443のポートは不足しており、多くのサービスで混雑しています。



そして、実装プロセス中に、代替ポートでのADFSの構成について説明した記事をどこかで見たことを思い出しました。 見つかった 、構成し始めた-動作しません。 サービス、サーバー、プール、IISの再起動で再生-動作せず、手順3でシャットダウンし、AD FS 2.0プロキシ構成ウィザードはADFSサーバーに接続できず、信頼を確立できません。 私もそのような記事を見つけましたが、いくつかの間違った代替ポートがあります。ADFSとADFSProxyの間のポートは変更され、サービスのポートは変更されません。



戦い


パッケージを分析することにしました。 バインドサイトとSet-ADFSProxyProperties -HttpsPort 444の設定にもかかわらず、ウィザードは頑固にADFSサーバーの443番目のポートに要求を送信し、スタートアップキーがないため、上記のリンクのステップ3を正常に完了できないことが判明しました。ノックする場所を伝えるための設定を含むファイルはありません。



次に、HTTPプロキシを使用して問題を回避することにしました。このオプションは手順3で使用できます。IISにアプリケーションリクエストルーティングをインストールし、ルーティングリクエストのルールを構成しました(「ポート1555へのすべてのリクエストはfs.contoso.ru:444にリダイレクトされる)」 -やれやれ、すべてうまくいきます! ウィザードを起動し、プロキシアドレス、ポート1555を指定し、テストを実行します-再度エラーが発生しました。 リクエストを確認します。ウィザードはリクエスト「connect fs.contoso.ru:443」を送信します。 ARRが接続トンネリングをサポートしていないことは明らかです。ARRをサポートするプロキシを探す必要があります。



ADFSサーバーにFiddlerをインストールし、設定でリモート接続を有効にし、HTTPS CONNECTSキャプチャを有効にし、暗号化を解除し、ルールのOnBeforeRequestセクションに次の行を追加しました。



if (oSession.url.toLowerCase() == "fs.contoso.ru:443") oSession.url = "fs.contoso.ru:444"



要求URLを変更します(同じ "connect fs.contoso.ru:443" 「)



if (oSession.host.toLowerCase() == "fs.contoso.ru") oSession.host = "fs.contoso.ru:444"



トンネル内の要求を目的のポートにリダイレクトします



oSession.utilReplaceInRequest("https://fs.contoso.ru/","https://fs.contoso.ru:444/")



リクエストの本文で、必要なリンクに変更します。



この組み合わせでは、テストは成功し、ウィザードは正常に完了し、ADFS Webリンクは外部の仕事から、portal.microsoftonline.comを開始します。 ADFSプロキシが獲得しました!



しかし、マイクロソフトの指示のステップ3を実行したので、今、「Godel、Escher、Bach:This Endless Garland」という本の用語で( ここからは celenに感謝します!)、もう一度この指示に飛び込んでセットアップを続ける必要があります。 はい、プロキシ仲介者を取り除きたいです。 手順4と6を実行します(手順5がなくても機能します)。プロキシを指定せずにウィザードを再試行して、プロキシなしで機能するように再構成しますが、結果は同じです。ポート443に要求を送信します。 次に、 Set-ADFSProxyProperties -ForwardProxyUrl ""



してプロキシ設定を削除し、Fiddlerをオフにし、サービスを再起動し、ログを調べて、httpプロキシなしでサービスが正常に機能することを確認します。Lyncが接続されています。 目標が達成されました!



まとめ


したがって、一時プロキシを使用して、ADFSプロキシをADFSに接続してから、この同じプロキシを削除できました。両方のサーバーがポート444で実行されています(httpポートは変更しませんでした)。 この方法は、外部IPアドレスが不足していて、Office 365を使用したい小規模企業に役立ちます。 まあ、Microsoftの願い-指示を修正し、何かが間違っている)



All Articles