Category Archives: Active Directory and Group Policy

Active Directory and Group Policy

How to rebuild the SYSVOL tree using DFSR

Active Directory has a number of different components to keep track of user and resource information in an organization….

If one piece starts to fail and a recovery effort falters, it could mean it’s time for a rebuilding process.

The system volume (SYSVOL) is a shared folder found on domain controllers in an Active Directory domain that distributes the logon and policy scripts to users on the domain. Creating the first domain controller also produces SYSVOL and its initial contents. As you build domain controllers, the SYSVOL structure is created, and the contents are replicated from another domain controller. If this replication fails, it could leave the organization in a vulnerable position until it is corrected.

How the SYSVOL directory is organized

SYSVOL contains the following items:

  • group policy data;
  • logon scripts;
  • staging folders used to synchronize data and files between domain controllers; and
  • file system junctions.
domain controller shares
Figure 1: Use the Get-SmbShare cmdlet to show the SYSVOL and NETLOGON shares on an Active Directory domain controller.

The Distributed File System Replication (DFSR) service replicates SYSVOL data on Windows 2008 and above when the domain functional level is Windows 2008 and above.

SYSVOL folder contents
Figure 2. The SYSVOL folder contains four folders: domain, staging, staging areas and sysvol.

The position of SYSVOL on disk is set when you promote a server to a domain controller. The default location is C:WindowsSYSVOLsysvol, as shown in Figure 1.

For this tutorial, we will use PowerShell Core v7 preview 3, because it fixes the .NET Core bug related to displaying certain properties, such as ProtectedFromAccidentalDeletion.

SYSVOL contains a number of folders, as shown in Figure 2.

How to protect SYSVOL before trouble strikes

As the administrator in charge of Active Directory, you need to consider how you’ll protect the data in SYSVOL to protect the system in case of corruption or user error.

Windows backs up SYSVOL as part of the system state, but you should not restore from system state, as it might not result in a proper restoration of SYSVOL. If you’re working with the relative identifier master flexible server master operations holder, you definitely don’t want to restore system state and risk having multiple objects with the same security identifier. You need a file-level backup of the SYSVOL area. Don’t forget you can use Windows Server backup to protect SYSVOL on a domain controller if you can’t use your regular backup approach.

If you can’t use a backup, then login scripts can be copied to a backup folder. Keep the backup folder on the same volume so the permissions aren’t altered. You can back up group policy objects (GPOs) with PowerShell:

Import-Module GroupPolicy -SkipEditionCheck

The SkipEditionCheck parameter is required, because the GroupPolicy module hasn’t had CompatiblePSEditions in the module manifest set to include Core.

Create a folder for the backups:

New-Item -ItemType Directory -Path C: -Name GPObackup

Use the date to create a subfolder name and create the subfolder for the current backup:

$date = (Get-Date -Format ‘yyyyMMdd’).ToString()

New-Item -ItemType Directory -Path C:GPObackup -Name $date

Run the backup:

Backup-GPO -All -Path (Join-Path -Path C:GPObackup -ChildPath $date)

If you still use login scripts, rather doing everything through GPOs, the system stores your scripts in the NETLOGON share in the C:WindowsSYSVOLdomainscripts folder.

Restore the SYSVOL folder

SYSVOL replication through DFSR usually works. However, as with any system, it’s possible for something to go wrong. There are two scenarios that should be covered:

  • Loss of SYSVOL information on a single domain controller. The risk is the change that removed the data from SYSVOL has replicated across the domain.
  • Loss of SYSVOL on all domain controllers, which requires a compete rebuild.

The second case involving a complete rebuild of SYSVOL is somewhat more complicated, with the first case being a subset of the second. The following steps explain how to recover from a complete loss of SYSVOL, with added explainers to perform an authoritative replication of a lost file.

Preparing for a SYSVOL restore

To prepare to rebuild the SYSVOL tree, stop the DFSR service on all domain controllers:

Stop-Service DFSR

On domain controllers where you can’t perform a restore, you’ll need to rebuild the SYSVOL tree folder structure and share structure.

On the domain controller with the SYSVOL you want to fix — or the one with the data you need to replicate — disable DFSR and make the server authoritative.

Get-ADObject -Identity “CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=TTSDC01,OU=Domain Controllers,DC=Sphinx,DC=org” -Properties * |

Set-ADObject -Replace @{‘msDFSR-Enabled’=$false; ‘msDFSR-options’=1}

Disable DFSR on the other domain controllers in the domain. The difference in the commands is you’re not setting the msDFSR-options property.

Get-ADObject -Identity “CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=TTSDC02,OU=Domain Controllers,DC=Sphinx,DC=org” -Properties * |

 Set-ADObject -Replace @{‘msDFSR-Enabled’=$false}

Rebuild the SYSVOL tree data

The next step is to restore the data. You can skip this if you’re just forcing replication of lost data.

On domain controllers where you can’t perform a restore, you’ll need to rebuild the SYSVOL tree folder structure and share structure. This tutorial assumes you’ve created SYSVOL in the default location with the following folder structure:

C:WindowsSYSVOL

C:WindowsSYSVOLdomain

C:WindowsSYSVOLdomainpolicies

