Managed Service Accounts Archives - blog - Alexander Ollischer | Citrix

Just recently I happened to face a pretty annoying issue, that took me a couple of hours to solve. And by the end it was quite simple and obvious actually.

Long story short – newly implemented AD FS 4.0 farm, properly configured and already working. No funny claims rules, no additional authentication factors enforced, still login was working only for a couple of accounts with no obvious similarities or discrepancies. All users were created equal.

Testing was done by navigating to https://sts.domain.com/adfs/ls/idpinitiatedSignon.aspx and logging in with valid user credentials. For some users it worked and for others… well it did not. They were just thrown back to the login mask, no error message or anything.

Please note that the aforementioned endpoint is by default disabled in Windows Server 2016 ADFS 4.0. You have to enable it first by running:

Set-AdfsProperties -EnableIdPInitiatedSignonPage $true

Troubleshooting was quite a chore as no events were triggered and or logged in any of the available Event Logs or log/tracing files. When using bogus login credentials on purpose, e.g. wrong username or password, I received corresponding error messages of invalid username or password.

I use a managed service account (gMSA) for the ADFS service, as this is best practice and recommend by Microsoft.

As stated by Vasil Michev in his blog post (and answer to my problem):

Turns out, the service account was missing the required permissions. Simply giving the account Read access to the user account in question resolved the issue – the user was now able to properly use AD FS. As it turns out, the root cause was that the for whatever reason, the access entry for “Authenticated Users” was removed from the “Pre-Windows 2000 Compatible Access” group in the affected environments.
and
In addition, a very similar issue might occur if the application in question is not able to read the tokenGroupsGlobalAndUniversal attribute. To solve this, make sure that the service account is a member of the “Windows Authorization Access Group”.

Furthermore as stated by Aaron.H in the corresponding Microsoft Forums thread:

I discovered that the Pre-Windows 2000 Compatible Access group in my production domain did not have Authenticated Users as a member like the new lab domain did. Once I added Authenticated Users to the Pre-Windows 2000 group, I was able to authenticate using regular domain accounts to ADFS.

Another reply states:

I just added the service account (which was created manually rather than a managed service account) for adfs to the Pre-Windows 2000 group and that resolved my issue, so you don't have to add the Authenticated Users group if you don't want to.

And a final statement on this issue:

Don't know if you guys solved it by now but i wanted to let you know the Pre-windows 2000 Group membership didn't work for me. However when i added the ADFS group managed service account to the ' Windows Authorization Access Group' it worked instantly. According to the description of this group ('Members of this group have access to the computed tokenGroupsGlobalAndUniversal attribute on User objects') this is expected behaviour.

There are a lot of reasons why correct permissions are not being assigned throughout the domain. The adminCount attribute, disabling inheritance, et al. So thanks to all guys involved in this issue and for clarifying things!

Further reading

While running the Active Directory Federation Services Configuration Wizard for the first time on a newly installed Windows Server 2016, I ran into the following error after deciding to create the first federation server in a federation server farm, and creating a Group Managed Service Account (gMSA) as Service Account for my ADFS implementation:

The specified service account 'CN=svc-ADFS-gMSA' did not exist. Attempt to create the group Managed Service Account failed. Error: There is no such object on the server.

During troubleshooting it turned out that the underlying issue actually lay far deeper than expected...

At first all prerequisites checks passed successfully:

Prior to running the Configuration Wizard I succesfully created the Key Distribution Services KDS Root Key for the gMSA by executing:

Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)

What did I miss? Well, silly me, I simply did not provision the gMSA prior to running the Configuration Wizard, though the Configuration Wizard states, that it will create a gMSA if it does not already exist:

So, how do I successfully create a corresponding gMSA in order to make it work with AD FS?

You can provision a gMSA using the New-ADServiceAccount cmdlet, where domain.com ist the your own TLD:

New-ADServiceAccount -Name svc-ADFS-gMSA -DNSHostName sts.domain.com -KerberosEncryptionType RC4, AES128, AES256 -PrincipalsAllowedToRetrieveManagedPassword serv-adfs$ -ServicePrincipalNames http/sts.domain.com/domain.com, http/sts.domain.com/domain, http/sts/domaim.com, http/sts/domain -Path "CN=Users,DC=DOMAIN,DC=local"

Verify whether the gMSA has been successfully provisioned in the corresponding OU provided with the -Path parameter:

Verify whether all required Service Principal Names (SPN) have been registered and associated with the newly provisioned gMSA by executing the following command:

setspn /l svc-ADFS-gMSA

After running the Configuration Wizard again it still fails with an error stating:

The system cannot find the file specified

Doing a Little Research resulted in "the GMSA was moved from the Managed Service Accounts container in Active Directory" and "make sure you have a Managed service account group object in ADUC. (not an OU)". Checking my Active Directory I realized that the required container Managed Service Accounts is actually missing! And I was unable to identify the reason why it was missing in the first place. Looking into my Deleted Objects container came up … empty.

So, how do I successfully re-create a corresponding Managed Service Accounts container in order to make it work with AD FS?

Further researching revealed I had to re-create a corresponding container with ADSIEdit named "Managed Service Accounts" and ensure ist security properties are correctly set to "Enable Inheritance".

Then I deleted my previously provisioned gMSA:

After that I ran the AD FS Configuration Wizard again and it was completed successfully:

Checking the AD FS Service as well as the corresponding Event Log showed that all went well:

Tag: Managed Service Accounts

Windows Server 2016 ADFS v4.0 – Certain (non-admin) Users Cannot Login – no error, just plain login mask

Windows Server 2016 ADFS v4.0 – The specified service account ‘CN=svc-ADFS-gMSA’ did not exist. Attempt to create the group Managed Service Account failed. Error: There is no such object on the server.