☰

在 MIT Kerberos 和 Active Directory 之间设置跨领域信任时出现“KDC 不支持加密类型”

tag-icon • tag-icon active-directory kerberos nfs4 pam-krb
在 MIT Kerberos 和 Active Directory 之间设置跨领域信任时出现“KDC 不支持加密类型”

我目前正在设置一个环境，其中有一组 Solaris 和 Linux 机器，使用专用的 Krberos 5 领域（MIT，在 Solaris 11 上，krb5-config --version返回Solaris Kerberos (based on MIT Kerberos 5 release 1.6.3)：）。我们还有一个用于单独领域的 Active Directory（Windows 2003）服务器。

我的目标是让所有用户都位于 AD 服务器中，而 host/nnn、nfs/nnn 和 cifs/nnn 主体位于基于 MIT 的领域中。我正在尝试在这两个领域之间建立跨域信任。

假设以下情况：

  • Unix 领域：示例.COM
  • AD 领域：广告示例.COM

我已经根据Microsoft 文档，双向信任。

跨领域身份验证仅在一个方向上有效。从 AD 到 Unix 有效：

# kinit [email protected]
Password for [email protected]: 
root@clienttest2:~# kvno [email protected]
[email protected]: kvno = 1

但是，相反的情况却没有，而是给了我一个错误信息：KDC 在获取以下凭证时不支持加密类型[电子邮件保护]

# kinit [email protected]
Password for [email protected]: 
root@clienttest2:~# kvno [email protected]
kvno: KDC has no support for encryption type while getting credentials for [email protected]

请注意，我尝试了各种不同的方法。其中一些是：

  • 配置 Unix 端的跨领域密钥rc4-hmac仅供使用，其结果是调用kvno甚至无法找到 Microsoft 端的 KDC。
  • 已添加default_tkt_enctypes和default_tgs_enctypes条目以强制使用rc4-hmac。这是使针对 AD 的登录身份验证正常运行所必需的。

这可能是什么原因造成的？我该如何弄清楚到底发生了什么？特别是，准确了解它试图使用哪种加密类型（KDC 不支持）将非常有帮助。了解哪个 KDC 发送了错误也很有用。

为了完整起见，以下是该文件的内容krb5.conf：

[libdefaults]
    default_realm = EXAMPLE.COM
    allow_weak_crypto = true
        verify_ap_req_nofail = false
        default_tkt_enctypes = rc4-hmac
        default_tgs_enctypes = rc4-hmac

[realms]
    EXAMPLE.COM = {
        kdc = unix-server.example.com
        admin_server = unix-server.example.com
    }
    AD.EXAMPLE.COM = {
        kdc = ad-server.ad.example.com
        admin_server = ad-server.ad.example.com
    }

[domain_realm]
    .example.com = EXAMPLE.COM
    .ad.example.com = AD.EXAMPLE.COM

[capaths]
    EXAMPLE.COM = {
        AD.EXAMPLE.COM = .
    }
    AD.EXAMPLE.COM = {
        EXAMPLE.COM = .
    }

[logging]
    default = FILE:/var/krb5/kdc.log
    kdc = FILE:/var/krb5/kdc.log
    kdc_rotate = {
        period = 1d
        versions = 10
    }

[appdefaults]
    kinit = {
        renewable = true
        forwardable = true
    }

答案1

我已经解决了这个问题。我在这里发布回复，以防其他人遇到同样的问题。

解决方案非常简单。我需要确保跨领域身份验证主体是使用单一编码类型创建的，类型为rc4-hmac：

addprinc -e rc4-hmac krbtgt/[email protected]
addprinc -e rc4-hmac krbtgt/[email protected]

据我所知，MIT KDC 在将票证发送到 AD 服务器时使用了最安全的编码类型。AD 服务器无法处理该编码，因此回复了不支持该加密类型的错误。由于主体只有一种编码类型，MIT 服务器在与 AD 服务器通信时将使用该类型。

答案2

我通过检查日志中的错误解决了这个问题。错误指出：
--日志开始于 2018-05-22 星期二 13:03:55 UTC，结束于 2018-06-18 星期一 10:41:01 UTC。 --
6 月 18 日 10:40:55 nlxxp1 realmd[1609]: * 正在解析：_ldap._tcp.local.domain
6 月 18 日 10:40:55 nlxxp1 realmd[1609]: * 正在对 10.xx1 执行 LDAP DSE 查找 6
月 18 日 10:40:55 nlxxp1 realmd[1609]: * 正在对 10.xx30 执行 LDAP DSE 查找
6 月 18 日 10:40:55 nlxxp1 realmd[1609]: * 正在对 10.xx60 执行 LDAP DSE 查找
6 月 18 日 10:40:55 nlxxp1 realmd[1609]: * 已成功发现：local.domain
6 月 18 日 10:41:00 nlxxp1 realmd[1609]: *假设软件包已安装
6 月 18 日 10:41:00 nlxxp1 realmd[1609]: * LANG=C /usr/sbin/adcli join --verbose --domain local.domain --domain-realm LOCAL.DOMAIN --domain-controller 10.xx1 --login-type user --login-user localuser --stdin-password 6 月
18 日 10:41:00 nlxxp1 realmd[1609]: * 使用域名：local.domain
6 月 18 日 10:41:00 nlxxp1 realmd[1609]: * 从 fqdn 计算出的计算机帐户名：NLXXP1
6 月 18 日 10:41:00 nlxxp1 realmd[1609]: * 使用域领域：local.domain
6 月 18 日 10:41:00 nlxxp1 realmd[1609]: * 向域控制器发送 netlogon ping：cldap://10.xx1
Jun 18 10:41:01 nlxxp1 realmd[1609]: * 从以下位置收到 NetLogon 信息：dc.local.domain
Jun 18 10:41:01 nlxxp1 realmd[1609]: * 将 krb5.conf 代码片段写入 /var/cache/realmd/adcli-krb5-QudocS/krb5.d/adcli-krb5-conf-8Gyp0B
Jun 18 10:41:01 nlxxp1 realmd[1609]: ! 无法验证身份：[电子邮件保护]：KDC 不支持加密类型
Jun 18 10:41:01 nlxxp1 realmd[1609]: adcli: 无法连接到 local.domain 域：无法以以下身份进行身份验证：[电子邮件保护]: KDC 不支持加密类型
Jun 18 10:41:01 nlxxp1 realmd[1609]: ! 无法加入域

我的域是一个混合域，带有 2003 DC。
在我进入 DNS 并更改 2003 DC 的 _ldap._tcp.local.domain 记录（我给它一个更大的权重 400）后，它选择了较新的（2012R2 DC），该 DC 能够将服务器加入域。

我猜 2003 DC 不支持所使用的加密类型。

相关内容