Kök DNS bölgesi ile aynı ada sahip Active Directory ormanı ve aynı ada sahip siteye göz atma

Bu önceki soru ile ilgili olarak neden kök etki alanı adını Active Directory ormanınızın adı olarak kullanmanın kötü bir fikir olduğu ...

Basitlik (ve dürüstlük) amacıyla ITcluelessinc olarak anlatacağım bir işverenim var. Bu işverenin harici olarak barındırılan bir web sitesi, www.ITcluelessinc.com ve birkaç Active Directory etki alanı vardır. BT konusunda clueless olarak, yıllar önce kendilerini adlı bir Active Directory ormanı kurdular ITcluelessinc.prvve buna karşı açıklanamayan zulümler gerçekleştirdiler. Bu söylenemez vahşetler sonunda onları yakaladı ve etraflarındaki her şey çöktüğünde, birisine "düzeltmek" için korkunç derecede bozuk ITcluelessinc.prvormandan göç etmeyi içeren büyük miktarda para ödemeye karar verdiler .

Ve elbette, BT hakkında clueless, duyduklarında iyi bir tavsiye bilmiyorlardı, aldıkları ITcluelessinc.comaklı başında tavsiyeler yerine yeni AD ormanlarını adlandırma tavsiyesini kabul ettiler ve üzerine bir şeyler koymaya başladılar. Birkaç saat önce hızlıca ilerleyin ve işlerinin çoğunun eski ITcluelessinc.prvActive Directory ormanına katıldığı ve kullandığı bir şirketimiz var ITcluelessinc.com. Bunun nispeten sorunsuz bir şekilde birlikte çalışması için, ITcluelessinc.comtrafiği üzerinden veya ITcluelessinc.prvtersini göndermek için DNS'de koşullu ileticiler kullandım .

resim açıklamasını buraya girin

( corp.ITcluelessinc.comVe eval.ITcluelessinc.comalan adları, daha sonra geldiğim ve kurduğum alan adları olarak adlandırılır ve henüz alakalı değildir.)

Birkaç saat önce ve ITcluelessinc'in teknik olmayan bir çalışanı, iş istasyonundan (ITcluelessinc kurumsal ağının içinde) www.ITcluelessinc.com'a göz atamadığını fark etti ve bunun bir sorun olduğuna karar verdi, Buna karar veren ITcluelessinc'in VIP çalışanı, çoğu Ricky-tick'in çözülmesi gerekiyor. Genellikle, büyük bir anlaşma değil, wwwiçin DNS bölgesinin altına bir A kaydı ekleyin ITcluelessinc.comve çıplak bağlantıyı denemediğiniz sürece siteye göz atabilirsiniz.

resim açıklamasını buraya girin

Yani, her şey düzgün bir şekilde ayarlanmış gibi görünüyor. Yönlendiriciler, wwwDNS'de ana bilgisayar girdisi ve yine de, ITcluelessinc.prvetki alanı denetleyicisini DNS sunucuları olarak kullanan istemciler , ev ağımdan aldığım web sayfası yerine www.ITcluelessinc.com adresine göz atmaya çalışırken bir bağlantı zaman aşımı alır .

Herkes Active Directory orman ve gereksinim koşullu ileticiler varlığı ITcluelessinc.prvgöz önüne alındığında, etki alanı iç istemcileri www.ITcluelessinc.com göz atmak nasıl izin verebilir hakkında herhangi bir düşüncesi var mı ITcluelessinc.com? Ya da, alternatif olarak, kimse onu çalıştırmanın tek yolunun ITcluelessinc.comActive Directory ormanından kurtulmak olduğuna ikna oldu mu?

Şu anda çalışmam gereken kurulum gibi görünüyor , ama açıkça değil ve bunun denemek için uğraştığı bir test ortamını nereden temin edeceğim konusunda hiçbir fikrim yok. Ve ne kadar değerli olursa olsun, bunu düzeltmenin tek yolunun kurduğum düzgün adlandırılmış ormanlara göç etmek olduğunu ve bu yeterince iyi bir cevap olmadığında, web sitesinin bir aynaya ev sahipliği yapmayı planladığınızı biraz kibarca önerdim. bizim bu sonları kadar etki alanı denetleyicileri her şey .ITcluelessinc.com

domain-name-system active-directory

— HopelessN00b
kaynak

Bu işe yaramalı - eski bir işte yaptığım kurulumu (ormanınız için kullanmak için bu kadar kötü bir alan, sempatim var) yansıtıyor, eksi iki ad alanı ve ileticiyi. İstemci sistemleri, wwwadı çözümlemeye çalışan bir NXDomain DNS yanıtı alıyor mu yoksa yanlış bir adres mi alıyor? Alternatif olarak, doğru adresi alıyorlar ancak bu adrese bağlanamıyorlar (web sitesi, ağ içindeki sunucularda barındırılıyor ve bir saç tokası NAT sorununa neden oluyor mu)?

