There are many ways to go about setting up an e-mail relay but this is the process I used and it is working well for me. The only cost that I’m out was the cost of a domain that I already had and was paying for.

The first step is to setup an account with mailgun, I chose the free plan which allows you to send up to 100 e-mails a day (more than enough for my homelab) and I believe it only lets you send to five verified e-mail addresses (Again, more than enough for my homelab). The setup of the account and the configuration of pulling your own domain in is very straight forward I’m not going to go into that here.

However, the next step is to bring up an actual relay server, which I was not familiar with and wanted to blog about. I’m using Ubuntu 24.04 LTS and utilizing postfix to do this.

Install Ubuntu 24.04 LTS

I did a default install of Ubuntu 24.04 LTS, choosing all the default options and not choosing any additional add ons.

You can then install postfix

sudo apt install postfix

When prompted choose “Internet Site” which is the default

You can then input the fully qualified domain name of the name you plan to send e-mail as

I then added the following to the /etc/postfix/main.cf configuration file

Underneath smtp_tls_session_cache_database add the following line

smtp_tls_note_starttls_offer = yes

Change the myhostname = to be your hostname that is fully qualified and able to be looked up by your local DNS server

Change mydestination to equal “localhost.localdomain, localhost”

Change relayhost to be what was provided by mailgun it will probably be similiar to: smtp.mailgun.org:587

Underneath relayhost add the following lines (change the e-mail to be what you will be sending e-mail from in Mailgun, could be postmaster@mg.yourdomain.com for example, after the : is your password for that account that was setup in mailgun).

smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = static:no-reply@mg.XXXXXlab.com:PASSWORD
smtp_sasl_security_options = noanonymous

Change mynetworks to equal the home network that you will be sending e-mail to the relay from (ex. 192.168.0.0/24)

You can now restart postfix with: sudo systemctl restart postfix

If you would like to view a sample main.cf file on my github located here: https://github.com/paularquette/HomeLabProjects/blob/main/ubuntu-postfix/main.cf

You can then send all e-mails to your relay server that your local DNS knows it by (relay.domainname.com) on port 25, and your relay will server will send them out to mailgun to have them delivered.

Note: You will have to setup the e-mail addresses you want to be able to send to in Mailgun, and accept the invite so mailgun will actually deliver the e-mail. Your first e-mail may show up as spam but I’ve had no issues after making the e-mail sender as not spam.

This attribute allows all users in the Domain to bind 10 computer objects to the Domain that they control. This could actually lead to more than 10 computer objects since every computer object is also technically a user. Best practices is to disable this setting and set it to Zero.

You can run the following command to see if your domain is currently configured as default of 10 objects:

Get-ADObject -Identity ((Get-ADDomain).distinguishedName) -Properties ms-DS-MachineAccountQuota

If you are currently set to 10 and want to fall in line with best practices you can run the following command to change this attribute to Zero:

Set-ADDomain -Identity ((Get-ADDomain).distinguishedName) -Replace @{“ms-DS-MachineAccountQuota”=”0”}

You will not be provided any feedback, you can then run the first command again to verify things are set to Zero.

Enable Recycle Bin

To enable the Recycle Bin you can run the following command (Replace DOMAIN.COM and make sure quotes copy):

Enable-ADOptionalFeature -Identity “CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=DOMAIN,DC=COM” -Scope ForestOrConfigurationSet -Target “DOMAIN.COM“

Create Key for gMSA Accounts

When you bring up a new domain you will need to create the KDSRootKey for group managed service accounts.

Add-KdsRootKey -EffectiveImmediately

Enable Central Store in Group Policy

Create the “PolicyDefinitions” folder in SYSVOL

Once enabled, copy the files from C:\Windows\PolicyDefinitions into this folder

Install & Configure LAPS

You can verify you have the AD Schema updated for LAPS by running:

Update-LapsADSchema

You can verify that the LAPS GPOs are in Computer Configuration > Administrative Templates > System > LAPS

Create Group Policy Security Baseline for Domain Controllers

