In this post we will be going over a new account type that has been release in Windows Server 2025. This account is similar to a gMSA which we covered using for scheduled task in a previous post.

dMSAs and gMSAs are two types of managed service accounts that are used to run services and applications in Windows Server. A dMSA is managed by an administrator and is used to run a service or application on a specific server. A gMSA is managed by AD and is used to run a service or application on multiple servers. Both offer improved security and simplified password management.

dMSA allows migration from a standard service account to a machine account with managed and fully randomized keys. Authentication for dMSA is linked to the device identity, which means that only specified machine objects mapped in Active Directory (AD) can access the account.

There are some pre request required before using a dMSA

• Only currently supported on Windows Server 2025
• Required at least domain controller running Windows Server 2025
• Have created a KDS root key

To check if there is a KDS root key run

Get-KdsRootKey

If there is no KDS root key we can create one using the below command. It takes 10 hours before activating.

Add-KdsRootKey -EffectiveImmediately

Once the pre-req are confirmed, the next step is going to be adding a registry value for any server that will be using a dMSA.

This can be set either in manually, group policy, or PowerShell. Below is the registry details.

Next we need to Enabled Delegated managed services. This can be done locally on the servers or using groups policy.

The policy setting to enable is below.

Computer Configuration\Administrative Templates\System\Kerberos\Enable Delegated Managed Service Account logons

To create the service account we can use PowerShell. (The DNS is required by the command but not needed for running services)

New-ADServiceAccount -Name Accountname -DNSHostName Accountname.domain.local -CreateDelegatedServiceAccount:$true -KerberosEncryptionType AES256

Next we need to grant permission for the device to retrieve the password for the account.

Set-ADServiceAccount -Identity Accountname -PrincipalsAllowedToRetrieveManagedPassword DeviceName$

Next we need to set the msDS-DelegatedMSAState, view the current value use

Get-ADServiceAccount -Identity Accountname -Properties "msDS-DelegatedMSAState"

We need to change this value to 3.

Now we are ready to use the dMSA. Select the service that the account is to be used on, in my case its SQL Server (Leave the password blank).

Restart the service and it should now be running using the dMSA account.

We can enabled Kerberos Event Logging to view events.

Open eventvwr and under Applications and Services Logs > Microsoft > Windows > Kerberos/Operational

This has been a quick overview of setting up dMSA account. Below link is some of the common question on using dMSAs.

https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/delegated-managed-service-accounts/delegated-managed-service-accounts-faq

Active Directory usually has a single password policy that is applied to all users. This is will typically be in the default domain policy unless a new group policy is created. 

There are certain scenario where we might want to have a different password policy, Admin users, testing password resets, service accounts…

With fine grained password policies, we can target either specific users or groups and assign them a specific password policy.

In this post we will be going through creating and assigning a fine grained password policy.

