Jump to content
Welcome to our new Citrix community!
  • 0

Configuring Azure for Seamless SSO when using FAS for Citrix - Issues with PRT


David Ashcroft

Question

Hi all, so I've seen multiple articles relating to this here on the discussion forum, and out on the wider internet, but I'm still having issues, so hoping to get a little advice.

 

We're currently in the process of a staged rollout for Cloud Azure Authentication. A reasonable number of our users are already setup as part of this. We have staged rollout switched on for Password Hash Sync and Seamless Single Sign on.

 

On our desktops and laptops, everything seems to work without issues, applications such as OneDrive are signing in automatically, and also our web applications that use Azure for authentication are also signing users in automatically without any issues.

 

Our issues seem to occur in our Citrix environment. We are using FAS to sign the users into the sessions. Our virtual desktops in Citrix are non-persistent, so SSO is even more important for a better user experience.

 

So when a user logs into Citrix, they are signing in automatically to OneDrive and other desktop applications, however web based applications are not performing seamless SSO at all. 

 

I've done a bunch of digging on this, and it appears that the PRT is not being issued as part of the login to the Citrix session. Running a dsregcmd /status via cmd in the Citrix session shows the AzureAdPrt as No, and I believe it should be Yes for Seamless SSO to work correctly. 

 

If I Lock the Citrix session and then unlock it by entering my password, it all works. The PRT appears to come across to the device, and immediately web apps begin to authenticate correctly and automatically. Furthermore, if I sign into a Citrix session directly via VMWare instead of through the usual storefront method, then again, Seamless SSO seems to work correctly. So this to me all points to the use of FAS for signing users in.

 

I've had a look online, and according to one of the Citrix articles (Azure Active Directory single sign-on | Federated Authentication Service (citrix.com)), if you're in a Hybrid Azure AD Joined environment (which we are), then we need to be using Azure AD Certificate based authentication. 

 

Can anyone confirm if there is a workaround for this? And if not, any assistance would be helpful in configuring this. I wasn't involved in our Citrix environment build, I'm just troubleshooting our issues with Seamless SSO. 

 

I've gone ahead and looked at this article:

How to configure Azure AD certificate-based authentication - Azure Active Directory - Microsoft Entra | Microsoft Learn

And I'm failing at step one here! It states in Azure to select the CA file and get a root certificate. Is this something that is part of Citrix, or from a domain controller, or somewhere else? I'm really quite stuck with this. I was hoping for something simple like a GPO or a simple change to make this work, but it appears it may be a little more complex than that.

 

Any advice is much appreciated of course.

 

Thanks in advance ?

Link to comment

14 answers to this question

Recommended Posts

  • 1

 

On 2/27/2023 at 7:43 PM, Jeff Riechers1709152667 said:

Ok, I was able to get it to work.  The big part was running dsregcmd /status and getting the results of the PRT.

 

In my environment I was getting CRL errors.  Even with adding public CRL it wouldn't validate.  I had to turn off CRL checking to even get it to work.

 

https://learn.microsoft.com/en-us/azure/active-directory/authentication/certificate-based-authentication-faq#how-do-i-turn-certificate-revocation-checking-on-or-off-for-a-particular-ca-

I was using IIS to host my CRL, this required me to enable Double Escaping.  Once I did that CRL checking from Azure AD worked.

 

image.thumb.png.276a215d627f899a9f50cd838d5f991f.png

 

I also added the Smart Cart Logon and Client Authentication to the Application Policies of the Smartcard logon.

 

 

 

 

 

Thanks for your help so far on all of this. Certificates are pretty new to me in this regard, it's something I guess I've been fortunate enough to never really have to delve into.

 

So with my test user in the staged rollout for Azure Cloud Auth, I logged into a Citrix session and FAS performed the sign on, and web apps did not auto sign in. The PRT was not showing as part of the dsregcmd /status check. 

 

To try and fix this, I've gone into Azure, turned on Certificate Based Authentication for a test group in which the same test user belongs to. I've connected to my domain controller and exported the root certification by visiting http://localhost/certsrv and downloading the root CA Cert. 
I've gone back into Azure and uploaded the same root CA Cert.

 

