🔗 特性：协商身份验证

• 目标：使 Squid 支持 Negotiate 身份验证协议。
• 状态：完成。
• 版本: 2.6+
• 开发者：GuidoSerassio，HenrikNordstrom，Robert Collins，FrancescoChemolli
• 更多:

🔗 详细信息

Negotiate 是 GSSAPI 的一个包装协议，而 GSSAPI 本身又是 Kerberos 或 NTLM 身份验证的包装。为什么是包装的包装？目前 Microsoft 以外的人都不知道。GSSAPI 本身就足够了。

真正重要的是，支持它意味着支持到 MS Windows 域的透明 Kerberos 身份验证。它比 NTLM 安全得多，并且对域控制器造成的负担也小得多。

有关 Squid 支持的其他方案以及身份验证总体工作原理的详细信息，请参阅 Features/Authentication。

🔗 在 Squid 中如何工作？

Negotiate 协议同时非常简单和有些复杂。Squid 的部分被故意保持得很小且简单，以提高整体系统的安全性。

身份验证辅助程序负责执行所有危险的安全加密和验证过程。Squid 最初可能会联系它以获取一个挑战令牌，然后将其盲目地转发给客户端。客户端提供的任何凭据或令牌都会原封不动地传递给辅助程序。

下面将描述用于此目的的协议行。相同的协议用于联系 NTLM 和 Negotiate 身份验证辅助程序。这使得 Squid 能够通过一个协议配置同时支持 Negotiate/Kerberos 和 Negotiate/NTLM 风格。

这种双重支持确实会导致一些管理上的混乱，当辅助程序不支持与客户端浏览器相同的风格时。

由于 NTLM 的状态性，这些认证器方案不支持并发。

🔗 从 Squid 接收的输入行

request [credentials] [key-extras]

request 是请求代码之一

YR	需要一个新的挑战令牌。这是两个进程之间的第一次通信。当 Squid 由于 auth_param 的 max_challenge_lifetime 和 max_challenge_uses 参数需要新挑战时，也可能随时发生。辅助程序应响应 TT 消息。
KK	验证用户的凭据。辅助程序响应 OK、ERR、AF、NA 或 BH 中的一个。

credentials 是在 HTTP 头部中收到的精确编码的 blob。此字段仅在 KK 请求上发送。

key-extras 是传递给辅助程序的附加参数，可以通过 auth_param 的 key_extras 参数进行配置。仅在 Squid-3.5 及更高版本中可用。

🔗 发回给 Squid 的结果行

result [token label] [kv-pair] [message]

result 是结果代码之一

TT	成功。呈现一个新的挑战 token 值。
AF	成功。有效凭据。从 Squid-3.4 开始，被 OK 结果弃用。
NA	成功。无效凭据。从 Squid-3.4 开始，被 ERR 结果弃用。
OK	成功。有效凭据。
ERR	成功。凭据无效。
BH	失败。帮助程序遇到问题。

OK 和 ERR 结果代码仅被 Squid-3.4 及更新版本接受。

token 是一个新的挑战值。根据 RFC 2045 的定义，令牌是 base64 编码的。

注意：Squid-3.3 及更早版本的 NTLM 认证器接口不支持 token 字段。Negotiate 认证器接口在 TT、AF 和 NA 响应时需要它。

此字段不得在 OK、ERR 和 BH 响应上发送。

label 是 Squid 用于此客户端请求的“用户名”。此字段仅在 AF 响应上接受。在任何其他结果代码响应上都不得发送。

kv-pair：一个或多个 key=value 对。此接口上保留的键名

clt_conn_tag=…	标记客户端 TCP 连接 (Squid-3.5)
group=…	reserved
message=…	Squid 可以在错误页面上显示的字符串消息。
tag=…	reserved
token=…	要使用的令牌，根据 RFC 2045 进行 base64 编码。此字段仅在 OK 响应上使用。
ttl=…	reserved
user=…	Squid 用于此客户端请求的“用户名”标签。对于 Negotiate 和 NTLM 协议，它通常分别具有 NAME@DOMAIN 或 NAME\DOMAIN 的格式。
*_=…	以 (_) 结尾的键名保留给本地管理员使用。

kv-pair 字段仅被 Squid-3.4 及更新版本接受。

此辅助程序返回的 kv-pair 可以通过 %note logformat 代码进行日志记录。

message 是 Squid 可以在错误页面上显示的字符串。此字段仅在 NA 和 BH 响应上接受。从 Squid-3.4 开始，此字段已被 BH 响应上的 message= kv-pair 弃用。

🔗 支持 NEGOTIATE 的 Squid 原生 Windows 构建

🔗 测试

🔗 测试 Squid

通过 Squid 发送任何带有 GET 或其他请求的 URL。

squidclient http://example.com/

正确配置的 Squid 将回复 Proxy-Authenticate: Negotiate，如下所示

HTTP/1.1 407 Proxy Authentication Required
Server: squid/3.2.0.14
Mime-Version: 1.0
Date: Thu, 12 Jan 2012 03:41:33 GMT
Proxy-Authenticate: Negotiate
...

🔗 从 Unix 测试 win32 辅助程序

如果您想测试 Unix 端的东西，实际上有一种方法可以从 Unix 盒子访问 win32 辅助程序，那就是执行一次“授权的中间人攻击”，如下所示

• 您需要在 Windows 盒子上运行 sshd（这本身就不是一件小事，但已超出本文档范围 - 有关详细信息，请参阅 http://www.cygwin.com/）。请注意，它必须以 SYSTEM 账户运行。
• 在 Unix 盒子上的 squid 用户创建一个 ssh 密钥对 - 公钥最好不要设置密码。
• 如果 /etc/passwd 中不存在，则为用户 'system' 创建一个条目，为其指定一个主目录（从现在起我们称之为 /home/system）。
• 在 Windows 盒子上的 /home/system/.ssh 目录中创建一个目录，并在其 authorized_keys 文件中复制 Unix 盒子上的 squid 用户的公钥。尝试从 Unix 盒子连接（您可以在 ssh 上运行 bash），保存服务器密钥并检查一切是否正常。

• 您需要 MS Windows 资源工具包中的 setspn 工具。您需要使用以下命令将 squid 盒子的服务名称添加到 Windows 盒子的机器账户中：

    setspn -A HTTP/netbiosname
    setspn -A HTTP/netbiosname.domain
  

• 在 squid.conf 中将 ssh 配置为辅助程序，该程序调用辅助程序（确保辅助程序在 %PATH% 中，即

       auth_param negotiate ssh system@netbiosname.domain "win32_negotiate_auth.exe"
  

🔗 故障排除

🔗 令牌类型错误

客户端最初提供的令牌用于辅助程序识别正在使用的风格

• type 1 token - NTLM

• type 2 token - Kerberos

您可能会看到提及这些令牌类型的警告或错误，尤其是在使用 Kerberos 辅助程序配置 Negotiate 身份验证时，类型 1 的问题尤其常见。

问题在于客户端和辅助程序的功能不匹配。negotiate_wrapper 辅助程序是目前唯一已知的能够同时处理这两种类型的辅助程序。

类别：功能

导航：站点搜索，站点页面，类别，🔼 向上