Azure IdP統合による証明書ベース(EAP-TLS)認証の構成

Create the authentication policies with Mist Access Assurance considering the same exact scenario with TLS users authenticating using certificates and TLS users authenticating using credentials. The first thing that we will do is we will import the root CA certificate so we can trust the certificates on our client signed by that CA. So we'll go to organization > access certificates and I'll click on add certificate authority.

I will go to my folder where I have all the pre-configured items ready. I'm going to copy my root CA cert, import it in here. It's the same cert we used with the other two vendors. It's now imported, it's decoded, we're good to go and good to proceed. We'll then go to organization authentication policies. Actually we go to identity providers first.

We need to configure an identity provider in here and unlike with ClearPass and ICE, we don't need to have a local AD on-prem. We would actually be able to talk to Okta as our identity provider to fetch the user group information to authenticate users and provide them with network access. So I will click on add IDP.

I will select this connector type as auth since we will use native API connector to talk to Okta. I will open my setup instructions since my Okta app has been pre-created. Same as AD for other providers so I'm going to take tenants. I'm going to select the auth type as Okta, paste the tenant ID. I'll take the client ID, paste it in here. I'll take the private key so we can authenticate ourselves to Okta.

Add it right there and finally I'll configure the ROPC API ID for TTLS authentication and it's secret. The last thing I will do is I will configure the domain name. So the domain name would actually tell us based on the user realm like when the user signs in as user at like in this case lab.mystify.com. We'll take that domain based on the domain. We'll talk to a respective IDP in our configuration so just give it a name called Okta. Click create. We have our IDP configured now.

The last step is to go to access authentication policies and create the two policies that we need based on our requirements. First, we will create a rule for certificate authentication. What we'll then do is in the match criteria on the left hand side we will use labels to match in certain conditions.

In our case, we need to match on wireless users that are using certificates or TTLS to authenticate and we also need it to match on the group employee that we will take from IDP. But as you can see by default we are not having any label associated with the group so what we can do is we can create a label right from that same place. We'll call it employee group.

We will select label type as directory attribute and the label value will be group and the actual value will be employee. Click create. We can now select this label on the left hand side. It shows up here as the directory attribute. Now we are matching on all these three conditions. Then on the right hand side we are deciding what we want to do with these types of users. By default we will allow access to the network but we also want to assign VLAN 750 and role corp. Again we need to create labels for that. So we'll go and create first corp VLAN label.

The label type will be AAA attribute and the value would be VLAN. I'll configure it as 750. I'll then create corp role attribute and I'll just configure it as corp. And then I'm going to create also labels for BYD VLAN and BYD role. So 751 and finally BYD role. Good to go.

So we can select corp VLAN and corp role. Now we'll create one more rule for our users that are doing TTLS based authentication. So we'll call it credential authentication and we'll match on wireless users that are doing TTLS and that they're also part of the same employee group.

And on the right hand side we'll assign them BYD VLAN and BYD role. At this point we can hit save and our authentication policy setup is done. The last thing is to create the actual WLAN template. So I'm going to go to WLAN templates. I'm going to create a new one. I'm going to call it MIST 802.1X. I'm going to click create.

Add a WLAN. Select security as 802.1X. And in this case we don't need to configure radio servers one by one. We don't need to add APs as radio clients. None of that is required. We'll just go and select MIST authentication as our authentication service. That's it. We'll then just go on and configure dynamic VLANs. It's the same two VLANs that we will be sending. So 750.751. Click create and just assign this template to the org.

Click save. At this point we should be able to test with our client devices. We have one laptop that's connected using a certificate. It got the role corp. We have a mobile device that connected using TTLS using username and password and got the role BYD. And now let's take a look deeper and look at the client insights.

What can we see with MIST access assurance here? So what you could see is in addition to the all the client events that are coming from the access point and that are showing the user experience, from the network perspective, you also see all the events coming from the NAC side of things as the client goes through the authentication and authorization process. So, first event is, okay, we're seeing the client certificate. We are grabbing all the metadata about the user certificate.

We see that the client trusted our server cert that's provided by the MIST authentication service. We'll then did a IDP lookup against Okta. And we got all the user group information from Okta. So we know now this user is part of all these user groups. And we see one of these groups is actually employee, which we needed to match on. And finally, when we look at the NAC client allowed access event, we're saying, okay, this client is good to go. It's allowed in the network. This is the VLAN that we are assigning from a NAC perspective. This is the user role that we are assigning from the NAC perspective.

And this is the authentication rule that hit during that process. So if we click on that link, it will actually go and highlight, this is the rule that this particular user hit during the auth process, right? Similarly, if we look at the mobile device, if we look at the client insights, we're now seeing that in this case, client trusted the service certificate, but instead of showing the client certificate, it actually did the IDP authentication using username and password credentials against Okta. Finally, we got the user role and group information from Okta.

And we've allowed client to access the network, assign a different VLAN 751 and different user group. But in this case, we are hitting a different authentication rule in our policy. So again, if we click on it, we're saying that particular user went through a different role.