Belgeniz yoksa bir AD grubunun hangi izinlere sahip olduğunu nasıl keşfedersiniz?

"Basit bir çözüm yok" ile muhtemelen uzunca bir cevap olacağını önceden yazayım.
Bunu çözmek bazı stratejik çalışmalar gerektirecektir (bu yüzden not bunu SF'ye taşımayı tavsiye ettim).

Şimdi nedenini açıklayacağım.

Windows, özünde çoğunlukla erişim kontrolünün DAC modeli değerine dayanmaktadır.
Her şey OS'de bir ACL ile güvence altına alınabilir - dosyalar, klasörler, kayıt defteri, adlandırılmış borular, soketler, paylaşımlar vb.

AD gruplarını kullanmak, bunu bir RBAC tipi modele soyutlamanızı sağlar, ancak dahili olarak hala bir DAC modelidir. (Demek istediğim, bir grup için bir ACE (erişim kontrolü girişi) oluşturabilirsiniz (yani rol), ancak yine de bir ACE oluşturuyorsunuz - ve erişimde doğrulanacak olan budur).

"çoğunlukla" .
Bunun birkaç istisnası var:

1. MAC - Dürüstlük Düzeyleri'nin bir uygulaması vardır (Vista/7/2008'de).
   Bununla birlikte, bu genellikle ve dahili işletim sistemi koruma mekanizmasıdır ve genellikle not gerçek erişim kontrolü için kullanılır (yerleşik UAC dışında). genellikle .
2. İşletim sistemi düzeyinde ayrıcalıklar. (Bu ayrıcalıkları vermek için belirli bir kullanıcıyı belirtmek mümkün olsa da, bir RBAC modeli olarak tasarlanmıştır - ve işlev görür).

Ama bekleyin, bu sadece işletim sisteminin kendisinde ...
Bir platform olarak Windows, uygulamaların (3. taraf, MS ürünleri ve işletim sistemi eklentileri) AD grubu üyeliğini RBAC mekanizması olarak kullanmasına izin verir ve teşvik eder:

1. 3. taraf uygulamalar basit bir AD/LDAP araması yoluyla grup üyeliğini doğrulayabilir; bu uygulamalar grup adını depolayıp çözüyor veya grubun SID'sini kaydediyor ve doğrudan bunun için sorgu yapıyor olabilir.
2. SQL Server'ı unutmayın - bu esas olarak (birkaç farklı türde) role dayanır, ancak genellikle kullanıcılara değil, bu rollere AD groups eklemek için en iyi uygulama önerilir. direkt olarak.
3. Olduğumuz sürece, COM + RBAC tarafından erişimi de yönetir, ancak yine de en iyi uygulama, COM + rollerine kullanıcı değil grup eklemektir.
4. Sharepoint, sitelere erişimi rollere/gruplara/ve posta listelerine göre de yönetir ...

Demek istediğimi görmeye başladın mı?
Umutsuz olduğunu söylemek istemiyorum, AMA ...

Özetlemek gerekirse:
Belirli bir grubun sahip olduğu kesin izin listesini bulmak için, siz (veya bir araç) aşağıdakilerin TÜMÜNÜ tekrar tekrar kontrol etmeniz gerekir (ve grup üyeliğini de tekrarlamayı unutmayın):

