Category Archives: Active Directory and Group Policy

Active Directory and Group Policy

How to take advantage of Teams-Exchange integration

When Microsoft introduced Teams, there was already an appetite in the marketplace for a platform that supports real-time chat, collaboration, meetings and calling.

The Slack success story motivated Microsoft to release its own version of a team messaging app in 2017. The introduction of Microsoft Teams provided a new way to communicate and collaborate, leading to less use of some Exchange functions. Because Exchange and email continue to be important, Microsoft developed Teams-Exchange integration functionality to give organizations a way to customize how they work with each application.

Exchange is still the go-to tool to organize and manage meetings, send email and centralize all key contact information, such as phone numbers and addresses. For users who rely on Microsoft Teams for collaboration, there are several ways to pull data from Outlook or Exchange Online into the Microsoft Teams channels or vice versa. The following examples highlight some of the Teams-Exchange integration requests administrators might get from users.

Access key Exchange data from within Microsoft Teams

Users who spend most of their time within Teams will want a way to retrieve email and calendars. Teams users can add a new tab with any content they like.

For Outlook email, add a tab by clicking on the (+) symbol in Teams as shown in Figure 1.1.

Teams content tab
Figure 1.1: Click the + symbol in Microsoft Teams to set up a new tab.

From the icons list at the top, select the one labeled Website. Give it a name and add the URL https://outlook.office365.com/mail/inbox for Outlook on the web as show in Figure 1.2.

Teams tab setup
Figure 1.2: To complete the setup for a new tab showing Outlook in Microsoft teams, give the tab a name and add the URL for Outlook on the web.

Use the tabs to add shared calendars for Teams

One of the other areas that users have missed from Teams relates to group calendars. Without direct access to a team’s calendars, many workers must switch between Outlook and Teams to view these shared calendars. A workaround is to create a new tab as explained above, but in this case, set it up to display the group’s shared calendar. Microsoft has this on its 2020 roadmap, but the following instructions will work today.

First, click on the office group calendar from the Outlook web client as shown in Figure 2.1.

office group calendar URL
Figure 2.1: Select the office group calendar from the Outlook web client to get the URL for the calendar.

After clicking the calendar icon, copy the URL from the address bar in the browser as shown in Figure 2.2.

copy calendar link
Figure 2.2: Copy the calendar URL from the address bar in the browser.

Next, go to Teams and add a new tab to the Team channel, select the Website icon and then paste the URL stored from the earlier step to complete the new tab as show in Figure 2.3.

Teams tab calendar setup
Figure 2.3: Complete the tab setup for a shared calendar in Teams by giving the tab a name and adding the calendar URL.

Notify users within Teams of certain email

Another capability that users might find helpful is getting a notification within Microsoft Teams when they receive a specific email.

For this setup, the Exchange administrator will use the automation platform called Power Automate, formerly known as Microsoft Flow. Power Automate is a service included with Office 365 to connect apps on the Microsoft platform so administrators can build customized routines that run automatically when certain conditions are met.

To start, sign into Power Automate and create a new flow. Select the trigger for Outlook named When a new email arrives and add the action in Teams called Post a message as shown in Figure 3.1.

Power Automate flow created
Figure 3.1: Use Power Automate to set up an automated task that triggers when a new email arrives from a specific person and results in a notification posted in a Teams channel.

You will need to perform basic configurations such as email account, filters for what type of email to monitor for and where to post the message. By default, once a flow is created it is active.

Notify users within Teams of certain events

Another useful automation routine to set up is to forward reminders in Teams for specific events. Since Exchange is the platform that manages all calendars and events, you can use a Power Automate task similar to the previous tip that triggers with an email.

Use Power Automate to build a flow that monitors a calendar — the user calendar, shared resource calendars or shared calendars — for a certain event, then automatically post a message to Teams when the start time approaches as shown in Figure 4.1.

Power Automate flow
Figure 4.1: Build a flow in Power Automate to monitor a calendar and then send a notification to a channel in Teams.

There are many more integration opportunities between Microsoft Teams and Exchange Online. For example, administrators can investigate the bots feature in Teams for another way to connect and process commands related to Exchange email, calendars and tasks. Services such as the Virtual Assistant and Bot Framework can offer more advanced integration capabilities without the help of a software developer.

Go to Original Article
Author:

How to fortify your virtualized Active Directory design

Active Directory is much more than a simple server role. It has become the single sign-on source for most, if not all, of your data center applications and services. This access control covers workstation logins and extends to clouds and cloud services.