image.thumb.png.e9effb2af5b5c720719e75d513d5db84.png

 

With the above setup, if I log back into a new session on Citrix, the PRT token appears, and web apps and the browser signs itself in without any issues.

 

I'll be honest, I have absolutely no idea how this is working, why it's working, or if it's even safe. I only really want this to work as part of Citrix, not for users to be prompted to be able to sign in based on a certificate in other instances. The CA Cert is not exposed externally at all, and we don't really want this to be the case, we only want this to work within Citrix. I'm assuming this works because within the Citrix sessions, it can resolve the CA via our internal DNS and so it works? 

 

Although it works, something just doesn't seem right here so I've turned off certificate authentication after these tests, even for my test user. Just so that I can perhaps get to grips with this a bit more. Any insight on this would again be much appreciated.

 

Thanks.

  • Like 1
Link to comment
  • 1

So if you upload your domain root, and don't add the CRLs you should be good.  Just know that if you revoke a user's FAS smart card it won't be invalid, so you may want to modify those to have a short life, like 12 hours.

 

Since the smartcards are only used internally for Citrix you won't have to worry really about the cert based auth being enabled.  It's just an option, but with the above mentioned shortened life of the certificates you won't run into issues.  You might be able to do some more restrictions on the Azure side.

 

With the new authentication token settings from MS, I am anticipating seeing these configurations more and more.  I created a more in depth setup guide up on my wiki if you want to read more on this.

 

https://www.jeffriechers.com/wiki/azuread-prt-with-fas-certificates/

 

  • Like 1
Link to comment
  • 0

Here is how I have resolved this.

 

1. On your maintenance machine make sure to run a dsregcmd /leave as part of sealing that machine for deployment to your catalogs, needs to be run on every update cycle.

2. Modify the \Microsoft\Windows\Workplace Join\Automatic-Device-Join and add an On Startup Trigger.  Make sure that schedule task is enabled to run.

3. Deploy the updated image to your non-persistent images.

 

With this method the on startup trigger will register the machine in Azure AD, and then the On Log On trigger will setup the PRT. 

 

For some reason both the machine and user connection can't happen at the same, hence the running twice.

Link to comment
  • 0
On 2/20/2023 at 1:44 PM, Jeff Riechers1709152667 said:

Here is how I have resolved this.

 

1. On your maintenance machine make sure to run a dsregcmd /leave as part of sealing that machine for deployment to your catalogs, needs to be run on every update cycle.

2. Modify the \Microsoft\Windows\Workplace Join\Automatic-Device-Join and add an On Startup Trigger.  Make sure that schedule task is enabled to run.

3. Deploy the updated image to your non-persistent images.

 

With this method the on startup trigger will register the machine in Azure AD, and then the On Log On trigger will setup the PRT. 

 

For some reason both the machine and user connection can't happen at the same, hence the running twice.

 

I've tried this. We took our master image and ran the dsregcmd /leave command. We added another trigger to the Automatic Device Join schedule task to run at startup of the system. We then pushed this update to our images, but there appears to be no difference.

 

If I login to a device as a test user, the web applications do not perform a Seamless SSO. If you check the output for dsregcmd /status, you can see the SSO AzureADPRT is set to No still. If we lock the machine and then unlock it, the AzureADPRT is then set to Yes. 

 

This still looks as if it's because of the way FAS passes the creds as part of the logon of the user to the session.

 

Any other suggestions? ?

Link to comment
  • 0

Ok, I am caught up.

 

So it has to be cert based auth enabled in Azure AD.

 

The Root CA they are requesting is for the CA that is generating the FAS smartcards.  So that would be your domain root and any intermediates.

 

https://learn.microsoft.com/en-us/azure/active-directory/authentication/concept-certificate-based-authentication has a long chain of clicking on things to follow, here is the high level.

 

Make sure your Domain Root Cert Authority has web based CRL setup, not OCSP or LDAP

Azure AD->Security-> Certificate Authorities, upload your domain root cert that is building smartcards