Download the Windows Server 2022 Security Baseline from Microsoft: https://www.microsoft.com/en-us/download/details.aspx?id=55319

Copy these files to a Domain Controller for example in C:\Temp

Copy the files from \Templates directory into the PolicyDefinitions folder in SYSVOL

In the \Scripts directory run the .\Baseline-ADImport.ps1 file to import the GPOs

Modify the firewall rules to enforce only the rules you specify:

1. Turn off Rule Merging for all profiles
2. Turn on firewall log with max size 32,767 for all profiles
3. Log dropped and successful packets for all profiles
4. Input Firewall Rules
   • ICMP (Ping Allow)
   • TCP/UDP 53 (DNS)
   • TCP/UDP 88 (Kerberos)
   • UDP 123 (Time Service)
   • TCP/UDP 135 (RPC Mapper)
   • TCP/UDP 389 (LDAP)
   • TCP 445 (SMB)
   • TCP/UDP 464 (Kerberos Password Change)
   • TCP 636 (LDAPS)
   • TCP 3268/3269 (Global Catalog)
   • TCP 49152-65535 (RPC Dynamic Range) [Will modify this later]
   • TCP/UDP 3389 (RDP) [Locked to Trusted IPs]
   • TCP 5985/5986 (WinRM) [Locked to Trusted IPs]
   • TCP 9389 (AD Web Services) [Locked to Trusted IPs]

Manually create the firewall logs on the DCs by launching Windows Defender Firewall, Go to the Log Settings and click “OK”

Create Another GPO or Add These Settings to the Current GPO

Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > System Services > Print Spooler

Define this policy and set the service startup mode to Disabled

Navigate to Computer Configuration > Preferences > Windows Settings > Registry (Use Update HKLM)

SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168\Enabled 0

SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\SSL 3.0\Server\Enabled 0

SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\TLS 1.0\Server\Enabled 0

SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\TLS 1.1\Server\Enabled 0

SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\TLS 1.2\Server\DisabledByDefault 0

SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\TLS 1.2\Server\Enabled 1

However, there was a recent Reddit thread that pointed my attention to supposedly not having any rearms like you did in the previous server versions.

With a fresh install of Server 2025, you are put into the initial grace period with 10 days. After this grace period the product will activate and you will have 180 days (I forced it with slmgr /ato), with 1 rearm left. From my testing I believe you will get 1 full year with the product. (10 days + 180 days + rearm (180 days)).

However, if you deploy Server 2025 and then try to create a VMware Template and deploy from template the customization, you will kill the 1 rearm you have. I think this might be where the disconnect is.

If we go back to 2006 though, and after installing Server 2025 on the VM you want to be your template, you can perform the following tasks so all new deployments will retain the 1 re-arm.

1. Set the Rearm Registry Setting to 1
   • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\SoftwareProtectionPlatform\SkipRearm
2. Run Sysprep, and make sure to check the generalize checkbox, and have the system shutdown
3. Convert said VM into a template, and then deploy from that template
   • Make sure you do not then try to customize in vmware! Just Deploy From Template and Power On!

From my initial experience this should provide any new VMs you deploy from template to also land in that 10 day grace period with 1 rearm left.

https://ubuntu.com/security/notices/USN-6859-1

Remove NTLMv1 From Environment:

Work to remove NTLM from the environment, although it may be impossible currently to remove NTLMv2 from the environment, disabling NTLMv1 is a great start.

Disable NTLMv1

Disable IPv6 if not using it

Disable IPv6 on client systems if it is not actively being used as this is a major problem with mitm6 attacks!

Check Group Policy Permissions

Look at all group policies and their permissions. Implement a naming convention if one is not already used and verify who has permissions to which group policies. Make sure no group policies are linked to high-target assets that have low level permissions. Check Group Policies for clear-text passwords.

Check SID-History

Check SID-History in the domain. If it is no longer needed remove it.

Remove Normal User Accounts From Any Administrative Groups

Make sure there are different user accounts for different administration tiers.

