使用 pymssql 的 Kerberos 委派(双跳)
Kerberos Delegation (Double-Hop) with pymssql
pymssql
模块声称支持 Kerberos 身份验证(和委派),但我似乎无法启用它。
我是 运行 的客户在 Windows。我需要通过反向数据库代理与双跳连接。客户端、代理和数据库都是域的一部分。当我尝试连接 SQL 服务器管理器时,我成功了。但是当我尝试连接 Python 中的 pymssql
模块时,它不起作用。如果我直接从客户端连接到数据库,我就能让 Kerberos 身份验证工作。但同样,当我尝试通过代理时,它失败了。
这让我相信 Kerberos 身份验证有效,但委派(双跳)无效。
根据 section on FreeTDS I should be able to create a file at C:/freetds.conf
and it should read connection information from there. I don't seem to be able to verify this in any meaningful way. Additionally, according to the freetds schema,我应该可以添加一个参数 enable gssapi delegation
,启用后(默认关闭)允许 Kerberos 委派。
底线:
我希望在 windows.
上为 pymssql 启用 Kerberos 委派(以便双跃点工作)
目前我已经在 C:/freetds.conf
创建了一个文件,并尝试了几种配置方法。
[global]
enable gssapi delegation = on
和
[global]
enable gssapi delegation = true
这个问题很容易回答,并且根源于 FreeTDS 的一个缺点。你没有做错。
如果我们看一下 FreeTDS 的 GSS-API C 代码,我们会在 lines 307 to 308
中看到
if (tds->login->gssapi_use_delegation)
gssapi_flags |= GSS_C_DELEG_FLAG;
您的配置参数已在委托标志中读取。
由于您使用的是 Windows 并且 Windows 使用其自身风格的 GSS-API,即 SSPI,我们看一下 C 代码:lines 273 to 278做
status = sec_fn->InitializeSecurityContext(&auth->cred, NULL, auth->sname,
ISC_REQ_CONFIDENTIALITY | ISC_REQ_REPLAY_DETECT
| ISC_REQ_CONNECTION | ISC_REQ_ALLOCATE_MEMORY,
0, SECURITY_NETWORK_DREP,NULL, 0, &auth->cred_ctx, &desc, &attrs, &ts);
如您所见,上下文标志不在变量中,而是直接传递。既不评估配置参数也不传递 ISC_REQ_DELEGATE
。
这 就是您遇到的问题。您现在有两个选择:
- 提出错误并等待修复。
- 从 GitHub 克隆,自行修复并发出拉取请求。
旁注:对于这两个代码部分,有几处我根本不喜欢:
- SSPI 不像 GSS-API 那样执行相互验证,但应该执行。
- 上下文标志被毫无意义地传递,但该 C 文件中从未使用过功能,例如
ISC_REQ_CONFIDENTIALITY | ISC_REQ_REPLAY_DETECT
和 GSS_C_REPLAY_FLAG | GSS_C_INTEG_FLAG
。仅当您需要此处未采用的进一步运输安全时才有必要。
- 可能还有更多问题需要修复,但我没有对其进行代码审查。
我也强烈建议在这里提出一些问题。
pymssql
模块声称支持 Kerberos 身份验证(和委派),但我似乎无法启用它。
我是 运行 的客户在 Windows。我需要通过反向数据库代理与双跳连接。客户端、代理和数据库都是域的一部分。当我尝试连接 SQL 服务器管理器时,我成功了。但是当我尝试连接 Python 中的 pymssql
模块时,它不起作用。如果我直接从客户端连接到数据库,我就能让 Kerberos 身份验证工作。但同样,当我尝试通过代理时,它失败了。
这让我相信 Kerberos 身份验证有效,但委派(双跳)无效。
根据 section on FreeTDS I should be able to create a file at C:/freetds.conf
and it should read connection information from there. I don't seem to be able to verify this in any meaningful way. Additionally, according to the freetds schema,我应该可以添加一个参数 enable gssapi delegation
,启用后(默认关闭)允许 Kerberos 委派。
底线: 我希望在 windows.
上为 pymssql 启用 Kerberos 委派(以便双跃点工作)目前我已经在 C:/freetds.conf
创建了一个文件,并尝试了几种配置方法。
[global]
enable gssapi delegation = on
和
[global]
enable gssapi delegation = true
这个问题很容易回答,并且根源于 FreeTDS 的一个缺点。你没有做错。
如果我们看一下 FreeTDS 的 GSS-API C 代码,我们会在 lines 307 to 308
中看到if (tds->login->gssapi_use_delegation)
gssapi_flags |= GSS_C_DELEG_FLAG;
您的配置参数已在委托标志中读取。
由于您使用的是 Windows 并且 Windows 使用其自身风格的 GSS-API,即 SSPI,我们看一下 C 代码:lines 273 to 278做
status = sec_fn->InitializeSecurityContext(&auth->cred, NULL, auth->sname,
ISC_REQ_CONFIDENTIALITY | ISC_REQ_REPLAY_DETECT
| ISC_REQ_CONNECTION | ISC_REQ_ALLOCATE_MEMORY,
0, SECURITY_NETWORK_DREP,NULL, 0, &auth->cred_ctx, &desc, &attrs, &ts);
如您所见,上下文标志不在变量中,而是直接传递。既不评估配置参数也不传递 ISC_REQ_DELEGATE
。
这 就是您遇到的问题。您现在有两个选择:
- 提出错误并等待修复。
- 从 GitHub 克隆,自行修复并发出拉取请求。
旁注:对于这两个代码部分,有几处我根本不喜欢:
- SSPI 不像 GSS-API 那样执行相互验证,但应该执行。
- 上下文标志被毫无意义地传递,但该 C 文件中从未使用过功能,例如
ISC_REQ_CONFIDENTIALITY | ISC_REQ_REPLAY_DETECT
和GSS_C_REPLAY_FLAG | GSS_C_INTEG_FLAG
。仅当您需要此处未采用的进一步运输安全时才有必要。 - 可能还有更多问题需要修复,但我没有对其进行代码审查。
我也强烈建议在这里提出一些问题。