获取web服务的kerberos/Windows AD登录工作时出现问题

Question

我已经为此挣扎了很长一段时间，我无法让它工作。

以下是设置：我有一个nginx Web服务器，在mywebapp.k8s.dal1.mycompany.io上提供django应用程序

它编译了SPNEGO插件，我的配置中有以下端点：

location /ad-login {
uwsgi_pass django;
include /usr/lib/mycompany/lib/wsgi/uwsgi_params;
auth_gss on;
auth_gss_realm BURNERDEV1.DAL1.MYCOMPANY.IO;
auth_gss_service_name HTTP/mywebapp.k8s.dal1.mycompany.io;
auth_gss_allow_basic_fallback off;
}

我的AD域控制器位于burnerdev1.dal1.mycompany.io，我配置了以下用户：

rep_movsd
portal

我在DC服务器上的管理员提示符下运行以下命令：

ktpass -out krb5.keytab -mapUser [e-mail] +rndPass -mapOp set +DumpSalt -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -princ HTTP/[e-mail]
setspn -A HTTP/[e-mail] portal

C:UsersmyselfDocumentskeytab>ktpass -out krb5.keytab -mapUser [e-mail] +rndPass -mapOp set +DumpSalt -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -princ HTTP/[e-mail]
Targeting domain controller: dal1devdc1.burnerdev1.dal1.mycompany.io
Using legacy password setting method
Failed to set property 'servicePrincipalName' to 'HTTP/mywebapp.k8s.dal1.mycompany.io' on Dn 'CN=portal,CN=Users,DC=burnerdev1,DC=dal1,
DC=mycompany,DC=io': 0x13.
WARNING: Unable to set SPN mapping data.
If portal already has an SPN mapping installed for HTTP/mywebapp.k8s.dal1.mycompany.io, this is no cause for concern.
Building salt with principalname HTTP/mywebapp.k8s.dal1.mycompany.io and domain BURNERDEV1.DAL1.MYCOMPANY.IO (encryption type 18)...
Hashing password with salt "BURNERDEV1.DAL1.MYCOMPANY.IOHTTPmywebapp.k8s.dal1.mycompany.io".
Key created.
Output keytab to krb5.keytab:
Keytab version: 0x502
keysize 110 HTTP/[e-mail] ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0x12 (AES256-SHA1) k
eylength 32 (0x632d9ca3356374e9de490ec2f7718f9fb652b20da40bd212a808db4c46a72bc5)
C:UsersmyselfDocumentskeytab>setspn -A HTTP/[e-mail] portal
Checking domain DC=burnerdev1,DC=dal1,DC=mycompany,DC=io
Registering ServicePrincipalNames for CN=portal,CN=Users,DC=burnerdev1,DC=dal1,DC=mycompany,DC=io
HTTP/[e-mail]
Updated object
C:UsersmyselfDocumentskeytab>

现在在"；"Active Directory用户和计算机"；部分，我右键单击用户并选择"；属性"；然后在"；委派"；选项卡I设置"；信任该用户委派给任何服务(仅Kerberos("；

接下来，我将krb5.keytab文件复制到我的Web服务器上，并重新启动nginx容器

在作为域一部分的Windows工作站上，当我运行klist:时，我以rep_movsd的身份登录

C:Usersrep_movsd>klist
Current LogonId is 0:0x208d7
Cached Tickets: (2)
#0>     Client: rep_movsd @ BURNERDEV1.DAL1.MYCOMPANY.IO
Server: krbtgt/BURNERDEV1.DAL1.MYCOMPANY.IO @ BURNERDEV1.DAL1.MYCOMPANY.IO
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize
Start Time: 7/16/2020 2:05:51 (local)
End Time:   7/16/2020 12:05:51 (local)
Renew Time: 7/23/2020 2:05:51 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96

#1>     Client: rep_movsd @ BURNERDEV1.DAL1.MYCOMPANY.IO
Server: HTTP/mywebapp.k8s.dal1.mycompany.io @ BURNERDEV1.DAL1.MYCOMPANY.IO
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
Start Time: 7/16/2020 2:06:01 (local)
End Time:   7/16/2020 12:05:51 (local)
Renew Time: 7/23/2020 2:05:51 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96

我设置Firefox进行SPENGO身份验证然后我点击我的webapp.k8s.dal1.mycompany.io/ad-login，得到一个403 Forbidden错误

nginx服务器调试日志显示：

[debug] 16#16: *195 Client sent a reasonable Negotiate header 
[debug] 16#16: *195 GSSAPI authorizing 
[debug] 16#16: *195 Use keytab /etc/krb5.keytab 
[debug] 16#16: *195 Using service principal: HTTP/[e-mail] 
[debug] 16#16: *195 my_gss_name HTTP/[e-mail] 
[debug] 16#16: *195 gss_accept_sec_context() failed: Cannot decrypt ticket for HTTP/[e-mail] using keytab key for HTTP/[e-mail]: 
[debug] 16#16: *195 GSSAPI failed 
[debug] 16#16: *195 http finalize request: 403, "/ad-login?" a:1, c:1 
[debug] 16#16: *195 http special response: 403, "/ad-login?" 
[debug] 16#16: *195 http set discard body 
[debug] 16#16: *195 charset: "" > "utf-8" 
[debug] 16#16: *195 HTTP/1.1 403 Forbidden

顺便说一句，我发现如果我为"；门户"；用户使用ktpass并在工作站上以该帐户登录，则登录将成功。我有一种错误的印象，认为我需要为每个用户创建一个新的键选项卡，并将所有用户组合在一起。

我们非常感谢任何帮助——我读了这么多相互矛盾的文件，这只会让我更加困惑，我一直在为此失眠。

提前感谢！

Answer 1

我已经仔细阅读了您的问题陈述，我认为如果您遵循我在下面写的步骤，问题就会得到解决。

1. 在创建keytab的DC服务器上，(1(必须暂时禁用UAC。(2( 创建keytab的用户必须是Domain Admins组的成员
2. 确保SPN不重复，然后从Active Directory用户帐户门户中删除SPN。在对同一帐户使用同一SPN创建新的密钥选项卡之前，必须执行此操作。下面的命令是一行，换行使其看起来像两行

setspn-d HTTP/[e-mail]门户

3. 按照以前的操作重新创建键选项卡
4. 您不需要运行命令setspn -A HTTP/[e-mail] portal，因为步骤3中ktpass命令已经在Active Directory用户帐户上设置了SPN
5. 用新的键选项卡替换旧的键选项卡
6. 重新启动nginx Web服务器服务
7. 清除浏览器缓存并清除Kerberos案例(klist清除(
8. 再试一次

您必须完成所有这些步骤，包括最后的步骤7。不要跳过任何。

您的服务帐户名为门户。此密码的哈希存储在Active Directory和keytab中。两个位置都有相同的哈希。nginix服务器上的keytab用于解密入站Kerberos服务票证，以确定用户试图访问web应用程序的用户。更具体地说，GSS身份验证完成了所有工作，它使用keytab对加密的服务票证进行解扰。用户rep_movsd不具有服务帐户凭据。它是Active Directory域的一部分，当访问nginix web服务器时，它会获得自己的Kerberos服务票证，并且只需拥有由keytab解密的服务票证即可向web服务器证明其身份。如果它不是BURNERDEV1.DAL1.MYCOMPANY.IO域的一部分，或者密码过期，或者是被禁用的帐户，它将无法获得服务票证，从而无法证明自己的身份并无法通过身份验证。

如果你有时间，请参阅我在TechNet Wiki上发表的关于键选项卡创建及其背后的逻辑的文章，以帮助你更好地理解这个复杂的主题。