Skip to content

After upgrading the MFA component on our ADFS server it stopped working. Further investigation showed the following event ID error:

Encountered error during federation passive request.

Additional Data

Protocol Name:

Relying Party:

Exception details:
Microsoft.IdentityServer.Web.NoValidStrongAuthenticationMethodException: No strong authentication method found for the request from
at Microsoft.IdentityServer.Web.Authentication.AuthenticationPolicyEvaluator.EvaluatePolicy(Boolean& isLastStage, AuthenticationStage& currentStage, Boolean& strongAuthRequried)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.GetAuthMethodsFromAuthPolicyRules(PassiveProtocolHandler protocolHandler, ProtocolContext protocolContext)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.GetAuthenticationMethods(PassiveProtocolHandler protocolHandler, ProtocolContext protocolContext)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)

Event ID 364, Source: AD FS, Log Name: AD FS\Admin

The upgrade inadvertently disabled the Multi-factor Authentication Method in ADFS:

In order to make it work again I had to enable the aforementioned MFA component in ADFS Management | Authentication Methods | Multi-factor Authentication Methos even though it may not be actively used:

After that everything went back to normal.

Further reading:

If the emails remain on the Exchange server and cannot be forwarded to the smarthost for sending, it may be because the certificate bound to the corresponding connector no longer exists or has been expired. Of course, it is also possible that the expected subject alternate name (SAN) is missing or incorrect. In that case you may receive an error stating:

454 4.7.5 The certificate specified in TlsCertificateName of the SendConnector could not be found

You can verify whether you have such an issue by checking the mail queue:


In case you have a lot of mails stuck in one of your mail queues you can further investigate the affected queue by running:

Get-Queue <queue name>

e.g. Get-Queue "SERV-MAIL\3" | fl

Having a look at the LastError property reveals the aforementioned error.

In my case the outbound Office 365 Send Connector was involved. In order to fix this I had to issue the following commands:

$TLSCert = Get-ExchangeCertificate -Thumbprint <thumbprint of valid certificate>
$TLSCertName = “$($TLSCert.Issuer)$($TLSCert.Subject)”
Get-SendConnector -identity “<send connector name>” | Set-SendConnector -TlsCertificateName $TLSCertName
Restart-Service MSExchangeTransport

You have to replace the thumbprint accordingly, i.e. matching your own certificate's thumbprint.

Run Get-ExchangeCertificate cmdlet

The procedure would be the same for all other Send Connectors or Receive Connectors.

By the time you go back to Queue viewer the queues should have started to empty.

Further reading:

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 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.


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

Another Exchange 2016 migration, another error while trying to migrate custom Receiver Connectors from Exchange 2010 to 2016 ...  an analysis.

...continue reading "Exchange 2016 – Migration of existing, custom Receive Connectors from Exchange 2010 to 2016 results in multiple errors"

Citrix XenDesktop 7.x - Citrix Session Printers are not visible via Control Panel, Devices And Printers

Affected System: Windows Server 2012 R2 as well as Windows Server 2016

Citrix Environment: XenDesktop 7.15 LTSR CU2

...continue reading "Citrix XenDesktop 7.x – Citrix Session Printers are not visible via Control Panel, Devices And Printers"

Just recently I ran into an error during initial setup of Exchange 2016 on a newly installed Windows Server 2012 R2 stating: "Service 'MpsSvc' failed to reach status 'Running' on this server". Further down the troubleshooting road I found out that this quite common error of not being able to start the Windows Firewall service is not Exchange Server specific.

...continue reading "Exchange 2016 – Setup fails with error “Service ‘MpsSvc’ failed to reach status ‘Running’ on this server”"

As I did quite some Exchange migrations (including single as well as multi tenancy environments) I was always wondering whether there are any additional post migration tasks that need to be addressed before you start removing your legacy Exchange server(s) from your organization. For instance, as with migrating from Exchange 2003 to, say, Exchange 2010 you had to update Global Address Lists, Address Lists, Offline Address Books, et al to the new Exchange 2010 version by executing the corresponding cmdlts, e.g. Move-OfflineAddressBook. Now when migrating from Exchange 2010 to Exchange 2016 (or even just from Exchange 2013 to Exchange 2016 with both having an almost identical architecture) what remains of those post migration tasks? Which ones are a necessity? What kind of architectural changes require you to think different and adjust certain settings prior to removing your legacy Exchange server(s)?

By talking about post migration tasks, what do I mean? Well, after you've successfully migrated all your databases, mailboxes, public folders, send/receive connectors, et al, what's still left? Maybe the not so obvious parts of your Exchange infrastructure that need addressing as well in order to avoid any unwanted behaviors and/or errors after you removed the last legacy Exchange server from your organization.

...continue reading "Exchange 2016 Migration – Finishing Touches – Post Migration Tasks"

If you want to use your NetScaler for all things that need to be accessible from the outside, over a single IP address, that poses an issue. As is usually a problem with small to medium sized businesses which only have one public IP address at their disposal, and need to implement features like a fully functional RDS environment (with RD Web Access, RD Gateway, etc), a XenApp/XenDesktop evnironment with StoreFront, and even AD FS, say, for Office365. Generally all these services require port 443 (https) to be fully functional, and you can only set up one distinctive IP address on your NetScaler providing this service, pointing it to your internal resources via Firewall rules, thus leaving you with only one option: NetScaler's Unified Gateway and Content Switching features. 

...continue reading "Citrix NetScaler v11 – How to setup your NetScaler as an RDS RD Gateway"

After logging into Exchange 2016's ECP you receive an HTTP Error 500 (same goes with OWA):


Searching the internet ends up with several possible solutions to this issue, ranging from missing System Attendant Mailboxes, to bogus ADSI settings regarding the Exchange CAS Service. I tried several of them to no prevail.

...continue reading "Exchange 2016 – HTTP Error 500 after logging into ECP/OWA"


I had quite some trouble installing and configuring AD FS 3.0 on a Windows Server 2012 R2 with a SQL Server 2005 Standard Edition server to store my Configuration DB in. Therefore I wanted to share that information, hoping it might be useful to others as well.

  1. Prerequisites
  2. Install IIS Role
  3. Configure IIS Default Web Site Binding (Port 443)
  4. Install AD FS Role
  5. Configure AD FS Role
  6. Verify AD FS Role functionality
  7. Troubleshooting AD FS Role

...continue reading "HowTo – Install and Configure Microsoft Active Directory Federation Services 3.0 (ADFS 3.0)"