C:WindowsSYSVOLdomainscripts

C:WindowsSYSVOLstaging

C:WindowsSYSVOLstagingdomain

C:WindowsSYSVOLstaging areas

C:WindowsSYSVOLsysvol

You can use the following PowerShell commands to re-create the folders in the minimum number of steps. Be sure to change the nondefault location of the Stest folder used below to match your requirements.

New-Item -Path C:StestSYSVOLdomainscripts -ItemType Directory

New-Item -Path C:StestSYSVOLdomainpolicies -ItemType Directory

New-Item -Path C:StestSYSVOLstagingdomain -ItemType Directory

New-Item -Path C:StestSYSVOL’staging areas’ -ItemType Directory

New-Item -Path C:StestSYSVOLsysvol -ItemType Directory

Re-create the directory junction points. Map SYSVOLdomain (source folder) to SYSVOLSYSVOL and SYSVOLstagingdomain (source folder) to SYSVOLstaging areas.

You need to run mklink as administrator from a command prompt, rather than PowerShell:

C:Windows>mklink /J C:stestSYSVOLSYSVOLsphinx.org C:stestSYSVOLdomain

Junction created for C:stestSYSVOLSYSVOLsphinx.org <<===>> C:stestSYSVOLdomain

C:Windows>mklink /J “C:stestSYSVOLstaging areassphinx.org” C:stestsysvolStagingdomain

Junction created for C:stestSYSVOLstaging areassphinx.org <<===>> C:stestsysvolStagingdomain

Set the following permissions on the SYSVOL folder:

NT AUTHORITYAuthenticated Users                           ReadAndExecute, Synchronize

NT AUTHORITYSYSTEM                                                        FullControl

BUILTINAdministrators           Modify, ChangePermissions, TakeOwnership, Synchronize

BUILTINServer Operators                                   ReadAndExecute, Synchronize

Inheritance should be blocked.

If you don’t have a backup of the GPOs, re-create the default GPOs with the DCGPOFIX utility, and then re-create your other GPOs.

You may need to re-create the SYSVOL share (See Figure 1). Set the share permissions to the following:

Everyone: Read

Authenticated Users: Full control

Administrators group: Full control

Set the share comment (description) to Logon server share.

Check that the NETLOGON share is available. It remained available during my testing process, but you may need to re-create it. 

Share permissions for NETLOGON are the following:

Everyone: Read

Administrators: Full control

You should be able to restart replication.

How to restart Active Directory replication

Start the DFSR service and reenable DFSR on the authoritative server:

Start-Service  -Name DFSR

Get-ADObject -Identity “CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=TTSDC01,OU=Domain Controllers,DC=Sphinx,DC=org” -Properties * | Set-ADObject -Replace @{‘msDFSR-Enabled’=$true}

Run the following command to initialize SYSVOL:

DFSRDIAG POLLAD

If you don’t have the DFS management tools installed, run this command from a Windows PowerShell 5.1 console:

Install-WindowsFeature RSAT-DFS-Mgmt-Con

The ServerManager module cannot load into PowerShell Core at this time.

Start DFSR service on other domain controllers:

Start-Service -Name DFSR

Enable DFSR on the nonauthoritative domain controllers. Check that replication has occurred.

Get-ADObject -Identity “CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=TTSDC02,OU=Domain Controllers,DC=Sphinx,DC=org” -Properties * | Set-ADObject -Replace @{‘msDFSR-Enabled’=$true}

Run DFSRDIAG on the nonauthoritative domain controllers:

DFSRDIAG POLLAD

The results might not be immediate, but replication should restart, and then SYSVOL should be available.

The process to rebuilding the SYSVOL tree is not something that occurs every day. With any luck, you won’t have to do it ever, but it’s a skill worth developing to ensure you can protect and recover your Active Directory domain.

Go to Original Article
Author:

Construct a solid Active Directory password policy

The information technology landscape offers many different methods to authenticate users, including digital certificates, one-time password tokens and biometrics.

However, there is no escaping the ubiquity of the password. The best Active Directory password policy for your organization should meet the threshold for high security and end-user satisfaction while minimizing the amount of maintenance effort.

Password needs adjust over time

Before the release of Windows Server 2008, Active Directory (AD) password policies were scoped exclusively at the domain level. The AD domain represented the fundamental security and administrative boundary within an AD forest.

The guidance at the time was to give all users within a domain the same security requirements. If a business needed more than one password policy, then your only choice was to break the forest into one or more child domains or separate domain trees.

Windows Server 2008 introduced fine-grained password policies, which allow administrators to assign different password settings objects to different AD groups. Your domain users would have one password policy while you would have different policies for domain administrators and your service accounts.

More security policies mean more administrative work

Deploying multiple password policies within a single AD domain allows you to check your compliance boxes and have additional flexibility, but there are trade-offs. First, increasing the complexity of your Active Directory password policy infrastructure results in greater administrative burden and increased troubleshooting effort.

Second, the more intricate the password policy, the unhappier your users will be. This speaks to the information security counterbalance between security strength on one side and user convenience on the other.

