Category Archives: Windows

Migrating User and Password Objects between Active Directory Forests

As part of some internal lab work, I had to move the user objects with their passwords to a new forest. It was key to migrate the passwords to ensure that disruption to the users was minimized.

To migrate the users, I used the Microsoft Active Direction Migration Tool (ADMT + documentation) alongside the Password Migration Service.

In this blog post I am going to cover;

  • Create connectivity between both AD Forests
  • Installing the ADMT software + Password Migration Service
  • Creating a user list for migration
  • Migrating User objects + Passwords between AD Forests

Create connectivity between both AD Forests

There must be IP network connectivity between the DC’s in your Forests.

DNS setup

You need to configure conditional forwarders between your forests, so they can resolve one another.

On the source domain controller;

  1. Open up the DNS console, and right click the Conditional Forwarder folder to create a new record.
  2. Enter your target domain name and IP address/es of your domain controllers in the target domain. Select “store this conditional forwarder in active directory”, to replicate to other DCs in the source domain.

It is also a good idea to add the target domain DNS suffix to your Source DC network adapter, this allows for short name resolution.

Repeat the same steps on the target domain controllers, pointing the conditional forwarder to your source domain.

After this, ensure you can successfully look up the domains from another with the correct Domain controller IP addresses being returned. Also check short name resolution works.

Create Active Directory Forest Two-Way Trust

Next you need to create a forest trust

  • You can read about the different options here

I will create a two-way forest trust which means we are able to authenticate users between domains, and this trust will be removed after I’ve migrated the users.

On the source domain controller

  1. Open Active Directory Domains and Trusts. right click your domain name and go to properties
  2. Click the trusts tab, and click the new trust button
  3. Enter the name of your target domain
  4. Select forest trust
  5. Select two-way trust
  6. Select forest wide trust
  7. Enter trust password (you will use this when you create the trust on the target domain side)
  8. Click next x2
  9. If you click to confirm the trust at this point, it will fail as it does not exist on the target domain side yet. (See screenshots)

Installing the ADMT software

Install this on your Target domain controller, or a machine in target domain. There is a requirement for an SQL server to host a database. I used SQL Express for the lab setup.

Installing the Password Migration Service

First you must generate an encryption key from a DC in your target domain. Open CMD as administrator and run;

admt /key option:create /sourcedomain:{source domain name} /keyfile:{folder path to save the file} /Keypassword:*

Using * for the pwd flag, will then prompt you for the password when the command is run

On your source domain, in the built-in Administrators group, add in the domain administrator from your target domain.

On the domain controller in your source domain, install the Password Migration Service.

When prompted, install the service as the domain admin from your target domain, this account will be added the log on as service right.

A reboot of the machine where this service is installed will be needed.

After the reboot, you will need to manually start the “Password Export Server Service”, after you’ve migrated your users, for security, you should stop this service.

Creating a user list for migration

The last step before migration, is creating a CSV file with a list of the users we want to migrate. I will do this using a simple PowerShell command

get-aduser –filter * -searchbase {OU full path} | Export-csv {path}

You can be more complex if you need to target users who are part of a security group or multiple OUs.

You will need to edit this CSV to use the accepted headers for use as an “include file” for ADMT. You can follow the official documentation for these headers.

Migrating users between AD Forests

Ok, we’ve finished the prep work. Now time to migrate the users.

  1. Open up ADMT console, right click on the Migration tool folder and select “User Account Migration Wizard”
  2. Type in your source domain, and select your target domain from the drop down
  3. Select the option “read objects from include file”
  4. Set your include file location and Source OU where your users are located
  5. Select the option to migrate the user’s passwords
  6. Select account options for after the migration
    1. If selected SID History Migration, accept the options
  7. Input the domain admin detail to authenticate to the Source Domain
  8. Configure user options for after the migration
  9. Select any user object attributes you do not want to be migrated
  10. Select your option for how to handle user conflicts
  11. Complete the user migration wizard
  12. Watch the progress, you also have easy access to view the logs from here
  13. Configure user’s password so that they do not need changing upon next login.
get-aduser -filter * -searchbase {OU path} | set-aduser -changepasswordatlogon $false


Hope this helps someone out there, I recommend that you read the ADMT document first before undertaking a migration of AD users in production, and then test in a lab environment.

Windows Server 2019 Evaluation – Activation fails

I had issues converting one of my evaluation installations of Windows Server 2019 to a fully licensed copy. I’d extended the evaluation a few times using “slgmr /rearm” a few times, but had finally decided I was going to move this setup into production.

The issue

When going through the settings UI to activate, I could see an error message as below, and clicking the “Change product key” option did nothing.

Running through the CLI using “slmgr.vbs” also returned errors;


