DirectoryServices を介して Active Directory ルックアップを実行することにより、特定の機能を保護するアプリケーションがあります。
このコードを古いドメインのウェブ ホストから新しいドメインに移行中です。コードは古いドメインで問題なく動作しました。ただし、新しいドメインに対してテストするとエラーが発生します。私たちの目標は古いドメインから移行することであるため、ドメイン間に完全な信頼があります。新しいドメインは、ドメイン内で読み取り専用のドメイン コントローラーを使用しますが、ファイアウォール ルールによって内部ネットワークから制限されます。ドメイン内の境界 DMZ サーバーのみが、読み取り専用ドメイン コントローラーにアクセスできます。
問題のあるコード行は次のとおりです。
using (PrincipalContext ctx = new PrincipalContext(ContextType.Domain,"mydc.local:389", null, ContextOptions.Negotiate))
新しいドメインに対してテストすると、次のように表示されます。
[COMException (0x8007203a): サーバーが動作していません。
この：
[ActiveDirectoryServerDownException: サーバーが動作していません。
読み取り専用ドメイン コントローラーの FQDN と共に。
DC の名前を指定しているので、私の要求はその DC に送られるべきではありませんか? これは、LDAP SRV レコードの DNS ルーティングの問題でしょうか? 私は DNS への表示専用アクセス権を持っていますが、読み取り専用 DC が Web ホストが存在する内部サイトで参照されていることを発見しました。また、これらの SRV レコードには優先順位が設定されていません。They are all 0. システム管理者は、プライマリ DC を指すプログラムによる方法が必要であると主張しています。私は PrincipalContext への呼び出しのおよそ 6 つのバリエーションを使用して、そうしようとしました。
私は最新の API に固執し、LDAP 文字列を記述することに頼りません。システム管理者側では、何を調査または検査できますか?
プログラマティック側では、リクエストを適切に送信していますか? DCを回避する代替方法または確実な方法はありますか? おそらくDNS次第ですが、現時点では不明です。
トラブルシューティング: LDAP 要求中に Web ホストのコマンド ラインから netstat を実行すると、2 つの書き込み可能な DC に対して LDAP 接続が要求されている場所が表示されます。その後、読み取り専用 DC にも要求が送信され、エラーがスローされます。