What makes a quality password? For the longest time, we had the following recommendations:

  • minimum length of 8 characters;
  • a mixture of uppercase and lowercase letters;
  • inclusion of at least one number;
  • inclusion of at least one non-alphanumeric character; and
  • no fragments of a username.

Ideally, the password should not correspond to any word in any dictionary to thwart dictionary-based brute force attacks. One way to develop a strong password is to create a passphrase and “salt” the passphrase with numbers and/or non-alphanumeric characters.

Ideally, the password should not correspond to any word in any dictionary to thwart dictionary-based, brute force attacks.

The key to remembering a passphrase is to make it as personal as possible. For example, take the following phrase: The hot dog vendor sold me 18 cold dogs.

That phrase may have some private meaning, which makes it nearly impossible to forget. Next, we take the first letter of each word and the numbers to obtain the following string: Thdvsm18cd.

If we switch the letter s with a dollar sign, then we’ve built a solid passphrase of Thdv$m18cd.

Striking the right balance

One piece of advice I nearly always offer to my consulting clients is to keep your infrastructure as simple as possible, but not too simple. What that means related to your Active Directory password policy is:

  • keep your domains to a minimum in your AD forest;
  • minimize your password policies while staying in compliance with your organizational/security requirements;
  • relax the password policy restrictions; and
  • encourage users to create a single passphrase that is both easy to remember but hard to guess.

Password guidelines adjust over time

Relax the password policy? Yes, that’s correct. In June 2017, the National Institute of Standards and Technology (NIST) released Special Publication 800-63B, which presented a more balanced approach between usability and security.

When you force your domain users to change their passwords regularly, they are likely to reuse some portion of their previous passwords, such as password, password1, password2, and so forth.

The new NIST guidance suggests that user passwords:

  • range between 8 and 64 characters in length;
  • have the ability to use non-alphanumerics, but do not make it a requirement;
  • prevent sequential or repeating characters;
  • prevent context-specific passwords such as user name and company name;
  • prevent commonly used passwords; and
  • prevent passwords from known public data breaches.

Boost password quality with help from tools

These are great suggestions, but they are difficult to implement with native Active Directory password policy tools. For this reason, many businesses purchase a third-party password management tool, such as Anixis Password Policy Enforcer, ManageEngine ADSelfService Plus, nFront Password Filter, Specops Password Policy, Thycotic Secret Server and Tools4ever Password Complexity Manager, to name a few.

Third-party password policy tools tap into the cloud to take advantage of public identity breach databases, lists of the most common passwords and other sources to make your domain password policy much more contemporary and organic. It’s worth considering the cost of these products when you consider the potential loss from a data breach that happened because of a weak password.

Go to Original Article
Author:

Enzoic for Active Directory brings continuous password protection

Enzoic has launched a new version of Enzoic for Active Directory that includes support for real-time password monitoring to fight against the use of compromised passwords.

Enzoic for Active Directory screens users’ passwords against its continuously updated database of compromised credentials, including billions of unique username and password combinations, according to the vendor.

Microsoft Azure Active Directory manages permissions and access to networked resources, making it a target for hackers to gain unauthorized access to user accounts, according to Enzoic. Verizon’s Data Breach Investigations Report found 29% of security breaches involved stolen credentials.

Enzoic for Active Directory 2.0 brings Continuous Password Protection that triggers an alert if a password becomes vulnerable, enabling Active Directory administrators to enforce password changes in response to real-time credential exposures, not just against a static list of exposed credentials or with periodic password resets.

Once a password is flagged as vulnerable, Enzoic notifies users and automates follow-up action, from prompting a user to change it to disabling the account according to an organization’s policies.

Enzoic for Active Directory 2.0 meets the National Institute of Standards and Technology 800-63B requirements with the following functions:

  • password screening against lists of commonly used passwords, passwords in cracking dictionaries and compromised passwords;
  • password checks upon password creation, as well as on a daily basis against a live database;
  • immediate response trigger when a compromised password is detected; and
  • elimination of periodic password resets due to continuous password monitoring.

According to a OneLogin study, only 35% of organizations’ password creation requirements check against common password lists, despite 92% of organizations claiming their current password guidelines are adequate. Furthermore, common passwords only represent a small portion of vulnerable passwords, with many password-related incidents stemming from cracking dictionaries used by hackers.

Many security vendors such as SolarWinds, Specops and nFront Security offer password complexity plugins for Active Directory, but do not offer around-the-clock monitoring. Enzoic claimed its continuous monitoring updates enhance overall enterprise security.

Go to Original Article
Author:

How does AD DS differ from Microsoft Azure Active Directory?

While Active Directory Domain Services and Microsoft Azure Active Directory appear similar, they are not interchangeable.

Administrators exploring whether to move to Azure Active Directory for enterprise authentication and authorization should understand how the cloud-based platform differs from the traditional on-premises Active Directory.

Distinguish on-premises AD from Azure AD

Active Directory (AD) is a combination of services to help manage users and systems, including Active Directory Domain Services (AD DS) and Active Directory Federation Services (AD FS). AD DS is the database that provides the directory service, which is essentially the foundation of AD.

AD uses an X.500-based hierarchical framework and traditional tools such as domain name systems to locate assets, lightweight directory access protocol (LDAP) to work with directories both on premises and on the internet, and Kerberos and NT LAN Manager (NTLM) for secure authentication. AD also supports the use of organizational units (OUs) and group policy objects (GPOs) to organize and present assets.