AD Administration (OU Admins) – Different Account / Password

VMware Administration – Preferably different domain, bare minimum different account / password

Local Workstation Admin Account – Different Account / Password

Use something like LAPS so no local user accounts and passwords are the same

This is a very easy pivot point for an attacker if they gain control of one system and can use the local administrator or another account to pivot to a bunch of other workstations.

Disable Simple/Unauthenticated Binds

Microsoft recommended turning off simple/unauthenticated binds in 2020 but it is still on in many places.

Reject Simple Authentication and Security Layer (SASL) Binds

Disable NetBIOS & LLMNR Domain Wide

An easy way for hackers to grab hashes and move around in the environment is with responder and NetBIOS and/or LLMNR enabled.

Disable NetBIOS & LLMNR

Investigate using Kerberos FAST Armoring

Investigate using Kerberos FAST Channel for Armoring Pre-Authentication.

Kerberos Fast Armoring

Password Cycle DSRM Password on Domain Controllers

Password cycle the DSRM password on all domain controllers, can be different or can be the same. You can sync this password from a Domain User account

Remove all unnecessary software from Domain Controllers

Anything with an agent is a potential path to compromise, think MECM. MECM can push software and make configuration changes, if MECM becomes compromised so do your DCs. VMware Tools may be a necessary evil but make sure that software is patched every month with Windows Patches.

Service Account Password Changes:

Take inventory of all service accounts in the domain. Document which service accounts are used by whom and for what purpose. Verify least privilege, and change the password yearly. This will keep documentation up to date and in the event of an attack you aren’t fumbling to figure out how to update the password and who is in charge of it.

Check for Group Managed or Managed Service Accounts:

Check the domain for use of Group Managed or Managed Service Accounts. Make sure this is documented somewhere.

Check for Constrained/Unconstrained Delegation

Check for Unconstrained or Constrained Delegation. If using unconstrained delegation and needed move to constrained delegation. Make sure the service account being used for constrained delegation is SUPER long to prevent kerbroasting.

ms-DS-MachineAccountQuota

By default in Active Directory this value is set to “10” which allows ANY user in Active Directory to bind ten machines to the domain. In the beginning stages of Active Directory maybe there was a need for this but now its just a big security risk.

Recommendation: Set this to zero

Add New Domain Controller Policy

By default, the “Default Domain Controllers Policy” allows anyone in “NT AUTHORITY\Authenticated Users” to bind machines to the Domain. Create a new GPO with locked down policy rights and link it to the Domain Controllers or Tier0 OU, make sure it is linked as a higher policy “link order”. The highest link order will win.

Protected Users Group

Look at highly privileged accounts and add them to the Protected Users Group if they are compatible with the protections that this group provides.

Recommendation: Add any real user accounts that are at Domain Admin or higher. (Enterprise Admins, Schema Admins, etc.)

krbtgt Account Password

Check the last time this password was changed and if it wasn’t changed in the last 180 days, change it. If someone has access to an Active Directory backup they can potentially own this account and if the password is never changed, own the domain.

Recommendation: Make sure you setup a schedule to recycle this password twice a year. This account holds two passwords so when you change the password you should change it twice, ideally 24 hours apart. That is a total of four password changes a year.

Verify SSL Certificates Exist on the Domain Controllers

Verify that valid certificates are in place for LDAPS calls over port 636. As part of this process investigate and try to remove any traffic that is talking on LDAP port 389.

Recommendation: Use either an internal PKI or public facing certificates to make sure all ldaps traffic is talking Active Directory over a secure connection.

Check if Exchange ExtensionAttributes were installed

If “ExtensionAttribute1” -> “ExtensionAttribute15” are in the schema of User/Computer/Group objects, check to see if any of them are in use.

Recommendation: If they are try to document what they are being used for and which ones are free and able to be used.

Check the Default Computer/User Bind OU

The default container for computer objects is (CN=Computers,DC=DOMAIN,DC=COM). This container cannot have group policy applied to it and objects should be set to write to another OU that can be better managed.

