用例和参考架构

用例概述

各种客户端类型可以通过各种方式访问企业网络。这就需要建立某种联合方式，来决定如何管理和授予对这些设备的访问权限，并定义每个客户端可以使用的网络资源。

架构：为什么要使用 RADIUS 协议？

如今，所有中央企业身份验证架构都基于 RADIUS 协议的使用，并使用 IEEE 802.1X 通过各种 EAP 方法进行强客户端身份验证。

企业中有时还会使用另外两种身份验证协议：

• TACACS 和 TACACS+ 可被视为传统协议。今天，它们有时仍被用于设备上的管理 CLI 访问，但也可以通过 RADIUS 来完成。请勿在新的部署中使用它。Juniper Mist Access Assurance 不支持此协议。
• Diameter 是一种不断演进的协议，它更复杂，但为协议路由和消息传递的稳健性添加了更多功能。该协议的主要用途是在移动网络中取代传统的SS7协议。Juniper Mist Access Assurance 不支持此协议。

RADIUS 协议在 IETF RFC 2865 和 RFC 2866 中定义。它有三个主要目的：

• 身份验证 - 希望访问网络的用户和设备的身份验证。身份验证可以只是一个简单的用户名和密码检查，或者对推出的PKI进行一些基于证书的检查，检查智能卡或移动SIM卡等等。因此，协议本身可针对新的身份验证方法进行扩展。
• 用户和设备成功通过身份验证后的 授权。作为身份验证的一部分，将决定用户或设备是否可以不受任何限制地访问整个网络，或者是否以某种方式限制了对网络的访问。此限制的含义取决于您可以限制哪些访问权限以及如何限制。最常见的示例是将 VLAN 分配给企业网络中的有线或无线客户端，因为分配的 VLAN 限制了用户可以访问的资源。
• 核算 - 用户和设备的 核算。在执行身份验证并应用授权后，网络将定期提供有关客户端使用网络的统计信息，例如在网络上的时间和传入和传出的字节。这在服务提供商网络中用于计费目的更为重要，但在企业网络中不太常用。

以下各项对于了解 RADIUS 协议至关重要。但是，我们没有审查该协议的全部细节以及它如何在这里实施。如果您需要更多信息，请考虑查看该协议的原始 RFC 或 其维基百科文章 。

• 该协议使用 UDP 消息进行交换。如果消息在传输过程中丢失，则会发生几次自动重新传输，直到请求被丢弃。
• RADIUS 协议本质上是可扩展的。默认属性值对 （AVP） 在 RFC 中定义，但供应商可以创建特定于其设备的新 AVP。通常，进行此类扩展是为了共享有关设备的更多信息或增强授权参数以提供更精细的实施点。
• 网络接入设备位于网络边缘的流量入口点：
  • 在企业网络中，这是接入交换机或接入点。
  • 它可以是远程分支机构中的多个实例，也可以是园区交换矩阵最低层的多个实例。
  • 未定义设备连接到网络访问设备时使用的协议。最常见的是，您会看到：
    • 以太网交换机端口上出现新的 MAC 地址。
    • 启动 EAP 身份验证的有线或无线客户端（本章稍后会详细介绍）。
  • 用户或客户端的授权强制执行通常发生在此级别。
  • 网络访问设备实现了 RADIUS 客户端，该客户端将所有消息封装为 RADIUS UDP 消息并将它们发送到 RADIUS 服务器。
• RADIUS 服务器通常位于网络的中心位置，可由使用 VPN（或公共 IP 地址）的网络访问设备访问，从而被动响应 RADIUS 客户端消息。
  • 出于冗余原因，通常会部署两台 RADIUS 服务器。但是，网络访问设备会选择何时故障转移到另一台 RADIUS 服务器。
  • 如果供应商扩展了标准 RADIUS 属性，则还必须通过供应商的 RADIUS 字典配置特定于供应商的属性，以便利用这些 RADIUS AVP。
  • RADIUS 服务器是网络中用于检查客户端身份验证的决策点。
    • 通过网络访问设备获取某种转发的客户端凭据。
    • 也从凭据数据库中检索客户端凭据。
    • 比较两组信息并确定它们是否有效，因此客户端可以通过或不通过。
  • RADIUS 服务器可以具有本地内置凭据数据库，也可以具有可使用标准协议远程访问的凭据数据库。这些协议通常是以下协议之一：
    • 使用公共 IdP 进行身份验证时为 OAuth2。
    • 使用本地（活动）目录时的轻型目录访问协议 （LDAP）。
    • SQL 或 HLR/HSS 数据库通常由（移动）服务提供商使用。
  • 除了用户记录，本地或远程凭据数据库还包含有关在客户端成功进行身份验证后要使用的授权配置文件的信息。
  • 成功完成用户身份验证后，RADIUS 服务器会使用 Access-Accept 消息进行响应，该消息还可以包含：
    • 动态加密密钥材料，用于在客户端设备和网络接入设备之间进一步建立安全通信。
    • 授权 RADIUS 在网络访问设备上强制实施 AVP，以限制客户端对网络的访问。使用特定于供应商的 AVP，RADIUS 服务器将仅发送网络访问设备上可理解的 AVP。