Microsoft Azure Active Directory is a directory service from Microsoft’s cloud that handles identity management across the internet using the HTTP and HTTPS protocols. Azure AD’s flat structure does not use OUs and GPOs, which prevents the use of the organizational structure of on-premises AD.

Instead of Kerberos, Azure AD uses authentication and security protocols such as Security Assertion Markup Language and Open Authorization. In addition, the AD Graph API queries Azure AD rather than LDAP.

Structural differences between Azure AD and AD DS

Microsoft Azure Active Directory cannot create domains, trees and forests like AD DS. Instead, Azure AD treats each organization like a tenant that accesses Azure AD via the Azure portal to manage the organization’s users, passwords and permissions.

Administrators can use AD DS and Microsoft Azure Active Directory separately or use both for a single AD entity.

Organizations that subscribe to a Microsoft cloud service, such as Office 365 or Exchange Online, are Azure AD tenants. Azure AD supports single sign-on to give users access to multiple services after logging in.

Microsoft Azure Active Directory is different from Azure Active Directory Domain Services. Where Azure AD provides fewer features than on-premises AD, Azure AD DS serves as a more full-featured domain controller that uses LDAP, domain joining, Kerberos and NTLM authentication. Azure AD DS is a complete version of AD in the Azure cloud.

When to consider a combination of AD DS and Azure AD

Administrators can use AD DS and Microsoft Azure Active Directory separately or use both for a single AD entity. For example, an application hosted in the cloud could use on-premises AD, but it might suffer from latency from authentication requests that bounce from Azure to the on-premises AD DS.

Organizations have several options to implement AD in Azure. For example, an organization can build an AD domain in Azure that integrates with the local AD domain via Azure AD Connect. This creates a trust relationship between the domains.

Alternatively, an organization can extend its on-premises AD DS to Azure by running AD DS as a domain controller in an Azure VM. This is a common method for enterprises that have local and Azure resources connected via a virtual private network or dedicated connectivity, such as an ExpressRoute connection.

There are several other ways to use a combination of the cloud and on-premises directory services. Admins can create a domain in Azure and join it to the local AD forest. A company can build a separate forest in Azure that is trusted by the on-premises AD forest. Admins can use AD FS to replicate a local AD DS deployment to Azure.

Understand Active Directory basics for enterprise success



Q

Get started
Bring yourself up to speed with our introductory content.

You can’t get the most out of a tool unless you understand its features. This tip explains the basics of Active Directory and how it controls access and maintains order.


Consistency and clarity are necessary when managing a company’s resources. Administrators need to know the Active…

“;
}
});

/**
* remove unnecessary class from ul
*/
$(“#inlineregform”).find( “ul” ).removeClass(“default-list”);

/**
* Replace “errorMessageInput” class with “sign-up-error-msg” class
*/
function renameErrorMsgClass() {
$(“.errorMessageInput”).each(function() {
if ($(this).hasClass(“hidden”)) {
$(this).removeClass(“errorMessageInput hidden”).addClass(“sign-up-error-msg hidden”);
} else {
$(this).removeClass(“errorMessageInput”).addClass(“sign-up-error-msg”);
}
});
}

/**
* when validation function is called, replace “errorMessageInput” with “sign-up-error-msg”
* before return
*/
function validateThis(v, form) {
var validateReturn = urValidation.validate(v, form);
renameErrorMsgClass();
return validateReturn;
}

/**
* DoC pop-up window js – included in moScripts.js which is not included in responsive page
*/
$(“#inlineRegistration”).on(“click”,”a.consentWindow”, function(e) {
window.open(this.href, “Consent”, “width=500,height=600,scrollbars=1”);
e.preventDefault();
});

Directory basics to see how the different services in this Microsoft tool work together for centralized management.

Active Directory is a combination of several services that run on Windows Server. Administrators new to IT should work to understand the Active Directory basics and how major enterprise applications, such as Exchange Server, depend on this directory service.

Active Directory Domain Services is the foundation

At the heart of Active Directory is Active Directory Domain Services (AD DS). When administrators discuss AD, they usually mean AD DS, which maintains a database of information for devices, resources, users and groups within the domain. AD DS defines user rights and verifies user credentials on the network.

AD DS defines user rights and verifies user credentials on the network.

AD DS runs on a server or server cluster called the domain controller. Each time a user logs in, accesses a network resource or runs an application, the AD domain controller authenticates the request. Corruption in the AD database or the failure of the domain controller server can devastate an enterprise, so administrators often set up AD DS on a server cluster for automatic replication and synchronization for resiliency and added performance.

Other services that rely on AD DS

Active Directory includes several other services that require AD DS as a foundation. For example, smaller organizations can use Active Directory Lightweight Directory Services, which functions almost identically to AD DS but does not need domains or separate domain controllers.

Active Directory Certificate Services creates, validates and revokes public key certificates used to encrypt files, emails, virtual private network traffic and Transport Layer Security/IPsec network traffic.

Active Directory Federation Services provides a single sign-on service to give users access to resources or services — typically outside of the enterprise — using one set of credentials.

