Windows AD etki alanında kilitli kullanıcı hesabının nedeni nasıl bulunur?

Outlook'taki son bir olaydan sonra, aşağıdaki sorunu en verimli şekilde nasıl çözeceğimi merak ediyordum:

Oldukça tipik küçük ve orta ölçekli bir AD altyapısı olduğunu varsayalım: birkaç DC, birkaç dahili sunucu ve Windows istemcisi, DMZ içinden kullanıcı kimlik doğrulaması için AD ve LDAP kullanan çeşitli hizmetler (SMTP geçişi, VPN, Citrix vb.) Ve birkaç dahili hizmetlerin tümü kimlik doğrulaması için AD'ye dayanmaktadır (Exchange, SQL sunucusu, dosya ve yazdırma sunucuları, terminal hizmetleri sunucuları). Tüm sistemlere tam erişiminiz var, ancak ayrı ayrı kontrol etmek için biraz fazla (istemcileri sayarak).

Şimdi, bilinmeyen bir nedenden dolayı, bir (veya daha fazla) kullanıcı hesabının birkaç dakikada bir şifre kilitleme politikası nedeniyle kilitlendiğini varsayalım.

• Bundan sorumlu servisi / makineyi bulmanın en iyi yolu ne olabilir?
• Altyapının saf olduğu varsayıldığında, ek yönetim aracı olmayan standart Windows ve varsayılan olarak birkaç değişiklik varsa, bu tür kilitlenmenin nedenini bulma sürecinin hızlandırılabileceği veya geliştirilebileceği herhangi bir yol var mı?
• Böyle bir hesap kilitleme DOS karşı sistemin esnekliğini artırmak için ne yapılabilir? Hesap kilitlemesini devre dışı bırakmak açık bir yanıttır, ancak daha sonra karmaşıklık zorlansa bile kolayca kullanılabilen parolalara sahip olan kullanıcılar sorunuyla karşılaşırsınız.

Verilen cevaplara görmediğim bir şey ekliyorum.

Bundan sorumlu servisi / makineyi bulmanın en iyi yolu ne olabilir?