图 2 显示了 RADIUS 协议在网络中的实施位置及其使用方式。

图 3 中的示例工作流程在交换机上使用基于 MAC 地址的身份验证来审视该框架如何协同工作。

1. 希望访问有线网络的设备会发送一些消息（ARP/DHCP 请求）。
2. 交换机会在端口上看到新的 MAC 地址，并阻止与网络的所有进一步通信。
3. 新检测到的 MAC 地址将转换为用户名和密码，并作为 RADIUS 访问请求发送以供批准。还会嵌入其他 RADIUS AVP，例如描述有关请求的位置（端口信息）的 AVP。
4. 收到 RADIUS 访问请求后，RADIUS 服务器会分析 RADIUS 消息的内容，并提取执行身份验证所需的 RADIUS AVP。在我们的例子中，使用了 username 属性，并将请求发送到内部凭证数据库以接收有关用户名的信息（与客户端的 MAC 地址相同）。
5. 如果已找到用户记录，则凭据数据库返回空密码，如果有效，则返回用于此客户端的密码和授权配置文件（通常是字符串）。
6. RADIUS 服务器比较从客户端和凭据数据库发送的密码。如果它们匹配，则会创建一条 Access-Accept 消息作为对交换机的响应。作为成功身份验证的一部分，授权配置文件用于添加为特定网络访问设备（交换机）存储的 RADIUS AVP，并将其添加到 Access-Accept 消息中。在我们的案例中，我们希望客户端使用特定的 VLAN，因此，属性“Tunnel-Private-Group-ID”包含配置为参考的交换机上的 VLAN 名称。
7. RADIUS 服务器将 Access-Accept 以及授权信息（要分配的 VLAN）返回给客户端。
8. 交换机作为网络接入设备，在收到 Access-Accept 消息后，允许客户端通过取消阻塞端口与网络进行进一步通信。如果交换机也获得授权 RADIUS AVP，则也会应用这些 AVP。在我们的案例中，分配给端口的默认 VLAN 将替换为我们已授权客户端使用的 VLAN。
9. 可选：创建 RADIUS Accounting-Start 消息并将其发送到 RADIUS 服务器。同样，这在企业网络中不是必需的。
10. 可选：RADIUS 服务器可以在本地存储或转发此信息到某种数据库中。
11. 可选： RADIUS 服务器将确认计费消息。
12. 客户端现在可以访问网络了。如果已使用授权，交换机将强制执行授权并以某种方式限制访问。

注意：

在我们的示例中，使用了一个简单的基于 MAC 地址的身份验证 （MAB）。但是，已知的 MAC 地址很容易被攻击者重复使用。因此，仅当客户端不支持 802.1X 身份验证时，才应使用 MAB。

架构： 802.1X 身份验证：它是什么？

• 基于端口的网络访问控制标准。
• 可以提供非常强大的加密身份验证。
• 始终涉及三方：
  • 恳求者——希望访问 LAN 或 WLAN 的设备。在此 JVD 中，我们有以下请求者：
    • Windows 11 桌面客户端有线或无线
    • Linux 桌面客户端有线或无线
  • 身份验证器—一种在客户端和网络之间提供数据链路的网络访问设备，可以允许或阻止两者之间的流量。在此 JVD 中，我们有以下身份验证器：
    • ® 瞻博网络 EX 系列交换机
    • ® 瞻博网络系列高性能接入点
  • 身份验证服务器 —接收并响应网络访问请求。在这个 JVD 中，我们有以下身份验证服务器：
    • Juniper Mist Access Assurance