Finally, Active Directory Rights Management Services controls encryption and access control for email, documents and web content.

Active Directory basics: Objects and OUs

The basic component in Active Directory is an object. Each object, such as resources — computers or printers — or individuals or groups, has an array of attributes based on an established schema. Admins cannot delete objects, only deactivate them.

IT can gather objects within a domain into organizational units (OUs) that make structural sense, such as by geographic location or business division, for resource management. Administrators can then apply group policies and administrative tasks at the OU level.

Active Directory also works across a series of levels. The domain is the lowest level and generally includes objects organized into a single database.

Trees are collections of one or more domains connected by a trust relationship. The forest is the highest level, which collects trees into a global structure and represents the ultimate boundary for accessibility in Active Directory. Objects are typically not accessible outside of the AD forest.

Dig Deeper on Microsoft identity and access management

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever’s puzzling you.

July Patch Tuesday brings three public disclosures

Microsoft announced three public disclosures from the 54 vulnerabilities released in the July Patch Tuesday.

An elevation of privilege public disclosure (CVE-2018-8313) affects all OSes except Windows 7. Attackers could impersonate processes, cross-process communication or interrupt system functionality to elevate their privilege levels. The patch addresses this issue by ensuring that the Windows kernel API enforces permissions.

“The fact that there is some level of detailed description of how to take advantage of this out in the open, it’s a good chance an attacker will look to develop some exploit code around this,” said Chris Goettl, director of product management and security at Ivanti, based in South Jordan, Utah.

A similar elevation-of-privilege vulnerability (CVE-2018-8314) this July Patch Tuesday affects all OSes except Windows Server 2016. Attackers could escape a sandbox to elevate their privileges when Windows fails a check. If this vulnerability were exploited in conjunction with another vulnerability, the attacker could run arbitrary code. The update fixes how Windows’ file picker handles paths.

A spoofing vulnerability in the Microsoft Edge browser (CVE-2018-8278) tricks users into thinking they are on a legitimate website. The attacker could then extract additional code to remotely exploit the system. The patch fixes how Microsoft Edge handles HTML content.

“That type of enticing of a user, we know works,” Goettl said. “It’s not a matter of will they get someone to do it or not; it’s a matter of statistically you only need to entice so many people before somebody will do it.”

Out-of-band updates continue

Chris Goettl of IvantiChris Goettl

Before July Patch Tuesday, Microsoft announced a new side-channel attack called Lazy FP State Restore (CVE-2018-3665) — similar to the Spectre and Meltdown vulnerabilities — on supported versions of Windows. An attacker uses a different side-channel to pull information from other registers on Intel CPUs through speculative execution.

Jimmy Graham of QualysJimmy Graham

Microsoft also updated its Spectre and Meltdown advisory (ADV180012). It does not contain any new releases on the original three variants, but the company did update the Speculative Store Bypass, Variant 4 of the Spectre and Meltdown vulnerabilities. This completed coverage for Intel processors, and Microsoft is still working with AMD to mitigate its processors.

Microsoft released out-of-band patches between June and July Patch Tuesday for a third-party Oracle Outside In vulnerability (ADV180010) that affects all Exchange servers.

“We don’t have a lot of info on the exploitability,” said Jimmy Graham, director of product management at Qualys, based in Foster City, Calif. “It should be treated as critical for Exchange servers.”

New Windows Server 2008 R2 servicing model on its way

Alongside its June Patch Tuesday, Microsoft announced plans to switch the updating system for Windows Server 2008 SP2 to a rollup model. The new monthly model will more closely match the servicing model used for older Windows versions, enabling administrators to simplify their servicing process. This will include a security-only quality update, a security monthly quality rollup and a preview of the monthly quality rollup.

“The 2008 Server users out there now need to adopt the same strategy, where they had the luxury of being able to do one or two updates if they chose to and not the rest,” Goettl said.

The new model will preview on Aug. 21, 2018. Administrators will still receive extended support for Windows Server 2008 SP2 until January 2020. After that, only companies that pay for Premium Assurance will have an additional six years of support.

For more information about the remaining security bulletins for July Patch Tuesday, visit Microsoft’s Security Update Guide.

What is Active Directory? – Definition from WhatIs.com

Active Directory (AD) is a Microsoft product that consists of several services that run on Windows Server to manage permissions and access to networked resources.

Active Directory stores data as objects. An object is a single element, such as a user, group, application or device, such as a printer. Objects are normally defined as either resources — such as printers or computers — or security principals — such as users or groups.

Active Directory categorizes objects by name and attributes. For example, the name of a user might include the name string, along with information associated with the user, such as passwords and Secure Shell (SSH) keys.

The main service in Active Directory is Domain Services (AD DS), which stores directory information and handles the interaction of the user with the domain. AD DS verifies access when a user signs into a device or attempts to connect to a server over a network. AD DS controls which users have access to each resource. For example, an administrator typically has a different level of access to data than an end user.

Other Microsoft products, such as Exchange Server and SharePoint Server, rely on AD DS to provide resource access. The server that hosts AD DS is the domain controller.

Active Directory services