• Kuruluşunuzdaki her sunucu için:
  • tüm klasör ve dosyalarda ACL'yi tekrar tekrar kontrol edin
  • tüm klasörlerde ve dosyalarda tekrar tekrar kontrol edin SACL (sistem erişim kontrol listeleri - bu kontrol denetimi)
  • tüm klasörler ve dosyalardaki sahibini tekrar tekrar kontrol et
  • aCL, SACL ve sahibini tüm kayıt defteri anahtarlarında tekrar tekrar kontrol edin
  • aCL, SACL ve sahibini tüm adlandırılmış kanallar, süreçler ve iş parçacıkları, hizmetler, işler vb.
  • Tüm işletim sistemi seviyesi ayrıcalıklarını kontrol edin (GPO'lar kullanılarak bu daha kolay olabilir ...)
  • Tüm COM + rollerini, MSMQ rollerini vb. Kontrol edin.
• AD'nizdeki her alan adı için:
  • Alan adı düzeyinde tüm ayrıcalıkları kontrol edin
  • tüm GPO'ları kontrol et (grup politikası nesneleri)
• Her veritabanı sunucusu için:
  • Tüm sunucu rollerini kontrol edin
  • tüm veritabanı rollerini kontrol et
  • tüm uygulama rollerini kontrol et (MSSQL'de)
• Her Sharepoint portalı için:
  • sunucu düzeyinde tüm rolleri ve ayrıcalıkları kontrol et
  • site düzeyinde ve liste düzeyinde tüm rolleri ve ayrıcalıkları kontrol edin
• Her 3. taraf uygulaması için:
  • AD gruplarının herhangi bir kullanımını kontrol edin
  • doğrulama how uygulama şu rolleri kullanır:
    -> Grup adı ve DN'ye karşı grup SID'ye karşı ... ör. grup GUID'i
    -> Uygulama doğrudan rol üyeliğini açıkça kontrol ediyor mu veya "daha akıllı" özyinelemeli yöntemler kullanıyor mu?
  • Bunun hem 3. taraf paketlenmiş ürünler ve platformlar (örneğin Oracle, SAP, MQSeries, WebSphere ...) hem de özel geliştirilmiş iş uygulamaları için geçerli olduğunu unutmayın.

Bu tamam mı?
Üzgünüm hayır. Örneğin, bu shouldnt özel AD grubu düzeyinde izinlere sahip olduğundan, kuruluştaki tüm masaüstleri incelemelerini dahil etmedim ( Örneğin, Administrators ve HelpDesk hariç) - ancak sık sık yaptıklarını unutmayın.
Ama bu tam bir liste değil ...

Bu, bir DAC modeli kullanmanın en büyük dezavantajıdır - "D", tüm bu ACL'leri aramak için merkezi bir yer olmadığından, "Dağıtılmış" için de olabilirdi.
Bahsettiğim gibi RBAC ve DAC/ACL arasındaki fark nedir? :

• DAC tanımları genellikle veriye/kaynağa eklenirken, RBAC genellikle iki yerde tanımlanır: kod/yapılandırma/meta verilerde (rol erişimi) ve kullanıcı nesnesinde (veya tabloda - her kullanıcının sahip olduğu roller).

Şimdi, çözümler hakkında biraz:

• Yukarıdaki listelerin farklı bölümlerini toplamak için çeşitli araçlar vardır, ör. @ Ian'ın cevabı, klasör ACL'lerini toplamak için powershell komut dosyalarını kullanarak yanıtlar. Bunun için birçok araç var (geçmişte CACLS kullandığım biliniyordu), bazıları not edildi burada .
  Listenin belirli bir bölümü için bir araç/komut dosyası istemek için ServerFault'da daha iyi fikirler edinebilirsiniz. Ancak listenin yalnızca bir bölümü olduğunu dikkate alın.
• Genellikle kimlik yönetimi alanında, büyük satıcıların bazılarından "rol yönetimi" ve "rol keşfi" ürünleri var - Özellikle birini tavsiye edemiyorum, ama göz atmaya değer: CA (eski adıyla iyi bir araç (tamamlanmamış olsa da) olan Eurekify), IBM , Oracle .
  Tabii ki başkaları da var ve ben bir başlangıçtan itibaren bile türünün en iyi küçük satıcılarını bulmak için ağır yalın olurdu (tamam, belki önyargılıyım; )). Yani, daha büyük satıcılar tarafından satın alınmamış olanlardan.
• Organizasyon, iş gereksinimleri ve benzerlerini haritalama sürecini başlatabilirsiniz (ve muhtemelen önemsiz de olsa) - hangi ayrıcalıklara sahip olmaları gerektiğini olsun, sadece statükonun ne olduğunu değil . Önceki noktada bahsedilen araçlardan bazıları burada yardımcı olabilir.
• Önceki rol analizi ve modellemesi iyi giderse, tam gelişmiş bir IdM/IAM/EAM çözümü kullanmayı düşünün. Yine, wrt satıcılarımın yorumları hala duruyor.
• Her durumda, ACL'lerin her yerde dağılımını en aza indirmeyi hedefleyin ve mümkün olduğunca merkezileştirilmiş minimum RBAC için zorlayın.

Ve, şu anda kendinizi bulduğunuz hoş olmayan durum önce olacak kadar şanslı olanlara son bir uyarı kelimesi:
Kesinlikle , IdM/IAM/EAM ürünleri gibi merkezi bir yetkilendirme platformuna bakın. (Bazılarının much diğerlerinden daha iyi olduğunu ve bazılarının da bu durumu çözmeyeceğini unutmayın.)

tl; dr: Doğru ve gerçekten berbatsınız . Yukarıya bakınız. ;)
(ama tüm umutlar kaybolmaz ...)

