Back in May, #MFD9 – Mobility Field Day 9 Juniper Networks unveiled their long-awaited cloud NAC solution (Check out my write-up on #MFD9 – Juniper Presents); Juniper branded it as Access Assurance, it also included all the features from IoT Assurance. I am not an expert NAC architect; My experience has been with the on-perm solutions. Anyone who has deployed a NAC knows all the aches and pains of getting 802.1X working with a NAC, especially if you are trying to do EAP-TLS, EAP-TTLS.
Can I do this?
This weekend, I had time to see if this is as easy to configure as advertised. I wanted to configure it without any assistance or hand-holding by reading the documentation and videos located here. Can I do this? Let’s find out my experience as I share my journey.
EAP-TTLS with Okta Directory:
There are couple of things to understand before I go any further:
- Mist Access Assurance is a cloud NAC solution it works with cloud directories such as Okta and MS Azure.
- If you have an on-prem Windows AD install, this is not a solution for you.
EAP-TTLS Flow:
I am a visual learner, so I drew a quick high-level diagram of the process using Okta with the steps involved:
- Setup Okta Directory.
- Configure Native Application Service.
- Configure API Service.
- Setup IDP in Mist Access Assurance.
- Download the Mist Cert and set up a profile on iPad/iPhone using Apple Configurator.
- Install the profile and connect.

The following link has the official Juniper Mist documentation on different configuration scenarios. You can always ask Marvis. I won’t get too deep into every step, but I did run into a few things that confused me a little. I am organizing some of that data flow.

First step is to copy the Okta tenant ID. Do not copy “.okta.com“, this is important and the instructions on the Mist website explicitly mention the same thing.

Follow this link for detailed “Okta Integration” step-by-step directions. After going through all the steps, the next step is to create IDP in the Mist dashboard. I mixed this one up initially, so I figured a visual representation of what goes where should be helpful. NOTE: “Private key will come from when you are generating the the “Public and Private Keys” as shown below.


Tenant ID Error:
Note: I initially had “.okta.com” in my “OAuth Tenant ID” which ended up causing this error, I knew something was wrong in my Idp config and I thought it may have been the keys and credentials. Only after creating the support ticket I realized it was simply the additional text. I liked the fact that the Description points out an error, would love to see it actually say something along the lines of, “Wrong Tenant ID” instead.

Next step is to create some “Auth Policy Labels” that will be used in the “Auth Policy”. Think of labels as something that will get assigned to the users/devices and based on the labels other actions can be performed.

High level work flow of the “Auth Policy Labels” and “Auth Policy”

There will be four labels for this process. The first set of roles will match with the Directory Attributes Idp is sending, “contractor” and “employee”. Next will assign those from “Mist Access Assurance”. The following link has the full list of all the “Mist RADIUS Attributes“.




After the labels, the next step is to create “Auth Policies”. These policies will be used to assign actions once users/devices connect. I am using the “Auth Policy” to assign RADIUS attributes such as VLAN and roles.
In the example below, if the Directory Role from the Idp is “employee” and they are using EAP-TTLS on the Wireless, they will get the RADIUS attributes of “employee” and VLAN “30”.
Similarly, if the Directory Role from the Idp is “contractor” and they are using EAP-TTLS on the Wireless, they will get the RADIUS attributes of “contractor” and VLAN “40”.

I was using my iPad and iPhone for testing, next I needed to get the TTLS profile loaded on them. I used “Apple Configurator” for that. First I needed to download the Mist Server Certificate. Simply copy the cert and save it as “mist_cert.crt”. This is the server cert that the device will need to trust to connect. NOTE: There was a little confusion on what should it say for the CN. I read “auth.mist.com” in some locations, but it would be the “Org ID”.



The following link has step by step directions on setting up the EAP-TTLS profile using the Apple Configurator. I basically created two profiles:
- Employee
- Contractor

Upload Mist Server Certificate that was saved earlier.

Fill in the Wi-Fi section as follows:
- SSID name – Mist-TTLS
- Protocols – TTLS
- Inner Authentication – PAP
- Trust – Check the Mist Server Certificate.



One thing to notice here is the use of PAP for “Inner Authentication”. Immediately, concerns around security come up, after all, “PAP” is supposed to be clear text. I am no security expert, however, I believe using EAP-TTLS as the outer authentication method and PAP as inner authentication can provide a decent secure 802.1X Wi-Fi SSID. But I leave that up to you and your needs and requirements to figure out what is best for you and your organization. I am not endorsing anything specific.
I encourage you to read up more on this here Is PAP Secure. I also highly recommend reading the following book, “Wireless Security Architecture” by Jennifer (JJ) Minella. Helped me clear up some security-related questions.

NOTE: I haven’t tried any other “Inner Autherntication” methods so far with EAP-TTLS, that is something I’d like to try it later.
Creating an SSID to use Mist Access Assurance is a simple process, you simply choose, “Mist Auth” under “Authentication Servers” and add the Dynamic VLANs with VLAN Type set as “Tunnel-Private-Group-ID”.