Azure AD->Security->Authentication Methods->Certificate-based authentication

 

I will need to mock this up in my lab, but this looks like what it will take.

Link to comment
  • 0

Ok, I was able to get it to work.  The big part was running dsregcmd /status and getting the results of the PRT.

 

In my environment I was getting CRL errors.  Even with adding public CRL it wouldn't validate.  I had to turn off CRL checking to even get it to work.

 

https://learn.microsoft.com/en-us/azure/active-directory/authentication/certificate-based-authentication-faq#how-do-i-turn-certificate-revocation-checking-on-or-off-for-a-particular-ca-

I was using IIS to host my CRL, this required me to enable Double Escaping.  Once I did that CRL checking from Azure AD worked.

 

image.thumb.png.276a215d627f899a9f50cd838d5f991f.png

 

I also added the Smart Cart Logon and Client Authentication to the Application Policies of the Smartcard logon.

 

 

 

 

Link to comment
  • 0
On 3/7/2023 at 1:22 PM, Jeff Riechers1709152667 said:

So if you upload your domain root, and don't add the CRLs you should be good.  Just know that if you revoke a user's FAS smart card it won't be invalid, so you may want to modify those to have a short life, like 12 hours.

 

Since the smartcards are only used internally for Citrix you won't have to worry really about the cert based auth being enabled.  It's just an option, but with the above mentioned shortened life of the certificates you won't run into issues.  You might be able to do some more restrictions on the Azure side.

 

With the new authentication token settings from MS, I am anticipating seeing these configurations more and more.  I created a more in depth setup guide up on my wiki if you want to read more on this.

 

https://www.jeffriechers.com/wiki/azuread-prt-with-fas-certificates/

 

 

Thanks again Jeff for all your help so far, and for the link to that document. I really appreciate you delving into this, replicating some of the workflows etc. 

 

I was hoping that you could perhaps just clear this up for me in some way then, since certificate based authentication is not something I've had to deal with before.

 

I assume in a traditional sense, certificate based authentication would work with a physical card or access key. The end users inserts the card or key, flash drive or whatever into their machine which contains a key. When the user attempts to authenticate to services or login, it uses the key on their card/flash drive to perform the authentication? The "revocation list" would have a list of cards/flash drive keys that have essentially been "revoked", and therefore they will no longer work?

 

I know this is bordering on very basic and high level territory here, but it will just help me to understand the flow and process. 

 

If the above is correct, then I'm still wondering how certificate based authentication is working for Citrix using FAS to generate the PRT. I'll attempt to explain my thought process, and hopefully you can fill in the gaps a bit... Like I said earlier, I haven't setup our Citrix environment so my knowledge of that side of things is rather limited too.

 

To clarify, our users still use standard passwords in order to access services, coupled with MFA. We do not use flash drives or access cards or anything that would constitute CBA in a traditional sense.

So when a user logs onto Citrix, they enter their network credentials on the store front (which redirects to Microsoft and prompts for MFA etc).

They then choose a machine from a catalogue, the Citrix app opens and their session begins. 

Initially, their session shows the login screen, but only for a second before the session automatically logs the user in (I assume this is FAS). 

The user can then work on their remote session as normal.

With certificate based authentication switched on for the user in Azure (pointing to our domain controller root CA), then the PRT token is issued and Seamless SSO works. 

 

So in the above instance, is FAS itself acting as the "smart card/flash drive" for auth within the session? If not, can you delve a little more into how it's working in this instance?

 

If I try externally, on my own laptop (not on the corporate network), to login to outlook.office365.com for example, an option appears with "login with certificate" and when I press this, it's immediately telling me that there are certificate issues and it won't let me continue. I assume that this is expected behaviour externally because our domain controller CA cannot be resolved externally? This really isn't an issue for us, we are only doing this for Citrix to work so that the PRT can be issued correctly. This is just more of a general query surrounding certificates. 

 

Hope that all makes sense, I really appreciate the help and information once again! ?

Link to comment
  • 0

 

