Active Directory Cheat Sheet

Enable advanced features to view all attributes and tabs

OU
-add child OU
-add individual user, computer, printer...

Users
-add user group
-set member of another group
-add member

Computers
-add computer group
-set member of another group
-add member

group scope:
1. domain local: You can assign these permissions only in the same domain where you create the domain local group. Members from any domain may be added to a domain local group.
2. global: A global group can be used to assign permissions for access to resources in any domain.
3. universal: Members from any domain may be added. Also, you can use a universal group to assign permissions for access to resources in any domain. Universal security groups are not available in mixed mode. 

group type :
1. security
2. distribution

# Delegation of Control:
-select users or groups
-select tasks to delegate:
  1. Create, delete, and manager user accounts
  2. Reset user passwords and force password change at next logon
  3. Read all user information
  4. Create. delete and manage groups
  ...
  0. Create a custom task to delegate
-indicate the scope of the task: 
  1. This folder, existing objects in this folder, and creation of new objects in this folder
  2. Only the following objects in this folder:
    a. account objects
    b. aCSResourceLimits objects
    c. bootableDevice objects
    d. Computer objects
- Select the permissions you want to delegate
  permissions:
  1. Full Control
  2. Read
  3. Write
  4. Create All Child Objects
  5. Delete All Child Objects
  6. Read All Properties
  7. Create User Objects
  8. Delete User Objects
  ...

# Group Policy Management
-Forest
--Domains
----Default Domain Policy
----Domain Controllers
------Default Domain Controllers Policy
----Other OU
-Sites

# Local Group Policy Editor
-Computer Configuration
----Software Settings
----Windows Settings
--------Security Settings
------------Account Policys
----------------Password Policy
------------Local Policies
----------------User Rights Assignment
----------------Security Options
------------Application Control Policies
----------------AppLocker
----Administrative Templates
-User Configuration
----Software Settings
----Windows Settings
--------Scripts(Logon/Logoff)
----Administrative Templates

# Group Policy Management Editor
-Computer Configuration
----Policy
--------Software Settings
--------Windows Settings
------------Security Settings
----------------Restricted Groups
--------Administrative Templates: Policy definitions
----Preference
-User Configuration
----Policy
----Preference

# add Domain Users to local Remote Desktop User Group
0. Create a security group called RemoteUsers and add the users to this group
1. In group Policy Management console, right click on the domain and select Create a GPO in this domain, and link it here. 
2. Provide the name of the GPO as Remote Desktop Users Policy and click OK.
3. Now right click the newly created GPO and click on Edit. The Group Policy Editor opens up.
4. Expand Computer Configuration > Policies > Windows Settings > Security Settings > Restricted Groups.
5. Again right click on the Restricted Groups and select Add Group. 
6. Type Remote Desktop Users in the pop up window, be sure not click on the Browse button as that will take you to the Local Remote Desktop Users group of that machine alone.
7. You will now need to add the RemoteUsers group in the Members of this group section.
8. open Command Prompt and type gpupdate /force on client machine or you could wait until the Group Policy refresh.
9. Using Computer Management to check the Remote Desktop Users group

# enable WinRM
Allow remote server management through WinRM
Right-click on the new Enable WinRM Group Policy Object and select Edit.
From the menu tree, click Computer Configuration > Policies > Administrative Templates: Policy definitions > Windows Components > Windows Remote Management (WinRM) > WinRM Service.
Right-click on Allow remote server management through WinRM and click Edit.
Select Enabled to allow remote server management through WinRM.
Enter an asterisk (*) into each field.
Click OK.

Now that Windows Remote Management has been enabled on the Group Policy, you need to enable the service that goes with it.
From the Group Policy Management Editor window, click Preferences > Control Panel Settings > Services.
Right-click on Services and select New > Service.
Select Automatic as the startup.
Enter WinRM as the service name.
Select Start service as the service action.
All remaining details can stay on the defaults. Click OK.

# Computer Management
----System Tools
--------Task Scheduler
--------Event Viewer
--------Shared Folder
--------Local Users and Groups
--------Performance
--------Device Manager
----Storage
--------Disk Management
----Services and Applications
--------Services
--------WMI Control

AGDLP - account, global, domain local, permission

A user belongs to multiple groups may has accumulated permission.
Deny permission has higher privilege than allow permission.
The effective permission can be checked in Advanced Security Setting

# Domain Trusts - Trusts help provide for controlled access to shared resources in a resource domain (the trusting domain) by verifying that incoming authentication requests come from a trusted authority 
One-Way and Two-Way Trusts
Transitive and Nontransitive Trusts