Bunun cevabı, bu verileri tam olarak nasıl görmek/yönetmek istediğinize bağlıdır. Benim önerim tüm bunları elde etmek için PowerShell olacaktır.

PowerShell kullanıcısını seçerseniz, yerel AD Cmdlet'lerini veya Quest'in ücretsiz Cmdlet'lerini kullanabilirsiniz (http://www.quest.com/powershell/activeroles-server.aspx). Yerel Cmdlet'leri kullanmak için, etki alanınızda en az bir Windows Server 2008 R2 etki alanı denetleyicisine veya Windows Server 2008 R2 sunucusunda çalışan bir AD LDS yapılandırma kümesinde en az bir örneğe sahip olmanız gerekir - bkz. http: Ayrıntılar için //technet.Microsoft.com/en-us/library/ee617195.aspx .

Etkili bir şekilde, tek yapmanız gereken belirli bir Grubun erişim seviyesi için klasör ACL'lerini tekrar tekrar kontrol etmektir. İnsanların girişimde bulunduğu birkaç yer vardır ( burada ve burada ), ancak bunun muhtemelen komut dosyasının gezinmesi gereken inanılmaz derecede büyük miktarda dosya yapısı olduğu göz önüne alındığında, kesinlikle biraz zaman alabilir. Yuvalanmış gruplar için daha da karmaşık hale gelir.

EDIT: @AviD orijinal komut sözdizimi hakkında spot-on ve tamamen yanlış bir şey yapıyordu! Konuyla ilgili daha fazla olacak şekilde düzenlendi.

Bu, Windows komut istemi aracılığıyla aşağıdaki gibi yapılabilir:

• Raporunuzu kaydetmek istediğiniz dizine gidin, seçili değilse varsayılan olarak oturum açmış olan kullanıcının dizinini kullanmalıdır. Bir örnek cd C:\Users\Administrator\Desktop

• Aşağıdaki komutu kullanarak bir rapor oluşturun:

  gpresult /s servername /user INTERNAL\user1 /h gpreport.html
  

• Yukarıdaki komut, GPOS'a ve raporun seçildiği kullanıcıya uygulanan kurallara dayalı bir rapor oluşturur. Bu kullanıcı, belirli bir grubun üyesi olan biri olmalıdır veya belirli bir grubun ayarlarını test etmek için bir test kullanıcısı oluşturabilirsiniz.

• Bu bilgiyi bulabilmenin bir başka yolu da GPO ve Windows 2008'de tüm ayarları görme ve duruma göre sıralama seçeneğine sahip olmanız, daha sonra tüm etkin ayarları kaydedebilmenizdir. GPO.