Yes, FAS generates virtual smart cards similar to those physical units you have used in the past.  If you drastically reduce the life of those certificates that can take the place of the CRL.  CRL are necessary so that if a smartcard is compromised you can quickly revoke it.  Every login attempt with that smartcard is checked off of the CRL to see if it has been revoked.  Once in that revoked section that smart card is effectively dead.  Similar to changing a user's password in LDAP if it was compromised.  

 

When you login to your Citrix session FAS generates the smartcard and stores it in your user profile on the VDA.  If you load up the certificates mmc console under the user context you should see the certificate there in their profile.  It all stays insular in that session.  So users can't take that smartcard outside of the Citrix session, like to their laptop, and use it outside of that environment.   So even though cert based authentication shows up on your Azure AD login, nobody will have the proper cert so they are not able to utilize it.

 

Also if only certain users require the Azure PRT, you can restrict the Certificate based access to just them.  That way things like Service Accounts, Admin Accounts, kiosk accounts, etc can't utilize those features in Azure AD.

Link to comment
  • 0
On 3/9/2023 at 12:59 PM, Jeff Riechers1709152667 said:

 

Yes, FAS generates virtual smart cards similar to those physical units you have used in the past.  If you drastically reduce the life of those certificates that can take the place of the CRL.  CRL are necessary so that if a smartcard is compromised you can quickly revoke it.  Every login attempt with that smartcard is checked off of the CRL to see if it has been revoked.  Once in that revoked section that smart card is effectively dead.  Similar to changing a user's password in LDAP if it was compromised.  

 

When you login to your Citrix session FAS generates the smartcard and stores it in your user profile on the VDA.  If you load up the certificates mmc console under the user context you should see the certificate there in their profile.  It all stays insular in that session.  So users can't take that smartcard outside of the Citrix session, like to their laptop, and use it outside of that environment.   So even though cert based authentication shows up on your Azure AD login, nobody will have the proper cert so they are not able to utilize it.

 

Also if only certain users require the Azure PRT, you can restrict the Certificate based access to just them.  That way things like Service Accounts, Admin Accounts, kiosk accounts, etc can't utilize those features in Azure AD.

Thank you so much Jeff for trying to clear this up for me. I think I understand it more now, still only at a high level, but it's really appreciated.

I'll dig into this a little more and see how it goes.

Thanks again!

Link to comment
  • 0

Hi Jeff,

I've implemented Azure AD Cert Based Auth as discussed here and am now getting the PRT token and SSO is working. Also using Windows 10 VDA E3 licensing which was a reason for me doing this in the first place as the PRT token not being applied was stopping the Windows 10 Pro from being uplifted to Windows 10 Enterprise. 

Anyway one thing I have noticed, is that when Cert Base Auth is enabled in Azure AD, new users who have yet to registered for Azure MFA are no longer able to. It looks like this may be by design as the Certificate is effectively an MFA enabled method. So when the user attempts to register for Azure MFA, they enter their username/password and then are requested to provide more info, however instead of being passed to the setup MFA bit, they get a screen asking them to verify their identity, with the only option being "use a client certificate or smartcard".

The only "fix" i can find for this is to add an exclude group to the Cert Based Auth Method in Azure AD, add my new users to that until they have registered for Azure MFA, then remove them from the group... very fudgy. 

 

Just wondering if you'd come across this behaviour and if you know a way round it?

 

Thanks,

 

John

 

 

Link to comment
  • 0

The alternative to using CBA to get SSO to Azure working with FAS, is to use the Seamless SSO option in the Azure AD Connect. This will allow a Kerberos-based authentication (which is not PRT, as that requires the user password to be entered into the Windows logon gina, hence no good with FAS). It does it using a special computer account that gets created in your on prem Active Directory with an SPN that allows it to be used to authenticate with Azure.

 

I've found that if using Azure Seamless SSO with published applications, the OneDrive client doesn't authenticate correctly, or takes a long time to. You'll need to use runonce.exe /alternateshellstartup at logon. I suspect there's an Active Setup that OneDrive needs for Seamless SSO to work.

 

Hope that helps!

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...