Cscript.exe %windir%\system32\slmgr.vbs /ipk {key}


0xC004F069 On a computer running Microsoft Windows non-core edition, run 'slui.exe 0x2a 0xC004F069' to display the error text.

Following the rabbit down the hole;


slui.exe 0x2a 0xC004F069 


Code: 0xC004F069
The Software Licensing Service reported that the product SKU is not found.
The fix

Continue reading Windows Server 2019 Evaluation – Activation fails

Notes from the field – Penetration tests

This blog post is by no means a comprehensive guide from an expert in the cyber security area. However my previous role meant I had the pleasure of reviewing a number of customer penetration tests and from this, pretty much all of them were all exploited in the same way. So I put together some basic information for any of my customers to review and think about before they had a penetration booked.

After all, might as well make it a challenge for the people you are hiring to hack your network 😉


Ok, so I’m only going to cover the basics, as there are far better articles out there on this.

  • Reconnaissance
    • Information gathering before attending the targets site
      • IP addresses of websites and MX record details
      • Details of email addresses (shared mailboxes, employees direct)
      • Social networks (details shared on LinkedIn by Employees, the companies twitter posts etc)
        • Consider the below twitter post by a company, what information can you glean from seeing a picture of their racks and other equipment.
        • If we know the company name, we can enumerate the various domain names they own to public IP addresses, and just plug that into a website like and maybe look for that Sonicwall and find out if its running the latest firmware.
        • Below when zooming in on the image, we can find details of an ADSL line
      • Job websites; are they hiring, especially in IT, what skills do they want? Looking for an engineer that knows a particular accountancy package?
  • Enumeration/Identification
    • Assessment of devices found and the search for vulnerabilities
      • Tools in use such as, but not limited to; nmap, Nessus, Metasploit, unicornscan, nikto, dotdotpwn, gobuster.
  • Exploitation
    • Create a plan of action/attack based on the information gathered.
    • Perform the attack/exploitation itself to achieve the end goal, usually access to systems from zero, escalation with the end goal being access to private/sensitive/restricted systems and data.
    • Tools in use such as, but not limited to; Kali Linux (OS and contains a lot of tooling), Nmap, Metasploit, BurpSuite, SQLMap, padbuster, custom exploit scripts
Common exploits to gain access

Ok so first, lets review how multiple networks were exploited or hacked.

Below is the common summary of issues found at many sites I reviewed, and this is what I will cover in this blog post ;

  • Null session authentication on Domain Controllers
  • Devices configured to use NBT-NS / LLMNR
  • SMB Signing
  • NTLMv1 in use for network authentication
  • Domain Users have Local Admin permissions to their machines
  • Poor password policy
  • No split accounts for Domain Admins
  • Poor patching on systems
Null Session Authentication

By default null sessions (unauthenticated) are enabled on Windows 2000 & 2003 servers. Therefore anyone can use these NULL connections to enumerate potentially sensitive information from the servers, read this as information from your Active Directory.

Therefore anyone with a legacy domain which has been upgraded through the years, will find that Null Session Authentication is enabled on their environments.

Seeing it in action Continue reading Notes from the field – Penetration tests

vBrownBag Session – Microsoft Azure for vSphere Admins

At VMworld 2018 I was invited to speak on the vBrownbag platform, which is a great community focused and run resource. Below is my session “Microsoft Azure for vSphere Admins”

You can find the presentation here –



Powershell – Get-ADuser and output the homedrives to CSV file

I had a customer with around 27 file servers used as locations for AD home drives. We needed to do some analysis on which users used which server, as things like DFS or a strategy of where to place users were not in place. So PowerShell to the rescue.

A simple version of this script is;

get-aduser -Filter * -properties * | select DisplayName,Enabled,HomeDirectory,LastLogonDate,CanonicalName | Export-csv -path c:\scripts\userhomefolder.csv

I created this more complex script after the amount of unique objects exceeded the maximum filter within excel, so by splitting into a file per server fixed this.

First off, create an array with the multiple file servers, then used the “foreach” command to loop a PowerShell command with each file server name.

We look into all user’s in AD and output to a CSV file any users with file server X into a CSV file.

#Add the AD module into the Powershell session
Import-module ActiveDirectory

#Array containing each File Server, can be FQDN or short name
$fileservers = 'FS1','FS2','FS3'

#Loop to run a script for each object in the array against all AD users, outputs in CSV to C:\ folder
Foreach ($fileserver in $Fileservers)
get-aduser -Filter * -properties * | select DisplayName,Enabled,HomeDirectory,LastLogonDate,CanonicalName | Where {$_.HomeDirectory -like "*$fileserver*"} |Export-csv -path c:\scripts\userhomefolder2-$fileserver.csv