Connecting to an EAP-TTLS SSID:
Time to connect to the SSID and look at the logs. First, I logged in with the “contractor” profile and entered the wrong password.
The Mist dashboard shows the whole process and the failure reason.
- NAC Server Certificate was validated.
- IDP Credentials failed, which led to NAC denying the client access.
- The “Authorization Failure” log message Description shows the error with “username/password”. NOTE: Correct “User Group” was applied (contractor).
- Dynamic pcap.



Dynamic Packet Captures has been an excellent feature of Mist since the beginning. I was curious to see what information it would provide me when using Mist Access Assurance. I was able to view the complete process from the start to the failure and the “deauthentication”.

In the next step I am going to connect with the correct credentials. When the connection is successful, Mist Dashboard will show the logs showing the successful connection. List of steps:
- NAC Server Certificate Validation – No change to this
- NAC IDP Authentication Success – Success this time
- NAC IDP Group Lookup Success – This wasn’t present in the failure
- NAC Client Access Allowed – Success
- NOTE: It is important to mention that during this step you are able to see the “Auth Rule” that was used/applied for this client access by simply clicking on it (see the last screenshot). This can help troubleshoot Policy related issues.
- Authorization and Association – Success with the User Group assigned as “contractor”.




Lastly, since the “contractor” is assigned VLAN40 from the “Auth Policies”, DHCP Success shows the IP address from VLAN40.

If I follow the same process, install the “employee” profile and then connect to the Mist-TTLS SSID, I should get assigned the User Group “employee” and VLAN30.



NOTE: These roles can also be used with WxLAN policies to allow or deny access to certain resources. I will have to do a separate write up for that.
EAP-TLS Flow:
EAP-TTLS is great, but can Mist Access Assurance do EAP-TLS and how complicate is it to configure? Unlike EAP-TTLS, EAP-TLS requires client and server side certificates and uses a different flow. It can also be a daunting task setting it all up, you either need your own PKI infrastructure or some some kind of cloud based provider to issue certificates and then use MDM to push them out. Before going any further I’ll post a high level EAP-TLS Flow (Note we have already completed the Idp configuration).

I do not have my own PKI in the lab, nor access to any cloud based provider, so I used what Mist recommends for testing in the following video, “Optional – Certificate creation for lab/testing use“. It was simple to use, and I was able to get my own CA up and running in less than 10 min (that also included watching parts of that video multiple times to catch up). I will not go over every step, but I will post some screen shots of client certificate creation.







Note the .pfx file as it contains the complete chain. In production you wouldn’t be using this method, this is just for testing and lab.
CA that was created earlier that was used to create the client certificates can now be imported into the Mist Dashboard. Under “Certificate Authorities” click on “Add CA”, paste your cert and you are good to go. When clients connect they will be able to Authenticate to this server and since this CA issued the client certificates, it can authenticate the clients.

Auth Policies:
For EAP-TLS, I created the Auth Policies using the CN Label, but tested connectivity using the CN and Groups successfully.



Connecting to an EAP-TLS SSID:
After I loaded up the EAP-TLS profile for a contractor I was able to successfully connect using client certificates.






If I want to find out which Auth Policy this client device is hitting, I can get that information by clicking on the Auth Rule displayed in one of the steps. Since this is a “contractor”, it should be using the “contractor” Auth Policy.

What happens if I change it to using Groups and Employee profile?

Employee is hitting the employee authentication policy

Since this profile is supposed to use VLAN30, DHCP Success message should display VLAN 30 and and IP address from 192.168.30.x range.

EAP-TLS Issues:
When I first created the “employee” certificate and profile I created the certificate wrong and ran into issues with connectivity. My connection was not successful. When I looked into the Mist Dashboard I saw the following errors. My client was failing and getting deauthenticated; but why? Take a look at the User Group, this is supposed to be “employee” but it was showing up as “contractor”

Dynamic Packet Capture was also available for deeper analysis.

Client was not recognizing the the CA and I realized that when I created the “employee” cert, I created it wrong and not created it under the CA, I also used the wrong private key.


Summary:
As I mentioned previously that I am no NAC Expert, but the fact that I was able to setup working EAP-TTLS and EAP-TLS SSIDs in about 4 hours (which included watching the videos, some multiple times, reading the documentation, troubleshooting couple of issues using the the Mist Dashboard as I was testing different scenarios etc) is not bad at all. I have written about “Client Onboarding and PSK Portal” in the past, which is also part of Mist Access Assurance now. There isn’t a need to configure, manage and install an onsite appliance, cloud based NAC solution allows Geo-redundancy and resiliency. Integrates with the Mist Dashboard well for insights and troubleshooting. Two additional things I would like to test using Mist Access Assurance:
- What happens if there is no Internet connectivity, will my existing connections continue to work until session time out or will they drop.
- Micro-segmentation on the wire, GBP.
It is still an evolving product, looking forward to Juniper Mist adding more features to it, such s posture assessment, profiling, possibly Mist MDM etc. Thank you for reading, if you are deploying, have deployed or tested Mist Access Assurance, feel free to share your thoughts and feedback.