it-swarm-id.com

Bagaimana Anda menemukan izin apa yang dimiliki grup AD, jika Anda tidak memiliki dokumentasi?

Anda baru saja dipekerjakan di perusahaan A dan administrator lama tidak ada lagi di sana. Permintaan mulai muncul untuk menambahkan pengguna ke grup pembatasan internet. Ketika Anda melihat grup tidak ada nama yang masuk akal dan tidak ada dokumentasi di luar sana untuk menjelaskan apa yang masing-masing kelompok memiliki hak dan apa fungsinya. Itu akan menimbulkan kekhawatiran bagi saya. Untuk keamanan, bagaimana Anda tahu jika setiap orang memiliki hak yang benar.

Bagaimana Anda menemukan apa yang berhak dimiliki kelompok? Apakah ada alat di luar sana yang akan menemukan informasi ini untuk Anda?

20
Ambar Batista

Saya perkenalkan apa yang mungkin akan menjadi jawaban agak panjang dengan "Tidak ada solusi sederhana".
Memecahkan ini akan membutuhkan beberapa pekerjaan strategis (itulah sebabnya saya merekomendasikan tidak memindahkan ini ke SF).

Sekarang saya akan menjelaskan alasannya.

Windows, pada intinya, sebagian besar didasarkan pada model DAC kontrol akses.
Semuanya di OS dapat diamankan dengan ACL - file, folder, registri, pipa bernama, soket, berbagi, dll.

Menggunakan grup AD memungkinkan Anda untuk mengabstraksi itu menjadi model tipe RBAC, tetapi secara internal itu masih merupakan model DAC. (Maksud saya adalah, Anda dapat membuat ACE (entri kontrol akses) untuk grup (mis. Peran), tetapi Anda masih membuat ACE - dan itulah yang akan diverifikasi pada akses).

Penekanan pada "kebanyakan".
Ada beberapa pengecualian berbeda untuk ini:

  1. Ada beberapa implementasi Tingkat Integritas MAC - yaitu (di Vista/7/2008).
    Namun, ini biasanya dan mekanisme perlindungan OS internal, dan biasanya tidak ditingkatkan untuk kontrol akses nyata (selain UAC bawaan). Biasanya .
  2. Hak istimewa tingkat OS. (Meskipun dimungkinkan untuk menentukan pengguna tertentu untuk memberikan hak istimewa ini, itu dimaksudkan - dan berfungsi sebagai - model RBAC).

Tapi tunggu, itu hanya di OS itu sendiri ...
Windows, sebagai platform, memungkinkan dan mendorong aplikasi (pihak ke-3, produk MS, dan tambahan OS) untuk menggunakan keanggotaan grup AD sebagai mekanisme RBAC:

  1. Aplikasi pihak ketiga dapat memverifikasi keanggotaan grup melalui pencarian AD/LDAP sederhana - aplikasi ini mungkin menyimpan nama grup dan menyelesaikannya, atau menyimpan SID grup dan menanyakan langsung untuk itu.
  2. Jangan lupa SQL Server - ini terutama didasarkan pada (beberapa jenis peran), namun praktik terbaik biasanya disarankan untuk menambahkan AD grup ke peran ini, dan bukan pengguna secara langsung.
  3. Selama kita berada di sana, COM + juga mengelola akses oleh RBAC, tetapi sekali lagi praktik terbaik adalah menambahkan grup, bukan pengguna, ke peran COM +.
  4. Sharepoint juga mengelola akses ke situs sesuai dengan peran/grup/dan milis ...

Mulai melihat maksud saya?
Saya tidak ingin mengatakan itu sia-sia, TAPI ...