Since AD is such a key part of many organizations, it is critical that it is always available and has the resiliency and durability to match business needs. Microsoft had enough foresight to set up AD as a distributed platform that can continue to function — without much or, in some cases, no interruption in services — even if parts of the system went offline. This was helpful when AD nodes were still physical servers that were often spread across multiple racks or data centers to avoid downtime. So, the question now becomes, what’s the right way to virtualize Active Directory design?

Don’t defeat the native AD distributed abilities

Active Directory is a distributed platform, so virtualizing it will hinder the native distributed functionality of the software. AD nodes can be placed on different hosts and fail-over software will restart VMs if a host crashes, but what if your primary storage goes down? It’s one scenario you should not discount.

When you undertake the Active Directory design process for a virtualization platform, you must go beyond just a host failure and look at common infrastructure outages that can take out critical systems. One of the advantages of separate physical servers was the level of resiliency the arrangement provided. While we don’t want to abandon virtual servers, we must understand the limits and concerns associated with them and consider additional areas such as management clusters.

Management clusters are often slightly lower tier platforms — normally still virtualized — that only contain management servers, applications and infrastructure. This is where you would want to place a few AD nodes, so they are outside of the production environment they manage. The challenge with a virtualized management cluster is that it can’t be placed on the same physical storage location as production; this defeats the purpose of separation of duties. You can use more cost-effective storage platforms such as a virtual storage area network for shared storage or even local storage.

Remember, this is infrastructure and not core production, so IOPS should not be as much of an issue because the goal is resiliency, not performance. This means local drives and RAID groups should be able to provide the IOPS required.

How to keep AD running like clockwork

One of the issues with AD controllers in a virtualized environment is time drift.

All computers have clocks and proper timekeeping is critical to both the performance and security of the entire network. Most servers and workstations get their time from AD, which helps to keep everything in sync and avoids Kerberos security login errors.

These AD servers would usually get their time from a time source if they were physical or from the hosts if virtualized from them. The AD servers would then keep the time synchronized with the internal clock of the computer based on CPU cycles.

When you virtualize a server, it no longer has a set number of CPU cycles to base its time on. That means time can drift until it reaches out for an external time check to reset itself. But that time check can also be off since you might be unable to tell the passage of time until the next check, which compounds the issue. Time drift can become stuck in a nasty loop because the virtualization hosts often get their time from Active Directory.

Your environment needs an external time source that is not dependent on virtualization to keep things grounded. While internet time sources are tempting, having the infrastructure reach out for time checks might not be ideal. A core switch or other key piece of networking gear can offer a dependable time source that is unlikely to be affected by drift due to its hardware nature. You can then use this time source as the sync source for both the virtualization hosts and AD, so all systems are on the same time that comes from the same source.

Some people will insist on a single physical server in a virtualized data center for this reason. That’s an option, but one that is not usually needed. Virtualization isn’t something to avoid in Active Directory design, but it needs to be done with thought and planning to ensure the infrastructure can support the AD configuration. Management clusters are key to the separation of AD nodes and roles.

This does not mean that high availability (HA) rules for Hyper-V or VMware environments are not required. Both production and management environments should have HA rules to prevent AD servers from running on the same hosts.

Rules should be in place to ensure these servers restart first and have reserved resources for proper operations. Smart HA rules are easy to overlook as more AD controllers are added and the rules configuration is forgotten.

The goal is not to prevent outages from happening — that’s not possible. It is to have enough replicas and roles of AD in the right places so users won’t notice. You might scramble a little behind the scenes if a disruption happens, but that’s part of the job. The key is to keep customers moving along without them knowing about any of the issues happening in the background.

Go to Original Article
Author:

Using Azure AD conditional access for tighter security

As is standard with technologies in the cloud, the features in Azure Active Directory are on the move.

The Azure version of Active Directory differs from its on-premises version in many ways, including its exposure to the internet. There are ways to protect your environment and be safe, but that’s not the case by default. Here are two changes you should make to protect your Azure AD environment.

Block legacy authentication

Modern authentication is Microsoft’s term for a set of rules and requirements on how systems can communicate and authenticate with Azure AD. This requirement is put in place for several security benefits, but it’s also not enforced by default on an Azure AD tenant.

Legacy authentication is used for many types of attacks against Azure AD-based accounts. If you block legacy authentication, then you will block those attacks, but there’s a chance you’ll prevent users trying to perform legitimate tasks.