Several other services comprise Active Directory. They are Lightweight Directory Services, Certificate Services, Federation Services and Rights Management Services. Each service expands the product’s directory management capabilities.

Lightweight Directory Services (AD LDS) has the same codebase as AD DS, sharing similar functionalities, such as the API. AD LDS, however, can run in multiple instances on one server and holds directory data in a data store using Lightweight Directory Access Protocol (LDAP).

[embedded content]

How to use the identity and access tool
from Microsoft

LDAP is an application protocol used to access and maintain directory services over a network. LDAP stores objects — such as usernames and passwords — in directory services — such as Active Directory — and shares that object data across the network.

Certificate Services (AD CS) generates, manages and shares certificates. A certificate uses encryption to enable a user to exchange information over the internet securely with a public key.

Active Directory Federation Services (AD FS) authenticates user access to multiple applications — even on different networks — using single sign-on (SSO). As the name indicates, SSO only requires the user to sign on once rather than use multiple dedicated authentication keys for each service.

Rights Management (AD RMS) controls information rights and management. AD RMS encrypts content, such as email or Word documents, on a server to limit access.

Major features in Active Directory Domain Services

Active Directory Domain Services uses a tiered layout consisting of domains, trees and forests to coordinate networked elements.

A domain is a group of objects, such as users or devices, that share the same AD database. Domains have a domain name system (DNS) structure.

Group Policy Management console
Active Directory’s Group Policy Management console gives admins a tool to customize user and computer settings in their organization.

A tree is one or more domains grouped together. The tree structure uses a contiguous namespace to gather the collection of domains in a logical hierarchy. Trees can be viewed as trust relationships where a secure connection, or trust, is shared between two domains. Multiple domains can be trusted where one domain can trust a second, and the second domain can trust a third. Because of the hierarchical nature of this setup, the first domain can implicitly trust the third domain without needing explicit trust.

A forest is a group of multiple trees. A forest consists of shared catalogs, directory schemas, application information and domain configurations. The schema defines an object’s class and attributes in a forest. In addition, global catalog servers provide a listing of all the objects in a forest.

Organizational Units (OUs) organize users, groups and devices. Each domain can contain its own OU. However, OUs cannot have separate namespaces, as each user or object in a domain must be unique. For example, a user account with the same username cannot be created.

History and development of Active Directory   

Microsoft offered a preview of Active Directory in 1999 and released it a year later with Windows 2000 Server. Microsoft continued to develop new features with each successive Windows Server release.

Windows Server 2003 included a notable update to add forests and the ability to edit and change the position of domains within forests. Domains on Windows Server 2000 could not support newer AD updates running in Server 2003.

Windows Server 2008 introduced AD FS. Additionally, Microsoft rebranded the directory for domain management as AD DS, and AD became an umbrella term for the directory-based services it supported.

Windows Server 2016 updated AD DS to improve AD security and migrate AD environments to cloud or hybrid cloud environments. Security updates included the addition of privileged access management (PAM).

PAM monitored access to an object, the type of access granted and what actions the user took. PAM added bastion AD forests to provide an additional secure and isolated forest environment. Windows Server 2016 ended support for devices on Windows Server 2003.

In December 2016, Microsoft released Azure AD Connect to join an on-premises Active Directory system with Azure Active Directory (Azure AD) to enable SSO for Microsoft’s cloud services, such as Office 365. Azure AD Connect works with systems running Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2 and Windows Server 2016.

Active Directory versus Workgroup

Workgroup is another Microsoft program that connects Windows machines over a peer-to-peer network. Workgroup allows these machines to share files, internet access, printers and other resources over the network. Peer-to-peer networking removes the need for a server for authentication.

Main competitors to Active Directory

Other directory services on the market that provide similar functionality to AD include Red Hat Directory Server, Apache Directory and OpenLDAP.

Red Hat Directory Server manages user access to multiple systems in Unix environments. Similar to AD, Red Hat Directory Server includes user ID and certificate-based authentication to restrict access to data in the directory.

Apache Directory is an open source project that runs on Java and operates on any LDAP server, including systems on Windows, macOS and Linux. Apache Directory includes a schema browser and an LDAP editor/browser. Apache Directory supports Eclipse plug-ins.

OpenLDAP is a Windows-based open source LDAP directory. OpenLDAP enables users to browse, search and edit objects in an LDAP server. OpenLDAP also features copying, moving and deleting of trees in the directory, as well as enabling schema browsing, password management, LDAP SSL support, and more.

Roll your own Windows patching tool with PowerShell

Manage
Learn to apply best practices and optimize your operations.

This tutorial based on PowerShell helps administrators build an automated routine that audits Windows machines, then applies missing patches to lighten this management task.



It’s a necessary but loathsome activity for just about every systems administrator: Windows patching.

“;
}
});

