Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


使用 Azure IdP 集成配置基于证书的 (EAP-TLS ) 身份验证

我们可以通过集成外部身份提供程序 (IdP) 来扩展可扩展身份验证协议 - 传输层安全性 (EAP-TLS) 身份验证过程。通过此集成,IdP 将验证 EAP-TLS 身份验证交换,并确保只有受信任的用户才能访问网络。通过与 EAP-TLS 身份验证的 IdP 集成引入额外的验证,您可以增强网络访问控制 (NAC) 的稳健性。

在瞻博网络 Mist™ 中,您可以使用 OAuth 将 Microsoft Azure Active Directory (AD)(现在称为 Microsoft Entra ID)集成为身份提供程序。通过此集成,可以将 Azure AD 作为标识提供者与 Mist Access Assurance 结合使用,并执行以下操作:

  • 通过 OAuth 执行委派身份验证检查用户名和密码,从而通过 EAP-TTLS 对用户进行身份验证。
  • 获取用户组成员身份以在身份验证策略中利用它们。
  • 获取用户帐户状态信息(活动/挂起)。
  • 通过 EAP-TLS 或 EAP-TTLS 授权用户。

Azure AD 返回以下详细信息,可用于微调瞻博网络 Mist Access Assurance 中的身份验证策略:

  • 组成员身份:有关用户所属组的信息提供有关用户角色和权限的见解。

  • 帐户验证:帐户状态对于确保瞻博网络 Mist Access Assurance 仅向有效的活动用户授予网络访问权限至关重要。

  • 其他用户上下文:收集有关用户的其他信息使我们能够更好地了解用户的个人资料。配置身份提供程序查找时,系统会向配置的身份提供程序发送 API 请求,以便为经过身份验证的用户获取其他上下文。


此任务演示如何在评估证书时查找与特定域名关联的公用名 (CN) 的 Azure AD。Azure AD 查找的结果提取有关用户的其他信息,这些信息将用于定义身份验证策略。此任务适用于无线网络。

作为此任务的先决条件,您必须配置 EAP-TLS 身份验证。有关详细信息,请参阅 配置基于证书的 (EAP-TLS ) 身份验证


  1. 在 Azure 门户上创建新应用程序,以将 Azure AD 用作 IdP。
  2. 将 Azure AD 集成为 IdP,并在 Microsoft Graph 中为已注册的应用程序授予 API 权限。
  3. 检索有关登录到瞻博网络 Mist 门户的用户的详细信息。
  4. 使用 IdP 获取的有关已登录用户的其他详细信息进一步细化身份验证策略。

要使用 Okta 作为 IdP 创建身份验证,请观看以下视频:

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 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.