This is where Azure AD conditional access can help. Instead of a simple off switch for legacy authentication, you can create one or more policies — a set of rules — that dictate what is and isn’t allowed under certain scenarios.

You can start by creating an Azure AD conditional access policy that requires modern authentication or it blocks the sign-in attempt. Microsoft recently added a “report only” option to conditional access policies, which is highly recommended to use and leave on a few days after deployment. This will show you the users still using legacy authentication that you need to remediate before you enforce the policy for real. This helps to ensure you don’t stop users from doing their jobs.

However, this change will severely limit mobile phone email applications. The only ones officially supported with modern authentication are Outlook for iOS and Android, and Apple iOS Mail.

Implement multifactor authentication

This sounds like an obvious one, but there are many ways to do multifactor authentication (MFA). Your Microsoft licensing is one of the factors that dictates your choices. The good news is that options are available to all licensing tiers — including the free one — but the most flexible options come from Azure AD Premium P1 and P2.

With those paid plans, conditional access rules can be a lot nicer than just forcing MFA all the time. For example, you might not require MFA if the user accesses a Microsoft service from an IP address at your office or if the device is Azure AD-joined. You might prefer that both of those scenarios are requirements to avoid MFA while other situations, such as a user seeking access on a PC not owned by the company, will prompt for extra authentication.

MFA doesn’t have to just be SMS-based authentication. Microsoft’s Authenticator App might take a few more steps for someone to set up the first time they register, but it’s much easier to just accept a pop-up on your mobile device as a second factor of authorization, rather than waiting for an SMS, reading the six-digit number, then typing it into your PC.

Without MFA, you’re running a high risk of having an internet-exposed authentication system that attackers can easily try leaked credentials or use spray attacks until they hit a successful login with a username and password.

The other common attack is credential phishing. This can be particularly successful when the threat actor uses a compromised account to send out phishing emails to the person’s contacts or use fake forms to get the contact’s credentials, too. This would be mostly harmless if the victim’s account required MFA.

Accounts in Azure AD will lock out after 10 failed attempts without MFA, but only for a minute, then gradually increase the time after further failure attempts. This is a good way to slow down the attackers, and it’s also smart enough to only block the attacker and keep your user working away. But the attacker can just move onto the next account and come back to the previous account at a later time, eventually hitting a correct password.

Azure AD conditional access changes are coming

The above recommendations can be enabled by four conditional access baseline policies, which should be visible in all Azure AD tenants (still in preview), but it appears these are being removed in the future.

baseline protection policies
Microsoft plans to replace the baseline protection policies with security defaults

The policies will be replaced by a single option called Security Defaults, found under the Manage > Properties section of Azure AD. The baseline policies helped you be a bit more granular about what security you wanted and the enablement of each feature. To keep that flexibility, you’ll need Azure AD Premium once these baseline policies go.

Turning on Security Defaults in your Azure AD tenant will:

  • force administrators to use MFA;
  • force privileged actions, such as using Azure PowerShell, to use MFA;
  • force all users to register for MFA within 14 days; and
  • block legacy authentication for all users.

I suspect the uptake wasn’t enough, which is why Microsoft is moving to a single toggle option to enable these recommendations. I also hazard to guess that Microsoft will make this option on by default for new tenants in the future, but there’s no need for you to wait. If you don’t have these options on, you should be working on enabling them as soon as you can.

Go to Original Article
Author:

Using the Windows Admin Center Azure services feature

To drive adoption of its cloud platform, Microsoft is lowering the technical barrier to Azure through the Windows Admin Center management tool.

Microsoft increasingly blurs the lines between on-premises Windows Server operating systems and its cloud platform.

One way the company has done this is by exposing Azure services alongside Windows Server services in the Windows Admin Center. Organizations that might have been reluctant to go through a lengthy deployment process that required PowerShell expertise can use the Windows Admin Center Azure functionality to set up a hybrid arrangement with just a few clicks in some instances.

Azure Backup

One of the Azure services that Windows Server 2019 can use natively is Azure Backup. This cloud service backs up on-premises resources to Azure. This service offers 9,999 recovery points for each instance and is capable of triple redundant storage within a single Azure region by creating three replicas.

Azure Backup can also provide geo-redundant storage, which insulates protected resources against regional disasters.

You access Azure Backup through the Windows Admin Center, as shown in Figure 1. After you register Windows Server with Azure, setting up Azure Backup takes four steps.