Excerpt from Microsoft here: Redirect users and computers containers – Windows Server | Microsoft Learn

“In a default installation of an Active Directory domain, user, computer, and group accounts are put in CN=objectclass containers instead of a more desirable OU class container. Similarly, the accounts that were created by using earlier-version APIs are put in the CN=Users and CN=computers containers.”

“Some applications require specific security principals to be located in default containers like CN=Users or CN=Computers. Verify that your applications have such dependencies before you move them out of the CN=users and CN=computes containers.”

Recommendation: If these items can be re-directed, redirect them to a different OU and make sure proper OU security is set.

Check Tombstone Lifetime / AD Recycle Bin

If the Active Directory Recycle Bin is not enabled, enable it!

The following PowerShell code can be used to see what the current Tombstone Lifetime is:

Write-Output “Get Tombstone Setting `r”
Import-Module ActiveDirectory

$ADForestconfigurationNamingContext = (Get-ADRootDSE).configurationNamingContext
$DirectoryServicesConfigPartition = Get-ADObject -Identity “CN=Directory Service,CN=Windows NT,CN=Services,$ADForestconfigurationNamingContext” -Partition $ADForestconfigurationNamingContext -Properties *
$TombstoneLifetime = $DirectoryServicesConfigPartition.tombstoneLifetime

Write-Output “Active Directory’s Tombstone Lifetime is set to $TombstoneLifetime days `r “

Note that no value returned means the tombstone lifetime setting is set to 60 days (default for AD forests installed with Windows 2003 or older).

Recommendation: If it is not set to 180 days, set it to 180 days. If the AD recycle bin is not enabled, enable it!

Check to see if Sysmon is installed on the Domain Controllers

Recommendation: If Sysmon is not installed, work on getting it installed and configured on the Domain Controllers at a bare minimum to provide more insight.

Check Domain Controller Firewall Settings

This may require a conversation with your Information Security team to understand how the Firewalls are configured that sit in front of the Domain Controllers. You want to make sure the bare minimum number of ports are enabled for client traffic and that admin ports are only able to be accessed by admins.

Recommendation: Review security with Information Security Team, and enable the Windows Firewall on all Domain Controllers and manage it with Group Policy. This also acts as an East/West traffic block so if someone gets into one server on the prod network they don’t automatically have RDP access per say to another DC on the same network segment. Setup monitoring for any RDP sessions, successful ones, and failures (including firewall logs). This will verify anyone RDP’ing to the DCs is legit, and will also help track down threat actors on the network. One of the first things threat actors will try to do is see if they have RDP access to the Domain Controllers, this is good information to send to the SOC or InfoSec.

Check to see if RPC Ports are restricted

Recommendation: If RPC Ports have not been limited on the Domain Controllers, limit them to a few ports, say 100, or 1,000, and then make the associated changes to firewall rules.

Check Time Settings on the Domain Controller running PDC Emulator

Many people know that the clients that talk to the Domain Controllers have to have the correct time, but it is super important that you are pulling a correct time source for your Domain Controllers.

Recommendation: Make sure the Domain Controllers, more specifically the Domain Controller with the PDC FSMO role is pulling its time from a trusted source. It might also be worth writing a script to monitor this as well.

Verify FSMO Role Holder(s), Global Catalog Servers, & Backups

Verify who is running the FSMO roles for your Domain(s). Make all DCs a Global Catalog if you have a single-domain forest. Verify how AD is being backed up.

Recommendation: Depending on your specific situation you may not be able to run all FSMO roles on one DC. In my jobs I have been able to. This allows you to target this DC as the DC to be backed up, snapshotted, etc. If you are running a single-domain forest, make sure all DCs are a global catalog.

Check Trusts

Check to see if there are any trusts configured for the domain.

Recommendation: If there are any trusts, figure out if they are still needed, and make sure there is documentation on why these trusts are setup and when they can be unconfigured.

Check Sites & Services for IP Configuration

Check AD Sites & Services for configuration of IP ranges. Make yourself familiar with how this setup and why it is setup the way it is.

Recommendation: Take notes on if Sites & Services is being used. If it is being used understand the network ranges and why it is configured the way it is. If priority is being given, understand why.

Turn off Print Spooler on Domain Controllers / High Level Servers

Turn off the Print Spooler on Domain Controllers and any other Tier0 servers like Azure Entra Sync.

Turn On Alerting for High Level Groups / Logins

Alert on logins to Domain Controllers, alert on logins using Domain Admin credentials. Alert if anyone gets added to Enterprise Admins, Schema Admins, Domain Admins, Administrators, or any other high level groups.

Lock down highly priviliged accounts to only the systems they need to be able to login to

Make sure high level accounts can only login to the systems they need to. For example Domain Admin accounts can only login to the Domain Controllers and privileged workstations/servers to administer AD.

This has been a long time coming. As of this June NTLM is no longer under active development and will start to be phased out. NTLM will still be usable with the next release of Windows Server.

I’m excited to read this news and looking forward to Microsoft pushing forward to more secure authentication systems.

This out of band patch is a cumulative update and can be installed in place of the normal March cumulative update that is published on Windows Update / local WSUS server. If you want this patch in WSUS you will have to side load it yourself.

We have confirmed in our testing environment that the lsass memory process was starting to creep up. We removed the March cumulative update and applied the out of band patch in our test environment and so far all seems good.

The below is copied from the Windows Message Center as of today. (Link below)
https://learn.microsoft.com/en-us/windows/release-health/windows-message-center#3143

Out-of-band updates to address a Windows Server domain controller issue

Updated March 25, 2024

Microsoft has identified an issue that affects Windows Server domain controllers (DCs), and has expedited a resolution that can be applied to affected devices. Out-of-band (OOB) updates have been released for some versions of Windows today, March 22, 2024, to addresses this issue related to a memory leak in the Local Security Authority Subsystem Service (LSASS). This occurs when on-premises and cloud-based Active Directory domain controllers service Kerberos authentication requests.

This issue is not expected to impact Home users, as it is only observed in some versions of Windows Server. Domain controllers are not commonly used in personal and home devices.

Updates are available on the Microsoft Update Catalog only. These are cumulative updates, so you do not need to apply any previous update before installing them, and they supersede all previous updates for affected versions. If your organization uses the affected server platforms as DCs and you haven’t deployed the March 2024 security updated yet, we recommend you apply this OOB update instead. For more information and instructions on how to install this update on your device, consult the below resources for your version of Windows:

• Windows Server 2022: KB5037422
• Windows Server 2019: KB5037425
• Windows Server 2016: KB5037423
• Windows Server 2012 R2: KB5037426

As of March 25, 2024, all affected versions have been addressed via the updates above.

If you have a personal account with Microsoft and turn off passwordless authentication in your account but enable two factor with the Microsoft Authenticator, it turns on passwordless authentication in the app for you and you can’t disable it. (Queue up the MFA fatigue).

The way to fix this is to setup another authenticator that’s not the Microsoft one. Save your sanity and stop being MFA bombed by threat actors trying to break into your accounts.

Do better Microsoft, do better.

On the Cluster-Aware Updating Dialog Box, click “Configure Cluster Self-Updating Options” on the right-hand side.

Click “Next” when the wizard opens

On the next screen, make sure you go pre-stage a computer object and put that info here.
Note: After creating the new computer object, do the following:
1. Edit the Security Properties of that computer object and give the cluster computer object FULL CONTROL of the new computer object you just created.
2. Protect the new computer object from accidental deletion
3. Disable the newly created computer object

Choose the schedule

Review Advanced Options

Leave defaults on the next screen

Review before clicking Apply:

Wait for the Cluster Role to complete

Successfully configured!

I’m currently registered for INE’s CTF: https://showcase.ine.com/ctf/challenge/OSxnj173uiDJ1FgMiGkU

I’m also registered for picoCTF which just opened today: https://picoctf.org/