• Users can no longer access the management of a Distribution Group in Outlook
• Synchronized Distribution Groups in Office 365 cannot be modified in Office 365 – as a synchronized object you must update in Active Directory
• Adding external contacts to a synchronized Distribution Group becomes difficult as you cannot synchronize contacts with Azure AD Connect

The solution is relatively simple – convert all Distribution Groups to Cloud objects.

This script was designed to do exactly that.

<#

#########################################################################################

##

## Name:        DG_Cloud.PS1

##

## Version:     1.0

##

## Description: $ Installs required components for Exchange Online Powershell Management

##              $ Creates a “Working” folder for Sea to Sky (C:\STS) for backups.

##              $ Creates an “Exports” folder for the temp files needed to migrate the

##              Distribution Lists.

##              $ Backs up the Distribution List Names and Attributes to DG_Details_Backup.csv

##              $ Backs up the Distribution List Members to DG_Members_Backup.csv

##              $ Capable of running mulitple times and retaining existing backups – creates

##              new backups each time it’s run if any new groups are detected

##              $ Selectively Creates a copy of each Distribution Group called Cloud_$Group

##              that are specifically Distribution Groups and not Mail-Enabled Security

##              groups.

##              $ Deletes the selected Distribtuion Groups from Active Directory

##              $ Initiates an Azure AD Connect to remove the AD objects from Cloud Environment

##              $ Forces wait period of 5 minutes to allow Azure AD to synchronize with Exchange

##              $ Completes process by renaming Cloud_$Group back to original name

##

## Usage:       Execute script in PowerShell with elevated privileges

##

## Author: Jason Zondag

##

## Disclaimer:  Has not been tried in every conceivable environment – always check the results

##              and fall back on the backups created to recreate the Distribution Groups if

##              necessary

##

#########################################################################################

###### ALTERNATIVE CODE FOR MFA LOGIN TO OFFICE 365  ####################################

#Connect & Login to ExchangeOnline (MFA)

$getsessions = Get-PSSession | Select-Object -Property State, Name

