构建可以在企业防火墙外部提供服务的 Web 站点是需要技巧的。通常并不需要为外部客户端授予企业域帐户，并且从纯实践的角度看，由于客户端通常配置了防火墙，所以 Kerberos 并不能很好地在 Internet 上工作。这意味着站点必须提供某种有别于 Windows® 中内置方法的身份验证和授权形式。

　　为了帮助解决这个问题以及我将描述的其他难题，Microsoft 实现了两个在服务器上使用的 Kerberos 扩展。这些扩展统称为 Service-for-User (S4U)。其目的是让服务器开发人员可以针对 Windows 提供的内置安全性模型进行编程，从而利用管理员已经熟悉的基于组的授权框架。

　　发现授权信息

　　我要介绍的第一个扩展可以帮助服务器发现域用户所属的组。Windows 中的授权框架已经变得十分复杂，因此服务器开发人员事实上不可能手动发现一个用户所属的组。Global 组来自于用户的主域并且可能是嵌套的。通用组可以来自于用户的所有主目录林，并且存储于全局目录中，同样也可能是嵌套的。域本地组存储于服务器域内，可能是嵌套的。本地组存储于服务器计算机上，并且最容易处理。Windows 2000 中的 SIDHistory 功能指的是可能需要为某些用户多次进行结果组扩展。称为域隔离 (domain quarantine) 的另一个功能指的是删除某些组。简单的说，试图通过手动方式找出域用户的组成员是开发人员最不想做的，并且应该避免。

　　获得某个用户组的权威列表的最好办法是为该用户创建一个登录并查看结果标记。在 Kerberos 身份验证的过程中，域控制器执行所有繁重的操作。代表客户端执行 Kerberos 身份验证的唯一问题是，服务器需要拥有客户端的主凭证，这实际上意味着可以访问客户端的密码或客户端的票据授权票据 (ticket-granting ticket, TGT) 及相关的会话密钥。如果服务器知道客户端的密码，则获得 sales 域中名为 Alice 的客户端标记就变得十分简单：

　　S4U2Self

　　在这种情况下，S4U 的解决方案是，让服务器遍历 Kerberos 身份验证的操作并获取客户端登录，但不提供客户端凭证。因此，在这种情况下并没有真正对客户端进行身份验证，而只是换了一种方式收集客户端的组安全标识符 (SID)。为了允许上述操作发生，Windows Server 2003 域控制器接受一种新类型的 Kerberos 请求，其中，服务请求一个从客户端到其本身的票据，并显示其自己的凭证而非客户端的凭证。这种扩展称为 Service-for-User-to-Self (S4U2Self)。

　　如果客户端和服务位于单独的域中，则它们之间需要有一个双向信任路径，因为代表客户端的服务必须请求来自客户端域的票据。

　　虽然线路层的细节都相当复杂，但服务开发人员只需调用一个函数即可：LsaLogonUser。从功能上看，这与前面所述的调用 LogonUser 非常相似，只是不需要提供客户端密码。结果是一个标记，服务可以将其与 AccessCheck 和 CheckTokenMembership 等函数一起使用，也可以将其与授权函数的新 AuthZ 系列一起使用。这就允许服务对其管理的对象的安全描述符执行访问检查。

　　为了保护客户端，LsaLogonUser 通常返回一个具有特定限制的标记。该标记具有一个模拟级别的 Identify，这意味着服务在使用该标记的模拟客户端时不能打开核心对象。然而，对于作为受信任计算基 (TCB) 的一部分的服务(例如作为 SYSTEM 运行的服务)来说，LsaLogonUser 会返回一个带有模拟级别的 Impersonate 的标记，允许使用客户端的标识来访问本地核心对象。这可以防止不受信任的服务使用 S4U2Self 票据来提升其自己的本地特权。

　　想要使用这一功能的开发人员只需要调用 LsaLogonUser。然而，LsaLogonUser 是一个难于使用的函数。它需要 14 个参数，其中一些是指向变长结构的指针或需要先打开的对象句柄。Microsoft® .NET Framework 的 1.1 版(在撰写本文时处于测试状态)在 WindowsIdentity 类中包含了一个新的构造函数，这大大地简化了此函数：