Azure Backup setup
Figure 1: The Windows Admin Center walks you through the steps to set up Azure Backup.

Microsoft designed Azure Backup to replace on-premises backup products. Organizations may find that Azure Backup is less expensive than their existing backup system, but the opposite may also be true. The costs vary widely depending on the volume of data, the type of replication and the data retention policy.

Azure Active Directory

Microsoft positions the Windows Admin Center as a one of the primary management tools for Windows Server. Because sensitive resources are exposed within the Windows Admin Center console, Microsoft offers a way to add an extra layer of security through Azure Active Directory.

When you enable the requirement for Azure Active Directory security, you will be required to authenticate into both the local machine and into Azure Active Directory.

To use Azure Active Directory, you must register the Windows Server with Azure, then you can require Azure Active Directory authentication to be used by opening the Windows Admin Center and then clicking on the Settings icon, followed by the Access tab. Figure 2 shows a simple toggle switch to turn Azure Active Directory authentication on or off.

Azure Active Directory authentication
Figure 2: The toggle switch in the Windows Admin Center sets up Azure Active Directory authentication.

Azure Site Recovery

Azure Site Recovery replicates machines running on-premises to the Microsoft Azure cloud. If a disaster occurs, you can fail over mission-critical workloads to use the replica VMs in the cloud. Once on-premises functionality returns, you can fail back workloads to your data center. Using the Azure cloud as a recovery site is far more cost-effective than building your own recovery data center, or even using a co-location facility.

Like other Azure services, Azure Site Recovery is exposed through the Windows Admin Center. To use it, the server must be registered with Azure. Although Hyper-V is the preferred hosting platform for use with Azure Site Recovery, the service also supports the replication of VMware VMs. The service also replicates between Azure VMs.

To enable a VM for use with the Azure Site Recovery services, open the Windows Admin Center and click on the Virtual Machines tab. This portion of the console is divided into two separate tabs. A Summary tab details the host’s hardware resource consumption, while the Inventory tab lists the individual VMs on the host.

Click on the Inventory tab and then select the checkbox for the VM you want to replicate to the Azure cloud. You can select multiple VMs and there is also a checkbox above the Name column to select all the VMs on the list. After selecting one or more VMs, click on More, and then choose the Set Up VM Protection option from the drop-down list, shown in Figure 3.

VM protection
Figure 3: To set up replication to Azure with the Azure Site Recovery service, select one or more VMs and then choose the Set Up VM Protection option.

The console will open a window to set up the host with Azure Site Recovery. Select the Azure subscription to use, and to create or select a resource group and a recovery vault. You will also need to select a location, as shown in Figure 4.

Azure Site Recovery setup
Figure 4: After you select the VMs to protect in Azure Site Recovery, finalize the process by selecting a location in the Azure cloud.

Storage Migration Service

The Storage Migration Service migrates the contents of existing servers to new physical servers, VMs or to the Azure cloud. This can help organizations reduce costs through workload consolidation.

You access the Storage Migration Service by selecting the Storage Migration Service tab in the Windows Admin Center, which opens a dialog box outlining the storage migration process as shown in Figure 5. The migration involves getting an inventory of your servers, transferring the data from those servers to the new location, and then cutting over to the new server.

Storage Migration Services overview
Figure 5: Microsoft developed Storage Migration Services to ease migrations to new servers, VMs or Azure VMs through a three-step process.

As time goes on, it seems almost inevitable that Microsoft will update the Windows Admin Center to expose even more Azure services. Eventually, this console will likely provide access to all of the native Windows Server services and all services running in Azure.

Go to Original Article
Author:

Get back on the mend with Active Directory recovery methods

Active Directory is the bedrock of most Windows environments, so it’s best to be prepared if disaster strikes.

AD is an essential component in most organizations. You should monitor and maintain AD, such as clear out user and computer accounts you no longer need. With routine care, AD will run properly, but unforeseen issues can arise. There are a few common Active Directory recovery procedures you can follow using out-of-the-box technology.

Loss of a domain controller

Many administrators see losing a domain controller as a huge disaster, but the Active Directory recovery effort is relatively simple — unless your AD was not properly designed and configured. You should never rely on a single domain controller in your domain, and large sites should have multiple domain controllers. Correctly configured site links will keep authentication and authorization working even if the site loses its domain controller.