/**
* remove unnecessary class from ul
*/
$(“#inlineregform”).find( “ul” ).removeClass(“default-list”);

/**
* Replace “errorMessageInput” class with “sign-up-error-msg” class
*/
function renameErrorMsgClass() {
$(“.errorMessageInput”).each(function() {
if ($(this).hasClass(“hidden”)) {
$(this).removeClass(“errorMessageInput hidden”).addClass(“sign-up-error-msg hidden”);
} else {
$(this).removeClass(“errorMessageInput”).addClass(“sign-up-error-msg”);
}
});
}

/**
* when validation function is called, replace “errorMessageInput” with “sign-up-error-msg”
* before return
*/
function validateThis(v, form) {
var validateReturn = urValidation.validate(v, form);
renameErrorMsgClass();
return validateReturn;
}

/**
* DoC pop-up window js – included in moScripts.js which is not included in responsive page
*/
$(“#inlineRegistration”).on(“click”,”a.consentWindow”, function(e) {
window.open(this.href, “Consent”, “width=500,height=600,scrollbars=1”);
e.preventDefault();
});

Windows systems get patched via Microsoft Update. There are many Windows patching tools that help with this procedure.

Windows Server Update Services (WSUS) is free, but lacks some tooling for administrators who might want to fine-tune the process. System Center Configuration Manager enables administrators to build highly customized patching rollouts, but it requires some time to learn — and it can be a sizeable expense for some organizations. Regardless of your choice, each uses the built-in Windows Update Agent to connect to Microsoft to obtain new updates.

If a commercial Windows patching tool is too costly and the limitations of a free tool are too constraining, there is the option to create your own automated procedure. There are several advantages to this approach. The main perk is the flexibility to build a Windows patching system that matches the organization’s needs. But this method requires specific expertise and will take a significant amount of work to build.

To start construction of a Windows patching tool, it helps to think about the details behind the process before writing a single line of code; for example:

  • How do you target the systems that need patches?
  • What source do you use for the patches?
  • Which patches do you apply?
  • How do you deliver the patches and install them?

There are several ways to handle these tasks, but in this article, we will address those areas in this fashion:

  • Targeting: via Active Directory organizational unit (OU);
  • Patch source: Microsoft Update;
  • Patch type: all critical patches; and
  • Delivery: use PowerShell to remotely invoke the Windows Update Agent.

The administrator can configure all the options at the time of patching, except perhaps the patch source. The Windows Update Agent uses the registry — possibly through a group policy object — to determine if the updates will come from Microsoft Update or a local WSUS server. A Windows patching tool built on PowerShell will use the source set in the Windows Update agent.

To start, we will use a prebuilt PowerShell module I developed called WindowsUpdate. Download and install the module. To see a list of available commands, enter:

Get-Command -Module WindowsUpdate

Next, query a list of computers to update. For this article, we’ll use a single Active Directory OU, but the source can be anything from a database, CSV file or an Excel spreadsheet, for example. We’ll use the Active Directory module included with Microsoft’s Remote System Administration Tools package.

After installing that module, we can query AD computers with the Get-AdComputer cmdlet. To find all computers in a single OU, use the SearchScope and SearchBase parameters. With the command below, we can find computers in the Servers OU from the domain mylab.local and return their names:

$computerToPatch = Get-AdComputer -SearchScope Base -SearchBase ‘OU=Servers,DC=mylab,DC=local’ | Select-Object -ExpandProperty Name

Next, let’s target a machine. When I use a new tool, I usually retrieve the existing state of the machine first. I perform a Get operation as a test for the tool and assess the current patch state. The command below queries the first computer in our variable and finds all the available updates that are not installed. By default, it just checks for missing updates:

Get-WindowsUpdate -ComputerName $computersToPatch[0]

Once you’ve seen the output and you’re comfortable with the patches the tool will install, use the Install-WindowsUpdate command to force the Windows Update agent on the remote computer to download and install the missing updates.

Install-WindowsUpdate -ComputerName $computersToPatch[0] -ForceReboot

Notice we’ve chosen to force a reboot on the machine if needed. By default, Install-WindowsUpdate does not attempt to reboot the computer if an update requires it.

We can take things a step further and install updates on all the target computers. In PowerShell, we can use a ForEach loop to iterate through each computer name in the $computersToPatch array and run Install-WindowsUpdate against each one.

foreach ($computer in $computersToPatch) {

Install-WindowsUpdate -ComputerNBame $computer -ForceReboot
}

The loop goes through each computer in the Servers OU, checks each for missing patches, installs them and reboots the machine to complete the update process.

This basic demonstration shows what’s possible with a free PowerShell tool. Open up the code for these commands and give them a closer look to see where a few modifications might work better with your environment.

Dig Deeper on Windows Operating System Management



Monitor Active Directory replication via PowerShell

breaks down, administrators need to know quickly to prevent issues with the services and applications that Active Directory oversees.

It is important to monitor Active Directory replication to ensure the process remains healthy. Larger organizations that use Active Directory typically have several domain controllers that rely on replication to synchronize networked objects — users, security groups, contacts and other information — in the Active Directory database. Changes in the database can be made at any domain controller, which must then be duplicated to the other domain controllers in an Active Directory forest. If the changes are not synchronized to a particular domain controller — or all domain controllers — in an Active Directory site, users in that location might encounter problems.

For example, if an administrator applies a security policy setting via a Group Policy Object to all workstations, all domain controllers in a domain should pick up the GPO changes. If one domain controller in a particular location fails to receive this update, users in that area will not receive the security configuration.

Why does Active Directory replication break?

