Multi-factor Authentication to the Active Roles MMC and Web UIs

Thank you for attending our One Identity Resilience Conference. We're going to be taking a look at Active Roles MMC and being able to launch the Management Console with multi-factor. My name is Richard Hosgood. I am the Pam Principal Presales Engineer here at One Identity. The way that this works in most environments is the users will go ahead and maybe RDP into the system or already be logged into the server. They would normally just go ahead and launch the Active Roles console. Where they don't have the ability is to protect it with multifactor, and that's what we're going to be showing in today's presentation. So there's quite a few authentication mechanisms built into OneLogin. And OneLogin is going to be leveraged as the Identity provider, but also the multifactor provider in this scenario. You can specify standard authentication whether it be a username and password. In addition to that, you can also have a username, password, and multifactor. There's also scenarios where you can be fully passwordless with leveraging Web Authen, or UB keys. And we're going to be showing that today in our session. Now the end user will have to set up their own security factors. In this case, I have OneLogin Protect and Web Authen and some UB keys configured for this particular user. And this will allow them to use multifactor directly when logging into the system itself. So what I'm going to do here is show you exactly how you would set something like this up inside a OneLogin. Now inside the security policies for your users, you can define a password-less state or you can specify just standard MFA. So by enabling the ability to turn on OneLogin Protect, or in this case, Web Authen with UB Key or Web Authen with Touch ID for Mac laptops. You can also leverage other mechanisms that will allow for Web Authen authentication as well. Once that's defined within the solution itself, the user would then have to modify their particular profile and have multiple security factors. In this particular case, I have four different multi factors set up. I have OneLogin Protect app on my phone. I have one on my iPad. And I also have my fingerprint reader for Web Authen and a UB Key on the side of my device itself. What I'm also going to show is how authentication occurs directly within Safeguard. So Safeguard is another piece this where we're leveraging OneLogin for the Identity. We're leveraging Safeguard for launching of the application. In this case, the application is Active Roles MMC. And inside of Safeguard, we have many different authentication methods as well. So if you wanted to Leverage Standard Active Directory, or LDAP, External Federation, Radius, FIDO2, or even OneLogin MFA, like we're going to be showing shortly, then you can go ahead and configure that. Now what's nice about this is you can use some of these as Primary Authentication or leverage other parts of this, such as MFA, as Secondary Means of Authentication for your users. It's really easy to set up OneLogin MFA directly within Safeguard. It's just a matter of putting the name in, description in, DNS, Names, Client ID, and Client Secret. Once that's configured, then your users will be able to Leverage Multifactor within Safeguard, our PAM solution. So how does that work? Well, you would go into the Authentication Enforcement for the user, specify the Authentication provider, in this case, it's a domain user, and we're requiring Secondary Authentication in this scenario. I'm going to go ahead and show that here where the user can either launch the session via Tile. You can launch Safeguard for Privileged Passwords directly by clicking on this. What this is going to do is fill in my name and my credentials here. Once I go ahead and authenticate, I'll have a notification on my phone via OneLogin Protect. And I will share out my screen here. And you should see that. And you'll notice that, me, the user is making this particular multifactor request, the location I'm at, and also that this is being done at this particular moment in time. I go ahead and accept that multifactor. It uses my biometrics by looking at my face. And what you'll notice is that I'm already logged into Safeguard for Privileged Passwords. What's nice about this is that I leveraged, in this case, OneLogin to do the automatic fill-in for the username and the password. I'm also leveraging OneLogin multifactor in this scenario in the Protect app to gain access into Safeguard for Privileged Passwords. The next piece to this would be launching the Active Roles MMC. So in this particular case, I have a favorite over here. If I click on that favorite, I can then launch the MMC console. I can do it now. I can do it later. I even have a maximum duration on how long I can have this available to me. By default, it has it for two hours. But if I want to increase that period of time, I can also do that. I can also provide Reason Codes and other information why I need access to Active Roles at this particular moment in time. When I go ahead and submit that request you'll see that immediately the request is available. Because in this particular scenario, I am just making a request that does not require any approvals. Now not only that, you can download the RDP file directly. This is going to allow me to launch the Active Roles MMC. But what it's going to do is send me through an RDP connection. That RDP connection is a jump box that has the MMC preconfigured. And not only that, it's going to inject the username and password for the credentials to gain access to that application. So what you're going to see here is actually me launching Active Roles MMC directly within a Mac laptop, which is not even possible. But the way that we make this possible is through Microsoft Remote Desktop apps. And as you can see here, I am an administrator for my particular domain. I can go in here and manage all of my Active Roles. And not only that, but all of this activity is fully recorded with a video playback of all my access within the system itself. I'm going to go ahead and close this part of the session and jump back into my presentation here. And that's exactly what we just saw just a moment ago is that the user opens their laptop. They log into Safeguard for privilege passwords, with Active Directory, or a local account. You can also leverage OneLogin as your Identity provider as well here. And we'll show that in just a moment. Not only that, OneLogin in this case is the multifactor provider. You can also leverage other multifactor providers in this scenario as well. And the OneLogin Protect app notified me. Then I got the approval, and I moved along and went into Safeguard for Privileged Passwords. And then not only that, I also went ahead and launched the Active Roles MMC. So this is leveraging OneLogin Safeguard to launch the Active Roles MMC. It's using three products from One Identity in this scenario. Some of the other scenarios that we also have are Passwordless with Safeguard Access into that MMC as well. So in this particular scenario. As I mentioned earlier. That you can leverage your fingerprint reader on your Mac or your fingerprint reader on your Windows system or even Windows Hello, a UB key. There's many different options that you have there for leveraging authentication. What's different about this is that we're not leveraging Web Authen for multifactor. We're using it as a primary factor. Now we find that this also equally as secure as a username password plus MFA. It just makes it much easier on the end users to gain access into the system. As I mentioned, here's a UB key in the example to do SAML 2.0 authentication. So how does this work? Well, the user would then go ahead and launch Safeguard for Privileged Passwords. They can then be redirected to the identity provider, in this case, it's OneLogin. The user then will authenticate. And when they authenticate, they will be specified to use a particular authentication mechanism. In this case, it's Web Authen. Or the user could have already been logged in to OneLogin with their Tiles for Safeguard for Privileged Passwords and be able to launch the actual session directly within the OneLogin browser. Now this will also send them in the same direction directly through Safeguard and they would be able to launch the session. I'm going to go ahead and show you that scenario here. You can see that this particular user can either log directly within OneLogin or they can log directly within Safeguard for Privileged Passwords. I'm going to start with Privileged Passwords first. The user then will be prompted to use a particular mechanism to log into the system. In this particular scenario, I'm going to use Web Authen. And what's going to happen next is the browser is asking my laptop to confirm my Identity via my fingerprint. I went ahead and touched that. And now I'm automatically logged in into Safeguard for Privileged Passwords. And I can go ahead and launch the Active Roles MMC. So that's similar to leveraging Active Directory with the multifactor solution. But in this particular case, it's single factor logging directly in, but highly secure scenario. Now as I also mentioned, that you can log directly within OneLogin. And in this particular scenario, I'm going to leverage the OneLogin Protect app as my single factor. And I got the notification again on my phone. And I'm going to go ahead and accept that. And as soon as I do that, you'll see the entire process now. So then I'll have my Tiles of the applications that I have access to. And I can go ahead and click on that single Tile, which would then use SAML 2.0 to authenticate me directly to Safeguard for Privileged Passwords. And as I mentioned here, I would then also want to launch the Active Roles MMC. And in this particular case, the other user has it open. So in this case, it wasn't going to launch. So what does this provide to you. Well, you have controlled access to Active Roles Console, Active Roles Console access. The admin needs to gain access into the system. They would go directly through Safeguard for Privileged Passwords. The RDP file gets downloaded to the user's desktop. That's what I showed in the prior scenario. And they would automatically launch the MMC console on their system. This could be on PC, Mac. It doesn't matter what the system is, as long as the system that is doing this supports RDP connectivity. Not only that, this can also be completed via a mobile device, such as a iPad or an Android type device as well. The benefits are that the user needs to access Active Roles Console via privileged access, in this case multifactor. The access is granted to the critical web application. And also all activity that's happening within Active Roles is 100% recorded with video playback of the session. And we're also reading window titles and every single thing that's happening within the session itself. So then that will bring me to my colleague, AJ Lindner And he's going to show you how Active Roles Web Interface also has multi-factor as well. Thank you. Hey, hey. My name is AJ Lindner. I'm a One Identity solutions architect. And I specialize in both our Active Directory management and our access management solutions within our Unified Identity Security Platform. Today, I'm going to demonstrate how you can enable both single sign on and multi-factor authentication for the Active Roles web interface. To get started, I'm going to demonstrate identity provider initiated single sign on with multifactor authentication to the One Identity Active Roles web interface using OneLogin by One Identity. First, I'll sign in to my OneLogin dashboard with my username and password. Now, depending on your OneLogin configuration, your users may or may not be prompted for multi-factor authentication at this initial sign in. I'm using OneLogin's SmartFactor authentication. Since I'm signing in from my home office during business hours, like I usually do, OneLogin's Vigilance AI I has determined that this is a low-risk sign in, and per my security policy, has suppressed the MFA prompt that might normally appear there. However, I have separate application security policies that will require multi-factor authentication when I try to access the Active Roles application. So on my OneLogin dashboard, I can access all three of the default Active Roles web interfaces. When I select the Admin page, before OneLogin connects me to Active Roles, you can see that I will now get prompted for MFA. So on my Android phone, I can accept the push notification and provide my fingerprint. Once that's finished, I'm taken directly to the Active Roles admin web interface signed in as myself. So now that you've seen what this looks like, I'm going to take a step back and walk through how this works today. And that means we need to talk about RS. Now, if you recall from the first half of the presentation, when Rich navigated to Safeguard to authenticate, the URL ended in /rsts/login. RSTS stands for Redistributable Secure Token Server. And let's break that down. First, an STS or Secure Token Server, sometimes called secure token service, is a component that allows an application to communicate with a single service to authenticate users against any number of identity providers using any number of authentication protocols. The R in RSTS stands for Redistributable, meaning the service is not intended to operate as a standalone application, but is instead intended to be customized by the parent applications that utilize it. However, it does support operation in standalone mode. And that's going to be relevant for our Active Roles scenario. In simpler terms, RSTS is an internal One Identity utility that our applications can use to support authentication through things like SAML, LDAP, OAuth, et cetera, without each application having to implement those protocols directly. If we look across the current state of our portfolio today in December 2022, this is already in use across our platform. Safeguard for Privileged Passwords, as we saw earlier, uses it to handle all authentication. Identity Manager has it as an optional component in order to support federation. Password Manager 5.10 added it to support authentication within a workflow, and 5.11 enabled it for federation to both the admin and help desk web interfaces. And of course finally, we have Active Roles. So for a while now, Active Roles has included the RSTS executable in its installation files. So customers can leverage that to provide federation capabilities. However, today, this is not currently supported by One Identity. Our roadmap does include plans to fully integrate RSTS with Active Roles for the upcoming 8.2 release, where it should be natively configurable within Active Roles itself, like it is for Safeguard. There are three primary protocols that RSTS supports-- namely, WS-FEd, OAuth2, and SAML2 Web SSO Profile, both for service provider initiated and identity provider initiated flows, which is what this presentation is focusing on. As far as providers go, there are various options that can be used for primary or secondary authentication. Again, our topic today is external federation via SAML2, where the identity provider itself includes the second factor prompt. However, this can also be used for Active Directory authentication, LDAP including secure LDAP, and of course, RADIUS. You can also layer an additional factor on top of the primary authentication. RSTS natively supports OneLogin for MFA using the API, which allows for all of the security factors you see in the slide. Additionally, it supports the legacy Duo Web prompt, FIDO2 tokens, and of course, RADIUS. So now that you have a general idea of what RSTS is, I'll briefly walk us through the steps needed in order to set this up today or in general in any Active Roles version prior to 8.2. First, we need to install RSTS. Like I mentioned, the RSTS executable is included in the Active Roles installation directory, which is typically the path you see in the screenshot, depending on the version number. Because of this, we can install and configure RSTS in standalone mode. To install it, once you command prompt as an administrator, navigate to the location of the RSTS executable and run RSTS space forward slash install. Once that installation is finished, you will see both the RSTS service running and an application event log for RSTS. Next, we can configure Active Roles to use RSTS for the web interface authentication. Active Roles natively supports federation using the WS-Fed protocol. But it's implemented in a particular way that won't necessarily work with many identity providers. However, fortunately it does work with RSTS. So from the Active Roles Configuration Center, we can enable federated authentication for the web interface and configure it like so. We can set the identity provider to custom. Now, RSTS actually runs a web server that's used for communication and configuration. So for the federated metadata URL, we need to point it to the RSTS web server, specifically the WS-Fed metadata page where it shares that information. The URL for RSTS will always default to forward slash RSTS, so use whichever URL is needed to direct Active Roles to the server where RSTS is installed. The realm and the reply URL can just be set to the root URL of your Active Roles web server. Finally, we can add the claims that Active Roles will send to RSTS to identify users. In this case, it's important that we use email address. So now Active Roles is configured to authenticate against RSTS. But RSTS is not configured yet. So in this case, we want to use OneLogin for external federation with SAML2. Although keep in mind, this can work with any identity provider that supports SAML. So to start, we'll create a new custom SAML application in our OneLogin tenant. We can give it a name and assign users to access it. In this case, I'm assigning it as a birthright application, so all users can access the Active Roles web interface via OneLogin federation, but allow the Active Roles security model to determine who can actually get in and what they have access to do. Now, I'll get to this in a moment, but we can actually hide this application from the portal. This is going to support the actual authentication mechanism. But later on, we will add some quick link applications to each of the different web interfaces, which is what our users will see on their OneLogin dashboard. Now, once this application is configured, we can download the SAML metadata file to use in RSTS. Now, back on our RSTS server, we can navigate to the admin panel at the URL where RSTS is located slash admin. Here we can add an authentication provider and configure OneLogin as our relying party. Give this a name and be sure to check the box for Set As Default Provider. What this setting does is ensure that users can only authenticate to Active Roles using OneLogin. And that if they navigate directly to Active Roles, it will immediately redirect to OneLogin for authentication. For the directory type, we of course want external federation. For realm, you should use the email suffix of your users. In the federation metadata, paste in the SAML metadata from the file you downloaded out of OneLogin. And finally, we can deselect the Require Authentication checkbox. By default, this setting allows RSTS to automatically terminate inactive sessions after a specific time and force re-authentication. In our case, we're going to allow OneLogin and Active Roles to enforce those session times. So at this point, we have the Active Roles web interface configured to authenticate against RSTS via WS-Fed. RSTS is then configured to authenticate using OneLogin via SAML2. If you navigate to any of the Active Roles web interfaces, it will automatically redirect you to OneLogin to authenticate using that SAML application we created. However, since we've chosen to hide that from the portal, when users access their OneLogin dashboard, they won't see a tile for Active Roles. And this is intentioned. By default, there are three different Active Roles web pages, and the ability to add as many as you'd like. We want dashboard tiles to direct to those specific web pages based on the user's access. So to do this, we can create quicklinks in OneLogin. In this case, the quicklink just provides a tile on the user's dashboard that directs them to a URL. We can create one for each of the different web interfaces and then assign access appropriately. Now, just a couple more notes on the final bit of configuration that needs to be performed within OneLogin. Still on those quicklinks, we can see that I've created three of them, one each for the admin, help desk, and self service pages, and assigned those to users via role-based access. Users will now see those tiles on their dashboard if they've been assigned to that application. The final step here is to strictly enforce multi-factor authentication for Active Roles specifically. As we saw earlier in this presentation, OneLogin user security policies determine how your users authenticate to OneLogin. Depending on those policies and features like SmartFactor authentication, we can't always be sure that a user has performed MFA when they initially accessed their dashboard. But OneLogin also offers application security policies, which can be used to enforce re-authentication or multifactor authentication when accessing specific applications. We can see here that I have an application policy that requires MFA. And that policy is assigned to the Active Roles SAML application that we created earlier. That means that every time I authenticate to Active Roles in a new session, I will be prompted for MFA. And with that, we're finished. As a final summary, in this presentation, we demonstrated how you can enable multifactor authentication for both the Active Roles MMC and the web interface, as well as federated authentication or single sign on using OneLogin or any other Identity provider that supports common protocols, like SAML2. Finally, a huge thank you to all the wonderful sponsors of One Identity Resilience 2022 in Barcelona.