Maksymalny rozmiar listy kontroli dostępu (ACL) na obiektach katalogu Active Directory
Wszystkie obiekty w usłudze Active Directory i wszystkie dające się zabezpieczyć obiekty na komputerze lokalnym lub w sieci posiadają tzw. deskryptory zabezpieczeń, które pomagają kontrolować dostęp do obiektów. Deskryptory zabezpieczeń zawierają informacje o tym, kto jest właścicielem obiektu (owner), kto może uzyskać do niego dostęp i w jaki sposób oraz jakie są zasady audytowania dostępu.
Deskryptory zabezpieczeń obiektu zawierają listy kontroli dostępu (access-contol list, ACL) opisujące wszystkie uprawnienia zabezpieczeń, które dotyczą tego obiektu. Co do zasady deskryptory mogą zawierać dwa rodzaje list ACL:
Arbitralna lista kontroli dostępu (discretionary access control list, DACL), które identyfikuje użytkowników i grupy, którym zezwala się lub odmawia dostępu;
Systemowa lista kontroli dostępu (system access control list, SACL), która kontroluje sposób audytowania dostępu.
Ten model kontroli dostępu może być stosowany do zabezpieczania jednostkowych obiektów takich jak pliki i foldery, obiektów Active Directory, kluczy rejestru, drukarek i innych urządzeń, portów, usług, procesów i wątków. Granularności ustawień pozwala elastycznie dostosować zabezpieczenia do wymagań organizacji, wydeloegować uprawnienia do obiektów oraz ich atrybutów.
Nie ma różny bez kolców, mechanizm ma ograniczenia pojemnościowe oraz nie jest specjalnie wygodny w utrzymaniu. Dzisiaj na tapetę weźmy ograniczenia rozmiaru.
The number of bytes of memory allocated for the ACL. The size of an ACL varies with the number and size of its ACEs. The maximum size of an ACL is 64K, or approximately 1,820 ACEs, depending on the size of the ACEs. However, for performance reasons, the maximum size is not practical, it will vary from 1820 to 2000.
Źródło: How Security Descriptors and Access Control Lists Work
The maximum size for an ACL, including its ACEs, is 64 KB (Reference: http://msdn2.microsoft.com/en-us/library/Aa374931.aspx )
It’s about the 64KB ACL size limit of Windows. It stands on every object supporting ACL
Źródło: Maximum number of ACEs in an ACL
Jeśli jest ograniczenie to trzeba się zastanowić nad dwiema rzeczami. Po pierwsze, czy da się przekroczyć opisany limit (a zatem czy jest on zablokowany i narzędzie zwróci błąd przy przekroczeniu rozmiaru) oraz co się dzieje, gdy zostanie przekraczony (jeśli narzędzie nie blokuje zmian powyżej limitu)? Po drugie czy i jak można monitorować wielkość list ACL?
Microsoft, a nie mógłbyś precyzyjnie określić liczbę wpisów w ACL? I ile to jest „w przybliżeniu 1820”? Nie da rady, bo poszczególne wpisy (access control entry, ACE) różnią się długością, w zależności od ustawień.
Zastanówmy się, więc jak precyzyjnie zmierzyć rozmiar listy, we właściwościach obietków zobaczymy zinterpretowaną listę (nazwy podmiotów (użytkownicy, grupy, komputery) i ich uprawnienia).
Jak zmierzyć rozmiar listy kontroli dostępu ACL?
Pomysł pierwszy, zrzućmy listę do pliku i sprawdźmy jego rozmiar. W tym celu zrzućmy ACL za pomocą programu icacls.
Przyznacie, że w przypadku plików i folderów sprawa jest nieskomplikowana i bez trudnu można by to zautomatyzować (jeśli zajdzie taka potrzeba).
A co właściwie zapisało się w pliku? Jak wygląda lista i w jakim formacie icacls zapisał dane do pliku?
Powyższy format zapisu to Security Descriptor Definition Language (SDDL). Mało czytelny, ale skondensowany. I o to chodzi, gdy ma się „tylko” 64k miejsca. Rzućmy jeszcze okiem na ACE strings (jeden z formatów za pomocą których wyświetlane są listy ACL w PowerShell).
During an install of SharePoint 2013 SP1 the following issues was encountered post installation where the configuration wizard would fail with the following error:
“The SDDL string contains an invalid sid or sid that cannot be translated”
To resolve this issue I attempted to run all SharePoint servers as the local service account. This attempt failed and did not change my outcome. The same…
Ed Wilson, “The Scripting Guy, continues on yesterdays post about WMI and PowerShell with today's post about Using PowerShell to Convert SDDL to Binary. SDDL, or Security Descriptor Definition Language, defines the string format to describe a security descriptor as a text string. The language also defines string elements for describing information in the components of a security descriptor.
When working with WMI and Windows PowerShell, it is common to think about using the Get-WmiObject cmdlet. Unfortunately, when using the Get-WmiObject cmdlet with the Win32_SecurityDescriptorHelper class, nothing happens. When I attempt to pipe the results to Get-Member, an error is produced. The two commands are shown here (gwmi is an alias for Get-WmiObject, and gm is an alias for Get-Member):
gwmi win32_SecurityDescriptorHelper #no output
gwmi win32_SecurityDescriptorHelper | gm #generates an error
Ed does a great job of discussing how he actually digs into the WMI object to get the information he wants out.
Perhaps the easiest way to work with the static WMI method is to use the [wmiclass] type accelerator. The SDDLToBinarySD method will translate a Security Descriptor Definition Language (SDDL) string into a binary byte array security descriptor (binary SD) format. The best way to talk about this technique is to walk through an example of converting an SDDL to a binary SD. First, I need to obtain an SDDL; I can do that by using the Get-Acl cmdlet. The first thing I do is give the Get-Acl the path to a file on my computer. I store the resulting object in the $acl variable. Next, I examine the SDDL associated with the file, by querying the SDDL property. These two lines of code are shown here:
$acl = Get-Acl C:\fso\BackupLog.txt
$acl.Sddl
...
One of the cool things that I can do with the static methods from the Win32_SecurityDescriptorHelper class is to convert a SDDL security descriptor into an instance of the Win32_SecurityDescriptor WMI class. The Win32_SecurityDescriptor WMI class is often used to provide security for various resources. For example, if I create a new share and I want to assign security to the new share, I will need to provide an instance of Win32_SecurityDescriptor. Using the SDDLToWin32SD method, I can use an SDDL to get the Win32_SecurityDescriptor I need. To illustrate using the SDDLToWin32SD method, I will use the Invoke-WmiMethod to perform the conversion. The following one-line command illustrates using the Invoke-WMIMethod cmdlet to call the SDDLToWin32SD method: Invoke-WmiMethod -Class Win32_SecurityDescriptorHelper -Name SDDLToWin32SD -ArgumentList $acl.Sddl
