Quick Guide to Setup Dynamic Access Control

Dynamic Access Control enables the functionality to deploy file or object permissions based on claims instead of access control lists (acl). As claims, we use pre-defined properties from active directory user objects like department, Title or Manager information. Almost everything from Active Directory can be used. So configuring DAC works like this:

Let’s assume, you want to restrict access on all Folders with “TopSecret” Confidentiality for users in Department “Agents” of Company “Investigate&Co”.

(1) Define Claims.

Open AD Administrative Center and go to Dynamic Access Control, where you open Claim Types. Now add all Properties you wish to use for filtering and grouping all of your Employees.

Claims will be used to give permissions. For our example, we add Department and Company.

1

(2) Define Resource Properties.

Still in AD Administrative Center, select Resource Properties in the left navigation tree. There appears a list of available Properties that can be enabled for use. For our example, enable Confidentiality and right-click on it to edit the properties. At the bottom, there’s a dialog to add Suggested Values. Hit “add” and create a additional “Top Secret” Entry with Value “4000” (just greater than the highest).

2

(3) Configure a Recource Property List.

There’s already a default configured “Global Resource Property List” that contains the most of the default available values. Just ensure the “Confidentiality” Property is listed here.

3

(4) Create a Central Access Rule.

File System Permissions are no longer configured on the file server itself, the cool thins is they’re now configured central and maintained general. So we don’t define a access policy for Folder XY and make decisions about recursion like done in past. What we do now is to define what kind of data can be accessed by what type of user.

For our example, we create this rule: Objects classified as “Top Secret” can only be accessed by users that are members of Department “Agents” and work for Company “Investigate&Co”. This Rule looks like this:

4

(5) Create a Central Access Policy.

A policy is a collection of all or many Central Access Rules. You assign a policy to a file server. With this functionality, you can define multiple and/or different policies for different servers.

5

(6) Configure Kerberos and KDC to support claims and Kerberos armoring.

Edit the Default Domain Controller Policy to enable the following Kerberos and KDC setting.

6

…and for Kerberos too…

7

(the difference betweek this two pictures is the selection of KDC and Kerberos in the left tree)

(7) Assign the Policy to the Fileserver.

Create a GPO either on root and use security filtering or link it directly to a OU that only contains the file server(s). This OU gets the following settings.

8

Under Computer Configuration/Windows Settings/Security Settings/File System, there’s a “Central Access Policy” Setting where you can define the DAC Policy we just created.

(8) Setup Fileserver, Verify Permissions.

Your file server needs the “File Server” role and “File Server Resource Manager” (FSRM) being installed to have the classification tab enabled on folders. Using “gpudate /force”, we ensure the new policy gets downloaded.

To verify our example rule is running, I created a folder called “Obama” and set the Confidentiality manually to “Top Secret”.

9

This isn’t the way you will set the properties on your data (mind the huge effort to do this on big filers). In production, you create rules in FSRM to automatically classify data based on rules. But this is another story.

So after classifying my folder, let’s use old good known “Effective Access” Tab in the Advanced Security Settings of the Folder to verify access of my User “Agent007” who’s in Department “Agents” and works for Company “Investigate&Co” and for JuniorAgent123 who’s in Department “Junior Agents”.

Folder NTFS Security Settings:

10

Effective Permissions for Agent007:

11

Effective Permissions for JuniorAgent123:

12

Conclusion

NTFS permissions gives the basic permissions for the users on objects and the DAC is used to restrict access by classification rules on top of it.

(9) Using File Classification Infrastructure of FSRM

If you open FSRM under the “Classification Management” tree, you see our enabled “Confidentiality” Property for Objects in here als “Global” Scope Property.

13

The Classification Rules tree is empty by default, you can create Rules here to classify files and folders. For example, a rule could classify files by scanning their content for credit card numbers and assign them the classification “Financial Data”. To get some examples and templates, there’s a downloadable package from Microsoft:

14

http://www.microsoft.com/en-us/download/details.aspx?id=27123

This Solution Accelerator is designed to help enable an organization to identify, classify, and protect data on their file servers. The out-of-the-box classification and rule examples help organizations build and deploy their policies to protect critical information on the file servers in their environment.

Advertisements

AD 2008 Password Setting Objects

Nach einiger Internet Recherche habe ich herausgefunden wie man die neuen Password Policies im Active Directory ab Version 2008 einsetzt. Gar nicht so einfach…

Bereits vorhandene PSO anzeigen