Active Directory replication can fail for several reasons. If network ports between the domain controllers are not open or if the connection object is missing from a domain controller, then the synchronization process generally stops working.

Since domain controllers rely on the domain name system, if their service records are missing, the domain controllers will not communicate with each other, which causes a replication failure.

Check Active Directory replication status manually

There are many ways to check the Active Directory replication status manually.

Administrators can run the following string using the command-line repadmin utility to show the replication errors in the Active Directory forest:
repadmin /replsum /bysrc /bydest /errorsonly

Administrators can also use the Get-ADReplicationPartnerMetadata PowerShell cmdlet to check the replication status, which is used in the script further in this article.

Use a script to check replication health

While larger organizations might have an enterprise tool, such as System Center Operations Manager, to monitor Active Directory, a PowerShell script can be a helpful supplement to alert administrators on the replication status. Because so much of a business relies on a properly functioning Active Directory system, it can’t hurt to implement this script and have it run every day via a scheduled task. If the script finds an error, it will send an alert via email.

The system must meet a few requirements before executing the script:

  • It runs on a computer that reaches all domain controllers.
  • It is recommended to use a computer that runs Windows Server 2012 R2 or a Windows 10 computer joined to a domain in the Active Directory forest.
  • The computer has the Active Directory PowerShell modules installed.

How does the script work?

The PowerShell script uses the Get-ADReplicationPartnerMetadata cmdlet, which connects to a primary domain controller emulator in the Active Directory forest and then collects the replication metadata for each domain controller.

The script checks the value of the LastReplicationResult attribute for each domain controller entry. If the value of LastReplicationResult is zero for any domain controller, the script considers this a replication failure. If this error is found, the script executes the Send-MailMessage cmdlet to send the email with a copy of the report file in a CSV file. The script stores the replication report in C:TempReplStatus.CSV.

The settings in the script should be modified to use the email address to send the message along with the subject line and message body.

PowerShell script to check replication status

The following PowerShell script helps admins monitor Active Directory for these replication errors and delivers the findings via email. Be sure to modify the email settings in the script.

$ResultFile = “C:TempReplStatus.CSV”

$ADForestName = “TechTarget.com”

$GetPDCNow =Get-ADForest $ADForestName | Select-Object -ExpandProperty RootDomain | Get-ADDomain | Select-Object -Property PDCEmulator

$GetPDCNowServer = $GetPDCNow.PDCEmulator

$FinalStatus=”Ok”

 

Get-ADReplicationPartnerMetadata -Target * -Partition * -EnumerationServer $GetPDCNowServer -Filter {(LastReplicationResult -ne “0”)} | Select-Object LastReplicationAttempt, LastReplicationResult, LastReplicationSuccess, Partition, Partner, Server | Export-CSV “$ResultFile” -NoType -Append -ErrorAction SilentlyContinue

 

$TotNow = GC $ResultFile

$TotCountNow = $TotNow.Count

IF ($TotCountNow -ge 2)

{

    $AnyOneOk = “Yes”

    $RCSV = Import-CSV $TestCSVFile

    ForEach ($AllItems in $RCSV)

    {

        IF ($AllItems.LastReplicationResult -eq “0”)

        {

            $FinalStatus=”Ok”

            $TestStatus=”Passed”

            $SumVal=””

            $TestText=”Active Directory replication is working.”

        }

        else

        {

            $AnyGap = “Yes”

            $SumVal = “”

            $TestStatus = “Critical”

            $TestText=”Replication errors occurred. Active Directory domain controllers are causing replication errors.”

            $FinalStatus=”NOTOK”           

            break

        }

    }

}

$TestText

 

IF ($FinalStatus -eq “NOTOK”)

{

    ## Since some replication errors were reported, start email procedure here…

 

### START – Modify Email parameters here

$message = @”                                

Active Directory Replication Status

 

Active Directory Forest: $ADForestName

                                  

Thank you,

PowerShell Script

“@

 

$SMTPPasswordNow = “PasswordHere”

$ThisUserName = “UserName”

$MyClearTextPassword = $SMTPPasswordNow

$SecurePassword = Convertto-SecureString –String $MyClearTextPassword –AsPlainText –force

$ToEmailNow =”EmailAddressHere”

$EmailSubject = “SubjectHere”

$SMTPUseSSLOrNot = “Yes”

$SMTPServerNow = “SMTPServerName”

$SMTPSenderNow = “SMTPSenderName”

$SMTPPortNow = “SMTPPortHere”

 

### END – Modify Email parameters here

 

$AttachmentFile = $ResultFile

 

$creds = new-object -typename System.Management.Automation.PSCredential -argumentlist “$ThisUserName”, $SecurePassword

Send-MailMessage -Credential $Creds -smtpServer $SMTPServerNow -from $SMTPSenderNow -Port $SMTPPortNow -to $ToEmailNow -subject $EmailSubject -attachment $AttachmentFile -UseSsl -body $message

}

When the script completes, it generates a file that details the replication errors.

Replication error report
The PowerShell script compiles the Active Directory replication errors in a CSV file and delivers those results via email.

Administrators can run this script automatically through the Task Scheduler. Since the script takes about 10 minutes to run, it might be best to set it to run at a time when it will have the least impact, such as midnight.