为无线网络配置基于证书的 (EAP-TLS) 身份验证

  1. 在 Microsoft Azure 门户上,在 Azure AD 上设置 IdP 连接器。
    1. 使用凭据登录到 Azure 门户并导航到 Azure AD。
    2. 在左侧导航栏中,选择“应用注册”。
      图 1:新应用程序注册 New Application Registration
      如果已注册应用程序,请转到 “拥有的应用程序 ”选项卡。单击应用程序名称以查看客户端 ID、租户 ID 和客户端密码等详细信息。
      如果要在 Azure 门户上注册新应用程序,请单击“ 新建注册 ”选项卡。
      • 名称 - 输入 Mist AA IDP connector
      • 支持的帐户类型 - 仅选择此组织目录中的帐户
    3. 单击注册以继续。
      将出现一个页面,显示有关新创建的连接器的信息,如图 2 所示。
      图 2:新应用程序详细信息 New Application Details
    4. 记下以下详细信息,您需要在瞻博网络 Mist 门户上设置 IdP 连接器:
      • 应用程序(客户端)ID - 您需要在 OAuth 客户端凭据 (CC) 客户端 ID 和资源 所有者密码凭据客户端 ID 字段中输入此信息。
      • 目录(租户)ID - OAuth 租户 ID 字段需要此信息。
    5. 在左侧导航栏上,选择“证书和机密>新建客户端机密”。
      输入以下详细信息,然后单击 添加
      • 名字
      • 到期时间
      系统生成 密钥 ID ,如图 3 所示。
      图 3:客户端密钥详细信息 Client Secret Details

      记下“值”字段中的信息。将 Azure AD 添加为 IdP 时,瞻博网络 Mist 门户中的 “OAuth 客户端凭据客户端密码” 字段需要此信息。

  2. 向 Azure AD 应用程序授予委托权限和应用程序权限。使用这些权限,应用程序可以读取用户、组和目录信息。
    1. 在已注册应用程序的 Azure 门户页上的左侧导航栏中,选择“API 权限”>“添加权限”。
      您必须为应用程序授予所需的访问权限,才能使用 Microsoft Graph API 获取有关用户的信息。
    2. 在“添加权限”页上的“Microsoft Graph”下,在“委派的权限”和“应用程序权限”选项卡上添加以下权限。
        • Directory.Read.All
        • Group.Read.All
        • 用户阅读
        • User.Read.All

      单击“ 为 AD 授予管理员同意 ”,如图 4 所示。

      图 4:应用程序的 API Permissions for Application API 权限

      应用程序需要在 Azure AD 中运行应用程序权限。当连接器使用用户名和密码进行身份验证时,委派的权限是必不可少的。

  3. 在瞻博网络 Mist 门户上,添加 Azure AD 作为标识提供者。
    1. 在瞻博网络 Mist 门户的左侧菜单中选择组织>访问>身份提供程序
      此时将显示“身份提供程序”页面,其中显示已配置的 IdP(如果有)的列表。
    2. 单击添加 IDP 以添加新的 IDP。
    3. “新建身份提供程序”页上,输入所需信息,如图 5 所示。
      图 5:将 Azure AD 添加为标识提供者 Add Azure AD as Identity Provider
      1. 名称 - 输入 IdP 名称(在此示例中,使用 Azure AD)
      2. IDP 类型 - 选择 OAuth
      3. OAuth 类型 - 从下拉列表中选择“ Azure ”。
      4. OAuth 租户 ID - 输入 Azure AD 租户 ID。
      5. 域名 - 输入域名,即用户的用户名(例如。域名字段检查传入的身份验证请求,标识相应的用户名和关联的域。为连接器设置域名后,连接器可以标识需要与之通信的 Azure 租户。
      6. OAuth 客户端凭据 (CC) 客户端 ID - 输入已注册的 Azure AD 应用程序的客户端 ID。
      7. OAuth 客户端凭据 (CC) 客户端机密 - Azure AD 应用程序机密。Azure AD 应用程序机密。输入 Azure 门户为 IdP 连接器生成的客户端机密的值组件。
      8. OAuth 资源所有者密码凭据 (ROPC) 客户端 ID — 输入 Azure AD 应用程序 ID。此 ID 与 OAuth 客户端凭据客户端 ID 相同。

当您使用 EAP-TLS 对用户进行身份验证时,瞻博网络 Mist 会将用户名与指定的域名进行匹配。瞻博网络 Mist 向相应的 Azure AD 租户发送 API 请求,以获取该用户的详细信息。

图 7图 6 显示了用户在 Azure AD 和瞻博网络 Mist 门户中的详细信息。

图 6: Azure AD User Details on the Azure AD 上的用户详细信息

在瞻博网络 Mist 门户上,可以查看 Azure AD 返回的组成员身份信息。在瞻博网络 Mist 门户上,导航到“ 监控>见解”>“客户端事件 ”以查看信息。

图 7:瞻博网络 Mist 门户 User Details on Juniper Mist Portal上的用户详细信息

图 7 所示的示例中,用户属于组 Employee



您可以根据 IdP 检索的用户组成员身份,使用带有目录属性的标签创建身份验证策略。


  1. 在瞻博网络 Mist 门户的左侧菜单中,选择组织>访问>身份验证策略
  2. 在身份验证策略页面上,单击创建标签并输入详细信息。
    图 8:身份验证策略 Labels for Authentication Policies的标签
    • 根据 IdP 检索到的用户组成员身份,创建标签类型为目录属性标签员工组。选择标签值作为,选择组值作为员工。使用此标签作为策略匹配标准。
    • 创建标签员工 角色 ,标签类型为 AAA 属性。选择标签值作为 角色 ,选择角色值作为 员工。使用此标签分配策略。
  3. 通过单击添加规则创建身份验证策略。系统将插入一个新行,允许您添加新策略。
    图 9:为身份验证策略 Create Labels for Authentication Policy创建标签
    1. 输入策略名称。

    2. 单击“匹配标准”列中的添加图标 (+),然后从显示的列表中选择用户标签。选择基于目录属性创建的标签(员工组)。

    3. 在“策略”列中,单击复选标记图标 (✓),然后选择要对接下来要标识的资源强制执行的操作“允许”或“阻止”。

    4. 单击“分配的策略”列中的 (+),然后选择基于已分配策略的 AAA 属性创建的标签(员工角色)。由于用户是员工组的一部分,因此您可以分配员工角色并将其移动到公司 VLAN

  4. 单击保存

    图 10 显示了已完成的身份验证策略。

    图 10:身份验证策略 Authentication Policy

在 WLAN 模板中创建身份验证策略

要为无线网络构建 WLAN 策略,我们需要首先创建用于分组和标识用户和资源的标签。这是设计策略的两个主要组件。标签允许您对用户/用户组或资源/资源组进行分类。有关详细信息 ,请参阅创建用户访问策略

  1. 通过在瞻博网络 Mist 门户中选择“组织>无线>标签”,在组织级别创建标签。只有组织级别的标签可用于 WLAN 策略。
    图 11:创建新标签 Create New Label
    输入详细信息,例如标签名称、标签类型作为 AAA 属性和标签值作为用户组。
  2. 转至组织>WLAN 模板。此时将显示“WLAN 模板”页面,其中显示现有 WLAN 模板的列表。在此示例中,使用现有模板。
  3. 选择模板,然后单击以打开模板页面。
  4. 向下滚动到策略部分,然后单击添加规则以创建新策略。
  5. 单击“用户”列中的添加图标 (+),然后从显示的列表中选择用户标签。
  6. 在“策略”列中,单击复选标记图标 (✓),然后选择要对接下来要标识的资源强制执行的操作“允许”或“阻止”。
  7. 单击“资源”列中的添加图标 (+),然后从显示的列表中选择一个或多个预定义应用程序。
  8. 完成策略的创建和排序后,单击屏幕顶部的“保存”。

以下视频演示了在使用与 Azure AD 集成的基于证书的 (EAP-TLS) 身份验证时,如何在 WLAN 模板中配置身份验证策略。

Your rule configured, let's validate. Let's take a look at which policy is now being hit for this particular user. So we went in and did the client certificate check. Let's just refresh those events so we see them. All right, so we went in and client trusted the server cert. We trusted the client cert. We then did an IDP lookup, right? Same thing as your ID. We got the three IDP roles.

Now, let's look at this client access allowed. We got the VLAN 750. We got the user group or role called employee. And now we are actually hitting that different rule now. Because we have this additional context, additional visibility from the IDP, we can now do differentiated access policies for our clients.

Now, what you could do with this employee role - how can you use it on the wireless side? You could go to organization labels. You can create a label AAA attribute. Let's call it "Employee." You'll match on the user group. And what you'll do, you could go to your WLAN template. You can create a network policy now. You can say, OK, if the user is part of this employee role or employee group, we can now decide which resources it can or cannot access on the network. So we can say, OK, let's probably block Facebook for employees and hit Save. This is how you can extend the role that's being supplied by the NAC and then apply it on the AP to do some additional restrictions on which resources the user is able to access.