选择安全 QOS 选项

安全 QOS 选项作为 SecurityQOS 参数的一部分传递给 RpcBindingSetAuthInfoEx 函数。 使用以下最佳做法。

使用相互身份验证

真正的相互身份验证仅适用于某些安全提供程序：协商 Kerberos) 、Kerberos 和 Schannel 时协商 (。 NTLM 不支持相互身份验证。 使用相互身份验证需要提供格式正确的服务器主体名称。 许多开发人员使用以下错误的安全做法：调用服务器以请求其主体名称 (RpcMgmtInqServerPrincName) ，然后他们盲目要求使用该主体名称进行相互身份验证。 此方法打破了相互身份验证的整个理念：相互身份验证的理念是，只调用某些服务器，因为它们受信任来分析和处理数据。 使用刚才描述的错误安全做法，开发人员将其数据提供给足够聪明的人，以返回其姓名。

例如，如果客户端软件应仅调用在 Joe、Pete 或 Alice 帐户下运行的服务器，则应调用 RpcMgmtInqServerPrincName 函数，并检查发回的名称。 如果是 Joe、Pete 或 Alice，则应使用其服务器主体名称请求相互身份验证。 这可确保对话的两半都转到同一主体。

如果客户端软件应调用仅在 Joe 的帐户下运行的服务，请直接编写 Joe 的服务器主体名称并发出调用。 如果服务器不是 Joe，则调用将直接失败。

很多时候，服务作为 Windows 系统服务运行，这意味着它们在计算机帐户下运行。 仍建议相互身份验证和创建服务器主体名称。

使用允许调用通过的最低 ImpersonationType

此最佳做法相当一目了然。 即使使用相互身份验证，也不要向服务器授予超过必要权限;合法服务器可能已遭入侵，即使在这种情况下，你发送的数据落入错误之手，至少服务器将无法代表你访问网络上的其他数据。 某些服务器会拒绝没有足够的信息来确定调用方并可能模拟呼叫者的呼叫。 此外，请注意，某些协议序列支持传输级别安全性 (ncacn_np 和 ncalrpc) 。 在这种情况下，如果在创建绑定句柄时通过 NetworkOptions 参数指定了足够高的模拟级别，则服务器始终可以模拟你。

最后，某些安全提供程序或传输可能会以透明方式将 ImpersonationType 提升到比指定的级别更高的级别。 开发程序时，请确保尝试使用预期的 ImpersonationType 进行调用，并检查是否在服务器上获得更高的 ImpersonationType。