Untuk rekap:
Untuk menemukan daftar izin yang pasti dimiliki oleh suatu kelompok tertentu, Anda (atau alat) perlu memeriksa secara SEMUA hal-hal berikut secara berulang (dan, jangan lupa untuk berulang tentang keanggotaan grup juga):

  • Untuk setiap server di organisasi Anda:
    • periksa ACL pada semua folder dan file secara rekursif
    • periksa secara rekursif SACL pada semua folder dan file (daftar kontrol akses sistem - audit kontrol ini)
    • periksa pemilik secara rekursif pada semua folder dan file
    • periksa ACL, SACL, dan pemilik secara rekursif pada semua kunci registri
    • periksa ACL, SACL, dan pemilik secara rekursif pada semua pipa, proses dan utas, layanan, pekerjaan, dll.
    • Periksa semua hak istimewa level OS (meskipun dimungkinkan hal ini dapat dibuat lebih mudah menggunakan GPO ...)
    • Periksa semua peran COM +, peran MSMQ, dll.
  • Untuk setiap domain dalam AD Anda:
    • Periksa semua hak istimewa tingkat domain
    • periksa semua GPO (objek kebijakan grup)
  • Untuk setiap server basis data:
    • Periksa semua peran server
    • periksa semua peran basis data
    • periksa semua peran aplikasi (dalam MSSQL)
  • Untuk setiap portal Sharepoint:
    • periksa semua peran dan hak istimewa tingkat server
    • periksa semua peran dan hak istimewa level-situs dan level-daftar
  • Untuk setiap aplikasi pihak ke-3:
    • Periksa penggunaan grup AD
    • verifikasi bagaimana aplikasi menggunakan peran ini:
      -> Nama grup vs. DN vs. SID grup vs. ... mis. GUID grup
      -> apakah aplikasi secara eksplisit memeriksa keanggotaan peran langsung, atau apakah itu menggunakan metode rekursif "cerdas"?
    • Perhatikan bahwa ini berlaku untuk produk dan platform paket pihak ketiga (mis. Oracle, SAP, MQSeries, WebSphere ...), dan untuk aplikasi bisnis yang dikembangkan khusus.

Apakah ini lengkap?
Sayangnya tidak. Sebagai contoh saya tidak termasuk meninjau semua desktop dalam org, karena mereka tidak boleh memiliki izin tingkat grup AD tertentu yang ditetapkan pada mereka (kecuali untuk misalnya Administrator dan HelpDesk ) - tetapi perhatikan bahwa mereka sering melakukannya.
Tapi ini bukan daftar lengkap ...

Ini adalah kerugian besar untuk menggunakan model DAC - "D" mungkin juga untuk "Terdistribusi", karena tidak ada tempat sentral untuk mencari semua ACL ini.
Seperti yang saya catat di Apa perbedaan antara RBAC dan DAC/ACL? :

  • Definisi DAC biasanya dilampirkan pada data/sumber daya, sedangkan RBAC biasanya didefinisikan di dua tempat: dalam kode/konfigurasi/metadata (akses peran), dan pada objek pengguna (atau tabel - peran yang dimiliki masing-masing pengguna).

Sekarang, sedikit tentang solusi:

  • Ada beberapa alat untuk mengumpulkan bagian-bagian berbeda dari daftar di atas, mis. @ Jawaban Ian menggunakan skrip PowerShell untuk mengumpulkan folder ACL. Ada banyak alat lain untuk itu (saya telah dikenal menggunakan CACLS di masa lalu), beberapa dicatat di sini .
    Untuk meminta alat/skrip untuk bagian tertentu dari daftar, Anda mungkin mendapatkan ide yang lebih baik di ServerFault. Namun perhatikan bahwa itu hanya satu bagian dari daftar.
  • Ada "manajemen peran" dan "penemuan peran" produk di luar sana, dari beberapa vendor besar, biasanya di ruang Manajemen Identitas - saya tidak bisa secara khusus merekomendasikan satu, tetapi layak melihat ke dalam: CA (sebelumnya Eurekify yang merupakan alat yang layak (meskipun tidak lengkap)), IBM , Oracle .
    Tentu saja ada yang lain, dan saya akan bersandar banyak untuk menemukan vendor kecil yang lebih baik, bahkan dari startup (oke, mungkin saya bias;)). Maksud saya, dari yang belum dibeli oleh vendor yang lebih besar.
  • Anda dapat (dan mungkin harus, meskipun ini jauh dari sepele) memulai proses memetakan organisasi, persyaratan bisnis, dan lainnya - dengan tujuan hak istimewa apa yang mereka harus dapatkan, dan bukan hanya apa status quo itu sekarang =. Beberapa alat yang disebutkan dalam poin sebelumnya dapat membantu di sini.
  • Jika analisis peran dan pemodelan sebelumnya berjalan dengan baik, pertimbangkan untuk solusi IdM/IAM/EAM yang lengkap. Sekali lagi, komentar saya masih tergantung vendor.
  • Bagaimanapun, bertujuan untuk meminimalkan distribusi ACL di semua tempat, dan Dorong untuk RBAC minimal, terpusat sebanyak mungkin.