— Shane Madden

@ShaneMadden: Düşüncelerim tam olarak ve özel bir konuşmada tartışıldı. Çalışmalı, ama çalışmıyor, ve neden olmasın konusunda bilgim yok. Bu noktada önereceğim tek şey, bir .prv istemcisinde bir paket yakalama başlatmak ve www için göz atmaya çalıştıklarında neler olduğunu görmek olacaktır.

— joeqwerty

@ShaneMadden Bir nslookup ile doğru adresi alıyor gibi görünüyor ve web sitesi harici olarak barındırıldığı için herhangi bir saç tokası NAT olmamalıdır . (İstemci -> .prv DC -> .com DC -> güvenlik duvarı -> iç ağlar). Bu işi daha önce rootdnsname etki alanındaki makineler rootdnsname'ye erişmeye çalışırken gördüm, ancak henüz rootdnsname ve rootdnsname web sitesine erişmesi gereken farklı bir etki alanına katılan istemcileri görmedim. ... yani sorunun böyle olması gerektiğini düşünüyorum.

— HopelessN00b

Evan ile hemfikirim. Yarısı ile ilgili ve bölünmüş beyin saçma yapan başka bir şirket için çalışmış, bahsetmeye değer bir hile, halka ekleyerek DNS sunucularını bir kayıt (veya alt alan adı) NSkayıt ekleyerek kontrol edebilmenizdir . Güvenlik duvarının DC'lerden dışa bakan DNS sunucusuna iletişime izin vermesi şartıyla, bu kabusu biraz hafifletir ve halka açık kayıtlar halka açık sunucuda yönetilebilir.

— Andrew B

@AndrewB Gerçek hikaye, ITcluelessinc, DNS'sini harici bir tedarikçiye dış kaynak kullandı, ancak hangisini bilmediğini ve çözemediğini, dolayısıyla harici ad sunucularında NS hileleri olmadığını. Ama bunu next_job $ için aklımda tutacağım, teşekkürler.

— HopelessN00b

İstemciler ana bilgisayar adını düzgün bir şekilde çözüyorsa, başka bir sorununuz var demektir. Ana bilgisayar adı istemci tarafından çözüldükten sonra DNS resim dışında.

Düşünülmesi gereken bazı şeyler:

İstemciler İnternet'e erişmek için herhangi bir HTTP proxy kullanıyor mu? Proxy'de doğru DNS bilgileri var mı?
Başarısız bir erişim girişiminden sonra istemcide DNS önbelleği nasıl görünür? Ana bilgisayar adı için doğru IP adresinin önbelleğe alındığını görüyor musunuz?
Aslında müşteri üzerinde neler oluyor? SYN_SENT durumunda doğru sunucu IP adresine, 80 numaralı TCP bağlantı noktasına takılmış bir bağlantı görüyor musunuz?
Web sitesinin adresine erişimi engelleme ile ilgili olabilecek herhangi bir güvenlik duvarı kuralı var mı?

Bu bir DNS sorunu değil, güvenlik duvarı / proxy / önbellek / filtre sorunu gibi kokuyor.

Ne yazık ki, kötü adlandırılmış Active Directory etki alanından kurtulmak için söyleyebileceğim gerçekten zorlayıcı bir şey yok. Onlar bu yolu yapmak için seçtim talihsiz, ama teknik bu var kutu çalışması. (Bu tür kötü adlandırma uygulamalarından da nefret ediyorum ... "aşağılık", inanıyorum ki, geçmişte buna nasıl atıfta bulunduğum ... Size bir alan adı değiştirme argümanı iletmek için iyi tavsiyelerde bulunsaydım ...)

— Evan Anderson
kaynak

If the clients are resolving the hostname properly then you've got another problem. Kahretsin. Bu durumda, muhtemelen bizim asstastic web proxy'imizdir. Teknik olarak çözülebilir olmayabileceğini düşündüğümde çok daha mutlu oldum ve nihayet $ # @ ^% ing karmaşasını düzeltmek zorunda kalacaklardı. :(

— HopelessN00b

Herhangi bir web proxy'sini atlayan bir sunucu veya dahili bilgisayarla test edin ve tekrar test edin. Evan ve Shane'in dediği gibi, kesinlikle bir www kaydı ile yapılabilir. Ne yapılamaz sadece itcluessinc.com gibi bu durumda web sitesine gider gibi bir varsayılan kayıt.

— TheCleaner

Evet, bil bakalım BT web sitelerini ve barındırma şirketlerini değiştirmeye karar veren departmanı yönetmediğinde ne olur? Bu doğru, eski wwwA kaydı işe yaramıyor, sisadmin sinirleniyor ve sirozunu ağırlaştırıyor.

— HopelessN00b