完全な開示: 私は AD の人間ではないので、これは明らかなことに関するものかもしれません。もしそうであれば、事前にお詫び申し上げます。この件に関して以前の質問を検索してみました。
AD 環境 (標準の CentOS 5.x - AD との特別な統合なし) に Linux ベースの Web アプリケーション サーバーをインストールしています。アプリは、グローバル カタログ サーバーに対して LDAPS クエリを実行します。どの AD サーバーと通信するかを検出するために、AD ドメイン (foo.int) に関連する A レコードの DNS ルックアップを実行します。この特定のクエリは失敗しているようです (まだ調査中です)。
その間、いくつか確認しておきたいことがあります。
- Linux サーバーを Microsoft DNS サーバーにポイントし、AD ドメイン (foot.in) をクエリする場合、いくつかの GC を指す A レコードを取得する必要があると考えるのは妥当でしょうか?
- GC の A レコードの可用性は、かなり標準的なものですか? それとも、環境ごとに異なりますか? 言い換えると、DC の内部 A レコードがまったく公開されていない環境もあるのでしょうか?
- これらの特定のレコードは自動的に管理/更新されるものでしょうか、それとも管理者が手動で追加/編集するものでしょうか?
答え1
Linux サーバーを Microsoft DNS サーバーにポイントし、AD ドメイン (foot.in) をクエリする場合、いくつかの GC を指す A レコードを取得する必要があると考えるのは妥当でしょうか?
いいえ、あなたが得るものはすべてドメイン コントローラ ドメイン内のグローバル カタログ サーバーだけが必要なわけではありません。グローバル カタログ サーバーだけが必要な場合はクエリを実行できます。_gc._tcp.<your_AD_FQDN>また、特定のサイト内の GC だけが必要な場合はクエリを実行できます_gc.<your_site_name>._sites.<your_AD_FQDN>。これは実際には SRV タイプのレコードです。
GC の A レコードの可用性は、かなり標準的なものですか? それとも、環境ごとに異なりますか? 言い換えると、DC の内部 A レコードがまったく公開されていない環境もあるのでしょうか?
すべての DC には A レコードがあり、自動的に登録されるはずです。ただし、NIC の自動 DNS 登録がオフになっていると、誰かが手動で登録しない限り A レコードが存在しない可能性があります。この機能がオフになっていると、AD が壊れます。
これらの特定のレコードは自動的に管理/更新されるものでしょうか、それとも管理者が手動で追加/編集するものでしょうか?
_sites、、、およびゾーン_msdcsは自動的に管理されます。誰かが設定でこれらの機能をオフにするような愚かなことをしていない限り、A レコードも自動的に管理されるはずです。_tcp_udp