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:
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:
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!
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:
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:
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:
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.
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.
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 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):
My working ShareFile Single sign-on / SAML 2.0 Configuration with AD FS 2.0 looks like this:
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)
ADFS v2 does not support WS-Federation POST sign-in, only GET.
HTTP Error 401. The requested resource requires user authentication
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.
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
Http/1.1 Internal Server Error 43531
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:
cd /tmp
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.
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