To start we need to open ADAC (Active Directory Administrative Center.

Next we need to add the node to view the password settings container. Select Managed and Add Navigation Nodes.

Select the required domain > System > Password Settings Container and add, the name can be customized I just used Password Settings Container.

To create the policy select the password node, right click, select new and Password Settings.

The below table shows each setting with a short description of each.

Set the required setting values. I would recommend assigned to a test group first to confirm all setting work as expected before applying to standard users .

Click ok and policy should now show.

To view if the password policy is applied select a users, right click and select view resultant password settings.

If the user doesn’t have policy applied you will receive a warning.

We can also create a password policy using PowerShell, this can be usefully if you need to script multiple policy.

We can use the below to create the policy I used PowerShell splatting to make the command shorter and easier to read.

$PassPolicy = @{

Name = "Name"
ComplexityEnabled = $true
LockoutDuration = "00:30:00"
LockoutObservationWindow = "00:30:00"
LockoutThreshold = "0"
MaxPasswordAge = "360.00:00:00"
MinPasswordAge = "1.00:00:00"
MinPasswordLength = "7"
PasswordHistoryCount = "24"
Precedence = "12"
ProtectedFromAccidentalDeletion = $true
}

New-ADFineGrainedPasswordPolicy @PassPolicy

Next we can run the below command to return the password policies.

Get-ADFineGrainedPasswordPolicy -Filter * | Select-Object Name

Last step is to apply the policy to either the user or group.

Add-ADFineGrainedPasswordPolicySubject Password_Policy_Name  -Subjects Group

Setting up a fine-grained password policy in Microsoft Active Directory is great way to enhance security by applying custom password and account lockout settings to specific user or groups.

After implementing the policy, it’s important to monitor and review its impact. Reviewing these settings over time can help maintain a balance between strong security and user convenience.

This is a quick post to go through an issue I ran in to when applying the Active Directory (AD) domain re-use policy. I have a post on setting up the domain re-use policy.

Even though the policy was configured and the user I was attempting to re-join the computer to AD I was still getting the domain error

Account exists and re-use is blocked by policy.

When looking through the netsetup logs under C:\Windows\debug, I was getting the following error.

Active Directory Policy check with SAM_DOMAIN_JOIN_POLICY_LEVEL_V2 returned NetStatus:0x5.

This issue was caused by having the following security option policy set Network access: Restrict clients allowed to make remote calls to SAM

This policy is recommend to improve security in AD, but by default it will only allow members of the administrators group in AD connect remotely to the Security Accounts Manager (SAM) database.

To fix the issue I added the same group used for domain joins to the policy to allow the domain re-join accounts to also be able to make remote calls to SAM.

Once the policy is updated on all DC’s the domain join should now work correctly.

In this post we will be going through setting up a authentication policies / authentication policy silos.

Microsoft Active Directory (AD) Authentication Policies and Authentication Policy Silos are security features designed to enhance authentication processes and protect sensitive accounts in an Active Directory environment.

• Authentication Policies provide granular control over authentication methods and restrictions, ensuring that only authorized users and devices can access resources.
• Authentication Policy Silos, allow administrators to group sensitive accounts and applying specific authentication policies to these groups to mitigate the security risk.

With these policies set it will help with protecting from unauthorized access and reducing the potential impact of security breaches.

https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/authentication-policies-and-authentication-policy-silos

First to allow the use of these policies we need to enabled the KDC support for claims, compound authentication, and Kerberos armoring on all domain controllers.

The policy setting is under

Computer Configuration > Administrative Templates > System > KDC

This needs to be set to enabled and supported.

We also need to enabled the Kerberos client support for claims, compound authentication, and Kerberos armoring on clients.

The policy setting is under

Computer Configuration > Administrative Templates > System > Kerberos

We can either apply individually or at the root level of the domain. I applied at the root level of the domain and apply the KDC policy directly on the domain controller OU.

The clients and DC’s will require a reboot for the policy to apply.

Authentication policy and policy silos are configured using Active Directory Administrative center (ADAC).

The polices containers are located under Authentication.

Authentication policies control the following:

• The ticket granting ticket (TGT) lifetime for the account, which is set to be non-renewable.
• The criteria that device accounts need to meet to sign in with a password or a certificate.
• The criteria that users and devices need to meet to authenticate to run services as a specific account.

First step is we need to create a new authentication policy.

Set a policy name, protect from accidental deletion and if the policy is in audit or enforced mode. In production in would use audit and review the event logs to confirm the restrictions work as expect before setting to enforce.

Next we need to set what the policy will be applied against. These can be

• User Accounts
• Service accounts
• Computer accounts

In this example we will be using users sign on policy to reduce the ticket granting ticket lifetime (TGT) time to 90 minutes.

Next we will configure the Authentication Policy Silos,

Give the Silo a

• Name
• Set to audit or enforce
• Add the permitted accounts
• Set the authentication policy

Next we need to set the silo policy on the accounts. This can be done by selecting the accounts from ADAC and going to silo.

Then select the required silo policy to apply.

We can checked the msDS-AssignedAuthNPolicySilo & msDS-AuthNPolicySiloMembersBL attributes on the accounts that have the silo applied to confirm.

Last step is to go back to the authentication policy and update the user sign on condition.

Set to AuthenticationSilo, equals and set the silo name to the one we created.

The DC may also need to have the kerbros ticket purged before the policies will apply this can be done by using klist purge

Now when we try to logon to the server in the silo it should be allowed. We can also use whoami /claims to see if the claims is applied.

If we try logon to another devices with the same account outside of the silo we should be blocked.

To troubleshoot or audit, we can enabled Audit user / device claims using group policy. The policy is setting is under Policies > Windows Settings > Security Settings > Advanced Auditing Policy Configuration > Logon/Logoff

We can check under the security logs on the DC for Eventid 4626

We can also enabled Authentication policy failures and success, this will need to be done on all DC’s. The logs are under
Microsoft > Windows >Authentication/AuthenticationPolicyFailures-DomainController

This will then log the accounts that are failing to be issue a TGT.

This has been a quick overview of creating an authentication silo, setting this up can be a bit tricky.

I did have issue getting the policy silo to work due to existing TGT but once configured it can really help with locking down access to tier 0 devices.

During a recent hardware refresh we have been running in to issue with domain rejoins, this happens for all users even the owner and domain admins.

During the build process we use a service account with delegated permission on the specific OU to do the domain join step.

If there was any issue or we need to re-join the device to AD we where getting the below error.

An account with the same name exists in Active Directory. Re-using the account was blocked by security policy.

This issue is from a update that was applied by Microsoft last year to harden domain joins.

https://support.microsoft.com/en-us/topic/kb5020276-netjoin-domain-join-hardening-changes-2b65a0f3-1f4c-42ef-ac0f-1caaf421baf8

This change isn’t suppose to effect users who are members of any of the below groups as they are exempt from the ownership check

• Administrators
• Enterprise Administrators
• Built-in Administrators groups

but we found that this was not the case as even with a domain admin I couldn’t rejoin. To view the domain join log go to C:\Windows\debug\NetSetup.LOG.

There is a registry workaround that can be applied but this is due to be removed in August 2024 so we wont go over that here.

To fix this issue Microsoft now recommend using a new GPO setting, we have to apply the specific policy setting to all domain controllers to set what accounts can re-join the devices to the domain.

We can set this to be either a single users or a security group but its recommend to use a group. This group should have as few users a possible this is to reduce the risk the hardening was introduced for.

To make the GPO setting available we need to install the September 12, 2023 or later updates on all member computers and domain controllers. 

First we will create a new security group

Next we can add the specific user or users to the group.

Next we can either create or re-use an existing policy, I will be creating new policy

Give the policy a name.

Next edit the policy and go to  Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options, double-click Domain controller: Allow computer account re-use during domain join.

If the policy is missing it most likely that the pre-req update has been installed yet.

Select the policy setting and click edit, add users or groups of trusted computer account creators and owners to the Allow permission.

Do not add the user account that performs the domain join.

Apply the new policy to the domain controllers OU.

Then run gpudpate /force on each DC or wait for about 15 minutes for the policy to apply.

To confirm if the setting is applied we can check the below registry value.

Once confirmed the setting is on the Domain Controllers,

Next we tried to re-join to the domain again with a domain admin account and now the join is successful.

and if we check the log we can now see the attempt was permitted.

Now that domain admins are able to re-join I wanted to test the lower privileged account in the re-join group we created earlier.

This was also successful.

Last test was to try an account that wasn’t part of the re-join group and confirm it would be blocked from re-joining which it was.

I have tested this on a Windows 10, Windows Server 2019 & 2022 without issue.

I have run in to issues on Windows 11 as it doesn’t seem to honor the policy setting not sure why might be a bug.

The only way I was able to get Windows 11 to re-join was to use the legacy reg value workaround and then delete after re-joining to AD.

Using the group policy is a easier method than having to use the registry value and hopefully Windows 11 will be fixed in a later update.