Dan, kata terakhir peringatan bagi mereka yang cukup beruntung adalah before situasi tidak menyenangkan yang saat ini Anda alami:
Pasti melihat ke platform otorisasi terpusat, seperti produk IdM/IAM/EAM. (Perhatikan bahwa ada yang banyak lebih baik daripada yang lain, dan beberapa bahkan tidak akan menyelesaikan situasi ini.)


tl; dr: Anda benar dan benar-benar kaca . Lihat di atas. ;)
(tapi semua harapan tidak hilang ...)

23
AviD

Jawabannya tergantung pada bagaimana tepatnya Anda ingin melihat/mengelola data ini. Rekomendasi saya adalah PowerShell untuk mendapatkan semua ini.

Jika Anda memang memilih untuk menggunakan PowerShell, Anda dapat menggunakan Cmdlets AD asli atau Cmdlets gratis Quest (http://www.quest.com/powershell/activeroles-server.aspx). Untuk menggunakan Cmdlet asli, Anda harus memiliki setidaknya satu pengontrol domain Windows Server 2008 R2 di domain Anda atau setidaknya satu contoh dalam set konfigurasi LDS AD yang berjalan pada server Windows Server 2008 R2 - lihat http: //technet.Microsoft.com/en-us/library/ee617195.aspx untuk detail.

Secara efektif, yang harus Anda lakukan adalah memeriksa folder ACL secara rekursif untuk tingkat akses Grup tertentu. Ada beberapa tempat ( di sini dan di sini ) di mana orang melakukan upaya, tetapi mengingat bahwa ini mungkin jumlah yang sangat besar dari struktur file yang harus ditelusuri skrip, itu pasti bisa memakan waktu. Itu menjadi lebih rumit untuk kelompok bersarang.

EDIT: @AviD adalah spot-on tentang sintaks perintah asli, dan itu melakukan hal yang salah sama sekali! Diedit agar lebih sesuai topik.

4
Ian Pugsley

Ini dapat dilakukan melalui Prompt perintah Windows sebagai berikut:

  • Buka direktori tempat Anda ingin menyimpan laporan Anda, jika tidak ada yang dipilih, maka itu harus default ke direktori pengguna yang login. Contohnya adalah cd C:\Users\Administrator\Desktop

  • Buat laporan menggunakan perintah berikut:

    gpresult /s servername /user INTERNAL\user1 /h gpreport.html
    
  • Perintah di atas akan menghasilkan laporan berdasarkan GPOS dan aturan yang diterapkan untuk pengguna yang dipilih untuk laporan tersebut. Pengguna ini harus seseorang yang merupakan anggota grup tertentu atau Anda dapat membuat pengguna uji untuk menguji pengaturan grup tertentu.

  • Cara lain Anda dapat menemukan informasi ini adalah dengan mengedit GPO dan pada Windows 2008 Anda harus memiliki opsi untuk melihat semua pengaturan dan mengurutkannya berdasarkan status, Anda kemudian dapat merekam semua pengaturan yang diaktifkan dari GPO.

1