So you got your SAML Authentication server all configured. You got your MFA rolling. You start your day. You open up another app that has an assigned enterprise application to it with conditional access set. Then you open up your Citrix tab. You go to the site. It redirects you. And BOOM. Just like that. ERROR!!!
You think think think and think about why you are getting the error. You know when you opened Citrix FIRST yesterday the world was all sunny and bright. But today, that is not the case. But you really read the error closely. And you notice something… Authentication method ‘Password.’ You know that when you opened Citrix yesterday with your password and MFA, then continued on, it all worked. But change the order, and it does not. So. You go and check your SAML authentication settings.
You’ll see that by default, the “Password” class type is selected when you create the SAML authentication server. If you click on it so it is no longer blue, then save it, you notice that everything seems to work. So anything that is set there is EXPECTED in the assertion, not what is ACCEPTED. This would happen more if you have conditional access to not prompt on prem for one app, and prompt always on the other enterprise app. If you clear that, it will allow you to use the SAML assertion you got from the other app, assuming it is with the same IDP. There is also another option that you see outlined. “Force Authentication.” This option, if set, will force the session you start to redo the authentication and not use anything that you have cached. This is also good for testing purposes to force it to go through the authentication process.
Ran into some fun with setting up FAS for MFA. I was testing a shorter list of ciphers on a test SSL profile on ADC on the test vServer. Come to find out, when accessing a machine that was using MFA from outside the network, I was getting an SSL error 4 on Windows machines and SSL error 47 on Stratodesk machines. I hadn’t seen that error since Receiver 4.x. It appears there are some additional ciphers needed in regards to the Citrix Workspace App. It appeared to work fine with the other cipher set using the HTML5 Workspace App. This article has the updated cipher set you need to have or it may cause you some issues (Changes To FAS Ciphers). These would be applied to your SSL profile assigned to the vServer on the ADC.
Ciphers needed in the SSL profile that are in link above
I also ran into an issue with EndGame.
When trying to connect from to VDI Windows 10 machines, you would encounter an incorrect user name or password error if EndGame was enabled, instead of it SSO logging you in.
Checking the event log on the machine, you encounter a Smart Card Logon Event 5.
There are 2 DLLs you have to add to a global exclusion, scardhook.dll and scardhook64.dll. These are located under C:\Program Files\Citrix\ICAService. Just excluding those DLLs got rid of the Event 5 Smart Card Logon error and allowed the Provider DLL to initialize.
After getting these exclusions applied, SSO works normally for accessing the VDI machines.
This configuration covers setting up EULA as a first factor in an nFactor flow to do one side of an MFA configuration. This will setup a group extraction that looks for an assigned Universal group that is designated to trigger directing traffic to an MFA provider. The reason for using a Universal group would be in an instance where you have a forest with multiple subdomains that have a two-way transitive trust. This allows you to manage group membership from one domain as the Universal group will be replicated to all the domain controllers. This example is to check membership of the Universal group and perform cascading LDAP for the users that are NOT members of that Universal group.
So I was trying to move to advanced authentication in a test environment. While I was doing that, I thought to myself that since my end goal with that test, would be to prep to move to MFA. That led to me thinking how I would want to implement that. Then…… I ran into a very interesting thing when you move from using basic authentication to an authentication profile with AAA-TM, that the EULA option goes bye bye. There isn’t even an option to select. So I went looking how to resolve that. One option was to follow a guide that I found to edit some xml files, but that meant that I would have to manually copy these to keep them in sync between the Citrix ADCs. I didn’t like that idea but did see the option to use EULA as a first factor in nFactor. Hmm… I was already thinking in that mode to setup nFactor since it would be needed to go down the MFA road. So that is the decision I decided to work on and get testing. I also found some interesting tidbits that I’ll point out in the configuration.
Update: Changed LDAPS policy settings to fix “Anonymous” issue.
Update: Added link to article to create custom XML file to change ${http.req.user.name} to ${AAA.USER.NAME}
So here we go!
You will need to have either Advanced or Premium license to have access to this feature. You will also need to have configured an Authentication Virtual Server which I will link soon.
In the “Authentication Schema” box, select the “Edit” pencil.
Click on the “LoginSchema.” This will bring up a list to choose from.
Scroll down and select “Eula.xml.”
Click the “Edit” button if you want to edit the EULA message.
After you change the EULA message below and click “Save,” click the “Select” button. This is VERY important or it won’t select it.
After you have configured the message, click “Save.”
Click “Create” button.
Click “OK.”
Click on “Add Policy.”
Click the “Add” button.
Name the policy and select “Action” as “NO_AUTHN.”
For the “Expression,” enter “HHTP.REQ.URL.CONTAINS(“/nf/auth/doAuthentication.do”)
Click “OK.”
Click “+” sign beside “NO_Authn_Pol” (whatever you name the Authentication Policy).
Select “Create Factor.” This factor will do the group extraction to test group access.
Name “Factor Name.” (Grp_Ext_Test in this example)
Select “Add Schema.”
Select “Only_User_Name.” This will have the user enter their user name to be evaluated.
Click “OK.”
Click “Add Policy.”
Click “Add.”
Enter “Name” for policy (test-ldap-grpexpt-pol in this example).
Select “Action Type” as “LDAP.”
For the “Expression” enter “true.”
Click “Add” on “Action.”
Select the root of the forest (domain if you only have 1 domain) for the “Server Name.” (The DC that you are trying to access will need to have the Global Catalog available for this to work correctly)
For the “Port,” choose either 3268 for unsecure LDAP or 3269 for secure LDAP (This will require that you upload the root certificate for the organization to utilize).
Make sure the UNCHECK the box for Authentication. This is just going to do a lookup if the user is part of the MFA group.
Enter your “Base DN” as where the users will be or the root of the forest / domain.
Enter “Administrator Bind DN” which is the account that will authenticate to the domain.
Enter and confirm “Administrator Password.”
Click “Test Network connectivity” to make sure that it is working correctly.
Complete “Server Logon Name Attribute” as “sAMAccountName.” The samaccountnames need to be unique in the forest or you will have issues with this global catalog lookup.
For “Group Attribute” select “memberOf.”
For “Sub Attribute Name” select “cn.”
Click the “+” sign beside “test-ldap-grpext-pol.”
Select “Create decision block” and enter “Decision block Name.” (Grp_Eval_Test in this example)
Click “Create.”
Click “Add Policy.”
Click “Add.” (NonMFA_Test in this example)
Select “Action Type” as “N0_AUTHN.”
Select “Action” as “NO_AUTHN.”
In the “Expression” enter “AAA.USER.IS_MEMBEROF(“UniversalGroup”).NOT.” (UniversalGroup is the group name of the MFA testing group)
Click on the “+” sign beside “NonMFA_Test.”
Select “Create Factor.”
Enter “Factor Name.” (LDAPS_Auth_Test in this example)
Click “Create.”
For the “Authentication Schema” click the pencil icon.
This allows you to take what was entered just after click on “Continue” for the EULA and populating that in the User Name / Password dialogue to prevent users from having to enter it twice.
Under the “Login Schema Files” select “PrefilUserFromExpr.xml. (Note that User Name contains $(http.req.user.name).
You can click the “+” sign on the bottom of the box to add additional LDAP/LDAPS policies. This is what you would normally see under the Basic Authentication on the Citrix Gateway.