You have two possible approaches to resolve the loss of a domain controller. The first option is to try to recover the domain controller and bring it back into service. The second option is to replace the domain controller. I recommend adopting the second approach, which requires the following actions:

  • Transfer or seize any flexible single master operation roles to an active domain controller. If you seize the role, then you must ensure that the old role holder is never brought back into service.
  • Remove the old domain controller’s account from AD. This will also remove any metadata associated with the domain controller.
  • Build a new server, join to the domain, install AD Directory Services and promote to a domain controller.
  • Allow replication to repopulate the AD data.

How to protect AD data

Protecting data can go a long way to make an Active Directory recovery less of a problem. There are a number of ways to protect AD data. These techniques, by themselves, might not be sufficient. But, when you combine them, they provide a defense in depth that should enable you to overcome most, if not all, disasters.

First, enable accidental deletion protection on all of your organizational units (OUs), as well as user and computer accounts. This won’t stop administrators from removing an account, but they will get warned and might prevent an accident.

protect from accidental deletion option
Select the option to protect from accidental deletion when creating an organizational unit in AD Administrative Center.

Recover accounts from the AD recycle bin

Another way to avoid trouble is to enable the AD recycle bin. This is an optional feature used to restore a deleted object.

Enable-ADOptionalFeature -Identity 'Recycle Bin Feature' -Scope ForestOrConfigurationSet `-Target sphinx.org -Confirm:$false

After installing the feature, you may need to enable it through AD Administrative Center. Once added, you can’t uninstall the recycle bin.

Let’s run through a scenario where a user, whose properties are shown in the screenshot below, has been deleted.

Active Directory user account
An example of a typical user account in AD, including group membership

To check for deleted user accounts, run a search in the recycle bin:

Get-ADObject -Filter {objectclass -eq 'user' -and Deleted -eq $true} -IncludeDeletedObjects

The output for this command returns a deleted object, the user with the name Emily Brunel.

Active Directory recycle bin
An AD object found in the recycle bin

For a particularly volatile AD, you may need to apply further filters to identify the account you wish to restore.

If you have a significant number of objects in the recycle bin, use the object globally unique identifier (GUID) to identify the object to restore.

Get-ADObject -Filter {ObjectGUID -eq '73969b9d-05fa-4b45-a667-79baba1ac9a3'} 
`-IncludeDeletedObjects -Properties * | Restore-ADObject

The screenshot shows the restored object and its properties, including the group membership.

restored Active Directory user account
Restoring an AD user account from recycle bin

Generate AD snapshots

The AD recycle bin helps restore an object, but what do you do when you restore an account with incorrect settings?

To fix a user account in that situation, it helps to create AD snapshots to view previous settings and restore attributes. Use the following command from an elevated prompt:

ntdsutil snapshot 'Activate Instance NTDS' Create quit quit

The Ntdsutil command-line tool installs with AD and generates the output in this screenshot when creating the snapshot.

Active Directory snapshot
The command-line output when creating an AD snapshot

You don’t need to take snapshots on every domain controller. The number of snapshots will depend on the geographic spread of your organization and the arrangement of the administration team.

The initial snapshot captures the entire AD. Subsequent snapshots take incremental changes. The frequency of snapshots should be related to the amount of movement of the data in your AD.

Restore data from a snapshot

In this test scenario, let’s assume that the group memberships of a user account have been incorrectly changed. Run the following PowerShell commands to remove the user’s group memberships:

Remove-ADGroupMember -Identity finance -Members (Get-ADUser -Identity EmilyBrunel) -Confirm:$false
Remove-ADGroupMember -Identity department1 -Members (Get-ADUser -Identity EmilyBrunel) -Confirm:$false
Remove-ADGroupMember -Identity project1 -Members (Get-ADUser -Identity EmilyBrunel) -Confirm:$false

You need to identify the snapshot from which you will restore the data. The following command lists the snapshots:

ntdsutil snapshot 'List All' quit quit
Active Directory snapshots list
The Ntdsutil utility produces a list of the available AD snapshots.

To mount the snapshot, run the following command:

ntdsutil snapshot "mount f828eb4e-3a06-4bcb-8db6-2b07b54f9d5f" quit quit

Run the following command to open the snapshot:

dsamain -dbpath 'C:$SNAP_201909161530_VOLUMEC$WindowsNTDSntds.dit' -ldapport 51389

The Dsamain utility gets added to the system when you install AD Domain Services. Note that the console you use to mount and open the snapshot is locked.