Trust Architecture
Trusts depend on the NTLM and Kerberos authentication protocols and on Windows-based authorization and access control mechanisms to help provide a secured communications infrastructure across Active Directory domains and forests.
- NTLM Protocol (Msv1_0.dll)
- Kerberos Protocol (Kerberos.dll)
- Net Logon (Netlogon.dll)
- LSA (Lsasrv.dll)

Trusted Domain Object
- TDO Contents
- TDO Passwords

Trust Types
- Automatic Trusts
-- Parent-child trust
-- Tree-root trust
- Manual Trusts
-- Shortcut Trusts
-- External Trusts
-- Realm Trusts
-- Forest Trusts

Parent/Child – part of the same forest – a child domain retains an implicit two-way transitive trust with its parent. This is probably the most common type of trust that you’ll encounter.
Cross-link – aka a “shortcut trust” between child domains to improve referral times. Normally referrals in a complex forest have to filter up to the forest root and then back down to the target domain, so for a geographically spread out scenario, cross-links can make sense to cut down on authentication times.
External – an implicitly non-transitive trust created between disparate domains. “External trusts provide access to resources in a domain outside of the forest that is not already joined by a forest trust.” External trusts enforce SID filtering, a security protection covered later in this post.
Tree-root – an implicit two-way transitive trust between the forest root domain and the new tree root you’re adding. I haven’t encountered tree-root trusts too often, but from the Microsoft documentation, they’re created when you when you create a new domain tree in a forest. These are intra-forest trusts, and they preserve two-way transitivity while allowing the tree to have a separate domain name (instead of child.parent.com).
Forest – a transitive trust between one forest root domain and another forest root domain. Forest trusts also enforce SID filtering.
MIT – a trust with a non-Windows RFC4120-compliant Kerberos domain. I hope to dive more into MIT trusts in the future.

Trust Processes and Interactions
- Kerberos V5 Referral Processing
- NTLM Referral Processing
- Other Authentication Protocol Referral Processing

# SID filtering
TGT contains a privileged attribute certificate (PAC) that contains, among other things, the user’s security identifier (SID).
This security identification information in the PAC is parsed and analyzed by a trusting domain, and various filters are executed depending on the type of the trust.
SIDs matching particular patterns are rejected by the trusting domain under various circumstances, as a security protection.
SID filtering is meant to stop malicious users with elevated credentials in a trusted domain/forest from taking control of a trusting domain/forest.
There is a set of SIDs that are set to ‘AlwaysFilter’, meaning they are always filtered out by a trusting domain, no matter the trust type.
The ForestSpecific rule is for those SIDs that are never allowed in a PAC that originates from out of the forest or from a domain that has been marked as QuarantinedWithinForest, unless it belongs to that domain.
The only SIDs that are allowed to be passed from such a domain are the “Enterprise Domain Controllers” (S-1-5-9) SID and those described by the trusted domain object (TDO).

# Domain Trust creation - via DNS
Open DNS Manager
Configure a DNS zone in Forward Lookup Zones for both Domains
Configure a DNS zone in Reverse Lookup Zones for both Domains(set Network range for reverse lookup zone and PTR record)
Configure the Conditional Forwarders for both Domains

Open Active Directory Domains and Trusts
Add a new trust
Trust Type: External trust
Direction of Trust: Two-way
Sides of Trust: Both this domain and specified domain
Type domain administrator's username and password
Outgoing trust authentication level-local forest: Forest-wide authentication
Outgoing trust authentication level-specified forest: Forest-wide authentication

# Restrict User Logon
1. Allow one user logs on to one computer or some computers:
Active Directory Users and Computers -> User Property -> Account -> Log On To -> Logon Workstations -> Enter Computer Name

2. Allow some users to log on some computers locally:
Create an OU, put the computers into it.
Create a GPO, link it to this OU and edit the GPO as below:
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment->Allow log on locally(Add users and groups)
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Option\Do not require CTRL+ALT+DEL->Disabled

# Set Unconstrained Delegation - https://blog.stealthbits.com/unconstrained-delegation-permissions/
Delegation is a security-sensitive operation, which allows service to act on behalf of another user.
This feature can be configured through the Delegation tab on a user or computer account. 
By selecting “Trust this computer for delegation to any service (Kerberos only),” you are enabling “unconstrained delegation”. 
Alternatively, you can specify a set number of Service Principal Names (SPNs) to restrict exactly what services a user or computer can impersonate, which would be considered “constrained delegation”.