EAP-TTLS with Azure configuration – credential based auth

NARRATOR: And there were use cases.

So far, we’ve been doing EAP-TLS authentication just by looking at the user certificates. Now, let’s add a little bit more into the mix. Let’s add identity provider lookup. So what we want to do is, we still want to do EAP-TLS authentication but we also want to do an additional check against an identity provider.

In this scenario, we will look at our certificate that had a common name user 1 at this domain name and we will do a lookup against Azure directory to fetch information about the user. We want to group memberships. We want to know if the account is still valid or not. We want to get some additional context for that user and build policies around that.

So what we will need to do, will need to go to organization access identity providers. And this is where we can add our connector to talk to Azure ID. So we can click on Add IDP or call this is our Azure AD, IDP type would be auth. While Azure supports both secure LDAP and auth, auth is more commonly used and more commonly available without higher tier of subscriptions from Azure side. So we’ll just use that as a standard API-based integration.

So we’ll then navigate to Azure portal.

We’ll go to our Azure Active Directory, we’ll navigate to app registrations to create our connector on the Azure side. I’ll click on new registration, we’ll call it mist AA IDP connector.

We’ll say that this application will only work for users in our Azure directory, nothing else. We don’t need anything else.

Here, we’ll click on register.

Now, what’s important here. We need a few components from here. We need the application client ID.

This goes into client credential client ID and it goes into resource owner password credential client, it should be the same. We’ll then go back, we’ll need to copy the directory tenant ID. This is your Azure tenant ID, will copy and paste it under the tenant ID.

We’ll then configure the domain name. So what the domain names field is doing is, it will look at the incoming authentication request, it will look at the full username that’s presented by the client, it will look at the domain name in that username. So for example, we had this test user at domain that on microsoft.com.

So what we will have to do here, is we will need to configure that domain name here, this will tell– let me to access assurance to see OK. If you see users with this domain name, go and talk to this specific Azure tenant. This is how you could theoretically connect multiple IDPs depending on which user realms here you’re looking at.

Finally, we’ll need to generate the client secret. So in order to do this, we’ll navigate to Azure portal, we go to certificate and secrets, we’ll click on create new secret, just say the secret.

For testing purposes, I will leave it valid for only six months.

You’ll need the value, not the secret ID, so you’ll need the value, paste it in this window, click create. There are a few more things we need to do on the Azure side, we’ll need to get this application some permissions.

So we’ll need to give a few permissions for Microsoft Graph API. There are delegated permissions and application permissions. We need to give both. Let’s start with application permissions. We’ll need to look at user– user read all. We don’t need any right.

You need groups. Also only read rights, we need directory.

Add those three and we’ll go and add the delegated permissions. This is what– if we will use a username and password-based authentication, this is where delegated permissions will come into play. So we’ll go and search for user then search for group and we’ll search for directory. Click add.

Now, as an admin of the Azure portal, I need to confirm these changes.

Now, the changes have been confirmed. That’s it. That’s all I need to do in order to build a connector.

And since we have one test user, I’ll just demonstrate to you that in the Azure portal, I have plenty of users but the one that we care about is this user.

Because that’s the same username as the common name of our test certificate. This is how we match the identity of the certificate to identity of the user in an identity provider.

And as you can see, this particular user is part of three groups. So theoretically, we should get all these three groups back when the client is authenticated. So now, without further ado, let’s go ahead and reconnect the client to get more details.

What we see now is that we are seeing all the NAC events for this particular user, for the new authentication item. So we see client trusted service certificate, it should the same event of validating the client certificate. Now we see new event that says IDP group look up successful.

So what we’ve done is, we’ve taken this certificate common name, we then found out that there is an identity provider that’s matching this domain name.

This is the identity provider we picked automatically during that authentication process. And we went and checked against Azure ID and we got the IDP rolls or in other words, we got the group membership of that particular user. We now know that this user is part of the employee group, it’s part of VAP group one, et cetera, et cetera.

Now we can build policies around that and say, OK, if the user is part of the employee group, maybe we want to do something else with them compared to everybody else. So let’s go ahead and go to authentication policies, we’ll create a label. We’ll create a directory attribute label with the sub value group.

So now, we are just saying employee group.

What it will do, it will look at these groups that are coming back from the IDP lookup. And now you can use them as much criteria in your policies.

So what we can do is say I want to give maybe a unique role for that given user.

Let just going to say this is employee role. In this role, we can later on use in our WxLAN policies.

If it’s a wide user, we could use it for our switching policies and things like that. So we can create this label, and we can create a new role, where we say, OK, if it’s a wireless user, it’s doing it tell us.

And if it’s part of this employee group, then we will assign employee role and we’ll move them to corporate VLAN. Let’s just put it this way.

So we’ll call it cert authentication employees. We don’t need that other role anymore. You can just safely disable it for now.