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:
Saml

Relying Party:
https://adfs.domain.com/saml/info

Exception details:
Microsoft.IdentityServer.Web.NoValidStrongAuthenticationMethodException: No strong authentication method found for the request from https://adfs.domain.com/saml/info.
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:

https://social.msdn.microsoft.com/Forums/sqlserver/en-US/bce14a02-cc4f-42ee-a5e0-94559b2ca5c8/issues-with-azure-mfa-and-adfs?forum=windowsazureactiveauthentication

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

This short blog describes how to enable NetScaler 11's Content Switching feature to proxy your AD FS infrastructure thus getting rid of a dedicated AD FS Proxy server.

...continue reading "Citrix NetScaler v11 – How to setup your NetScaler as an AD FS proxy"

1

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)"

1

In order to make this work, check out the Prerequisites section, and read my other articles about installing and configuring AD FS prior to setting them up with ShareFile and/or NetScaler. This setup requires multiple steps with functional verification tests in between each step in order to minimize sources of error.

Prerequisites:

  • Public Signed Server Certificate adfs.domain.com
  • Firewall configuration allowing external traffic destined for your internal AD FS server to pass through (https, Port 443)
  • AD FS 2.0 downloadable installer (for Microsoft Windows Server 2008 and 2008 R2)
  • Internet Information Services (IIS) 7 or 7.5 Server Role installed (for Microsoft Windows Server 2008 and 2008 R2)
  • AD FS 3.0 Server Role installed (for Microsoft Windows Server 2012 R2)
  • Internet Information Services (IIS) 8.5 Server Role installed (for Microsoft Windows Server 2012 R2)
  • .NET Framework 3.5 SP1 Feature installed
  • SQL Server 2005 (Express, Standard, Enterprise), SQL Server 2008 (Express, Standard, Enterprise), or Windows Internal Database

Detailed HowTo's for AD FS Installation and Configuration can be found here:

AD FS related errors can be found in the Event Log by expanding the Applications and Services Logs node, and navigating to AD FS 2.0 \ Admin (for Windows Server 2008 and 2008 R2):

adfs_error_logs_01

My working ShareFile Single sign-on / SAML 2.0 Configuration with AD FS 2.0 looks like this:

adfs_working_config_dc2_02

Testing your setup:

  • https://mydomain.sharefile.com/saml/login
  • https://adfs.mydomain.com/adfs/ls
  • https://adfs.mydomain.com/adfs/ls/IdpInitiatedSignOn.aspx

Lessons learned during my configuration

Error Signin ADFS:

adfs_error_signin_03

adfs_error_signin_01 adfs_error_signin_02

Add corresponding ShareFile Subdomain URLs to Relying Party Trusts configuration (in my case I had to add both sharefile.com and sharefile.eu TLDs):

  • Tab: Identifiers
  • Tab: Endpoints

adfs_error_signin_04 adfs_error_signin_05

Error Signin ADFS:

adfs_error_signout_02

Event Log Error, Event ID 364, Source: AD FS 2.0, Error Number: MSIS7000

Have a look at TechNet - Troubleshooting Fedpassive request failures with AD FS 2.0

adfs_41

Encountered error during federation passive request.
Additional Data
Exception details:
Microsoft.IdentityServer.Web.RequestFailedException: MSIS7000: The sign in request is not compliant to the WS-Federation language for web browser clients or the SAML 2.0 protocol WebSSO profile.
at Microsoft.IdentityServer.Web.Dispatchers.UnknownRequestDispatcher.DispatchInternal(PassiveContext context)
at Microsoft.IdentityServer.Web.PassiveProtocolHandler.ProcessRequestInternal(PassiveContext context)
at Microsoft.IdentityServer.Web.PassiveProtocolHandler.ProcessRequest(HttpContext context)

I found something interesting at Windows Identity Foundation 101’s : WS-Federation Passive Requestor Profile (part 1 of 2), when searching for MSIS7000:

ADFS v2 does not support WS-Federation POST sign-in, only GET.

HTTP Error 401. The requested resource requires user authentication

sf_saml_internal_error_401_02

sf_saml_internal_error_401_03

It turned out I had to start the AD FS service with proper credentials. As I had issues with launching the service, I switched it to LOCAL SYSTEM, which in return caused this particular issue. So, first I had to remedy the issue of failed service start by configuring the SPN for the service account, and providing internet access to my AD FS server in order to enable querying if CRL through .NET. Then I adjusted the corresponding Application Pool in IIS on my AD FS server in order to reflect the AD FS service's account. In the end I was able to start the service properly. Afterwards SAML SSO from internal networks worked as well.

Have a look at:

Error Signout ADFS:

adfs_error_signout_02

adfs_error_signout_01 adfs_error_signout_03

Add Logout URL to Relying Party Trusts configuration:

  • Tab: Endpoints
  • Endpoint Tpye: SAML Logout
  • Binding: POST
  • URL: https://adfs.domain.de/adfs/ls/?wa=wsignout1.0

adfs_error_signout_04

adfs_error_signout_05

Now as we have successfully configured a working SSO environment using ShareFile and AD FS, we can go the extra mile and add NetScaler to the equation, of course as a means of security enhancement. As you should never ever expose an ADFS server to the internet, you could use NetScaler as a Proxy. Read more about in my blog article https://blog.ollischer.com/citrix-netscaler-v11-how-to-setup-your-netscaler-as-an-ad-fs-proxy.

Errors:

  • "SAML Assertion verification failed; Please contact your administrator", i.e. incorrect IDP certificate configured on NetScaler

saml_sso_NS_error_01

saml_sso_NS_error_02

  • Http/1.1 Internal Server Error 43531

saml_sso_NS_error_03

Run one of the following commands from the shell prompt of the NS to view the real time hits on the (as per CTX138840)

  • authentication policies and session policies applied on the NS Gateway vServer:

    nsconmsg –d current –g pol_hits

  • rewrite policy bound at a global level or to a load balancing, content switching, or NS Gateway vServer:

    nsconmsg –d current | egrep –i rewrite

  • responder policy bound at a global level or to a load balancing, content switching, or NS Gateway vServer:

    nsconmsg –d current | egrep –i responder

In order to troubleshoot authentication with Aaad.debug (as per CTX114999) run the following command from the shell prompt of the NS:

  1. cd /tmp
  2. cat aaad.debug

Another Event ID 364 error message:

  • MSIS2001: Configuration service URL is not configured.
  • MSIS7012: An error occurred while processing the request. Contact your administrator for details

After checkings the AD FS 2.0 service I discovered that it was not running. When trying to start the service it did not start and subsequent Events 7000 and 70009 were logged in Event Log Viewer. It turned out that the server hosting AD FS 2.0 need internet access or you need to disable generatePublisherEvidence for .NET 3.5. See:

Service Control Manager (SCM) is timing out the service start before it is complete. This is usually due to lack of internet connectivity from the AD FS 2.0 Federation Server or AD FS 2.0 Federation Server Proxy. At service start, when generatePublisherEvidence is enabled for .NET 3.5, the server will attempt to connect to crl.microsoft.com over TCP port 80. AD FS 2.0 does not rely on a positive or negative response from generatePublisherEvidence, and the default value can cause Service Control Manager to time out while waiting on the TCP/80 connection to fail to connect to crl.microsoft.com.

Further reading: