Citrix Federated Authentication Services and the magical Primary Refresh Token (PRT) – How to get it? What are possible workarounds?

Reading Time: 4 minutes

This is a question which I am getting asked from customers very frequently and I thought its a good idea to share some views on this topic. If you have found this blog post, I expect you already know what the Primary Refresh Token is and looking for an advice to get that bloody thing working. Over the last two years I have been in a lot of nightly discussions with my fellow CTP colleague Julian Jakob regarding this topic and this is basically the output of our bundled awareness on the matter.

For the people who are unfamiliar what the Primary Refresh Token is: It is a token which represents the users authentication state to Entra ID (Azure AD). This means the Primary Refresh Token is being used to enable single-sign-on and reduce the frequency of password prompts. The PRT is obtained during the initial authentication and can be used to obtain new access tokens without requiring the user to re-enter their credentials. When working with Conditional Access and your goal is to detect if the device is joined the Entra ID tenant before accessing applications this will require the Primary Refresh Token as well.

I do not want to ruin your day but to make it short: It is almost impossible to get a Primary Refresh Token when working with Citrix Federated Authentication Service! It doesn’t matter if the Virtual Desktop Agent is Hybrid-Joined and the Identity Provider is Entra ID or Microsoft Active Directory Federation Services.

If you can not live without the Primary Refresh Token, you need to think about an alternative way to receive the Primary Refresh Token during the windows authentication process. There are some ways on how to achieve this and that’s exactly the purpose of this post.

Method 1 – Microsoft Entra Certificate-Based Authentication (CBA)

You need to make the switch and use x.509 certificates to authenticate against Microsoft Entra ID. In case you have external partners and contractors accessing your environment, this will become a huge challenge and will probably be impossible to handle. If all of the endpoints are centrally managed by the IT department (without any exemptions!) it may be a possible solution. Julian Jakob shared some insights on the configuration – Citrix FAS – Azure AD CBA with Primary Refresh Token (PRT) (julianjakob.com) This is the only scenario you will receive a Primary Refresh Token with Citrix Federated Authentication Services.

Method 2 – Microsoft Active Directory Federation Services (ADFS)

Active Directory Federation Services uses Windows Integrated Authentication (WIA) by default for any application that uses a web browser for its authentication process (intranet access). This means you can use Citrix Federated Authentication Services in combination with Microsoft Active Directory Federation Services to leverage a single-sign experience for the users. In addition this allows the use of Multi-Factor Authentication and more granular handling of authentication requests (Access Control Policies). Please note something important: You still will not receive a Primary Refresh Token with this scenario.

Method 3 – Working with Trusted Locations (Conditional Access)

Lets assume the Identity and Access Management team tries to enforce the use of Entra ID (Azure AD) joined devices for accessing enterprise resources. As we do not have a primary refresh token, the access to secured resources will fail. It would be possible from a Conditional Access viewpoint to work with “Trusted Locations” and start specifying/allowing the public IP range(s) which the Virtual Desktop Agents are using for their outbound internet connection. This still would not make single-sign-on possible but the users would at least able to use applications after a successful authentication. Depending on the security configuration this could mean that users are forced to do Multi-Factor-Authentication again or exclude Multi-Factor Authentication for Trusted Locations on the VDA.

Method 4 – Citrix NetScaler with nFactor Authentication

Finally some NetScaler Love ♥ With the nFactor framework we are able to use Entra ID (Azure AD) to benefit from Multi-Factor Authentication and Conditional Access. In addition we will get a primary refresh token. Wait what?! Yes it really works but this has nothing to do with Citrix Federated Authentication Services anymore. From a high level perspective it is working the following way: The user is still accessing the NetScaler Gateway which is configured as a SAML SP and redirects to Entra ID (First Factor). After the successful SAML authentication, we configure a Second Factor with nFactor on the NetScaler and prompt the user to enter her/his password. With the collected information (UserPrincipalName from the SAML Assertion) and the password we are able to do a traditional user authentication which will result in a primary refresh token during the windows logon process. Its not the most seamless login for the end-users but HEY at least it doesn’t require a complex Citrix Federated Authentication infrastructure. . You even could push this further with enabling passwordless sign-in with authentication strengths policies (Microsoft Authenticator Phone Sign-In) and only ask for the password exactly once on the NetScaler side.

Update – 5th February 2024: In the meantime Julian Jakob has published a dedicated blog article on the NetScaler nFactor method, which goes more in to detail on how to do the configuration – NetScaler – How to get rid of SSO / missing PRT Issues using Entra ID Phone Sign-in (julianjakob.com)

Method 5 – Azure NPS Extension

With the Azure NPS Extension it possible to use Microsoft Entra Multi-Factor Authentication without changing the authentication method to SAML or OIDC. The Azure NPS extension will be configured on a Windows Server with the Network Policy Server (NPS) role installed and trusted with the customer Entra ID (Azure AD) tenant. Afterwards the Citrix NetScaler will be configured as a traditional RADIUS client and the primary refresh token will be available for the user session on the Virtual Desktop Agent (Hybrid-Joined). The downside of this method is that the NPS Extension is lacking some features compared to Citrix Federated Authentication Services. Please see the tables below.

Azure NPS

Pro	Contra
Easier integration	Doesn’t allow password changes
Primary Refresh Token is created	Users can only have one active token type (preferred) (Needs to be changed on ‘aka.ms/mfasetup’)
	No Conditional Access
	Needs Microsoft Entra ID P1/P2 license
	Token enrolment (onboarding) is not seamless User needs to go to ‘aka.ms/mfasetup’ first.

Federated Authentication Services

Pro	Contra
Allows password changes	Complex Integration
Allows Single-Sign-On to Citrix Resources	Needs Public Key Infrastructure (PKI)
Allows Conditional Access (Limited)	No Primary Refresh Token is created (for most cases)
Self-Service Enrollment for MFA Token

That’s all for the moment. If you have any thoughts on this please use the comment section bellow 💡

Photo by Jose Fontano on Unsplash