$isconnected = (@($getsessions) -like ‘@{State=Opened; Name=ExchangeOnlineInternalSession*’).Count -gt 0

If ($isconnected -ne “True”) {

Connect-ExchangeOnline

}

#########################################################################################

#>

clear

Write-Host “———————————————————————————————-” -ForegroundColor Cyan

Write-Host “!!!!!IMPORTANT!!!!!!” -ForeGroundColor Red

Write-Host “———————————————————————————————-” -ForegroundColor Cyan

Write-Host “!!!!!IMPORTANT!!!!!!” -ForeGroundColor Red

Write-Host “YOU MUST RUN THIS SCRIPT FROM THE DOMAIN CONTROLLER THAT IS RUNNING AZURE AD CONNECT” -ForeGroundColor Red

sleep 5

Write-Host “IF YOU ARE NOT PLEASE USE CTRL + C TO ESCAPE AND RUN FROM THE APPROPRIATE DOMAIN CONTROLLER” -ForeGroundColor Red

Write-Host “———————————————————————————————-” -ForegroundColor Cyan

Write-Host “It’s also important to note that this only affects Distribution Lists and not Mail-Enabled” -ForeGroundColor Green

Write-Host “Security Groups.  Mail-Enabled Security Groups must be handled differently.” -ForeGroundColor Green

Write-Host “———————————————————————————————-” -ForegroundColor Cyan

sleep 15

Pause

Write-Host “Connecting to Exchange Online – installing all required PowerShell Modules and initiaing a connection” -ForegroundColor Green

# ————————————————————————–

# Load PowerShell Modules

# ————————————————————————–

Set-ExecutionPolicy RemoteSigned -Force

Import-Module ActiveDirectory

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

Install-Module -Name ExchangeOnlineManagement -Force

Import-Module ExchangeOnlineManagement

#Connect & Login to ExchangeOnline (MFA)

$getsession = get-pssession | select-object -Property State | select -expandproperty state

If ($getsession -ne “Opened”) {

Connect-ExchangeOnline

}

Write-Host “Completed” -ForegroundColor Green

Write-Host “———————————————————————————————-” -ForegroundColor Cyan

Write-Host

Write-host

Write-Host “______________________________________________________________________________________________” -ForegroundColor Cyan

Write-Host “Synchronized Distribution Groups with no ManagedBy settings will be defaulted to Organization” -ForeGroundColor Yellow

Write-Host “Management. This value cannot be translated.” -ForeGroundColor Yellow

Write-host

Write-Host “You must set a default account value to replace Organization Management.” -ForeGroundColor Green

Write-Host “The default account must be a valid licensed address for this tenant.  IE. seatosky@domain.com ” -ForeGroundColor Green

$ManagedByDefault = Read-host “Enter the email address of a valid licensed account for this tenant:”

Write-Host “______________________________________________________________________________________________” -ForegroundColor Cyan

# Disable Azure AD Connect from initiating a sync while this process is underway

Set-ADSyncScheduler -SyncCycleEnabled $false

Write-host “Azure AD Connect Schedule Sync has been disabled temporarily.”

# ————————————————————————–

# Create Working and Export folders

# ————————————————————————–

Write-Host “Creating a Working Directory C:\DG-Migrate and an Exports Directory within the Working Directory” -ForegroundColor Green

# Create a working directory

$orginfo = Get-OrganizationConfig | select -expandproperty Name

$WorkingDirectory = “C:\DG-Migrate\” + $orginfo + “\”

$ExportDirectory = $WorkingDirectory + “ExportedAddresses\”

If(!(Test-Path -Path $WorkingDirectory )){

# if WorkingDirectory doesn’t exist neither does ExportDirectory – create them both

            Write-Host ”  Creating Directory: $WorkingDirectory”

            New-Item -ItemType directory -Path $WorkingDirectory | Out-Null

            Write-Host ”  Creating Directory: $ExportDirectory”

            New-Item -ItemType directory -Path $ExportDirectory | Out-Null

        } else {

# WorkingDirectory may exist but that doesn’t mean ExportDirectory does – create if it doesn’t exist

If(!(Test-Path -Path $ExportDirectory )){

            Write-Host ”  Creating Directory: $ExportDirectory”

            New-Item -ItemType directory -Path $ExportDirectory | Out-Null

}

}

Write-Host “Completed” -ForegroundColor Green

Write-Host “———————————————————————————————-” -ForegroundColor Cyan

Write-Host “Creating a backup of all AD Synchronized Distribution Lists and placing into the Working Directory” -ForegroundColor Green

# ————————————————————————–

# Export all the Distribution Group Information to a separate file

# ————————————————————————–

$check = (get-distributiongroup | Where {($_.IsDirSynced -eq $true) -AND ($_.RecipientType -eq “MailUniversalDistributionGroup”)})

if ((($check | Measure-Object).count) -ne 0) {

# Not 0 so we found some Distribution Groups to migrate

# We don’t want to overwrite an existing backup set – rename any existing files with a time stamp

    if (Test-Path ($WorkingDirectory + “DG_Details_Backup.csv”)) {

        $filename = ($WorkingDirectory + “DG_Details_Backup.csv”)

        $fileObj = get-item $filename

        $DateStamp = get-date -uformat “%Y-%m-%d@%H-%M-%S”

        $extOnly = $fileObj.extension

        if ($extOnly.length -eq 0) {

            $nameOnly = $fileObj.Name

            rename-item “$fileObj” “$nameOnly-$DateStamp”

            }

        else {

            $nameOnly = $fileObj.Name.Replace( $fileObj.Extension,”)

            rename-item “$fileName” “$nameOnly-$DateStamp$extOnly”

        }       }

$check | select `

    GroupType, `

    SamAccountName, `

    IsDirSynced, `

    @{label=”ManagedBy”;expression={

        ($_.managedby `

        | % { get-mailbox -identity $_ | select-object -ExpandProperty PrimarySMTPAddress } `

        | Where-Object {$_ -like “*@*”}) -join ‘;’}

        }, `

    MemberJoinRestriction, `

    MemberDepartRestriction, `

    ReportToOriginatorEnabled, `

    Description, `

    AddressListMembership, `

    Alias, `

    DisplayName, `

    PrimarySMTPAddress, `

    @{label=”EmailAddressess”;expression={

        ($_.EmailAddresses | Where-Object {$_ -like “*smtp:*” }) -join ‘;’}

        },`

    ExternalDirectoryObjectId, `

    HiddenFromAddressListsEnabled, `

    LegacyExchangeDN, `

    MaxSendSize, `

    MaxReceiveSize, `

    ModeratedBy, `

    ModerationEnabled, `

    PoliciesIncluded, `

    PoliciesExcluded, `

    EmailAddressPolicyEnabled, `

    RecipientType, `

    RecipientTypeDetials, `

    RequireSenderAuthenticationEnabled, `

    WindowsEmailAddress, `

    Identity, `

    Id, `

    Name, `

    DistinguishedName, `

    ExchangeObjectId, `

    Guid `

| Export-CSV ($WorkingDirectory + “DG_Details_Backup.csv”) -NoTypeInformation

sleep 20

    }

else {

    Write-Host “There are no appropriate Distribution Lists to migrate.  Cancelling migration.”

    Break

}

Write-Host “Completed” -ForegroundColor Green

Write-Host “———————————————————————————————-” -ForegroundColor Cyan

Write-Host “Creating a backup of Distribution List Membership and placing in the Working Directory” -ForegroundColor Green

# ————————————————————————–

# Export all the Distribution Group Members to a separate file

# ————————————————————————–

$output = @()

$Identities = import-csv ($WorkingDirectory + “DG_Details_Backup.csv”) | select Name,PrimarySmtpAddress,Managedby,GroupType,RecipientType

If ($Identities) {

Foreach($group in $Identities) {

    $Members = Get-DistributionGroupMember $group.PrimarySmtpAddress -resultsize unlimited

    if (@($Members.count) -eq 0) {

        #$managers = ($group | Select @{Name=’DistributionGroupManagers’;Expression={[string]::join(“;”, ($_.Managedby))}})

        $userObj = New-Object PSObject

        $userObj | Add-Member NoteProperty -Name “DisplayName” -Value EmptyGroup

        $userObj | Add-Member NoteProperty -Name “Alias” -Value EmptyGroup

        $userObj | Add-Member NoteProperty -Name “RecipientType” -Value EmptyGroup

        $userObj | Add-Member NoteProperty -Name “Recipient OU” -Value EmptyGroup

        $userObj | Add-Member NoteProperty -Name “Primary SMTP address” -Value EmptyGroup

        $userObj | Add-Member NoteProperty -Name “Distribution Group” -Value $group.Name

        $userObj | Add-Member NoteProperty -Name “Distribution Group Primary SMTP address” -Value $group.PrimarySmtpAddress

        $userObj | Add-Member NoteProperty -Name “Distribution Group Managers” -Value $managers.DistributionGroupManagers

        $userObj | Add-Member NoteProperty -Name “Distribution Group Type” -Value $group.GroupType

        $userObj | Add-Member NoteProperty -Name “Distribution Group Recipient Type” -Value $group.RecipientType

        $output+=$UserObj

        }

    else {

    Foreach($Member in $members) {

        #$managers = $group | Select @{Name=’DistributionGroupManagers’;Expression={[string]::join(“;”, ($_.Managedby))}}

        $userObj = New-Object PSObject

        $userObj | Add-Member NoteProperty -Name “DisplayName” -Value $Member.Name

        $userObj | Add-Member NoteProperty -Name “Alias” -Value $Member.Alias

        $userObj | Add-Member NoteProperty -Name “RecipientType” -Value $Member.RecipientType

        $userObj | Add-Member NoteProperty -Name “Recipient OU” -Value $Member.OrganizationalUnit

        $userObj | Add-Member NoteProperty -Name “Primary SMTP address” -Value $Member.PrimarySmtpAddress

        $userObj | Add-Member NoteProperty -Name “Distribution Group” -Value $group.Name

        $userObj | Add-Member NoteProperty -Name “Distribution Group Primary SMTP address” -Value $group.PrimarySmtpAddress

        $userObj | Add-Member NoteProperty -Name “Distribution Group Managers” -Value $managers.DistributionGroupManagers

        $userObj | Add-Member NoteProperty -Name “Distribution Group Type” -Value $group.GroupType

        $userObj | Add-Member NoteProperty -Name “Distribution Group Recipient Type” -Value $group.RecipientType

        $output+=$UserObj

        }

    }

   }

   # We don’t want to overwrite an existing backup set – rename any existing files with a time stamp

    if (Test-Path ($WorkingDirectory + “DG_Members_Backup.csv”)) {

        $filename = ($WorkingDirectory + “DG_Members_Backup.csv”)

        $fileObj = get-item $filename

        $DateStamp = get-date -uformat “%Y-%m-%d@%H-%M-%S”

        $extOnly = $fileObj.extension

        if ($extOnly.length -eq 0) {

            $nameOnly = $fileObj.Name

            rename-item “$fileObj” “$nameOnly-$DateStamp”

            }

        else {

            $nameOnly = $fileObj.Name.Replace( $fileObj.Extension,”)

            rename-item “$fileName” “$nameOnly-$DateStamp$extOnly”

        }       }

    $output | Export-CSV ($WorkingDirectory + “DG_Members_Backup.csv”) -NoTypeInformation

   }

# ———————————————————————————————-

sleep 15

Write-Host “Completed” -ForegroundColor Green

Write-Host “———————————————————————————————-” -ForegroundColor Cyan

# ————————————————————————–

# Create the Cloud copies of the Distribution Lists

# ————————————————————————–

Write-Host “Creating Cloud copies of each AD Synced Distribution List” -ForegroundColor Green

$Identities = import-csv ($WorkingDirectory + “DG_Details_Backup.csv”) | select -expandproperty PrimarySmtpAddress

# Create the cloud versions

If ($Identities) {

    foreach ($group in $identities) {

    If (((Get-DistributionGroup $group -Resultsize Unlimited -ErrorAction ‘SilentlyContinue’).IsValid) -eq $true) {

        $OldDG = Get-DistributionGroup $group

        [System.IO.Path]::GetInvalidFileNameChars() | ForEach {$Group = $Group.Replace($_,’_’)}

        $OldName = [string]$OldDG.Name

        $OldDisplayName = [string]$OldDG.DisplayName

        $OldPrimarySmtpAddress = [string]$OldDG.PrimarySmtpAddress

        $OldAlias = [string]$OldDG.Alias

           

            if ((![string]$OldDG.managedby) -or ([string]$OldDG.managedby -eq “Organization Management”)) {

                [string]$OldDG.managedby=$ManagedByDefault

                }

           

        $OldMembers = (Get-DistributionGroupMember $OldDG.PrimarySmtpAddress).primarysmtpaddress “EmailAddress” > “$ExportDirectory\$OldName.csv”

        $OldDG.EmailAddresses >> “$ExportDirectory\$OldName.csv”

        “x500:”+$OldDG.LegacyExchangeDN >> “$ExportDirectory\$OldName.csv”

        Write-Host ”  Creating Group: Cloud-$OldDisplayName” -ForegroundColor Green

        New-DistributionGroup `

            -Name “Cloud-$OldName” `

            -Alias “Cloud-$OldAlias” `

            -DisplayName “Cloud-$OldDisplayName” `

            -ManagedBy $OldDG.ManagedBy `

            -Members $OldMembers `

            -PrimarySmtpAddress “Cloud-$OldPrimarySmtpAddress” | Out-Null

        Sleep -Seconds 3

        Write-Host ”  Setting Values For: Cloud-$OldDisplayName” -ForegroundColor Green

        Set-DistributionGroup `

            -Identity “Cloud-$OldPrimarySmtpAddress” `

            -AcceptMessagesOnlyFromSendersOrMembers $OldDG.AcceptMessagesOnlyFromSendersOrMembers `

            -RejectMessagesFromSendersOrMembers $OldDG.RejectMessagesFromSendersOrMembers `

        Set-DistributionGroup `

            -Identity “Cloud-$OldPrimarySmtpAddress” `

            -AcceptMessagesOnlyFrom $OldDG.AcceptMessagesOnlyFrom `

            -AcceptMessagesOnlyFromDLMembers $OldDG.AcceptMessagesOnlyFromDLMembers `

            -BypassModerationFromSendersOrMembers $OldDG.BypassModerationFromSendersOrMembers `

            -BypassNestedModerationEnabled $OldDG.BypassNestedModerationEnabled `

            -CustomAttribute1 $OldDG.CustomAttribute1 `

            -CustomAttribute2 $OldDG.CustomAttribute2 `

            -CustomAttribute3 $OldDG.CustomAttribute3 `

            -CustomAttribute4 $OldDG.CustomAttribute4 `

            -CustomAttribute5 $OldDG.CustomAttribute5 `

            -CustomAttribute6 $OldDG.CustomAttribute6 `

            -CustomAttribute7 $OldDG.CustomAttribute7 `

            -CustomAttribute8 $OldDG.CustomAttribute8 `

            -CustomAttribute9 $OldDG.CustomAttribute9 `

            -CustomAttribute10 $OldDG.CustomAttribute10 `

            -CustomAttribute11 $OldDG.CustomAttribute11 `

            -CustomAttribute12 $OldDG.CustomAttribute12 `

            -CustomAttribute13 $OldDG.CustomAttribute13 `

            -CustomAttribute14 $OldDG.CustomAttribute14 `

            -CustomAttribute15 $OldDG.CustomAttribute15 `

            -ExtensionCustomAttribute1 $OldDG.ExtensionCustomAttribute1 `

            -ExtensionCustomAttribute2 $OldDG.ExtensionCustomAttribute2 `

            -ExtensionCustomAttribute3 $OldDG.ExtensionCustomAttribute3 `

            -ExtensionCustomAttribute4 $OldDG.ExtensionCustomAttribute4 `

            -ExtensionCustomAttribute5 $OldDG.ExtensionCustomAttribute5 `

            -GrantSendOnBehalfTo $OldDG.GrantSendOnBehalfTo `

            -HiddenFromAddressListsEnabled $True `

            -MailTip $OldDG.MailTip `

            -MailTipTranslations $OldDG.MailTipTranslations `

            -MemberDepartRestriction $OldDG.MemberDepartRestriction `

            -MemberJoinRestriction $OldDG.MemberJoinRestriction `

            -ModeratedBy $OldDG.ModeratedBy `

            -ModerationEnabled $OldDG.ModerationEnabled `

            -RejectMessagesFrom $OldDG.RejectMessagesFrom `

            -RejectMessagesFromDLMembers $OldDG.RejectMessagesFromDLMembers `

            -ReportToManagerEnabled $OldDG.ReportToManagerEnabled `

            -ReportToOriginatorEnabled $OldDG.ReportToOriginatorEnabled `

            -RequireSenderAuthenticationEnabled $OldDG.RequireSenderAuthenticationEnabled `

            -SendModerationNotifications $OldDG.SendModerationNotifications `

            -SendOofMessageToOriginatorEnabled $OldDG.SendOofMessageToOriginatorEnabled `

            -BypassSecurityGroupManagerCheck

        sleep 3

    }                

    Else {

        Write-Host ”  ERROR: The distribution group ‘$Group’ was not found” -ForegroundColor Red

        Write-Host

    }

}

}

# ————————————————————————–

# Delete all the Distribution Groups in Active Directory

# ————————————————————————–

Write-Host “All Distribution Lists have been replicated in the Cloud with Cloud_ as a prefix” -ForegroundColor Green

Write-Host “Completed” -ForegroundColor Green

Write-Host “———————————————————————————————-” -ForegroundColor Cyan

Write-host “If you encountered any errors during the creation of the Cloud-Group process you may hit CTRL + C now to kill the process.” -ForegroundColor Red -BackgroundColor Black

Write-host “If you kill the process now to fix any issues you should remove the Cloud-Group objects from Azure AD and start fresh.” -ForegroundColor Red -BackgroundColor Black

Write-host “WARNING – The Azure AZ Connect Sync Schedule is currently Suspended. You must complete the script or manually restart the Schedule.” -ForegroundColor Black -BackgroundColor Red

Write-Host “———————————————————————————————-” -ForegroundColor Cyan

Write-host “Press Enter to delete the migrated Distribution Lists from Active Directory” -ForegroundColor Cyan

pause

If (test-path ($WorkingDirectory + “DG_Details_Backup.csv”)) {

    $Identities = import-csv ($WorkingDirectory + “DG_Details_Backup.csv”) | select -expandproperty Identity

    foreach ($group in $identities) {

        Remove-ADGroup -identity “$group” -confirm:$false

        sleep 2

        }

}

Write-Host “All Distribution Lists have been removed from Active Directory” -ForegroundColor Green

Write-Host “Completed” -ForegroundColor Green

Write-Host “———————————————————————————————-” -ForegroundColor Cyan

sleep 15

Pause

# ————————————————————————–

# Initiate a Delta Sync with Azure AD Connect and set a timer of 5 minutes

# ————————————————————————–

Write-Host “Synchronizing Changes with Azure AD Connect.  Please allow 5 minutes for process to complete.  You will be prompted when to continue.” -ForegroundColor Green

Start-AdSyncSyncCycle -PolicyType Delta

Write-Host “PLEASE BE PATIENT – Confirm the Distribution Lists have been removed from Office 365 Azure AD before continuing” -ForegroundColor Green

sleep 300

Write-Host “Completed” -ForegroundColor Green

Write-Host “———————————————————————————————-” -ForegroundColor Cyan

Pause

# ————————————————————————–

# Complete the process by renaming the Cloud copies to the original names

# ————————————————————————–

Write-Host “Updating the placeholder Distribution Lists to replace the original AD synchronized Distribution Lists” -ForegroundColor Green

If (test-path $ExportDirectory) {

    $Identities = import-csv ($WorkingDirectory + “DG_Details_Backup.csv”) | select -expandproperty Identity

    foreach ($group in $identities) {

        $TempDG = Get-DistributionGroup “Cloud-$Group”

        $TempPrimarySmtpAddress = $TempDG.PrimarySmtpAddress

        [System.IO.Path]::GetInvalidFileNameChars() | ForEach {$Group = $Group.Replace($_,’_’)}

        $OldAddresses = @(Import-Csv “$ExportDirectory\$Group.csv”)

        $NewAddresses = $OldAddresses | ForEach {$_.EmailAddress.Replace(“X500″,”x500”)}

        $NewDGName = $TempDG.Name.Replace(“Cloud-“,””)

        $NewDGDisplayName = $TempDG.DisplayName.Replace(“Cloud-“,””)

        $NewDGAlias = $TempDG.Alias.Replace(“Cloud-“,””)

        $NewPrimarySmtpAddress = ($NewAddresses | Where {$_ -clike “SMTP:*”}).Replace(“SMTP:”,””)

    Write-Host “Converting Cloud-$Group to $Group”

        Set-DistributionGroup `

            -Identity $TempDG.Name `

            -Name $NewDGName `

            -Alias $NewDGAlias `

            -DisplayName $NewDGDisplayName `

            -PrimarySmtpAddress $NewPrimarySmtpAddress `

            -HiddenFromAddressListsEnabled $False `

            -BypassSecurityGroupManagerCheck

        Set-DistributionGroup `

            -Identity $NewDGName `

            -EmailAddresses @{Add=$NewAddresses} `

            -BypassSecurityGroupManagerCheck

        Set-DistributionGroup `

            -Identity $NewDGName `

            -EmailAddresses @{Remove=$TempPrimarySmtpAddress} `

            -BypassSecurityGroupManagerCheck

    sleep 3

    }

    }

Write-Host “Completed” -ForegroundColor Green

Write-Host “———————————————————————————————-” -ForegroundColor Cyan

# Re-Enable AD Sync Schedule

Set-ADSyncScheduler -SyncCycleEnabled $true

Write-Host “The conversion process happens in Exchange and can take a while to reflect in Azure AD”

Write-Host “Check to make sure that Azure AD is updated and now showing all of the Distribution Lists are converted to Cloud objects”

Pause

The post Office 365 – Migrating Distribution Groups appeared first on Wiredwolf Canada.

For this post I am relaying what I’ve discovered about trying to migrate a VM from VMware to Promox VE.

The original VM:

• 4 vCore x 1 socket
• 8 GB memory
• 1 x 250 GiB VMDK
• 1 x 1.1 TiB VMDK
• Windows 2016 Standard

Granted, I have made things more difficult by having multiple network segments.  In my last post I think I mentioned setting up multiple VLANs, Bridges, and Interfaces in Proxmox.  This was because I’ve gone back and forth between two networks, and my Synology NAS straddles both.  I ended up adding the Synology NAS to as storage to the same Promox host twice, once per network, to hopefully make network access more efficient to the mass storage device.

Over the past week I have been working with the ovftool to migrate the file server to Promox, each time taking in excess of 24 hours and inevitable session timeouts, causing the import to stall and ultimately fail.  Since you cannot pick up where you left off (that would be a sweet feature to ask for) the process has been started multiple times.  This last attempt today, however, completed in just 8 hours successfully, so evidently my theory on network traffic efficiency won out.

The first step – use the VMware ovftool (installed to Proxmox VE server) to import the desired VM:

ovftool –overwrite vi://192.168.155.81/FileServ /pve-zfs

The second step – use qm to import the VM to Promox:

qm importovf 210 /pve-zfs/FileServ.ovf /pve-zfs

Once completed, the VM showed up in Proxmox as expected, as ID 210, but without a network interface (which is also expected).

First challenge – machine is not bootable.

Referencing Promox support documentation on importing VMs:  Migrate to Proxmox VE – Proxmox VE

Convert the SCSI disks to IDE or SATA.  

• Detach disk
• Change format to IDE or Sata
• Connect 

Still no joy.  Disks were converted fine.  
I then added a CDROM to the VM and booted to a Windows Server 2016 install media ISO – confirmed that C:\ is the %systemroot%.  

I then went back to the hardware and made a few edits:

1. Converted the Machine version to q35 from default i440fx
2. Converted the SCSI Controller to PVSCSI
3. Converted the Processors from kvm64 to host

Still no joy – machine does appear to boot it just can’t find a boot partition.

Maybe the OVF will give me some insights? Before getting that desperate, I tried one last thing – I switched the BIOS from SeaBIOS to OVMF (UEFI).

Bingo – the machine instantly booted successfully.

Lesson learned – don’t rely on the qm importovf to properly read the OVF and translate it to the same profile in Proxmox.  Make sure you have your hardware profile from VMware before 

The post Proxmox – Post 2 appeared first on Wiredwolf Canada.

Proxmox has actually been around for a while.  In essence, it’s a web-skinned Linux KVM.  Proxmox is built on a Debian build, and heavily relies on the operator to be somewhat proficient with Linux.  While it takes some of the guesswork out of the Linux experience, there is no way an operator will be able to fully run Proxmox without dropping to bash occasionally.

Initially I was very impressed with Proxmox.  It installs very easily and the web console is both intuitive and provides quite a lot of help.  After watching a few training videos I could see that importing VMs can be done numerous ways, and that networking appeared to be fairly flexible.As I continued down the road of converting my ESXi 6.7 hosts, though, I started to see where Proxmox still has a ways to go.

My first trial was to install Windows 10.  This went quite smoothly and I was able to load the VirtIO disk drivers into the install without too much difficulty, and get the VM booted.  After that, though, I encountered numerous issues with the VirtIO supported drivers and the Windows 10 image.  After the driver package and guest software for VirtIO was installed, it took no less than 2 hours to boot the image again.  It took quite a while to figure out that the issues were with VirtIO, so 3 builds later I was on the SeaBIOS with the default drivers and found that to be stable.  Not as quick as with the VirtIO driver set (when it did eventually boot to a desktop) but stable and far more reasonable boot times.

My second trial was to add storage.  This was relatively easy.  On my second Proxmox node I used an old Datto Siris box I’d reset.  It has JBOD, no RAID to speak of, so I set up ZFS.  Within a couple of minutes I’d wiped out the VMFS 6 partitions and set up a single solid ZFS volume.  I also have a Synology NAS – 4 NICs, 4 Bays.  I went the easy route and just set up an SMB/CIFS share and connected to Proxmox.

The third trial was a bit more daunting.  On my first Promox node I’d already created a Windows 10 instance.  My second node had nothing on it.  I set up the second node to be the Cluster to join, then discovered that the first node couldn’t join the cluster because it already had a VM running on it.  So I set up the first node to be the Cluster to join, and discovered that in the Web UI there is absolutely no way to ‘unjoin’ or even remove the cluster config.  Now I had 2 nodes, each believing they were the master node.

After a lot of searching I finally figured out how to remove the cluster info from both servers so I could try again.

To Remove a Node:

1. SSH to host (better to not use the Web UI Shell for this)
2. Check nodes
   pvecm nodes
3. Identify the node you want to remove by it’s Node id
4. Remove the node
   pvecm delnode <nodeid>
5. Now we want to remove the Cluster
   1. Set the cluster to indicate that there’s now only the 1 member
      pvecm expected 1
   2. Stop the Cluster Service
      systemctl stop pve-cluster
   3. Start the PVE local service
      pmxcfs -l
   4. Delete the PVE cluster conf files and the lock file
      rm -r /etc/pve/cluster.conf /etc/pve/corosync.conf
      rm -r /etc/cluster/cluster.conf /etc/corosync/corosync.conf
      rm /var/lib/pve-cluster/.pmxcfs.lockfile
   5. Stop the Cluster Service (again)
      systemctl stop pve-cluster
   6. Reboot

The first time I did this the /etc/pve/cluster.conf and /etc/cluster/cluster.conf files did exist.  Of course I’ve blown this up several times now, so I’ve come to realize that these files no longer exist.  Execute the commands anyway (doesn’t hurt anything) and ignore the warnings that these two files cannot be found.

I did eventually get the cluster to connect the nodes and I did find that the Promox server quite conveniently shifted to the Datacenter console to manage both the nodes and the storage, which actually is quite convenient.  Unfortunately unless both nodes are identical it’s not quite so simple to seamlessly move VMs around, but it does work quite well.

My fourth trial was to migrate VMs from my VMware ESXi host to Proxmox.  The first one I selected was a VM called ‘Unifi Controller’.  It’s a VM I no longer use, but it’s small making it relatively portable, and being that it’s no longer in use there was no danger of losing anything critical.

This ended up being quite the exercise.  The space in the name caused a lot of problems.  Exporting the VM from the VMware Web UI was no issue, nor uploading to Promox. The Debian OS had no trouble with it either, just making it /Unifi\ Controller/, but the ‘qm importovf’ native to Proxmox couldn’t handle it, converting the space to %20 instead.  Eventually I worked out that if I renamed the .ovf and .vmdk files to something else without a space, and edited the .ovf file to match the file names I’d already reset, then the ‘qm importovf’ command was able to blast through the conversation from VMDK to RAW format and add the VM to the node.  Obviously I did have to recreate the network config, but that was relatively easy and the VM came up without issue.

Convert the VMDK disk to RAW:
qemu-img convert -f vmdk /pve-zfs/Unifi\ Controller-1.vmdk -O raw /pve-zfs/Unifi\ Controller/Unifi\ Controller-1.raw -p

Import the VM to Promox (after renaming the files to unificontroller.xxx):
qm importovf 200 unificontroller.ovf pve-zfs

The problem with this process is the download/upload of the OVF from VMware.  If you’re exporting a 1 TB server and you’re on a laptop with only 500 GiB storage, then you can’t get there from here.  So the more logical approach is to import the OVF directly from ESXi to Proxmox, which turns out to be fairly easily done through a program called ovftool (VMware – download and install from their site to your Proxmox server):

ovftool –overwrite vi://192.168.1.5/FileServ /pve-zfs

I had to add –overwrite as this process has failed numerous times and when it does – you have to start over.

The syntax is easy:

• ovftool – command
• –overwrite – option
• vi://192.168.1.5/FileServ – virtual interface IP address of your ESXi host and /VM-Name
• /pvs-zfs – the storage name you are importing to

The only problem I have with this process is that it’s very slow.  The VM must be shut down to execute the export/import and I’ve found this process on a 1 TB transfer can easily take a day.  I’m going to keep trying to figure out if there’s a way to speed this up.  If I do, I will document it here.

The post Proxmox – Post 1 appeared first on Wiredwolf Canada.

Typically I use the EmailAddress (Mail) attribute to cross-link the accounts.

Example:

Azure AD user:  Smiles J. McDuff

Azure AD email:  smiley@mydomain.com, sjmcduff@mydomain.onmicrosoft.com

In AD I then create the user –

AD User:   Smiles McDuff

SamAccountName:  sjmcduff

Set Email Address:  smiley@mydomain.com

When I do an Azure AD Connect Sync the new AD user should match to the Azure AD user and overwrite the user and attributes to that based in Active Directory.

Sometimes that doesn’t happen, such as making a typo with the email address, and instead of cross-linking the accounts between AD and AAD, a new user account is created in AAD.  Now things get tricky, because no matter how many times you delete the incorrect account in Azure AD, the next sync will just recreate it.

The solution is to capture the ObjectGUID attribute for the user in Active Directory and set that as the ImmutableID for the user in Azure.

Command:

Get-ADUser sjmcduff | select-object userPrincipalName, objectGuid

Result:

UserPrincipleName  :  sjmcduff@mywindowsdomain.com

objectGuid : b316d357-25fd-4912-9896-faf007a16289

Now convert that Guid to something we can use as an ImmutableID –

[Convert]::ToBase64String([guid]::New(“b316d357-25fd-4912-9896-faf007a16289”).ToByteArray())

Result:  

V9MWs/0lEkmYlvrwB6FiiQ==

This is our new ImmutableID value for the Azure AD user account.

connect-msolservice

Get-MsolUser -UserPrincipalName “sjmcduff@mydomain.onmicrosoft.com” | select-object userPrincipalName, ImmutableId

Result:

UserPrincipalName : sjmcduff@mydomain.onmicrosoft.com
ImmutableId :                              [Confirm ImmutableID is blank -if not record it in your notes]

Command:

Set-MsolUser -UserPrincipalName “sjmcduff@mydomain.onmicrosoft.com” -ImmutableId “V9MWs/0lEkmYlvrwB6FiiQ==”

Comand:

Get-MsolUser -UserPrincipalName “sjmcduff@mydomain.onmicrosoft.com” | fl userPrincipalName,ImmutableId

Confirm ImmutableID matches

Now when you sync, the accounts should pair up properly.

The post Azure AD Connect – Fixing the Sync appeared first on Wiredwolf Canada.

The concept is pretty simple – LAPS sets a Local Administrator password policy against all the computers (except domain controllers) in a domain environment.  A typical policy:

• Password is reset every X number of days
• Password meets complexity requirements
• Password meets length requirements

In my own environment I set a policy of 90 days and 24 completely randomized characters.

I found lots of resource online for getting started:

• How to install and configure Microsoft LAPS – 4sysops
• How to Configure Microsoft Local Administrator Password Solution (LAPS)

Both sites are great at detailing out the process.

The drawbacks I encountered:

1. If deploying the MSI package via GPO you do have to reboot the system for the install to happen
2. It doesn’t work for Domain-Joined systems in Azure unless you’ve planned for this in advance

When you deploy an Azure Windows VM, the ‘administrator’ account is reserved by Azure, so you’re prompted to create your own.  Out of the box configurations for LAPS utilizes the Administrator account, so unless you plan ahead and have a policy that resets the default Administrator to a different username, and incorporated the same username into your LAPS policy, your Azure Windows VMs will accept the policy but never return a password.

Truthfully I did cheat this last bit by just adding the Administrator username to the Azure VM and giving it a random password.  LAPS then did grab that account and reset the password according to policy.  This isn’t the right way to do it though, so I don’t recommend it.  Best practice would be to set your own Local Administrator username and implement across your domain, and incorporate into your LAPS policy.

Oct 18, 2024 – update

I keep hitting my head against needing to validate LAPS passwords.  Sometimes I don’t want the password, I want to know how many or which systems have a LAPS password:

Get-ADComputer -LDAPFilter “(ms-mcs-AdmPwd=*)” | select-object name

(Get-ADComputer -LDAPFilter “(ms-mcs-AdmPwd=*)”).count

Inversely to find out how many or which systems do not have a LAPS password:

Get-ADComputer -LDAPFilter “(!(ms-mcs-AdmPwd=*))” | select-object name

(Get-ADComputer -LDAPFilter “(!(ms-mcs-AdmPwd=*))”).count

The post Windows Security – LAPS appeared first on Wiredwolf Canada.

This post is more specific to creating a clean room, restoring your controllers to the clean room to run tests on them, particularly to make sure they’re replicating with each other, and restore them to the original Resource Group.  In this post we are using Commvault as the backup medium and restoring to Azure using a Commvault Media Agent.

Step 1: Create a Clean Room in Azure

The clean room in Azure is a Resource Group into which Commvault will restore backups of the Active Directory Domain Controllers. This Resource Group should be created in the same region as the production environment.

Resource Group:                RG-CACENTRAL-AD-Cleanroom
Within the Resource Group create:
Virtual Network:               VNET-CACENTRAL-AD-Cleanroom
Scope:                                  10.200.0.0/16
Subnet 1:                             SNET-CACENTRAL-AD-Cleanroom
                                              10.200.0.0/24
Subnet 2:                            AzureBastionSubnet
                                             10.200.254.0/26
Storage Account:              cleanroomstorage1
Public IP:                           PIP-Bastion-Cleanroom

NOTES

• Subnet 2 is automatically created when Bastion is deployed, and the name of the subnet must be AzureBastionSubnet
• The storage account is a requirement of Commvault as a place holder for the recovery VHDs
• Commvault also requires the name of the virtual network/subnet
• Throughout this exercise the vnet was never given its own security group or public IP address. This is a sandbox area with no internet access to ensure there can be no tampering with the domain controllers while they’re being recovered.
Bastion Deployment

Step 2 – Add Bastion

• In the resource group click on Create
• Enter “Bastion” in the search field
• Select Microsoft Bastion
• Click on Create to add the Bastion Plan to the Resource Group

o Subscription: pre-selected
o Resource Group: pre-selected
o Name: RG-CACENTRAL-CLEANROOM-BASTION
o Region: pre-selected (but make sure it matches)
o Tier: Basic
o Virtual Network: select VNET-CACENTRAL-AD-Cleanroom
o Subnet: select AzureBastionSubnet
o Public IP select ‘Create new’
o Public IP Name PIP-Bastion-Cleanroom

It can take a few minutes for Bastion to deploy.

The Clean Room has now been set up. Please note that the only Public IP to this environment is with Bastion and Bastion cannot be accessed outside of the Azure Portal.

Step 3 – Restoring the VMs to the Clean Room

Using Commvault the restoration process will deposit/create replica VMs to the resource group.

• Use the option to not start the VM when the restore is completed so you can check each one individually for corruption.
• Try to restore from the same time frame for each domain controller
IE – restore for Nov 11 2022 8 PM for one, then every other one should be the same or close
• Recommend you start with your PDCE role holder and restore each subsequent domain controller to a time or date after the PDCE

Step 4 – Verifying Azure Cleanroom VMs

The restored VMs can be booted up but may require additional modifications to function in the different vnet. This can be set on the vnet object or each network interface object.

• Update the Network Interface for each VM
o IP configurations – set to Static and note the IP address
o DNS Servers – add the static IP assigned to each VM as DNS servers
o Update the root IP A address of the domain, test pinging to ensure it resolves to the correct address
Use Bastion to connect to each domain controller. Note that your username should not be your pre-2000 (DOMAIN\username) but rather your modern username (username@internaldomain.loc)

• Suggest you open Active Directory Sites and Services and add the SNET-CACENTRAL-AD-Cleanroom subnet and link to the site name of the original domain controller

Testing AD

In this environment I was able to connect to each domain controller and immediately execute commands to verify AD replication. 

• Start Elevated CMD
• Execute: repadmin /syncall
• Execute: repadmin /showrepl
• Execute: repadmin /replsummary

I also created a bogus DNS entry under our domain and confirmed that it did replicate between controllers. Once confirmed be sure to remove this entry.

There was an issue with NETLOGON/SYSVOL replication with DFS Replication. In DNS the root A host record of the local domain is the original IP address of the PDCE and doesn’t automatically update. We resolved this issue in our test environment by adjusting this IP from the original to the new IP of the PDCE. Immediately all servers showed the NETLOGON and SYSVOL folders, and policies were being replicated between the domain controllers.

After moving back to the production environment make sure this DNS record is updated to its original value.

Step 5 – Migration back to Production Environment

The process to migrate the VMs to the Production Environment is simplified by only migrating the managed disks. To move the virtual disks the easiest way is to snapshot then create a replica from the snapshot in the target Resource Group.

• Shut down the VMs in the Clean Room
• Click on the disk to replicate in the Clean Room
• Click on Create Snapshot
• Give the snapshot a name but leave it in the same Resource group
• Set the networking to ‘Disable public and private access’
• Review + create
• Create

Now click on the snapshot in the Resource group

• Click on Create Disk
• Give the disk a name that identifies it as the replacement OS disk for the DC being restored
• Select the Resource group where the DC is being restored
• Select an appropriate size for the disk
• Set the networking to ‘Disable public and private access’
• Review + create
• Create

Go back to your production Resource group and ensure the servers you are about to restore are shut down

• Start with your PDCE Virtual machine
• Click on Disks
• In the OS Disk section, click on Swap OS Disk

Pay attention to the disk name, size, and which resource group it is in, to ensure correct selection.

Note:
You must confirm the OS Disk Swap by typing in the name of the VM

Click on OK at the bottom of the screen and wait for deployment to complete.

You will need to repeat this process for each VM being restored.

Final Steps

Once you have restored all the domain controllers in this fashion, start them up one at a time starting with your PDCE, and execute your AD tests again.

Because you are only swapping disks and not recreating the VMs you do not need to worry about configuration changes to the VM itself. All that information is retained. The analogy here would be that you have restored to a new drive to an earlier point in time, removed the corrupted or locked drive, and replaced with the new drive.

Tech Notes:

• I found it can sometimes take Azure a little while for the disks to appear in the dropdowns (sometimes a few minutes)
• I strongly recommend that you test this process biannually up to the point of restoring the disks to the production VMs.
• Bastion also has its own costs so if you aren’t going to be using it regularly then you can add when needed and remove when your recovery process has been concluded.  Keeping the Clean Room Resource Group doesn’t really cost anything but it’s so easy to recreate you might as well remove it as well.
• After recovery you should ensure your backups are continuing as expected – check your backup logs and run new backups manually as a test

The post Azure Repair and Recovery for Active Directory appeared first on Wiredwolf Canada.

The process is actually very simple using ntdsutil.

Open an elevated CMD (as Administrator

ntdsutil

activate instance ntds

snapshot

create

That’s it – the manual process.

To autotmate this process Petri has a good article on the process:  https://petri.com/automating-creation-active-directory-snapshots/

Basically create a batch file in your scripts folder called ad-snapshot.bat

@echo off

ntdsutil snapshot “activate instance ntds” create quit quit

exit

Use the Task Scheduler to create a job to fire this job once a week. 

The post Active Directory Backups appeared first on Wiredwolf Canada.

The production environment:

• One AD server is already in Azure
• One AD server is hosted on-premises in a VMware hypervisor
• Backup is done on both servers with CommVault

We created a Resource Group and populated with the following:

• Virtual Network separate from our production network with 2 subnets with no Public IP
  • Cleanroom Subnet
  • AzureBastionSubnet
• Bastion
• StorageAccount

Using CommVault both servers were restored to the vnet subnet for the Cleanroom.

The Azure server came up right away with no issues.  AD DS was healthy.

The VMware hosted server did not come up – it could not be booted and gave a BSOD of 0xc00002e2 which is Directory Services could not be started.  Uh oh – this is a problem.

Azure can be a little difficult when it comes to a BSOD on a server.  There is no ‘console’ per-say so there’s no way to reboot the server and start pounding on the F8 key to start in Directory Services Recovery Mode.  Even after an exhaustive Google search session, there wasn’t a lot to be found.  Lots of articles on how to enable DSRM on a failed domain controller if the option wasn’t available, but very little on how to actually get a VM to boot into DSRM.

The good news is it is doable, but it’s quite complex and involved.  Here are the steps I performed to achieve my goal:

Step 1 – create a recovery VM

This is done by utilizing Azure CLI commands.

Repair a Windows VM by using the Azure Virtual Machine repair commands – Virtual Machines | Microsoft Learn

I used the CLI option in the top right of Azure to open a CLI shell into Azure.  This is the simplest way to get a shell without having to install a whole bunch of Azure modules into PowerShell and navigate MFA authentication, etc.

az extension add -n vm-repair

This installs the extension so you can run the repair and create the repair environment

If you’ve already installed the extension at some point you may need to update it:

az extension update -n vm-repair

You will be prompted to enable a Public IP – if you aren’t using Bastion you might as well indicate Y – you will need it to access your recovery VM.

Now you run some simple commands 

az vm repair create -g MyResourceGroup -n myVM –repair-username username –repair-password ‘password!234’ –enable-nested –verbose

• where MyResourceGroup is the resource group the failed VM is currently residing
• where myVM is the name of the failed VM
• where repair-username is the is admin user you want to use for your recovery VM 
• where repair-password is the admin password you want to use for your recovery VM (I suggest you use a strong password)
• where –enable-nested sets up your recovery VM (a 2016 server) with Hyper-V installed

Once these commands complete, you’ll have a new Resource Group called repair-myVM–timestamp which has your bootable 2016 recovery VM and a copy of your failed drives – the non-bootable AD controller system drives and whatever other disks were attached to the failed VM from the restore.

Boot up the myVM recovery VM if it isn’t already and use RDP (or Bastion if you have it) to connect to the server using the repair-username and repair-password you specified in the previous command.

• Your Windows 2016 Server should have Hpyer-V installed to it.  If not, install it.
• Open Computer Management -> Disk Management and make sure the drive(s) you need to use for Hyper-V VM are set to “Offline”
• Open Hyper-V and create a VM with appropriate vCPU cores and memory (acknowledging the limits of your Server 2016 recovery instance)
  • Do not create a drive – choose to add a drive later
• Edit your new Hyper-V VM
  • Click on IDE Controller 1
  • Click on Add Hard Drive
  • Select the physical disk available
  • Click on Apply then OK
• Right click on the VM and click on Connect
• Start the VM
• When it starts booting up start tapping F8 to get into the boot menu
• Select Directory Services Recovery Mode
• Log in with your DSRM (Administrator) password

You can now perform the steps to correct whatever issues you’re having with AD.

When completed and you can boot the VM up and log in with your domain credentials, shut down the VM, then shut down your Recovery VM.

Go back to your Azure CLI 

az vm repair restore -g MyResourceGroup -n MyVM –verbose

Obviously, you will again substitute your values for MyResourceGroup and MyVM (same as above).

This final command will completely remove the recovery environment including the repair-ResourceGroup that was created from your Azure tenant.  

You should now be able to boot your recovered AD Domain Controller in Azure.

If your issue was not with Active Directory or you’re having issues recovering Active Directory due to disk issues:

Troubleshoot Windows stop error – directory service initialization failure – Virtual Machines | Microsoft Learn

I found this to be an extremely helpful article on fixing disks with NTDS installed. 

• You can use the 2016 Server to run DISKPART on the attached drive to set the active partition (Gen 1 VMs)
• You can use REG QUERY to find the location of the NTDS (typically C:\Windows\NTDS but it can be moved such as I found in my case which complicated things considerably)
• You can run BCDEDIT commands to force the VM to boot to DSRM (safeboot dsrepair) so you can re-attach the disk to your VM in Azure and not worry about not being able to hit F8 on a console
  • Note – you will have to also reverse this or the BCD will always boot to DS Recovery Mode
  • Note – you still have to have your DSRM password to log in

Other Helpful Resources

I used all of these online resources to solve my problem.

Blue screen errors when booting an Azure VM – Virtual Machines | Microsoft Learn

Troubleshoot a Windows VM in the Azure portal – Virtual Machines | Microsoft Learn

How to reset the Directory Services Restore Mode administrator account password – Windows Server | Microsoft Learn

How to fix Error 0xc00002e2 after rebooting Windows Domain Controller – Hostway Help Center

Azure Serial Console for Windows – Virtual Machines | Microsoft Learn

Fixing non-bootable Azure Virtual Machine (cloud-aware.net)

How to boot Windows Server in Directory Services Restore Mode (DSRM) (kapilarya.com)

Recovering the Active Directory database in Windows Server 2012 R2 | Dell Canada

How to Deploy Hyper-V Nested Virtualization on Azure: Full Overview (nakivo.com)

Attach a managed data disk to a Windows VM – Azure – Azure Virtual Machines | Microsoft Learn

The post Recover a Domain Controller in Azure appeared first on Wiredwolf Canada.

I started testing Ping Castle on my own Active Directory (mostly a lab environment) and scored way worse than I expected.  Ping Castle is like golf – the lower the score the better.  It’s scored based on findings in 4 categories, each category scored out of 100, with an overall total of 100 for all 4 categories.  I scored a 92/100.  Abysmal. 

Ping Castle shines in that it backs up all of its findings (which are extensive) with documentation to support best-practices, knowledge base articles on the subject, and recommendations.  One of those findings was the lack of good auditing configured on my AD domain.  The following list is what is recommended.  This is referenced in adsecurity.org but I couldn’t find the exact settings.  After more searching I did find it eventually on some other site, and re-running the analysis confirms my settings are now correct.  

Here are those settings for future reference:

Default Domain Controller Policy

Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Audit Policy

Audit account logon events: Failure
Audit account management: Success & Failure
Audit directory service access: Failure
Audit logon events: Failure
Audit policy change: Success & Failure
Audit privilege use: Success & Failure
Audit system events: Success & Failure

Computer Configuration\Policies\Windows Settings\Security Settings\Advanced Audit Policy Configuration\Audit Policies

Account Logon

Audit Credential Validation: Success & Failure
Audit Kerberos Authentication: Service Success & Failure
Audit Kerberos Service Ticket: Operations Success & Failure

Account Management

Audit Computer Account Management: Success & Failure
Audit Other Account Management Events: Success & Failure
Audit Security Group Management: Success & Failure
Audit User Account Management: Success & Failure

Detailed Tracking

Audit DPAPI Activity Success & Failure
Audit Process Creation Success & Failure

DS Access

Audit Directory Service Access Success & Failure
Audit Directory Service Changes Success & Failure

Logon/Logoff

Audit Account Lockout Success
Audit Logoff Success
Audit Logon Success & Failure
Audit Special Logon Success & Failure

Policy Change

Audit Audit Policy Change Success & Failure
Audit Authentication Policy Change Success & Failure

System

Audit IPsec Driver Success & Failure
Audit Other System Events Success & Failure
Audit Security State Change Success & Failure
Audit Security System Extension Success & Failure
Audit System Integrity Success & Failure

I would imagine the Default Domain Policy should also be updated, or another GPO applied at the root of the domain specifically for auditing, but those settings would be more lax as we’d only be interested in logging the actual logins to the workstations as opposed to these settings which are tracking changes to security around authentication and key objects.

On the workstation these policy settings should be sufficient:

Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Audit Policy

Audit account logon events: Failure
Audit account management: Success & Failure
Audit directory service access: Failure
Audit logon events: Failure
Audit policy change: Success & Failure
Audit privilege use: Success & Failure
Audit system events: Success & Failure

I will write more about the Ping Castle findings later.

The post Active Directory Auditing appeared first on Wiredwolf Canada.

The post PowerShell – Active Directory – New Email Domain appeared first on Wiredwolf Canada.