我在使用 Windows 2012 DC 作为 KDC 在 Ubuntu 16.04 上配置 KRB5 时遇到一个奇怪的问题。如果向 kinit 的密码提示提供了密码，则使用服务 AD 帐户调用 kinit 会成功，但在使用具有完全相同密码的 keytab 文件时会失败。当然，最简单的解释是密钥表文件中的密码错误。但该文件是自动生成的，并且由相同代码生成的密钥表在另一个环境中工作。尽管如此，我多次手动生成了新的 keytab 文件，并在 Windows 上生成了一个 keytab 文件ktpass（您可以在命令行上向 ktpass 提供密码），以排除任何与密码相关的问题。然而，结果始终是相同的：使用密钥表文件进行身份验证不起作用。
我猜这个问题可能与 Windows DC 上的某些设置有关，但我不知道在哪里查找。
使用密码成功验证：
root@my-server / # KRB5_TRACE=/dev/stdout kinit -V service_user :(
Using default cache: /tmp/krb5cc_0
Using principal: [email protected]
[3880] 1550161945.213705: Getting initial credentials for [email protected]
[3880] 1550161945.213896: Sending request (194 bytes) to DOMAIN.INT
[3880] 1550161945.214051: Sending initial UDP request to dgram 192.168.0.1:88
[3880] 1550161945.215117: Received answer (190 bytes) from dgram 192.168.0.1:88
[3880] 1550161945.215158: Response was from master KDC
[3880] 1550161945.215184: Received error from KDC: -1765328359/Additional pre-authentication required
[3880] 1550161945.215225: Processing preauth types: 16, 15, 19, 2
[3880] 1550161945.215243: Selected etype info: etype aes256-cts, salt "DOMAIN.INTrmcloudmember", params ""
Password for [email protected]:
[3880] 1550161955.687314: AS key obtained for encrypted timestamp: aes256-cts/0FBD
[3880] 1550161955.687371: Encrypted timestamp (for 1550161956.151464): plain 301AA011180F32303139303231343136333233365AA1050203024FA8, encrypted 9B8C1FB7CC85C23D0D803DCF2C29655D329628F98C505CEBE8EA1F3353D8D513CFAE25C1E146D74C5C4FE71326FCF12F6ED911FBC2B14FE2
[3880] 1550161955.687398: Preauth module encrypted_timestamp (2) (real) returned: 0/Success
[3880] 1550161955.687404: Produced preauth for next request: 2
[3880] 1550161955.687430: Sending request (274 bytes) to DOMAIN.INT
[3880] 1550161955.687522: Sending initial UDP request to dgram 192.168.0.1:88
[3880] 1550161955.695617: Received answer (94 bytes) from dgram 192.168.0.1:88
[3880] 1550161955.695671: Response was from master KDC
[3880] 1550161955.695690: Received error from KDC: -1765328332/Response too big for UDP, retry with TCP
[3880] 1550161955.695696: Request or response is too big for UDP; retrying with TCP
[3880] 1550161955.695701: Sending request (274 bytes) to DOMAIN.INT (tcp only)
[3880] 1550161955.695731: Initiating TCP connection to stream 192.168.0.1:88
[3880] 1550161955.696053: Sending TCP request to stream 192.168.0.1:88
[3880] 1550161955.697043: Received answer (1831 bytes) from stream 192.168.0.1:88
[3880] 1550161955.697053: Terminating TCP connection to stream 192.168.0.1:88
[3880] 1550161955.697089: Response was from master KDC
[3880] 1550161955.697117: Processing preauth types: 19
[3880] 1550161955.697127: Selected etype info: etype aes256-cts, salt "DOMAIN.INTdomainmember", params ""
[3880] 1550161955.697143: Produced preauth for next request: (empty)
[3880] 1550161955.697152: AS key determined by preauth: aes256-cts/0FBD
[3880] 1550161955.697201: Decrypted AS reply; session key is: aes256-cts/DD7B
[3880] 1550161955.697220: FAST negotiation: unavailable
[3880] 1550161955.697239: Initializing FILE:/tmp/krb5cc_0 with default princ [email protected]
[3880] 1550161955.697329: Storing [email protected] -> krbtgt/[email protected] in FILE:/tmp/krb5cc_0
[3880] 1550161955.697364: Storing config in FILE:/tmp/krb5cc_0 for krbtgt/[email protected]: pa_type: 2
[3880] 1550161955.697394: Storing [email protected] -> krb5_ccache_conf_data/pa_type/krbtgt\/DOMAIN.INT\@DOMAIN.INT@X-CACHECONF: in FILE:/tmp/krb5cc_0
Authenticated to Kerberos v5
使用密钥表文件进行身份验证失败：
root@my-server / # KRB5_TRACE=/dev/stdout kinit -V -k -t /etc/krb5/service_user.keytab service_user
Using default cache: /tmp/krb5cc_0
Using principal: [email protected]
Using keytab: /etc/krb5/service_user.keytab
[3844] 1550161914.505633: Getting initial credentials for [email protected]
[3844] 1550161914.505787: Looked up etypes in keytab: des-cbc-crc, des, des-cbc-crc, rc4-hmac, aes256-cts, aes128-cts
[3844] 1550161914.505838: Sending request (194 bytes) to DOMAIN.INT
[3844] 1550161914.505972: Sending initial UDP request to dgram 192.168.0.1:88
[3844] 1550161914.507116: Received answer (190 bytes) from dgram 192.168.0.1:88
[3844] 1550161914.507146: Response was from master KDC
[3844] 1550161914.507170: Received error from KDC: -1765328359/Additional pre-authentication required
[3844] 1550161914.507199: Processing preauth types: 16, 15, 19, 2
[3844] 1550161914.507216: Selected etype info: etype aes256-cts, salt "DOMAIN.INTdomainmember", params ""
[3844] 1550161914.507263: Retrieving [email protected] from FILE:/etc/krb5/service_user.keytab (vno 0, enctype aes256-cts) with result: 0/Succes-s
[384] 1550161914.507280: AS key obtained for encrypted timestamp: aes256-cts/3ABA
[3844] 1550161914.507329: Encrypted timestamp (for 1550161914.976630): plain 301AA011180F32303139303231343136333135345AA10502030EE6F6, encrypted BD37FD997AD3BB56EA1893F99CDCDC7AF49964AC65E686316BE58F545609C3EE15E5753D57B9812794EB480E7F3D2B61613B2F9518DB5841
[3844] 1550161914.507344: Preauth module encrypted_timestamp (2) (real) returned: 0/Success
[3844] 1550161914.507353: Produced preauth for next request: 2
[3844] 1550161914.507371: Sending request (274 bytes) to DOMAIN.INT
[3844] 1550161914.507407: Sending initial UDP request to dgram 192.168.0.1:88
[3844] 1550161914.513601: Received answer (156 bytes) from dgram 192.168.0.1:88
[3844] 1550161914.513649: Response was from master KDC
[3844] 1550161914.513665: Received error from KDC: -1765328360/Preauthentication failed
[3844] 1550161914.513684: Preauth tryagain input types: 16, 15, 19, 2
kinit: Preauthentication failed while getting initial credentials
更新2019-09-02：我没有找到解决方案，而是改用管道将密码传递给 kinit。
答案1
我面临着完全相同的问题。根本原因是kerberos服务器只支持rc4-hmac加密类型。
解决方案：在 ktutil 中使用
ktutil: addent -password -p foo@bar -k 0 -e rc4-hmac
Password for foo@bar:
ktutil: wkt foo.keytab
ktutil: quit
ktinit -kt foo.keytab foo
这对我有用。如果它不适合您，请一次尝试所有不同的加密类型。
答案2
我们遇到了同样的问题，发现这是由于域帐户被更新为使用不同的sAMAccountName// CN（name所有帐户都更新为与初始创建时不同的内容）。
让我们意识到这个问题的是这一行：
Selected etype info: etype aes256-cts, salt "DOMAIN.INTdomainmember", params ""
在我们的例子中，该salt值引用原始名称而不是更新后的名称。在原始问题的输出示例中，盐是DOMAIN.INTdomainmember，它暗指域帐户名 ，domainmember而不是service_user（如命令中使用的kinit）。
我们的修复方法是删除并重新创建服务帐户（从一开始就使用正确/所需的名称），这解决了问题。
一定要喜欢 Kerberos！