Sen olamaz sadece PDCe Alanın tamamı için hesap lokavta ilişkin en güncel güncel bilgiler var ise, hangi istemci yaklaşık bilgiye sahip olmamasıdır, çünkü IP (PDCe Güvenlik günlüğüne bakmak ya hostname), başarısız oturum açma girişimlerinin PDCe dışında başka bir DC'de gerçekleştiği varsayılarak, başarısız oturum açma denemeleri geldi. PDCe, "xyz Hesabı kilitlendi" diyecektir, ancak başarısız oturum açmaların etki alanındaki başka bir DC'de gerçekleşip gerçekleşmediğini nereden söylemeyecektir. Yalnızca oturum açma işlemini doğrulayan DC, istemcinin adresi de dahil olmak üzere oturum açma hatasını kaydeder. (Ayrıca RODC'leri bu tartışmaya getirmemek.)

Birkaç etki alanı denetleyiciniz olduğunda başarısız oturum açma denemelerinin nereden geldiğini öğrenmenin iki iyi yolu vardır. Etkinlik yönlendirme ve Microsoft'un Hesap Kilitleme Araçları .

Merkezi bir konuma olay yönlendirmeyi tercih ediyorum. Tüm etki alanı denetleyicilerinizdeki başarısız oturum açma denemelerini merkezi bir günlük sunucusuna iletme. Ardından, alan adınızın tamamında başarısız oturum açma bilgilerini aramak için yalnızca bir yeriniz vardır. Aslında ben şahsen yani şimdi orada, gerçekten yok Microsoft'un hesabı kilitleme araçları seviyorum tek iyi yol.

Olay yönlendirme. Çok seveceksiniz.

Altyapının saf olduğu varsayıldığında, ek yönetim aracı olmayan standart Windows ve varsayılan olarak birkaç değişiklik varsa, bu tür kilitlenmenin nedenini bulma sürecinin hızlandırılabileceği veya geliştirilebileceği herhangi bir yol var mı?

Yukarıyı görmek. Daha sonra SCOM veya Nagios gibi izleme sisteminizi veya ne kullanırsanız kullanın, bu tekli olay günlüğünü tarayabilir ve cep telefonunuzu kısa mesajlarla ya da her neyse patlatabilirsiniz. Bundan daha fazla hızlanmıyor.

Böyle bir hesap kilitleme DOS karşı sistemin esnekliğini artırmak için ne yapılabilir?

1. Kullanıcı eğitimi. Onlara Windows hizmetlerini etki alanı kullanıcı hesapları altında çalışacak şekilde ayarlamalarını durdurmalarını, bittiğinde RDP oturumlarından çıkış yapmalarını, Outlook için önbelleğe alınmış parolaların Windows Kimlik Bilgisi Kasası'nı nasıl temizleyeceklerini öğretmelerini vb.
2. Kullanıcıların artık bu kullanıcı hesapları için şifreleri yönetmesine gerek kalmayacak şekilde Yönetilen Hizmet Hesaplarını kullanın. Kullanıcılar her şeyi emer. Bir kullanıcıya seçim yaparsanız, her zaman yanlış seçim yapacaktır. Bu yüzden onlara bir seçim yapma.
3. GPO aracılığıyla uzak oturum zaman aşımlarını zorlama. Bir kullanıcı bir RDP oturumunda 6 saat boyunca boşta kalırsa, onları başlatın.

Yönetici sorunlarını daha geniş bir ortamda temizlerken de aynı sorunu yaşadık. DC denetim günlükleri teknik olarak gerekli bilgileri sağlamasına rağmen, AD'deki herhangi bir değişiklikle birlikte bu günlükleri tarayan ve oturum açma girişimleri arayan ManageEngine'nin ADAudit Plus ürününü uygulamaya karar verdik. Yerleşik bir raporlama özelliği ve biraz Excel çalışması kullanarak, oturum açma işlemlerinin nereden geldiğini (oldukça kolay) izleyebildik. Bizim durumumuzda, çoğunlukla, çeşitli uygulamalar uygulanırken hizmet hesapları yerine yönetici hesapları kullanan yöneticilerle ilgilidir.

Böyle bir hesap kilitleme DOS karşı sistemin esnekliğini artırmak için ne yapılabilir?

Yapamazsın.

Evinizi yakabilecek birçok şey var. DHCP kapsamı tükenene kadar IP adreslerini tekrar tekrar istemek için basit kod gibi. Veya MFT dolana kadar dizin oluşturan basit kod ve geri yüklemeniz için bölümünüzü yeniden biçimlendirmeniz gerekir. Her şeye karşı koruyamazsınız.

Lokavtlarla ilgili daha yaygın bir senaryo, kimlik bilgilerini birkaç yıl önce yaygın olandan çok daha geniş bir cihaz yelpazesine giren kişilerdir. Yazıcılar (e-posta taramalarına) veya akıllı telefon veya tablet gibi. Kimlik bilgilerini nereye girdiklerini unuturlarsa veya artık cihaza erişimleri yoksa, cihazın sonsuza kadar kimlik doğrulaması yapmaya devam etmesi mümkündür. E-posta yetkilendirme, bu cihazları izlemek için zor bir vektördür ve bunu yapsanız bile, kullanıcı buna erişemeyebilir veya nerede olduğunu bilmeyebilir. IP 10.4.5.27? Hesaplarının kilidini açmak için her gün yardım masasını aramak zorunda olan bir kullanıcıyı biliyorum, sonra hemen oturum açacaklar ve sonra hesapları tekrar kilitlenecekti. Bunu aylarca yaptılar. Onlara hesaplarının yeniden adlandırılmasını söyledim.

Hayatın caydırıcıları vardır, hepsini kaldıramayız.