• 定义 EAP 的封装方法：
  • 使用的 EAP 方法是可交换的。它们在请求方（逐一提供它支持的不同封装方法）和身份验证服务器（它承认请求方提供的方法它支持的方法）之间协商。
  • 请求方和身份验证服务器之间最常见的传输是 EAP over LAN （EAPoL）。从 NAS 到身份验证服务器，这些消息会在 RADIUS 内部通过隧道传输。
  • 请求方选择要使用的外部 EAP 身份，称为网络访问标识符 （NAI），如 RFC 2486 中首先所述。这允许接收身份验证服务器将请求代理到另一个身份验证服务器，以防它不负责漫游客户端。
  • NAS/验证器不参与认证过程本身。该过程仅在请求方和身份验证服务器之间处理。NAS/身份验证器仅转发消息。这意味着，如果验证器支持 802.1X，它将能够处理所有已知的 EAP 协议。问题始终是请求方和身份验证服务器是否都支持给定的 EAP 协议。
  • 根据所使用的 EAP 协议，身份验证服务器向验证方发送的 Access-Accept 消息可以包含动态创建的加密密钥材料。然后，这可用于在请求方和验证方之间建立加密链路。最常用的是用于 WLAN 访问的企业级动态 WPA2 和 WPA3 加密。

图 5 中的示例显示了具有内部 PAP 身份验证方法的 EAP-TTLS，该方法涉及以下内容：

• 此 EAP 方法使用企业公钥基础架构 （PKI） 生成和预部署以下证书信息：
  • RADIUS 服务器上的根 CA、任何中间签名 CA 和 TLS 服务器证书（使用公钥和私钥）。
  • 根 CA 和任何中间签名 CA，通过某种企业设备管理方法发送给请求方。这是验证服务器提供的证书所必需的。
• 然后，请求方开始发送 EAPoL 消息，验证方会在 RADIUS 消息内部转发到身份验证服务器，以执行以下作：
  • 在请求方和 RADIUS 服务器之间建立安全的 TLS 隧道。
  • 在 TLS 隧道内（下图中未显示），将交换用户名和密码凭据。
• 与之前基于 MAC 地址的身份验证一样，这些凭据将针对凭据数据库进行交换，并在身份验证服务器上进行验证。
• 如果凭据检查验证可选授权，则 RADIUS AVP 可能会添加到返回的 Access-Accept 消息中。在此示例中，我们强制执行要使用的特定 VLAN。
• 然后，当验证方从身份验证服务器收到回 Access-Accept 消息时，验证方会监督请求方的访问开放，并强制执行所有收到的授权参数（在本例中，将客户端访问特定 VLAN 的权限授予）。

注意：

为了更好地与前面的示例进行比较，我们删除了嵌入式动态加密密钥材料分发以及请求方和验证方之间加密链路的任何后续协商，这通常是 WPA2 和 WPA3 企业 WLAN 客户端的典型做法。

在企业网络中，应在技术上可行的情况下使用强大的 EAP 方法。查看下图以能够选择最佳方法。

在技术上无法使用 EAP 的情况下，请考虑下图所示的选项。

架构：在验证方和 RADIUS 服务器之间使用 RadSec 隧道

Juniper Mist Access Assurance 解决方案在验证方和 RADIUS 服务器之间使用围绕 RADIUS UDP 消息的附加协议/隧道。

• 此隧道基于 TLS V1.2 和 V1.3 协议，例如用于通过 HTTPS 保护 Web 服务器连接的协议。
• 通往 RADIUS 服务器的 TCP 目标端口为 2083。
• RADIUS 服务器是 Juniper Mist 身份验证云的一部分，可通过 FQDN radsec.nac.mist.com 访问。
• Juniper Mist身份验证云负责创建证书并将其加载到身份验证器，以便可以与身份验证云构建 TLS 连接。因此，Juniper Mist 为每个组织创建自己的 PKI。

选择这种 RadSec 设计的原因有几个技术原因。

