通过

安全和Skype for Business联机

  • 项目
  • 适用于:
    Skype for Business, Skype for Business Online, Microsoft Teams

重要

由世纪互联在中国运营的Skype for Business将于2023年10月1日停用。 如果尚未升级 Skype for Business Online 用户，系统会自动安排他们进行辅助升级。 如果想要自行将组织升级到 Teams，强烈建议你立即开始规划升级路径。 请记住，成功升级与技术和用户就绪情况一致，因此在导航到 Teams 旅程时，请务必利用我们的 升级指南 。

Skype for Business Online（不包括世纪互联在中国运营的服务）已于 2021 年 7 月 31 日停用。

Skype for Business Online (SfBO) ，作为 Microsoft 365 和 Office 365 服务的一部分，遵循所有安全最佳做法和过程，例如通过深层防御实现的服务级别安全性、服务中的客户控制、安全强化和操作最佳做法。 有关完整详细信息，请参阅Microsoft信任中心 (https://microsoft.com/trustcenter) 。

设计上可信任

Skype for Business Online 的设计和开发符合 Microsoft 可信计算安全开发生命周期 (SDL) 的要求（https://www.microsoft.com/sdl/default.aspx 有具体说明）。 创建更安全的统一通信系统的第一步是设计威胁模型，并按每项功能的设计要求对其进行测试。 多个与安全相关的改进功能内置在编码过程和实践中。 生成时工具会在将代码签入到最终产品之前检测缓冲区溢出和其他潜在安全威胁。 无法针对所有未知安全威胁进行设计。 没有任何系统会保证完全的安全。 但是，由于产品开发从一开始就遵循安全设计原则，Skype for Business Online 将行业标准安全技术作为其体系结构的基本组成部分。

默认可信任

Skype for Business Online 中的网络通信默认进行加密。 通过要求所有服务器使用证书，以及使用 OAUTH、TLS、Secure Real-Time Transport Protocol (SRTP) 和其他行业标准加密技术（包括 256 位高级加密标准 (AES) 加密），所有Skype for Business Online 数据都会在网络上受到保护。

SfBO 如何处理常见的安全威胁

本部分介绍 SfBO 服务安全面临的更常见威胁，以及Microsoft如何缓解每个威胁。

被盗用密钥攻击

密钥是用于加密、解密或验证机密信息的机密代码或数字。 在公钥基础设施 (PKI) 中使用的敏感密钥有两个必须考虑的因素：每个证书持有者拥有的私钥以及在通信伙伴成功识别和会话密钥交换后使用的会话密钥。 破解密钥攻击是指攻击者破解私钥或会话密钥的行为。 攻击者在成功破解密钥之后，可以使用此密钥对已加密的数据进行解密，而数据的发送者对此毫不知情。

Skype for Business Online 使用 Windows Server 操作系统中的 PKI 功能来保护用于加密传输层安全性 (TLS) 连接的密钥数据。 用于媒体加密的密钥是通过 TLS 连接进行交换。

网络拒绝服务攻击

如果攻击者阻止有效用户正常使用网络和正常工作，就会发生拒绝服务攻击。 利用拒绝服务攻击，攻击者可以：

  • 向受到攻击的网络中正在运行的应用程序和服务发送无效数据，干扰它们的正常工作。
  • 发送大量流量以造成系统过载，直到系统停止对合理请求做出响应或对合理请求做出响应的速度变得很慢。
  • 隐藏攻击证据。
  • 阻止用户访问网络资源。

SfBO 通过运行 Azure DDOS 网络保护并限制来自同一终结点、子网和联合实体的客户端请求来缓解这些攻击。

窃听

在攻击者获取对网络中数据路径的访问权并能够监控和读取流量内容时，会发生窃听。 窃听也称为监听或窥探。 如果流量内容采用纯文本形式，则攻击者在获取路径的访问权之后即可读取流量内容。 例如，通过控制数据路径上的路由器进行攻击。

SfBO 使用相互 TLS (MTLS) 在 Microsoft 365 或 Office 365 内的服务器通信以及从客户端到服务的 TLS，使得在给定会话可能受到攻击的时间段内难以实现此攻击。 TLS 可对各方执行身份验证，并对所有流量内容进行加密。 这不会防止窃听，但攻击者无法读取流量，除非加密已中断。

借助从几个项（包括从不以明文格式发送的 TURN 密码）派生的密钥 SfBO 服务可通过检查消息完整性来确保数据有效。 TURN 协议不强制要求对流量进行加密，由该协议发送的信息受消息完整性保护。 尽管它愿意进行窃听，但它发送的信息 (即 IP 地址和端口) 可以直接通过查看数据包的源地址和目标地址来提取。 SfBO 服务通过使用从几个项派生的密钥（包括 TURN 密码）检查消息的消息完整性来确保数据有效，该密码永远不会以明文形式发送。 SRTP 用于媒体流量并且也被加密。

标识欺骗（IP 地址欺骗）

当攻击者在未经授权的情况下确定和使用网络、计算机或网络组件的 IP 地址时，会发生欺骗。 如果攻击成功，攻击者可以像通常由 IP 地址标识的实体一样执行操作。 在 Microsoft Lync Server 2010 的上下文中，仅当管理员执行了以下两项操作时，才会出现这种情况：

  • 配置的连接仅支持传输控制协议 (TCP) (不建议这样做，因为 TCP 通信) 未加密。
  • 将这些连接的 IP 地址标记为受信任的主机。

此操作对于传输层安全性 (TLS) 连接而言不成问题，因为 TLS 对所有方进行验证并加密所有通信。 使用 TLS 可防止攻击者对特定连接（例如，相互 TLS 连接）执行 IP 地址欺骗攻击。 但攻击者仍可能欺骗 SfBO 使用的 DNS 服务器的地址。 但是，由于 SfBO 中的身份验证是使用证书执行的，因此攻击者不需要有效的证书来欺骗通信中的一方。

中间人攻击

当攻击者在发生通信的两个用户不知情的情况下，通过自己的计算机重新路由这两个用户之间的通信时，就会发生中间人攻击。 攻击者可以在将通信内容发送到预期接收人之前监控和读取通信内容。 通信中的每个用户在不知不觉中向攻击者发送流量并接收来自攻击者的流量，同时认为他们只与目标用户通信。 如果攻击者可修改 Active Directory 域服务以将他（她）的服务器添加为受信任服务器或修改域名系统 (DNS) 以让客户端在与服务器通信时通过攻击者，则会发生这种情况。

中间人攻击还可能发生在两个客户端之间的媒体流量中，但在 SfBO 中点对点音频、视频和应用程序共享流使用基于 TLS 的会话启动协议 (SIP) 在对等设备之间协商的加密密钥通过 SRTP 进行加密。

RTP 重放攻击

如果双方之间的有效媒体传输被截获并重新传输用于恶意目的，就会发生重放攻击。 SfBO 使用具有安全信令协议的 SRTP，该协议使接收方能够维护已接收的 RTP 数据包的索引，并将每个新数据包与索引中已列出的数据包进行比较，从而保护传输免受重播攻击。

SPIM

Spim 是主动提供的商业即时消息或状态订阅请求。 虽然 SPIM 本身不会导致网络攻击，但至少有些烦人，而且可能降低资源可用性和影响生产，甚至有可能导致网络攻击。 例如，用户通过发送请求相互发送垃圾消息。 用户可以相互阻止对方来防止出现这种情况，但对于联盟，如果建立了协作的 Spim 攻击，则很难防止出现这种情况，除非你禁用联盟伙伴关系。

病毒与蠕虫

病毒是一种代码单元，其目的是复制更多类似的代码单元。 病毒需要主机（如文件、电子邮件或程序）才能起作用。 与病毒一样，蠕虫是一个代码单元，编码以重现更多类似的代码单元，但与病毒不同，它不需要主机。 病毒和蠕虫主要是在客户端之间传送文件期间或从其他用户发送 URL 时出现。 例如，如果你的计算机上存在某种病毒，则该病毒可使用你的身份代表你发送即时消息。 标准的客户端安全最佳实践（例如定期扫描病毒）可以缓解此问题。

个人身份信息

SfBO 有可能通过公共网络披露信息，该网络可能能够链接到个人。 这些信息类型具体可分为两大类：

  • 增强的状态数据 增强状态数据是用户可以选择共享或不通过指向联盟合作伙伴的链接或与组织内联系人共享的信息。 此数据不会与公共 IM 网络上的用户共享。 客户端策略和其他客户端配置可能会为系统管理员提供一些控制能力。 在 SfBO 服务中，可以为单个用户配置增强状态隐私模式，以防止不在用户的联系人列表中的 SfBO 用户看到用户的状态信息。
  • 必需数据 必需数据是服务器或客户端正确操作所需的数据。 这是在服务器或网络级别为路由、状态维护和信号所必需的信息。 下表列出了 SfBO 运行所需的数据。

表 1 - 增强状态数据

Data 可能的设置
个人数据 名称、职务、公司、Email地址、时区
电话号码 工作电话号码、手机号码、住宅电话号码
日历信息 忙/闲、外出通知、会议详细信息 (有权访问日历)
状态 离开、可用、忙碌、请勿打扰、脱机

表2 - 强制性数据

Data 可能的设置
IP 地址 计算机的实际地址或经过 NAT 转换的地址
SIP URI david.campbell@contoso.com
名称 David Campbell（在 Active Directory 域服务中定义）

SfBO 的安全框架

本部分概述了构成 Microsoft SfBO 安全框架的基本元素。 这些要素如下所示：

  • Microsoft Entra ID为用户帐户提供单个受信任的后端存储库。
  • 公钥基础结构 (PKI) 使用受信任的证书颁发机构 (CA 颁发的证书) 对服务器进行身份验证并确保数据完整性。
  • 传输层安全性 (TLS)、HTTPS over SSL (HTTPS) 和相互 TLS (MTLS) 可实现终结点身份验证和 IM 加密。 点对点音频、视频和应用程序共享流是使用安全实时传输协议 (SRTP) 进行加密和完整性检查。
  • 用于用户身份验证的行业标准协议，如果可能。

本部分中的文章介绍了其中每个基本元素如何工作以增强 SfBO 服务的安全性。

Microsoft Entra ID

Microsoft Entra ID充当 Microsoft 365 和 Office 365 的目录服务。 它存储所有用户目录信息和策略分配。

SfBO 的公钥基础架构

SfBO 服务依赖于证书进行服务器身份验证，并在客户端和服务器之间以及不同服务器角色之间建立信任链。 Windows Server 公钥基础架构 (PKI) 为建立和验证此信任链提供了基础架构。

证书是数字 ID。 它们通过名称来标识某台服务器并指定其属性。 若要确保证书上的信息有效，证书必须由证书颁发机构 (CA) ，该证书颁发机构由连接到服务器的客户端或其他服务器信任。 如果服务器仅与专用网络中的其他客户端和服务器建立连接，则 CA 可以是企业 CA。 如果服务器与专用网络外部的实体进行交互，则可能需要公共 CA。

即使证书上的信息是有效的，也必须通过某些方法来确认提供证书的服务器实际上就是证书所代表的服务器。 在这种情况下可以使用 Windows PKI。

每个证书都链接到一个公钥。 证书上指明的服务器持有一个只有它自己知道的对应的私钥。 连接的客户端或服务器使用公钥对随机的信息段进行加密并将其发送到该服务器。 如果该服务器将此信息解密并以纯文本形式返回此信息，则连接的实体就可以确定该服务器持有证书的私钥，因此该服务器即是证书上指明的服务器。

CRL 分发点

SfBO 要求所有服务器证书包含一个或多个证书吊销列表 (CRL) 分发点。 可从 CRL 分发点 (CDP) 下载 CRL，以验证该证书自颁发以来未被吊销，并且仍处于有效期内。 CRL 分发点在证书属性中标记为 URL，并且是安全的 HTTP。 SfBO 服务使用每个证书身份验证来检查 CRL。

增强型密钥使用

SfBO 服务的所有组件都需要所有服务器证书来支持用于服务器身份验证的增强型密钥用法 (EKU) 。 配置用于服务器身份验证的 EKU 字段意味着证书可以对服务器进行身份验证。 此 EKU 对 MTLS 至关重要。

用于 SfBO 的 TLS 和 MTLS

TLS 和 MTLS 协议在 Internet 上提供加密通信和终结点身份验证。 SfBO 使用这两种协议创建受信任的服务器网络，并确保通过该网络进行的所有通信都经过加密。 服务器之间的所有 SIP 通信都通过 MTLS 进行。 从客户端到服务器的 SIP 通信都通过 TLS 进行。

TLS 使用户能够通过其客户端软件对连接到的 SfBO 服务器进行身份验证。 在 TLS 连接中，客户端从服务器请求获取有效证书。 有效证书必须满足以下条件：由受客户端信任的 CA 颁发，且服务器的 DNS 名称必须与证书上的 DNS 名称一致。 如果证书有效，则客户端使用证书中的公钥对用于通信的对称加密密钥进行加密，因此只有证书的原始所有者可以使用其私钥对通信内容进行解密。 生成的连接是受信任的，并且从该点开始，不会受到其他受信任的服务器或客户端的质询。 在此上下文中，可将用于 Web 服务的安全套接字层 (SSL) 视为是基于 TLS 的。

服务器到服务器的连接依靠相互 TLS (MTLS) 进行相互验证。 在 MTLS 连接上，发出消息的服务器和接收消息的服务器交换来自相互信任的 CA 的证书。 证书可向一台服务器证明另一台服务器的身份。 在 SfBO 服务中，遵循此程序。

TLS 和 MTLS 有助于防止窃听和中间人攻击。 在中间人攻击中，攻击者将通过其计算机重新路由两个网络实体之间的通信，而这两个网络实体对此毫不知情。 TLS 和 SfBO 的受信任服务器规范通过使用两个终结点之间的公钥加密协调使用端到端加密来缓解应用程序层上部分中间人攻击的风险，攻击者必须具有具有相应私钥的有效且受信任的证书，并颁发给客户端要与之通信的服务的名称才能解密通信。

SfBO 的加密

SfBO 使用 TLS 和 MTLS 来加密即时消息。 无论通信是限制在内部网络还是跨越内部网络外围，所有服务器到服务器的通信都需要 MTLS。

下表总结了 SfBO 使用的协议。

表 3 - 流量保护

通信类型 rotected by
服务器到服务器 MTLS
客户端到服务器 TLS
即时消息和状态 TLS（如果已配置 TLS）
音频、视频和媒体的桌面共享 SRTP
桌面共享（信号） TLS
Web 会议 TLS
会议内容下载、通讯簿下载和通讯组扩展 HTTPS

媒体加密

媒体通信使用安全 RTP (SRTP) 进行加密，SRTP 是为 RTP 通信提供保密性、身份验证和重播攻击保护的实时传输协议 (RTP) 的配置文件。 SRTP 使用通过安全随机号码生成器生成的会话密钥，并使用信令 TLS 信道进行交换。 此外，中介服务器与其内部下一个跃点之间的双向媒体流也使用 SRTP 进行加密。

SfBO 通过 TURN 生成用户名/密码以安全访问媒体中继。 媒体中继通过 TLS 安全 SIP 信道交换用户名/密码。

FIPS

SfBO 使用符合 FIPS（联邦信息处理标准）的算法进行加密密钥交换。

用户和客户端身份验证

受信任的用户是凭据已通过 Microsoft 365 或 Office 365 Microsoft Entra ID 进行身份验证的用户。

身份验证是向受信任的服务器或服务提供用户凭据的过程。 SfBO 使用以下身份验证协议，具体取决于用户的状态和位置。

  • 现代身份验证是 Microsoft 为实现客户端到服务器的通信而实施 OAUTH 2.0 的过程。 它启用安全功能，例如基于证书的身份验证、多重身份验证和条件访问。 为了使用 MA，需要为 MA 同时启用联机租户和客户端。 2017 年 5 月之后创建的 SfBO 租户默认启用 MA。 此时间之前创建的租户，请按照此处的说明予以启用。 以下客户端均支持 MA：Skype for Business 2015 或 2016 客户端、Skype for Business Mac、Lync 2013 客户端、3PIP IP 电话、iOS 和 Android。
  • 当新式身份验证未启用 (或) 不可用时，将使用组织 ID。
  • 摘要式协议 - 用于所谓的匿名用户。 匿名用户是未识别 Active Directory 凭据但已受邀参加本地会议并拥有有效会议密钥的外部用户。 摘要式身份验证不用于其他客户端交互。

SfBO 身份验证由两个阶段组成：

  1. 在客户端和服务器之间建立安全关联。
  2. 客户端和服务器使用现有的安全关联签署它们发送的消息，以及验证所收到的消息。 在服务器上启用身份验证时，不接受来自客户端的未经身份验证的消息。

用户信任会附加到用户发出的每条消息，而不会附加到用户标识本身。 服务器将检查每条消息是否具有有效的用户凭据。 如果用户凭据有效，则不仅第一个接收该消息的服务器，而且 SfBO 中的所有其他服务器都不会对消息进行挑战。

拥有联盟伙伴颁发的有效凭据的用户会受到信任，但其他限制可能会阻止这些用户享有与内部用户相同的全部权限。

对于媒体身份验证，ICE 和 TURN 协议也使用摘要式质询，如 IETF TURN RFC 中所述。 有关详细信息，请参阅 媒体遍历。

客户端证书提供了一种替代方式，供 SfBO 对用户进行身份验证。 用户无需提供用户名和密码，因为他们具有证书以及解析加密质询所需的与证书对应的私钥。

Windows PowerShell 和 SfBO 管理工具

在 SfBO 中，IT 管理员可以通过 O365 管理门户或使用 Tenant Remote PowerShell（TRPS）管理他们的服务。 租户管理员使用新式验证对 TRPS 进行身份验证。

在 Internet 边界配置对 SfBO 的访问

为了使 SfBO (能够加入会议等 ) 的用户正常工作，客户需要配置其 Internet 访问，以便允许到 SfBO 云中服务的出站 UDP 和 TCP 流量。 有关详细信息，请参阅此处： https://support.office.com/article/Office-365-URLs-and-IP-address-ranges-8548a211-3fe7-47cb-abb1-355ea5aa88a2#bkmk_lyo

UDP 3478-3481 和 TCP 443

客户端使用 UDP 3478-3481 和 TCP 443 端口向 A/V 边缘服务请求服务。 客户端使用这两个端口分别分配 UDP 和 TCP 端口以供远程方连接。 若要访问 A/V Edge 服务，客户端必须首先与 SfBO 注册机构建立经过身份验证的 SIP 信令会话，以获取 A/V Edge 服务身份验证凭据。 这些值通过 TLS 保护的信令信道发送，并通过计算机生成以减轻字典式攻击。 然后，客户端可以使用这些证书执行摘要式身份验证，使用 A/V 边缘服务分配端口以用于媒体会话。 初始分配请求从客户端发送，并使用来自 A/V 边缘服务的 401 随机 nonce/质询消息进行响应。 客户端发送第二个分配，其中包含用户名以及用户名和 nonce 的哈希消息验证代码 (HMAC) 哈希。

序列号机制也可以防止重播攻击。 服务器根据自己对用户名和密码的了解计算预期的 HMAC，如果 HMAC 值匹配，则执行分配过程。否则，数据包将被丢弃。 相同的 HMAC 机制也适用于此呼叫会话中的后续消息。 此用户名/密码值的生存期最长为 8 个小时，之后客户端需重新获取新用户名/密码以用于后续呼叫。

UDP/TCP 50,000–59,999

TCP 50,000 出站用于 SfBO，包括应用程序和桌面共享以及文件传输。 UDP/TCP 50,000-59,999 端口范围用于与 Microsoft Office Communications Server 2007 合作伙伴的媒体会话，这些合作伙伴需要 A/V 边缘服务提供的 NAT/防火墙遍历服务。 由于 A/V Edge 服务是使用这些端口的唯一进程，因此端口范围的大小并不表示潜在的攻击面。 良好的安全做法是：始终不运行不必要的网络服务，以最大限度地减少监听端口的总数。 如果网络服务未运行，则远程攻击者不会利用它，并且减少了主计算机的攻击面。 但是，在单个服务中，减少端口数不会带来相同的好处。 A/V 边缘服务软件打开 10,000 个端口时并不会比打开 10 个端口时更容易受到攻击。 此范围内的端口分配是随机进行的，当前未分配的端口不会侦听数据包。

外部用户 A/V 流量遍历

如要让外部用户和内部用户能够交换媒体，则需访问边缘服务来处理建立和 终结会话所需的 SIP 信号。 此外还需要 A/V 边缘服务充当媒体传输的中继。 呼叫顺序如下图所示。

“加入会议”中的呼叫顺序。

  1. 用户收到一封电子邮件，其中包含加入 SfBO 会议的邀请。 该电子邮件包含会议密钥和基于 HTTP 的会议链接 URL。 密钥和网址对于特定会议而言都是唯一的。

    用户通过单击电子邮件中的会议 URL 启动加入过程，这会在用户计算机上启动客户端检测过程。 如果检测到客户端，则启动该客户端。 如果未检测到，则会将用户重定向到 Web 客户端。

  2. SfBO 客户端发送包含用户证书的 SIP INVITE。 联合或远程用户使用其企业凭据加入会议。 对于联合用户，SIP INVITE 首先会发送到他或她的家庭服务器，后者对用户进行身份验证并将 INVITE 转发给 SfBO。 匿名用户需通过摘要式身份验证。

    SfBO 对远程或匿名用户进行身份验证，并通知客户端。 如步骤 2 所述，加入会议的联合用户由他们的企业进行身份验证。

  3. 客户端发送 INFO 请求以将用户添加到 A/V 会议。

    A/V 会议发送一个添加用户响应，其中包含用于呈现给 A/V 会议边缘服务的令牌以及其他信息。

    [注意]上述所有 SIP 流量都流经 Access Edge 服务。

    客户端连接到 A/V 会议服务器，后者验证令牌并作为代理而将包含其他授权令牌的请求发送给内部 A/V 会议服务器。 A/V 会议服务器验证最初通过 SIP 信道发出的授权令牌，以进一步确保有效用户加入会议。

  4. 在客户端和 A/V 会议服务器之间，通过 SRTP 协商和设置媒体连接。

  5. 用户收到一封电子邮件，其中包含加入 SfBO 会议的邀请。 该电子邮件包含会议密钥和基于 HTTP 的会议链接 URL。 密钥和网址对于特定会议而言都是唯一的。

SfBO 的联合安全措施

联盟让你的组织能够与其他组织通信，以共享 IM 和状态。 在 SfBO 中，默认设置为开启联盟。 但是，租户管理员可以通过 Microsoft 365 或 Office 365 Admin 门户来控制这一点。 了解更多详情。

应对 SfBO 会议的威胁

SfBO 让企业用户能够创建和加入实时 Web 会议。 企业用户还可以邀请没有Microsoft Entra ID、Microsoft 365 或Office 365帐户的外部用户参与这些会议。 受联合合作伙伴雇用并具有安全和身份验证身份的用户也可以加入会议，并且可以在升格后担任演示者。 匿名用户无法以演示者身份创建或加入会议，但在加入会议后可升级为演示者。

让外部用户参加 SfBO 会议大大增加了此功能的价值，但也带来一些安全风险。 为应对这些风险，SfBO 提供以下附加保障措施：

  • 参与者的角色决定了其会议控制权限。
  • 参与者类型可让你限制对特定会议的访问。
  • 已定义的会议类型决定了哪类参与者可以参加。
  • 会议安排仅限于拥有Microsoft Entra帐户和 SfBO 许可证的用户。
  • 匿名，即未经身份验证的用户，想要加入电话拨入式会议拨打其中一个会议访问号码，然后提示他们输入会议 ID。 还会提示未经身份验证的匿名用户记录其名称。 记录的名称用于在会议中标识未经身份验证的用户。 在至少有一位领导或经过身份验证的用户加入之前，匿名用户不会加入会议，并且无法为他们分配预定义角色。

参与者角色

会议参与者分为三组，每组都有自己的权利和限制：

  • 组织者：创建会议（无论临时会议还是计划的会议）的用户。 组织者必须是经过身份验证的企业用户，并且能够控制会议的所有最终用户方面。
  • 演示者：授权在会议上使用支持的任何媒体演示信息的用户。 根据定义，会议组织者也可以是演示者，并确定谁还可以成为演示者。 会议安排或会议开始时，组织者可以做出决定。
  • 与会者 已受邀参加会议但无权充当演示者的用户。

演示者还可以在会议期间将某一与会者升格为演示者。

参与者类型

会议参与者也按照地点和证书分类。 你可以使用这两个特征来指定哪些用户可以访问特定的会议。 用户可以大致分为以下几类：

  1. 属于租户的用户这些用户具有租户Microsoft Entra ID凭据。

    1. 公司网络内部 - 这些用户从公司网络内部加入。
    2. 远程用户 - 这些用户是从公司网络外部加入的用户。 这些用户包括在家工作或在路上工作的员工以及其他人员，如受信任供应商的员工，他们已根据服务条款方面获得企业证书。 远程用户可以创建和加入会议并担任演示者。

  2. 不属于租户的用户这些用户在Microsoft Entra ID中没有租户的凭据。

    1. 联合用户 - 联合用户拥有与联合合作伙伴的有效凭据，因此被 SfBO 视为经过身份验证。 联合用户可以在加入会议后加入会议并提升为演示者，但他们无法在与其联合的企业中创建会议。
    2. 匿名用户 - 匿名用户没有 Active Directory 标识，并且不与租户联合。

客户数据显示，许多会议涉及外部用户。 在允许这些用户加入会议之前，这些客户也希望确保外部用户的身份。 如以下部分所述，SfBO 将访问权限限制为已明确允许的用户类型，并要求所有用户类型在进入会议时提供适当的证书。

参与者与会

在 SfBO，匿名用户被转移到名为大厅的等候区。 演示者可以接受这些用户参加会议或拒绝他们。 这些用户被转移到大厅，通知领导后，用户将等待领导接受或拒绝，直到连接超时。在大厅里，用户会听到音乐播放。

默认情况下，从 PSTN 拨入的与会者直接进入会议，但可以更改此选项以强制拨入与会者前往大厅。
会议组织者决定参与者是否可以加入会议而无需在大厅等待。 每个会议都可以设置为使用以下任何一种方法启用访问：

  • 只有我，会议组织者 除组织者外，每个人都必须在大厅中等待，直到被录取。
  • 人员我从我的公司邀请 你公司的任何人都可以直接进入会议，即使没有邀请。
  • 组织中的任何人Microsoft 365 或 Office 365 租户中的所有 SfBO 用户都可以加入会议，而无需在大厅中等待，即使不在通讯组列表中也是如此。 所有其他人（包括所有外部和匿名用户）必须在大厅等候，直到被允许参加会议。
  • 任何人 任何 (没有限制) 谁有权访问会议链接，都可以直接进入会议。 如果指定了“仅限组织者（锁定）”以外的任何方法，会议组织者还可以指定通过电话拨入的人员直接参加会议而绕过大厅。

演示者功能

会议组织者决定参与者是否可以在会议期间演示。 每个会议都可以设置为将演示者限制为以下任何一种情况：

  • 仅限组织者 只有会议组织者才能演示。
  • 来自我公司的人员 所有内部用户都可以演示。
  • 每个人，包括我公司以外的人 参加会议的每个人（没有限制）都可以演示。
  • 人员我选择“会议组织者”，通过将用户添加到演示者列表来指定哪些用户可以演示。

Microsoft 信任中心