Mastering SAML-based single sign-on with Parallels RAS

Good evening. Welcome for joining this technical webinar on Single Sign-On and Parallels RAS. My name is Steven De Winter. I'm the Global Senior Director for Sales Engineering at Parallels. And I will be your guide for this one hour webinar. It's pretty packed. I have a lot of content, a lot of technical things I want to share with you on this topic. Today, this webinar is part of a larger initiative where we do from time to time advanced technical webinars. We have done one, I think it was two or three weeks ago on advanced architectures. It's a webinar into the same type of content and the same type of skills that is required to follow this webinar. So this is not a webinar for people who have never seen Parallels RAS before, but this is like really a technical webinar going into details on how Parallels RAS works with the Single Sign-On. This is also content that we cover during advanced PPA training. So if you plan to do the Parallels RAS technical professional advanced exam, this is a large part of that same content, that same material that we're going to cover this afternoon. On the agenda. So we're going first of all to take a look how things look if everything goes well. And so we're going to look at the sample part, we're going to take a look at how the Windows backend part works, the prerequisites, the enrollment service. So that's all how to configure and install and all the prerequisites to get the Single Sign-On working between Parallels RAS and your identity provider of your choice. And then once that is done, we're going also a little bit of the happy path and we're going to take a look like if something goes wrong, how do you have to troubleshoot Single Sign-On issues with Parallels RAS. And then hopefully, we should have like a little bit of time left at the end for Q&A. For those people that follow this webinar live and I have seen that there's a lot of people already online joining. I have a colleague of mine, Paul Fisher. He's one of our senior sales engineers out of the UK and he's on the chat. So if you have like any questions or remarks or things you want to double check, I personally don't see the Q&A part or the chat for this moment, but my colleague Paul is live. So he will try to answer things which can be answered over the chat. And if there are like good questions, I will from time to time check in with Paul if he can give me an update of everything which is going on on the chat. And from there, we can then make the webinar interactive. So that's the advantage for people who are joining live. For people who are following the recording, my contact details are at the end of the presentation. So if there will be anything you need, you can always reach out and let me then see how I can help you further or my team can help you any further. So we have a packed agenda. So let's jump in. So if you take a look at the overall process of how single sign-on works in Parallels RAS, you will see that there are basically two main parts. There is the first part, which is the SAML part. So this is the part where, let's say you start with Parallels Client, that you are redirected to your identity provider, you do your authentication there, and then you get your SAML ticket back to log in into the, let's say, the Parallels RAS portal. And then there is a second part, which is not SAML-based, but which is certificate-based, in which we convert that identity that you have received from your identity provider into a Windows identity. And then from there, we use certificates and all kinds of other methods to be able to access the resources and start applications of Desktop 3.0 through your either web client or your native Parallels clients. For today's webinar, we've also split that into two parts. So let's first start with taking a look at the first part, the SAML part, how that works, and how you have to configure that to have everything up and running in Parallels RAS. So let's have a look. So the first thing you need to know about single sign-on or web-based single sign-on and Parallels RAS is that we use SAML as underlying protocol. So it's based on SAML. At the current time, Parallels RAS does not yet support OpenID Connect. So I'm already trying to avoid one of the questions that might pop up on the chat. So today, everything is based on SAML. Good news is that you can use any SAML IDP. So if your identity provider is compatible with SAML, which I think every identity provider is these days, then there should be no issue. And for explaining how things work, I'm not going into detail of the SAML protocol itself, but I think there are two concepts that need to be a little bit explained before we dive into the flows and how things work. So there is something in SAML which is called an assertion. And an assertion is basically a bunch of information, which is very often or typically encrypted. And the assertion is what you get once you have been successfully authenticated into your identity provider. So basically what happens, and I'll explain the flow on the next slide, but you will be redirected to your IDP. Your IDP sends you back. That information which is sent back is an assertion. It's an encrypted package, which gives you the permissions that you have been successfully authenticated into your identity provider. And in that assertion are specific lines of information. And one such a line of information is called a claim. So a claim is a piece of information which is part of the assertion. And the assertion is the ticket, is the information that you get back from your identity provider. And those claims can be, typically such an assertion has multiple claims. Such a claim could, for example, be your name, your email address, your role, your group memberships, and so on and so on. So it can be a lot of information, but you will see that we're going to use one specific claim to do the mapping between your identity on the identity provider and your identity on the Windows side of the story. So these are a few concepts that you need to know. And once this is clear, then let's have a look how it practically works. So on the left side, you have your Parallels Client. And the first thing you will see is if you have single sign-on configured and you go to your Parallels RAS environment, and let's assume you're not yet authenticated with your identity provider, what will happen is your web browser goes to your identity providers and your identity provider, wrong direction, and your identity provider will tell you that you don't have a valid ticket yet, you don't have a valid SAML ticket yet, that you have to be redirected to your identity provider. So what will basically happen is your Parallels RAS gateway, in our case, will instruct your web browser or your client to redirect to your identity provider. Then on your identity provider, and that could be, for example, like Microsoft Entra ID or Octa or any set before any SAML-based identity provider, you will do your authentication over there. So that could be username, password, or that could be an app, or that could be a fingerprint, that could be anything which is linked to the identity provider. And then once you're authenticated on your identity provider, and you're also allowed from your identity provider to use this consumer, this application in your IDP, you will receive your identity provider will redirect your web browser again to the Parallels environment. And that redirection will also contain that assertion. So that encrypted list of that encrypted ticket that contains those claims. And then once that is done, you're logged in into the Parallels RAS environment, but you're not yet mapped to your user. So what we will then do at that point in time is we will look up that claim versus some attributes on the active directory. And if we can match it, then we know which mapping Windows user is behind this identity on the identity provider. And we will display your applications which are available for your user. Of course, that displaying the applications that is more or less the same as without some way. So that's based on the filters and the other settings in RAS which you will not cover at this time. But this is basically the flow. When you go to your gateway, if you're not yet authenticated with your identity provider, you're redirected to your identity provider first, you do the authentication, it comes back and if you have the assertion which contains claims, we map it to a Windows user, we check for that Windows user, what are the settings on the filters and we show you the applications of the desk which are available. So this is the first part of the authentication flow into RAS. So if you want to configure this part, we need to do a few things. So the first thing what we need to do is on the identity provider side, we need to create a new enterprise application. So this is for example, for Microsoft Entra ID that I have written things out. For those of you who want to know more details, all this information is also in our admin guide. So if you go to docs.parallels.com, you can also find this information over there. Or we have also very specific knowledge-based articles that describe for specific IDPs how it works. So I believe this knowledge-based article, this link on this page is going to the one for Entra ID, but we have similar documents, for example, for Opta and some other popular identity providers. So what needs to happen if you do it very specifically for Entra ID, we have to go to, you have to log into the Azure portal, open the Entra ID part, go to enterprise applications, click on new enterprise application. And then unfortunately, there is no Parallels RAS template available on the Azure marketplace. So what you have to do is you have to select the integrate any other application you don't find in the gallery and click on create. So that will just pull up the, let's say the default SAML template for Entra ID. And what you need is basically that metadata URL. So that's something important that we need on the Parallels site. So once you have created your application and you have specified that it's SAML, it will more or less bring you to this screen. And then what you need to do is copy that metadata URL, because you need it in the next step. And what's the next step? The next step is that you go to your Parallels RAS environment and under the connection stuff, you will see that there's a possibility for SAML. And it's similar like with everything in RAS, you click on plus and you can add your first SAML configuration. And something important to mention at this point is that Parallels RAS can have multiple SAML configurations. So you can have more than one SAML configuration. What is important is that if you have one site and you have multiple SAML configurations, you will also need multiple teams. Because what we're going to do is we're going to attach a SAML profile to a team. And then Parallels RAS knows that if you go to this team, that it needs to be configured via SAML. Or if you go to another team, that it is, for example, done with standard username and credentials. So it's technically possible to have multiple SAML profiles. For example, if you're a service provider, you could have like maybe five SAML profiles for each of your different customers, but then you would need to create five teams where you then link this specific SAML profile. And then if you go to team customer one, then for example, it will load SAML one. So if you click on plus, you will see that there are three options under the general tab, how to add the settings. The most easy one is, of course, if you just click on import metadata URL. So that's why you have to first go to your RAS site, sorry, to your EMPR ID site and attach that metadata URL. But if you then click on import, you will more or less end up here because Parallels RAS will automatically read the configuration from that metadata URL on the IDP site. The other option is, let's assume that for some reason, you cannot access that XML file. You could also download it and import the XML file. So that's the second reason, the second way that you could do it. The third one, creating it manually, that's something I would strongly disadvise. I would either go online with the XML URL or download and upload the XML file if the first one is not possible, I would not create it manually. What you have to change manually is on the service provider side. So you will see under the XML properties that you have the IDP, which is like automatically filled in by the metadata URL that you have read. But under the service provider side, you will typically see that your host is still set to your local name. So you will probably see something like lab.domain.local or your internal settings. It is very important that you're using something which is accessible from the outside world. Typically, if people are going to connect over internet to your host environment, what will happen is, once that identity provider has authenticated you, it needs a reply URL. So it needs a URL where it can send, where it can redirect your browser to do and send that assertion. That reply URL needs of course to be accessible from your web browser. And if your client is, your web browser or your client is on public internet, of course you need to have a public DNS name. So don't forget to change here, your host to your public DNS name. And also important for single sign-on to work, make sure that your DNS work, make sure that all these other things work before you start doing this part of the configuration. But once this is done, what you will see is that you have like two important fields of information in here. The first one is that SP entity ID, which is like a sort of unique identifier for the configuration on the service provider side, on the Parallels RAS side. And then that reply URL, that's the URL that your identity provider will use to redirect you to and do the login once you have been successfully authenticated onto your identity provider. So with these two pieces of information, you can go back to your identity provider. And for example, in the case of Microsoft Entra ID, you can then add that identity provider that we just brought in the previous step into the SAML configuration on Entra ID. And the same thing for your reply URL, you can add that to your reply URL over there. There are two other settings, which is the logon URL and the logout URL. These are optional, but these you can of course also copy over from the previous step. So then once we click on save, we are almost there. Then there's like one last thing that needs to happen, and that is the mapping of the claims. And so what you will see is that on the Microsoft side, on the Entra ID side, you have multiple claims that you can configure. And then on the Parallels side, under attributes, you have to map a specific claim from your SAML attribute to your Entra ID attribute. And if you're just using the default Microsoft claims, which probably many do, you will see that the SAML attributes have like a sort of URL, and look and feel it. So that's schemas.xmlsoap.org.vs.2005, and so on and so on. And that is, for example, your ID on the Entra ID, so for example, in my case, that would be like steven.dewinteratparallels.com. And then of course, we need to map that one way or another to an attribute on the ID side. So in my case, I have now mapped it to the user principal name, but for example, in some organizations, it could be that your user principal name is maybe something like sdewinteratparallels.local. And then you could, for example, map it to your email address if your email address matches, for example, with your SAML. So this is also important that that mapping is done. Once this step is done, the SAML part is configured. So this is step one, you configure the SAML part of the login scheme. The second part is a bit more Windows focused. So the second part of the story is about certificates and then how to log into a Windows backend without having the Windows password. Let me just stop here for one second and check with Paul. Paul, were there any questions that came in on this first part that need to be addressed or is everything still A-okay on the chat and the Q&A part of the webinar? Yeah, everything's good. There was a couple came in around, can we have multiple SAML providers, which you answered, which are based on themes, of course. And is there a limit to that? Which, no, there isn't a limit. Okay, perfect. Thank you, Paul, for keeping an eye on that side of the webinar. So then the second part is a bit different. Basically, if you want to log into, let's say a Windows server or a Windows desktop, there are only two ways you can actually do that in the Microsoft world. One way is based on the username and the password, and the other way is based on smart cards and certificates. For those of you who are less familiar with SAML, something that SAML doesn't do is send over passwords. And so once you get that assertion back, that entry ticket, it will not say, like, Steven's password is password 123. It will just say, like, Steven is allowed to log in, and here are some details of Steven, but it will not give you Steven's password. So that means that if you want to log in to a Windows desktop or Windows application in the Windows world, that we need to do it smart card, based on smart card and certificates. And that's basically what will happen. So if you take a look at the second part of the login, so we are now logged in into Parallels RAS. Parallels RAS knows that we are, let's say, Steven at the company.local. How does now the real login, and let's say I click on a desktop, so what will happen? What will happen is the following. And for this, you need to understand a little bit how things work under the hood. And what I'm sharing on this slide is something you would typically not find in any official Parallels RAS documentation, but this is to give you a sort of glimpse under the hood how that login mechanism more or less works without going into too many details. But the magic is in two parts. So the first part is that you need a user to log in on the Windows network. So even before you can log in to the Winlogon service or a server, you need to log in to the network and you need to be able to access that machine. For doing that, we use a special service account, and that special service account is called the NLA user. I'm going to talk about that in the next slide, but that NLA user is a special user. And what that NLA user will do is you will use that NLA user to go from your Parallels client to your Windows server. And that NLA user has something very special. It's allowed to connect via RDP, but it's also blocked to connect via RDP. So it's a bit of a very strange setting, but on one hand, you put it into the group which allows people to connect over RDP, but then you create a policy that blocks login from RDP. And what that will do is it will create an error on your credential provider, on the credential provider on the server where you want to log in. And that credential provider will then load the Parallels credential provider. And then what will happen is in that token, so that NLA user is using a special sort of launch token, and that launch token is the identity of the user. So in my case, I put them be like Steven at company.local. And what that will do is that will trigger the enrollment server. So the enrollment server, I'm also going to explain that in one second, but the enrollment server is an extra component that you have to install on your Parallels environment. But that enrollment server will then connect with your Active Directory and with your certificate authority, and it will generate a short living user certificate for Steven. If it would not yet exist, let's assume it doesn't exist, it will create it. And then what will happen is we will like emulate a sort of virtual smart card on your, let's say session host. We will open it with that newly created certificate. And then we will do a sort of smart card based login into the server with the real identity of the users. So at that point in time, we switch from that NLA user to your normal user and we log into the system. So this is a bit under the hood how it works. I'm going in more details later on, but this is a bit under the hood how it works. So that NLA user triggers a sort of error. That error will trigger the enrollment server also with a special purpose account to generate a user certificate. That user certificate will be loaded in a virtual smart card, and that virtual smart card will then be used to mimic a login into the Windows system where you want to connect. So that could be then your session host or your VDI in which you want to log in. So this is more or less what happens under the hood. And then of course, once that is done, that login is done, the application or the desktop is streamed back to the windows, to the Parallels client. So what is important? There are, let's say, four prerequisites which are needed to get this thing working. And what is special about these prerequisites is that they are very sensitive to details. So we have a long knowledge-based article. It's also on this slide. It's the 124813 knowledge-based article. But that KB explains into detail how to create these specific users and these specific certificate templates. But they are mandatory to get everything working. So the first thing which is mandatory is that the NLA user, which I've already mentioned before. So that's the user that will make the initial RDP connection between the Parallels client and the host machine. It's also what will trigger the Windows On service. And it's then also that that will then do the rest of the flow. The special thing, as already mentioned before, it must be a member of the local remote desktop user group. But it must also be explicitly denied via GPO, the RDP login rights to trigger that custom credential provider to work. And it also needs to have specific privileges to log into the enrollment server because it's also that NLA user that will log into the enrollment server. And that then will trigger the enrollment server to create the certificates. The creation of the certificates itself is done with another service account. So that is not done with the NLA user, but that's done with the enrollment user. So the enrollment user is a second service account on the platform. That enrollment user only needs to have access on the enrollment server. And it's that user that will have specific permissions to request on behalf of a user a certificate. So that's a very powerful user. And that's a user which has on the certificate authority the right to request on behalf of another user and a user certificate. And it's then that user certificate of that user that people use in that virtual smart. Next to these two service accounts, there is also templates which are needed. So one template is the enrollment agent certificate template. So that's a template that needs to be created to allow that enrollment user to fetch those certificates. So that enrollment agent certificate template will give the needed permissions on the enrollment user to get the certificates. And then the SmartCat logon certificate template is a second template which is needed. That's then the template that we're going to use to attach, that we're actually going to use inside the, let's call it the virtual SmartCat to do the login system. Whenever we get those certificates, it will be like these user-based SmartCat logon certificates which are based on that kind of template. I'm not going into detail on how to create these specific users and these specific templates. My main piece of advice would be, don't try to be smarter than the knowledge-based article. First of all, do everything exactly as it has been described in the knowledge-based article. Test if it works, and if it works and you think that you could fine-tune or tweak or need to modify something for your own environment or for your own policies or for your own security settings, then start making changes. But then at least you know that the basis worked and that if something breaks, it's linked to the changes that you have made yourself. The enrollment server itself. So this is an extra component on the RAS site. You can install it the same way as, for example, installing an extra session host or an extra provider or an extra connection broker or gateway. So if you go into your Parallels RAS console, you go to enrollment servers, you click on plus and you deploy the service. In theory, you can install the enrollment server on a single box and you can install everything on the same machine. And of course, we would highly recommend to, if you do this in a production environment and this is like a sizable environment that you would install the enrollment servers onto a separate box. So don't install the enrollment servers on your connection broker. Certainly don't install them on your gateways, but install them on a separate box. Of course, if you're doing like a lab or a proof of concept or a test, it will work. It's not a technical limitation, but it's more like a security advice to put that on a separate machine. Why? Because that's a very powerful machine because the enrollment server in combination with the enrollment service account can create logins for any user on the system. So you have to treat it a bit like a sort of active directory and it's a common practice to not put it on an internet facing server. For high availability, of course, you can also install multiple enrollment servers. So you're not limited to one. You can install two, three, four enrollment servers. That's not an issue. Once the role is installed, then you will go to AD integration. It will ask you a few things. It will ask you your certificate authority. It will ask you your enrollment agent user and it will ask you your NLA user. You type in your username and password and then there's a button on the right that says like validate everything. And if all good, it should say valid. If over here it already mentions something is wrong, then yeah, please fix that before continuing. But long story short, this is it. So if you manage to configure your sample settings and you manage to set up your enrollment server, then you're all ready for testing single sign-on end-to-end. So that's what needs to happen. So configure your sample part, test if your sample works. And then once that works, deploy your enrollment server, create those prerequisites, those special accounts, those certificate templates, make your configuration and that's it. So it's not more complicated than that, but it's very sensitive to little details which we will cover during the part on troubleshooting. Before we go to the troubleshooting part, there's another thing I need to explain to you and that's the different authentication types. So in Parallels RAS, we support four authentication types. One of them is credentials, that's let's say the default username, password, maybe expanded with MFA and that MFA can then be, for example, based on Google or Microsoft Authenticator, can be based on some email settings or can be based on a third-party product, but that's the default. Then we have smart cards. So this is a local smart card on the end user device which is used as mechanism to authenticate into Parallels RAS. This is different from, for example, redirecting your smart card into an application. So if you want to redirect your smart card into an application because you want to do like authentication inside the application with your smart card, let's take an example. For me, like I'm a Belgian resident, I have a Belgian ID. For some government websites, I need to put my Belgian ID into a card reader, for example, to declare my taxes. That's not smart card, that's actually, that's also smart card, but that's smart card redirection to an application. So that's, let's say, that has nothing to do with the smart card logins. It would be different if I want to use my Belgian ID to log in into Parallels RAS, that would be smart card login. And then we have two flows which are based on a single, on SAML. The first one is what I have just described. So it's the Fools SSO experience where we use SAML for the first part, and then we use the credentials, sorry, the certificates for the, the certificates and the enrollment server for the access to the applications and desktops. So that's what we call Fools Web SAML authentication. There is also something which was added. I think in RAS 19 or 19.3, like fairly recent, that's web-plus-credentials. So that's like a sort of in-between between credentials and web. What it does is it does the SAML part, so it will connect to your identity provider, it will check with your identity provider if you're allowed to log in, it will get the SAML ticket and log you into the Parallels environment. But instead of using the enrollment servers and the certificates and all that kind of stuff, it will just prompt you one more time to enter your Windows credentials, and then you have to type in your Windows credentials in Parallels RAS, and then it will allow you. So it's something in-between credentials and web. I like to call it, web-plus-credentials is a bit, not super clear. I like to call this like a sort of pre-authentication. So where some companies said like, yes, you can log into, we don't want to set up all that certificate things and enrollment servers. We want to keep it very simple, but on the other hand, we want to make sure that everyone is authenticated against the IDP, because that's where we're doing like single sign, where we're doing multi-factor authentication, or that's our centralized place for managing all accounts and that we can use to block or allow people to log in. So that is something in-between. What you need to know is that at this point in time, not every combination is possible. So credentials is possible with everything. The full SSO is possible with everything. The web-plus-credentials is, for example, today only available for the Windows client and the web-plus-html pipeline. So we're still working on adding support for the other clients, but this is, I think, something also important to work. Excuse me. For the web-plus-credentials itself, so how does it work? So I have put some screenshots on top. So you connect to your environment. You will be redirected to your IDP. You log into your IDP. Then you're redirected back to your Parallels environment that will show you your applications. And then the first time you start an application, it will prompt you for your password. So it cannot rely on your enrollment server or your certificates to do the full single sign-on. So it will pop up for the Windows password and allow you to log in. How can you configure your client to automatically work with web-plus-credentials? So on the Windows side, you can, via policy, push the authentication type to web-plus-credentials, or you could create a pre-configured client where everything is set to web-plus-credentials. So that's one way to set the things good on the client side. For the web client, you need to do it via the policy. So on the web client, there's a policy under connection, which is called primary connection. And then there, you can specify the authentication type. So if you go to the web portal, then it knows that it has to do web-plus-credentials, and then it can redirect. And something which I forgot to mention that here on the authentication types, you can also specify which types are allowed. So by default, web-plus-credentials and web-plus-sample is enabled, but if you want to have the web-plus-credentials, you can also enable them over here in the models configuration. Let me stop for one second before we go to the troubleshooting. Paul, is there any questions or remarks on the chat or the QA part? Yeah, the questions have lit up. There's been a lot, so thanks for that. I'm working my way through them, really. I think, yeah, I'll just keep doing that. It saves me time. What I will do is I will start doing the troubleshooting. So hopefully some of the questions or some of the specific cases are also covered in the troubleshooting section. One of the reasons we do this webinar is because we've noticed on our support site that we get a lot of questions. And very often, it's like something very small or something like a little detail where things go wrong. And one of the ideas behind this webinar was to help partners and customers to better understand how it works, but also if something goes wrong, like where to look. So this is actually the second part of the webinar. So if everything goes well, you can stop now. You don't have to look at slide 18. But let's say something goes wrong and you need some help. Of course, you can go to Parallel Support, but many of you are pretty skilled engineers. So if we can give you some hints or some tips where to look, and in many cases, you are able to find yourself where things go wrong. In general, like with everything in Parallels ROS, like if something goes wrong, have a look in the ROS logs. So if you go to Percentage, Program Data, Percentage, Parallels, ROS logs, you will find all the logs. You have over there the Enroll Server log, which is like your friend, have a look over there. Also on the agent side, so on your session host or on your VDI, have a look in the VDI or the RDSH agent logs for having like a complete picture of what's going on. If needed, increase the log level. So I didn't cover it in this slide deck, but you can put, for example, your logs into verbose logs, and then you will have like much more information that will also be able to help you. Also in general, if you have an issue, try to find out if it's on the SAML part or on the certificate part. That's also like a good step. Sometimes we get like support tickets saying like SAML, like SSO is not working, but is it the SAML part? Is it the credential part? So already try to identify is it in the first half or is it in the second half. For troubleshooting the SAML part, also have a look at your IDP logs. If, for example, you redirect to your IDP and you're not getting out of your IDP, then typically it's like a misconfiguration on your IDP. Another useful thing is have a look in your web browser, the SAML ticket. And to see that, you will need like a sort of plugin into your web browser, like one of those SAML browser extensions. There are a lot of them, if you click on the Chrome store, for example. But that could also help you to see like what is sent back. So that's another piece of advice. If the problem is in the second half, so the SAML is all working. You have your login, you see your applications and it's at the moment when you click on a desktop or an app that you get some kind of error message. The Windows event view is then your friend and there's a security log event which has the ID 4625 that will probably indicate where to look. So there are plenty of reasons and I'm going also into details, but that's like your first place to look for issues with certificates or if something goes wrong in the second part of the login. There is also in the admin guide page, which is called SAML SSO error messages. That's also something I would recommend. Have a look over there, because that will tell you like, if you see this error, it's that. If you see that error, it's that. So it gives you like a sort of overview of the most common errors and where to look. But let's go a little bit more into detail. So I'm going to look at six places where things can go wrong. And we just follow the path. We just follow the flow. And this is also some piece of advice. Like if something goes wrong, first check if your SAML part is correct before you start looking at the certificates. So let's start with the SAML part. And the first thing that could go wrong is you go to your Parallels environment and you're not redirected. So instead of being redirected to your identity, provided you stay on the RAS site, that is very often, or you're redirected to like a blank page or something like that, or page cannot be displayed or timeout error. But if you get like these kinds of errors, it's very often because your metadata URL is not correct, or your gateway is not able to access, for example, your clients or your IDP. So for example, if you specify that the gateway has to download the metadata URL and it's not able to do that, then it could also be that site. So if you have redirect errors, typically it is because the metadata URL is not completely correct, or the client cannot be redirected, or the gateway cannot validate certain settings. So have a look on that site. If you're redirected to your identity provider and you're not sent back to Parallels RAS, then typically it's something which is not right on your identity provider site, or at least have a look in your identity provider log files, because then over there we will see what's going wrong. Very often it will be something with the relying party. So the relying or the reply URL is the link that is used to send the information back. If, for example, your Parallels configuration says like this is my ID and that ID doesn't exist on your identity provider, you can end up in like type one or type two problems because the identity provider doesn't know for which application the user is being authenticated and that can generate errors. So if something goes wrong in these earlier steps, recheck your network, recheck your metadata URL, recheck your IDP configuration, recheck your reply URLs, recheck your DNS, recheck all these things. That's typically where it goes wrong. And then the second place where it can go wrong, so you're authenticated on your identity provider, everything went well, and the assertion is sent to Parallels. If the Parallels client shows something like login failed or specific, like some assertion validation failed, it means that there is something wrong with the assertion. Then the first thing to look at is, for example, things like the certificate of the assertion. So be careful. This is not the certificates on the enrollment server or on the Windows site or on your site, but this is the certificate which is used to sign that SAML ticket. If there is, for example, if that certificate is not trusted or it's expired or it's signed by another root setter and that one is not trusted anymore or expired, that can create these SAML assertion validation errors. Or another one is a clock skew. So what do I mean with that? If that SAML ticket is sent back, that assertion is sent back, it will tell you that this ticket is valid, for example, from 2 o'clock till 5 o'clock. But let's assume that your clock on your server side is wrong and it's maybe only like 1.30, they have like a half hour of deviation, then Paroles-Ras will also say like, hey, this is an invalid ticket because it's not yet into the time when it's valid. So have a look at these kinds of things if you have like these assertion failures. The next thing where it can go wrong is your assertion is fine, but you get like an error like, could not find this user in AD or fail to find AD user 4, and then some data. This is very simple. This is because we cannot match the identity in the SAML ticket with an identity in your Windows Active Directory. So double check your attributes, double check your mapping. Piece of advice, if it doesn't work for any user, then typically it's something wrong with the attributes, with the attribute mapping at least. If it works for some users and for some other users not, check if all the data is available. Let's, for example, say that you use email to do the matching between the SAML attribute and your Windows AD attribute. Maybe for some users, the email field is not filled in in Active Directory. So try to find out if it's like a problem for all users or if it's only for like one specific user. If it's like for one specific user, then typically it's some of the user data which is wrong. If it's not working for all users, check if that mapping between attributes for SAML and attributes for AD are working correct or has been set up correct. Once this is done, you are logged in into ROS. So this is the part where you know that your SAML configuration is good. So if you're here and it's still not working, then typically it's because there is something wrong on the certificate or resource side of things. This is where it becomes a bit more difficult to troubleshoot because it can be many things. Again, the event viewer is probably like your best friend at this point in time. Also, maybe take a look at your Kerberos logs because we're using Kerberos under the hood for some of the authentication. Check, for example, also if your root and Kerberos certificates are not expired. Check your full chain. Again, clocks are also very sensitive. Something which you also need to double check, these are the control revocation lists. So CRL stands for control revocation list. A certificate is valid for a certain amount of time. So that user certificate that we generate, for example, for Steven, is valid from today until, let's say, tomorrow, maybe for 24 hours. But everyone that uses a certificate can also check if the certificate has not been revoked. It's not because the certificate was valid at a certain point in time that it's still valid at this moment. So from time to time, certificates are checked if they have not been revoked and that is done via the control revocation list. So make sure that, for example, your servers and your VDIs have access to the control revocation list of your certificate authority, for example, to check if these things are good. Another thing where it sometimes goes wrong is things like antivirus and other security tools. If you're convinced that you have done everything correct and that you have excluded all the logic, try disabling your antivirus. Try disabling your security tool on your endpoint. And not on your endpoint, but on your VDI or on your session host. Sometimes, and especially those more modern security tools, sometimes block access because we're hooking into, for example, the credential provider. So this is something which is very sensitive for security. So some of these tools will see this as an issue. We have knowledge-based articles that describe for many of these AV or security tools how to write exclusions. Besides that, there are plenty of log files. Have a look in the scardhooker.log. That's the log file where you see all the information from the virtual smart card. Check the internal CA, check everything. So this is something that is a bit more difficult to troubleshoot from time to time. But these are like some best practices. What you can also do to check if everything is working end-to-end is this procedure. So you can log in to your enrollment server. And you can start your certificate manager with the command which is on the screen. So you can do like run us, user lab enrollment. My enrollment is called enrollment. But if you do that and then you start your certificate manager, you can test if that certificate works. So what you could do is go to personal certificates, all tasks, advanced operations, and then you can choose like enroll on behalf of. You could then, for example, check if you're able to enroll such a parallel smart card certificate, for example, And at least if this is working, you know for sure that your templates are good. You know for sure that your enrollment user is good. You know that your certificate authority is good. So you can already like exclude a bunch of things from checking if it's done correct or not correct. So this is like also like one piece of advice. And another thing, and this is something fairly recent. Microsoft has changed some of the security settings around the DPL library. So the protective process light libraries. There is something which is called LSA. That's the login subsystem. The default setting has changed. So the default setting has changed that you cannot, let's simplify that you cannot use those custom credential providers like we do with the trust. It's a bit like oversimplified. But if you get this error, to sign in remotely you need to be on the site in the remote desktop services, blah, blah, blah. This is very often caused by this recent change from Microsoft. So the most simple way is to change the registry key or work with a policy to set it back to the previous default setting, which is like disabled. There is also a knowledge-based article very specifically on this one. So if you have this specific error on a recent operating system, then this is probably the issue. With that said, I'm through my troubleshooting. Probably other things that can go wrong, but I wanted to keep a little bit of time for Q&A. For those of you who want to try things out or have more information, we also have our Tech Bytes. We have some Tech Bytes also on the advanced topics. But let me use the last five minutes of the webinar to check together with Paul if there are any questions that we need to address together or other things that came up from the chat. Yeah, hi. So I've got through most of them. There's a few I think probably best taking off. It might take a bit of answering or a bit of thinking about. But if you can see the questions, have you got those in front of you now? I don't have the questions in front of me. So maybe if you can just pick the ones that we can cover in the next few minutes, that would be nice. Yeah. There's an easy one that's just come in a few times about can we get a copy of this presentation. I think, yeah, we will share the video. Yeah. The video will be published on our website also for on-demand. So if somebody wants to watch the video later on, there will be an on-demand version available. And for the slides, yes, we can make them available. That's not an issue. If you don't get them, I think my email was on the page before. Or if you want to hook up via LinkedIn, I can also send them to you. Yeah. There's a question from Gerrit, which I'm just going to note down, I think, and we'll get back to him afterwards. It's to do with deploying the client with some parameters through Intune, so we can get back to you on that one. If you're working with single sign-on, there are specific policies that can be used to push configurations. But, of course, it's always a little bit tricky if it's the first time you have to log in and you don't have a policy yet. Then, of course, the client will by default try to log in with username password. So this is something we actually also cover in our advanced TPA training. So we have a module on configuring clients. So we can, for example, configure a client with specific settings, even without having never connected to an environment that the settings are pre-configured, for example, for single sign-on login from the first time. So, yes, it's certainly possible and we have information on that. There's been a few questions around not wanting to use AD. I think the general response to that is AD is required, wherever that is, whether it's on-premises, whether it's Azure or Enter ID domain services, that is required. There's a few people saying that a lot of their devices are now in Intune and kind of moving away from AD. I think, yeah, at the moment, AD is required. Your thoughts on that, Steven? Yes, correct. And maybe like a small nuance, so Active Directory is required, but you don't need the AD sync functionality. So you could do other mappings. They don't necessarily need to be like fully synced like you would normally have to do with the, what is it called these days, the Entra AD sync tool from Microsoft. They can be completely isolated, as long as you have like an attribute that matches in the SAML claim with the AD site, that's fine. So you don't need to synchronize passwords or that kind of stuff. That's all not needed. Yeah, I think I've answered most of them. So, yeah, there's a couple that we'll get back to you on. Just answer in an email. Okay, perfect. Then if there are no more questions, then I want to thank everyone for being present. I think there was a lot of people in this webinar. If you have any suggestions for future sessions like these or the previous ones, let us know. We love doing these kinds of technical webinars. So give us inspiration and we are more than happy to organize this. For those of you who it's the end of the day, I wish you a lovely evening for people joining from U.S. or even more west. Enjoy your day and thank you for being in this webinar. Thank you. Bye-bye.