• 当 RADIUS 服务器在 Internet 上处于远程状态时，这是一种更可靠的传输。
• 凭据和客户端信息得到保护，免受窃听和中间人攻击（如 RadSec TLS 隧道导致 的爆炸半径 ）。这也放宽了对在 RADIUS 客户端和服务器之间定义强大且单独的共享密钥的需求。
• 企业防火墙管理员在打开 TLS 连接时比打开远程 UDP 端口更有信心。
• 通过使用固定 FQDN，该解决方案能够通过全局 DNS 负载均衡器选择最近的Juniper Mist身份验证云。RadSec 终止总是发生在最近的可用Juniper Mist身份验证云上，以优化延迟。
• 如果使用第三方设备或瞻博网络交换机（不是由Juniper Mist云进行管理），则需要规划额外的代理。该代理的作用类似于传统现场 RADIUS 的替代品，并在 RADIUS 和 RadSec 之间向Juniper Mist身份验证云转换。Juniper Mist™ Edge 设备可用于托管此代理服务。
• RADIUS 未来使用 授权更改消息非常容易嵌入，因为Juniper Mist RADIUS 服务器可以对这些消息使用现有的 TLS 隧道。

需要注意的是，旧版 RADIUS 服务器不再是本地服务器，需要通过企业 VPN 访问。它现在是 Juniper Mist 身份验证云产品/服务的一项功能。凭据数据库通常也不是本地的，因为客户开始采用公共 IdP（如 Azure AD 和 Okta），因为现在不仅需要对客户端凭据进行身份验证。RadSec 隧道和配置由 Juniper Mist 身份验证云进行管理，以无缝实现这一点。

架构：Juniper Mist Access Assurance 框架

下图突出显示了 Juniper Mist Access Assurance 的整个最终框架。请注意，Access Assurance 管理员使用且只能看到用于管理交换机和接入点的同一Juniper Mist门户。

参考本章中使用本地 RADIUS 服务器和凭据数据库进行的第一个身份验证示例（图 3），将其与 图 8 进行比较。请注意 图 8 中的差异：

• Juniper Mist身份验证云负责监督证书的创建，以及将证书加载到用于构建 RadSec 隧道的身份验证器设备上。
• RADIUS 服务器和凭据数据库已移至Juniper Mist身份验证云。
• 现在在身份验证器和 Juniper Mist Access Assurance（RADIUS 服务器）之间使用 RadSec 作为 TLS 隧道。
• 所有剩余的工作流程保持不变，并且不会改变其运行方式。

图 9 添加了一个 Juniper Mist Edge 设备作为上述图 8 的代理。如果您的第三方设备（交换机和接入点）或瞻博网络 EX 交换机不是由Juniper Mist云托管的，那就适用了这种情况。如果您现有 RADIUS 服务器，则可以使用 Mist Edge 代理作为即插即用的替代品，无需对现有交换机或接入点配置进行任何更改。

图 10 显示了在实施 RadSec 和 Juniper Mist Access Assurance 时 EAP 身份验证方法会发生什么变化：

• Juniper Mist身份验证云负责监督证书的创建，以及将证书加载到用于构建 RadSec 隧道的身份验证器设备上。
• RADIUS 服务器已移至Juniper Mist身份验证云。
• 凭据数据库已移至公共 IdP。
• RadSec 作为 TLS 隧道现在用于验证方和 Juniper Mist Access Assurance（RADIUS 服务器）之间。
• 所有剩余的工作流程保持不变，并且不会改变其运行方式。

在 图 11 中，您可以看到包含一个 Juniper Mist Edge 设备作为上图的代理，如上图所示。

在分支机构和园区交换矩阵设计中实施

NAC 解决方案始终发生在客户端进入网络的地方。您必须能够阻止未经身份验证设备的流量，或者通过网络最低入口层的授权实施来限制访问。根据设计，NAC 解决方案独立于网络接入后进行的传输。NAC 解决方案不关心转发是基于 VLAN、VXLAN 还是路由。下表列出了可能的排列：

表 1：Access Assurance 实施详细信息