Wenn bereits eine PSO erstellt wurde ist sie unter folgendem Pfad abgelegt. Dieser ist nur zu sehen wenn die Advanced Features im View Menü aktiviert sind.

CN=Password Settings Container,CN=System,DC=Domäne,DC=de

PSO über ADSI Edit anlegen

Der ADSI Editor ist unter Server 2008 bestandteil der Administrative Tools und kann direkt aus dem Startmenü aufgerufen werden. Dort navigiert man gleich zum Password Settings Container (Pfad siehe oben) und erstellt über Rechtsklick -> New -> Object ein neues “msDS-PasswordSettings Object. Daraufhin kann man folgende Fragen beantworten:

Attribute
Wert (Beispiel)
Beschreibung
cn
PSO für Chefs
msDS-PasswordSettingsPrecedence
10
muss >0 sein, das niedrigste hat Vorrang
msDS-PasswordReversibleEncryptionEnabled
FALSE
[boolean] FALSE ist dringend empfohlen
msDS-PasswordHistoryLength
3
[0-1024] in Tagen
msDS-PasswordComplexityEnabled
TRUE
[boolean]
msDS-MinimumPasswordLength
8
[0-255]
msDS-MinimumPasswordAge
00:01:00:00
[dd:hh:mm:ss]
msDS-MaximumPasswordAge
120:00:00:00
[dd:hh:mm:ss] muss >= sein als [minimum Age]
msDS-LockoutThreshold
12
[0-65535] Anzahl der Fehlversuche bis Sperre
msDS-LockoutObservationWindow
00:00:20:00
[dd:hh:mm:ss] Zeitspanne der Fehlversuche
msDS-LockoutDuration
00:00:20:00
[dd:hh:mm:ss] Zeitspanne bis Account freigabe

Erscheint beim erstellen eine Fehlermeldung kann dies zwei Gründe haben:

(1)  Falsche Angaben bei den Attributen
Die Verdächtigen sind dabei die Attribute, die eine Zeitangabe in Form von Tage:Stunden:Minuten:Sekunden enthalten. Z.B. darf der Wert im Attribut msDS-LockoutObservationWindow nicht größer sein (höchstens gleich) als der Wert im Attribut msDS-LockoutDuration.

(2) UAC
Möglicherweise muss ADSI Edit explizit als Administrator gestartet werden.

PSO über PowerShell Anlegen

Über PowerShell ist das Anlegen einer PSO natürlich viel einfacher, sofern man nicht schon an fehlenden Modulen scheitert: PowerShell Module und SnapIn’s
Mit dem New-ADFineGRainedPAsswordPolicy Befehl kann jede Option über Parameter mitgegeben werden. Schön dargestellt mit jedem Parameter auf einer Linie (verbunden mit dem `-Zeichen am Ende jeder Zeile) sieht das dann so aus:

New-ADFineGrainedPasswordPolicy `
-Name “PSO for Manager” `
-Precedence 10 `
-ReversibleEncryptionEnabled $false `
-PasswordHistoryCount 3 `
-ComplexityEnabled $true `
-MinPasswordLength 8 `
-MinPasswordAge “1:00” `
-MaxPasswordAge “120” `
-LockoutThreshold 12 `
-LockoutObservationWindow “0:20” `
-LockoutDuration “0:20”

Details zum Befehl: http://technet.microsoft.com/en-us/library/ee617238.aspx

PSO an Benutzergruppen knüpfen

Nun muss über die Eigenschaften nur noch definiert werden für welche Benutzergruppen die PSO gelten soll. Dazu trägt man bei msDS-PSOAppliesTo einfach eine Benutzergruppe ein:

Quellen
http://blog.dikmenoglu.de/…

Creating a RODC

This is a short quick step guide to create a RODC on Server 2008 R2.

Requirements:

  • Create an additional Security Group (i.e. “RODCx Admins”)

Step-to-Step Guide:

  • Go to Roles and add Active Directory Services as usual
  • Start “dcpromo” using the Run Command
  • “Use advanced mode installation”, what else? 🙂
  • Add the domain controller to an existing forest
  • On the “additional Domain Controller Options” Page choose “Read-only domain controller (RODC)
  • Enter the manually created Security Group to manage the RODC Server

There’s another possibility to create to RODC without having any connection to any “normal” DC using an previously created installation media.

Source:
http://technet.microsoft.com/en-us/library/cc754629%28WS.10%29.aspx