LDAP and Active Directory

Lightweight Directory Access Protocol (LDAP) is an open, vendor-neutral, industry standard application protocol for accessing and managing distributed directory information services over an IP network. It’s often used for authentication and storing information about users, groups, and applications.

LDAP is a standards-based protocol that sits on top of TCP/IP and allows clients to perform various operations in a directory server. The standard TCP ports for LDAP are 389 for unencrypted communication and 636 for LDAP over a TLS-encrypted channel. That being said, it’s not uncommon for LDAP servers to listen on alternative ports.

A directory server is a type of network database that stores information represented as trees of entries (as opposed to a relational database which uses tables comprised of rows and columns).

Active Directory (AD)

AD uses an LDAP format for its underlying database. As mentioned above, LDAP is an industry standard employed by Microsoft which enables IT departments to use a directory tree structure when creating user accounts and user groups. AD provides the structure and it can also be used to join computers to the directory.

Forest, trees, domains

The Active Directory framework can be viewed at a number of different levels. The forest, the tree, and the domain are the logical divisions in an AD network. Within a deployment, objects are groups into domains. The objects for a single domain are stored in a single database. Domains are identified by their DNS name structure (the namespace).

A domain is a logical group of network objects that share the same AD database (workstations and computers, users, other devices).

A tree is a collection of one or more domains and domain trees in a contiguous namespace.

A forest is a collection of trees that share a common global catalog, directory schema, logical structure, and directory configuration. The forest is at the top of the structure and represents the security boundary within which users, computers, groups, and other objects are accessible.

Configuring AD

Create new user icon

Organizational Units (OU) are typically configured to provide at least some of the Group Policy rights and some of the security access lists for the Organizational Unit. Moving a user between OU’s will change the user rights assigned to that user.

Creating a new OU to click and drag Users into
In AD, it’s easy to move an entire OU by mistake, so AD generates confirmation messages whenever items are moved.

Configuring Permissions

Windows has the capability to set permissions on files and folders on a very granular level. Arranging users into security groups, it is possible to configure permissions at a group-level, avoiding the monstrous task of having to set permissions for each individual user.

By simply right clicking on a folder and selecting Properties, moving over to the Security tab, and clicking the Advanced button in the bottom right, we can manage special permissions for that directory.

Before you can set folder-specific permissions, you must disable the folder’s inheritance of permissions from its parent folder. There will be a Block Inheritance pop-up windows which has two choices: convert the permissions (which will retain the same permissions but makes them editable) or remove all inherited permissions (which will delete all existing permissions, including Admin accounts), leaving you with a blank slate.

Block Inheritance pop-up

By default, the Type is set to Allow, which will grant members of the principle group the permissions you assign. As an alternative, you can change the drop-down to Deny, which will exclude members of this principle group from the basic permissions for this folder and it’s files.

Select a principle link (a target group to manage permissions)

It is important to implement a granular access control structure that gives users the minimum permissions necessary to perform their jobs. Granular permissions can be set by clicking the “Show advanced permissions” link in the top right of the middle panel and configuring the permissions accordingly:

Applying granular permissions

Group Policy Management

Group Policy Objects enable a system admin to manage many users and computers at once by setting and enforcing security policies at the AD Forest, Domain, and OU level.

Example of examining and changing the current password policy in the GPO:

In PowerShell, if you execute the command:


You will see the current defaults for your password policy. Let’s suppose they are weak and need to be strengthened. If we wanted to change the password length to a minimum of 10 characters, enable password complexity, and set a minimum and maximum password age .

Site note: NIST now suggests we all remove the requirement of periodic password changes in 800-63b — mostly because we as humans are NOT good at creating novel passwords and will inevitably follow a pattern. For example, if our password is “BlueHouse1” — chances are, when it’s time to change our password, we’re going to use… “BlueHouse2“… and then once that expires, we may move onto “BlueHouse3“. It appears to be safer to simply have one, long passphrase that doesn’t change. The problem is, who is really going to change this policy after we’ve all spent so many years changing our password every month or so?

Back to the command prompt, we can execute the following commands:

Set-ADDefaultDomainPasswordPolicy-MinPasswordLength 10 -Identity [domainhere]

This will change the minimum password length to a default value of 10.

Set-ADDefaultDomainPasswordPolicy -Identity [domainhere] -ComplexityEnabled $true

This will enable the password complexity requirement.

Set-ADDefaultDomainPasswordPolicy -MinPasswordAge 10:10:10 -Identity [domainhere]

This will set the maximum password age to 10 hours, 10 minutes, and 10 seconds.

To link the GPO to an OU, you will need to specify the -Target parameter in the command, e.g.:

-Target "OU=finance"

I wanted to use this simple example to show the alternative to using GPO’s GUI to quickly change or update the Default Domain Policies through PowerShell. You can always check your work by looking in the Group Policy Management Editor.