位置	访问 方法	设计	Mist 云 管理？	NAC 需要 地点	RadSec 支持？	Mist Edge 需要代理吗？
分支	有线	独立瞻博网络交换机	是的	接入交换机	是的	不
分支	有线	瞻博网络虚拟机箱	是的	接入交换机	是的	不
分支	无线电	Mist 接入点	是的	接入点	是的	不
分支	有线	瞻博网络交换机/虚拟机箱	不	接入交换机	不	是的
分支	有线	瞻博网络交换机/虚拟机箱未Mist托管	不	接入交换机	不	是的
分支	有线	第三方交换机	不	接入交换机	不	是的
分支	无线电	第三方接入点	不	接入点	不	是的
CF EVPN 多宿主 / CRB / ERB	有线	独立瞻博网络交换机	是的	接入交换机 / ToR	是的	不
CF EVPN 多宿主 / CRB / ERB	有线	瞻博网络虚拟机箱	是的	接入交换机 / ToR	是的	不
CF EVPN 多宿主 / CRB / ERB	无线电	Mist 接入点	是的	接入点	是的	不
CF EVPN 多宿主 / CRB / ERB	有线	瞻博网络交换机/虚拟机箱	不	接入交换机 / ToR	不	是的
CF EVPN 多宿主 / CRB / ERB	有线	瞻博网络交换机/虚拟机箱未Mist托管	不	接入交换机 / ToR	不	是的
CF EVPN 多宿主 / CRB / ERB	有线	第三方交换机	不	接入交换机 / ToR	不	是的
CF EVPN 多宿主 / CRB / ERB	无线电	第三方接入点	不	接入点	不	是的
CF IP-Clos	有线	独立瞻博网络交换机	是的	接入交换机/叶式	是的	不
CF IP-Clos	有线	瞻博网络虚拟机箱	是的	接入交换机/叶式	是的	不
CF IP-Clos	无线电	Mist 接入点	是的	接入点	是的	不
CF IP-Clos	无线电	第三方接入点	不	接入点	不	是的

图 12 描述了使用 Access Assurance 的最常见部署选项。

一旦针对 RadSec（或带 Edge 代理的 RADIUS）配置了网络接入设备Juniper Mist就可以根据客户要求开始集成 NAC 解决方案了。下面是典型任务的示例：

• 目前，Juniper Mist Access Assurance 解决方案支持以下身份验证方法：
  • 密码认证协议 （PAP） — 主要用于基于 MAC 地址的认证。
  • 可扩展认证协议传输层安全性 （EAP-TLS） — 主要用于机器身份验证，因为它需要从企业 PKI 预部署到请求方的证书。
  • 使用 PAP 作为内部身份验证的可扩展身份验证协议隧道传输层安全 （EAP-TTLS） — 当需要根据 IdP 核对用户名和密码时，主要用于用户身份验证。
  • 不太常见：受保护的可扩展身份验证协议传输层安全性 （PEAP-TLS）（请注意，不支持 PEAP-MS-CHAPv2，因为 OAuth2 等后端方法不支持 NTLM 哈希）。
  • 不太常见： 带有 TLS 的隧道可扩展身份验证协议 （TEAP）。请考虑迁移到 EAP-TLS。

不在此列表中的方法需要与客户讨论以及如何更改使用它们的设备。这些方法通常由传统设备使用，需要评估是否正确支持它们。

• 讨论存在哪些凭据数据库以及如何将它们集成到身份验证和授权过程中。
  • 对于基于MAC 地址的身份验证，Juniper Mist Access Assurance 托管允许的 MAC 列表（您还可以选择通过 OUI 标识供应商）。
  • 最常用的公共 IdP 包括：
    • Azure AD
    • Okta 在 Juniper Mist 身份验证云和 IdP 之间利用 OAuth2。
    • Google Workspace 在 Juniper Mist 身份验证云和 IdP 之间利用 LDAP over SSL （LDAPS）。
    • 对于其他使用 OAuth2 的 IdP，请联系您的瞻博网络代表。
• 讨论对授权配置文件的需求以及如何将其应用于网络访问设备（尤其是在使用第三方供应商属性时）。
• 讨论企业 PKI 的需求：
  • 大多数客户都有可以使用的现有 PKI。获取公共根 CA、任意中间 CA，并要求 IT 人员为 Juniper Mist Access Assurance RADIUS 服务器的 PEM 格式的 TLS 服务器生成公钥/私钥。
  • 当请求方被引入Juniper Mist根 CA 时，为每个组织生成并用于 RadSec 的Juniper Mist PKI 可以重新用于 EAP-TTLS。
  • 使用用户或计算机证书（EAP-TLS、PEAP-TLS 和 TEAP-TLS）的所有方法都应通过客户的移动设备管理 （MDM） 从客户的企业 PKI 获取证书。
• 讨论对物联网设备的需求，因为它们通常不会利用强大的 EAP 身份验证方法，因为所需的计算会耗费大量电池。回退通常是基于 MAC 的身份验证或用于 WLAN 的 MPSK。
• 讨论对 BYOD 集成和门户页面的需求。
• 在教育环境中，可能需要像 Eduroam 这样的漫游支持。
• 讨论需要充当请求方的接入点是否需要在交换机端口上进行身份验证。在固件较新的非 EOL 瞻博网络接入点上支持此功能。