Welcome to One Identity Unite. My name is Richard Hosgood and I'm a PAM Principal Presales Engineer here at One Identity. We're going to be talking about Active Roles, MMC with utilizing Multifactor Authentication while launching that MMC.
As we get into it, we're going to talk about the standard access of how you would normally gain access to the MMC console for Active Roles. Normally, you would just log into your machine or maybe your remote into another machine that has that particular console, you would go ahead and launch that console. Now, what's missing here is multifactor authentication. So if you wanted to add that extra layer of security of multifactor authentication while launching the Active Roles MMC, we can do exactly that. And that's what we're going to be showing today.
Now, we're going to combine a few of our technologies here at One Identity, one of them being OneLogin Authentication. And within OneLogin, we have this technology called Smart Flows. And you can do standard authentication, such as a username, a password, you gain access to a particular application that you need to do your job. In addition to that, there can be multifactor. There's other scenarios that you see down here as well where it's passwordless.
So within the passwordless scenario, you can actually require that the user doesn't even type in a password during authentication. They would use their email address to identify them, and then they would be able to hit Next, and then they would be prompted to utilize a multifactor type device, such as a fingerprint reader, a yubikey, or some other technology in order to confirm their Identity. So they would physically have to have that device with them at the time of logging into the system.
Now what the end user needs to do in that particular scenario is set up multifactor devices. In this case, you see OneLogin Protect. I have it installed on my phone as well as my tablet. Not only that, I also have the ability to use WebAuthn and yubikey in this scenario. So if you go into Safeguard Authentication, which Safeguard is our Safeguard for Privilege Password Vault.
And the vault has the ability to launch sessions. In this case, we're going to launch a session that is launching this Management Console. But the authentication into Safeguard is going to be your multifactor layer where you're adding additional security before the user can launch the application. Now this could be any application. But in this scenario, we're going to be doing this for the Management Console for Active Roles. And inside of Safeguard also has some authentication methods.
So we talked about OneLogin. And now within Safeguard, you can actually utilize OneLogin to authenticate, whether it be External Federation or the OneLogin MFA technology that you see there on the bottom. The way that you would set up this MFA technology is just name it whatever your organization names their MFA through OneLogin. You'd specify a DNS host, the client ID, and a client secret. And that's going to leverage the OneLogin API in order to do multi-factor.
Where Safeguard has the ability utilize other multifactor means as well where you can leverage radius. So that would be a Radius server that would sit in your environment. And you'd be able to connect to that and do multifactor as well. So where the MFA Authentication Enforcement comes from, well, you'd have to specify that the login process requires a secondary authentication directly within Safeguard.
And when you go into Active Directory, the way that it would work is you would have OneLogin as your authentication to get into Safeguard for privileged passwords. That ties to either an Active Directory account or local account. And then in addition to leveraging Active Directory or local account, it would have multifactor enabled via OneLogin. And then in this particular scenario, it's the OneLogin Protect app. And it's notifying the user is it actually you who's logging into Safeguard. Once the user confirms their Identity, they would then be able to gain access in a Safeguard for privilege passwords user interface. At that point in time, they can launch a session and go into the Management Console.
Now, what I'm going to do now is show you that particular scenario. So if I go over here with this particular user, an Active Directory user. The password is already inputted because I pre-inputted that information in here. Once the user then uses the login mechanism, then they'll be notified of a notification for OneLogin Protect.
Now once I open up my OneLogin Protect app, which I'm going to share here on my screen, and you should be able to see that right now. And you'll be able to see there's an accept or reject. It's giving my information, such as my name, my location, the date, time, and if I go ahead and accept that request, it looks for my face, does biometric information, and then we're going to go ahead and stop mirroring here. And you'll see the authentication takes place.
Once the user is then logged in, they can go ahead and launch the MMC console directly within the user interface for Safeguard. And that's what you're seeing here in orange is a favorite icon of mine where I can go ahead and make that request for the MMC. But in this scenario, I'm not going to do that. I'll show you that with another user in a different authentication mechanism.
So here is the scenario that I'm going to show today is Passwordless. So you're still logging into Safeguard for your access. And in this case, you're also using a SAML 2.0 authentication mechanism that will tie to pretty much any IDP. But in this scenario, we are leveraging OneLogin. And if you look at this scenario, it's a MacBook. The user is then utilizing the fingerprint reader that's on the device itself. And then it will automatically allow for that authentication. That can also work with Windows, as well, Windows Hello via the camera, or even with a yubikey, or some other biometric type device that supports this type of authentication.
And in this scenario, you have that same user logging into Safeguard. They can go through the OneLogin portal, like they normally do if they want to gain access to their particular applications. They would have to confirm their Identity first. In this case, it's WebAuthn, and then the user would then click on the little tiles that are on the left hand side and be able to launch the application.
If the user wanted to go directly to the application first, it would then redirect them back to OneLogin and make sure that they still went through the passwordless technology, and making sure that the application is launched through the session. Now, not only are we allowing access to Active Roles in this scenario, but we're also recording that activity. And I'll show you exactly how that process works. So the user makes that request, the request goes through, it's approved, it can be approved by an individual who needs to approve the level of access or it can be automatically approved. In this scenario that I'm going to show is automatically approved.
It then sends an RDP file. That RDP file is utilized to launch the MMC console on a specific box. And when the MMC console it goes through an RDP connection directly to Safeguard for privileged sessions. And then the MMC appears on the screen. The reason why it's going through the Safeguard for privileged sessions appliance is it's recording the activity. So you actually will have a video playback of the particular session.
So in this case, the user is either using Multifactor or Passwordless to gain access to the Active Roles console in this scenario. I'm going to go ahead and demonstrate that as well. So you can see here in this case, I'm utilizing External Federation. This External Federation is tying to OneLogin for my authentication. I'd also like to point out something that AJ is going to be discussing later on in this demonstration, and that's the RSTS login capability here within Safeguard for Privilege passwords.
Now, that technology spans across many products within the One Identity portfolio. But basically, it's allowing for very simple authentication with very complex type of authentication means. And I go ahead and click on OneLogin. You can see that it was redirecting to OneLogin to gain access. The user confirms their email. And then continues access to the system.
Once that is done, the user will have their defined factors for passwordless in this scenario. I'm going to use WebAuthn, but you can use any one of these means. So if the user is not physically in front of their laptop that they're normally on, they can use OneLogin Protect, they can use yubikey on a different machine, they can use Windows Hello, or maybe even have a secondary yubikey.
In this case, it's going to request that Google Chrome is going to confirm my Identity. I then take my finger and put it on my biometric device and confirm my Identity. And now I would be gaining access to the system as you're seeing here. And then once the user's in, they can make a new request to an asset. In this case, the asset is the Active Roles MMC. You can make that request now, later. You can specify that you want it to be longer than two hours if you allow the users to specify how long or the duration should be for this particular application.
I'm going to go ahead and submit this request. Once the request is submitted, it's immediately available to me. I can then download this particular RDP file, and it's going to go ahead and launch the MMC console directly on my desktop here. I'm going to go ahead and close that and hit continue here. And now this is remoting into a particular server with a subset of credentials that will have access to the Management Console, and the Management Console is going to launch. It's not just going to be a full on RDP desktop. It is specifically that application once it comes up here.
Once the application launches, then Active Roles is going to log in and authenticate with that particular user. And when that occurs, the user then can go in here and make modifications in the Active Roles console. This also extends the Active Roles console into a different system type that normally wouldn't be able to launch a console. As I mentioned earlier, I'm on a MacBook. So in here if I go into a particular OU or make a change, all of those changes would then be visible within the system itself.
I'm going to go ahead and close this and cancel the session. And that is how you gain access to Active Roles console via Multifactor, leveraging Safeguard, Active Roles, and OneLogin. You can also just use Safeguard and Active Roles and bring your own Identity provider. I'm going to go ahead and pass it over to my colleague AJ Lindner. 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 multifactor authentication for the Active Roles web interface.
To get started, I'm going to demonstrate Identity provider initiated single sign on with multi-factor authentication to the One Identity Active Roles web interface using OneLogin by One Identity. First, I'll sign into 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 Smart Factor Authentication. Since I'm signing in from my home office, during business hours, like I usually do, OneLogin's vigilance AI has determined that this is a low risk sign. 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 RSTS. 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 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, launch a 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. You could 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 sample 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 intention. 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 quick links in OneLogin. In this case, the quick link 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 quick links, we can see that I've created three of them-- one each for the admin, help desk, and self service pages-- and assign 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 multifactor 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 smart factor 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.