Active Directory snapshot
Mount and open the AD snapshot.

When you view the group membership of the user account in your AD, it will be empty. The following command will not return any output:

Get-ADUser -Identity EmilyBrunel -Properties memberof | select -ExpandProperty memberof

When you view the same account from your snapshot, you can see the group memberships:

Get-ADUser -Identity EmilyBrunel -Properties memberof -Server TTSDC01.sphinx.org:51389  | select -ExpandProperty memberof
CN=Project1,OU=Groups,DC=Sphinx,DC=org
CN=Department1,OU=Groups,DC=Sphinx,DC=org
CN=Finance,OU=Groups,DC=Sphinx,DC=org

To restore the group memberships, run the following:

Get-ADUser -Identity EmilyBrunel -Properties memberof -Server TTSDC01.sphinx.org:51389  | select -ExpandProperty memberof | 
ForEach-Object {Add-ADGroupMember -Identity $_ -Members (Get-ADUser -Identity EmilyBrunel)}

After reinserting the group memberships from the snapshot version of the account, add the user into those groups in your production AD.

Your user account now has the correct group memberships:

Get-ADUser -Identity EmilyBrunel -Properties memberof | select -ExpandProperty memberof
CN=Project1,OU=Groups,DC=Sphinx,DC=org
CN=Department1,OU=Groups,DC=Sphinx,DC=org
CN=Finance,OU=Groups,DC=Sphinx,DC=org

Press Ctrl-C in the console in which you ran Dsamain, and then unmount the snapshot:

ntdsutil snapshot "unmount *" quit quit

Run an authoritative restore from a backup

In the last scenario, imagine you lost a whole OU’s worth of data, including the OU. You could do an Active Directory recovery using data from the recycle bin, but that would mean restoring the OU and any OUs it contained. You would then have to restore each individual user account. This could be a tedious and error-prone process if the data in the user accounts in the OU changes frequently. The solution is to perform an authoritative restore.

Before you can perform a restore, you need a backup. We’ll use Windows Server Backup because it is readily available. Run the following PowerShell command to install:

Install-WindowsFeature -Name Windows-Server-Backup

The following code will create a backup policy and run a system state backup:

Import-Module WindowsServerBackup
$wbp = New-WBPolicy

$volume = Get-WBVolume -VolumePath C:
Add-WBVolume -Policy $wbp -Volume $volume

Add-WBSystemState $wbp

$backupLocation = New-WBBackupTarget -VolumePath R:
Add-WBBackupTarget -Policy $wbp -Target $backupLocation

Set-WBVssBackupOptions -Policy $wbp -VssCopyBackup

Start-WBBackup -Policy $wbp

The following command creates a backup of the system state, including the AD database:

Add-WBSystemState $wbp

The following code creates a scheduled backup of the system state at 8 a.m., noon, 4 p.m. and 8 p.m.

Set-WBSchedule -Policy $wbp -Schedule 08:00, 12:00, 16:00, 20:00
Set-WBPolicy -Policy $wbp

In this example, let’s say an OU called Test with some critical user accounts got deleted.

Reboot the domain controller in which you’ve performed the backup, and go into Directory Services Recovery Mode. If your domain controller is a VM, you may need to use Msconfig to set the boot option rather than using the F8 key to get to the boot options menu.

$bkup = Get-WBBackupSet | select -Last 1
Start-WBSystemStateRecovery -BackupSet $bkup -AuthoritativeSysvolRecovery

Type Y, and press Enter to restore to original location.

At the prompt, restart the domain controller to boot back into recovery mode.

You need to mark the restored OU as authoritative by using Ntdsutil:

ntdsutil
C:Windowssystem32ntdsutil.exe: activate instance NTDS
Active instance set to "NTDS".
C:Windowssystem32ntdsutil.exe: authoritative restore
authoritative restore: restore subtree "ou=test,dc=sphinx,dc=org"

A series of messages will indicate the progress of the restoration, including the number of objects restored.

Exit ntdsutil
authoritative restore: quit
C:Windowssystem32ntdsutil.exe: quit

Restart the domain controller. Use Msconfig before the reboot to reset to a normal start.

The OU will be restored on your domain controller and will replicate to the other domain controllers in AD.

A complete loss of AD requires intervention

In the unlikely event of losing your entire AD forest, you’ll need to work through the AD forest recovery guide at this link. If you have a support agreement with Microsoft, then this would be the ideal time to use it.

Go to Original Article
Author:

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.