在建立MIT Kerberos和Active Directory之间的跨域信任时，"KDC不支持加密类型“。

Question

我目前正在设置一个环境，其中有一组Solaris和Linux机器，使用的是专用的Krberos 5领域(麻省理工学院，在Solaris 11上，krb5-config --version返回：Solaris Kerberos (based on MIT Kerberos 5 release 1.6.3))。我们还为单独的领域提供了(Windows 2003)服务器。

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

假设如下：

• Unix领域: EXAMPLE.COM
• 广告领域: AD.EXAMPLE.COM

我已经根据微软文档建立了AD跨领域信任，使用了双向信任。

所发生的情况是，跨域身份验证只在一个方向工作。从AD到Unix works：

# kinit adtest@AD.EXAMPLE.COM
Password for adtest@AD.EXAMPLE.COM: 
root@clienttest2:~# kvno ltest@EXAMPLE.COM
ltest@EXAMPLE.COM: kvno = 1

但是，恰恰相反，它给了我一条错误消息: KDC在获取adtest@AD.EXAMPLE.COM凭据时不支持加密类型。

# kinit ltest@EXAMPLE.COM
Password for ltest@EXAMPLE.COM: 
root@clienttest2:~# kvno adtest@AD.EXAMPLE.COM
kvno: KDC has no support for encryption type while getting credentials for adtest@AD.EXAMPLE.COM

请注意，我尝试过各种不同的东西。其中一些是：

• 将Unix端的交叉域键配置为仅使用rc4-hmac，这样对kvno的调用甚至无法在微软端找到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
    }

Answer 1

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

解决办法很简单。我需要确保跨域身份验证主体是用rc4-hmac类型的单一编码类型创建的：

addprinc -e rc4-hmac krbtgt/AD.EXAMPLE.COM@EXAMPLE.COM
addprinc -e rc4-hmac krbtgt/EXAMPLE.COM@AD.EXAMPLE.COM

据我所知，在向AD服务器发送票据时，MIT使用最安全的编码类型。AD服务器无法处理该编码，因此回答错误，表示不支持加密类型。如果主体只有一个编码类型，MIT服务器将在与AD服务器对话时使用该类型。

Answer 2

我通过检查日记中的错误来解决这个问题。该错误声明：

-日志于2018-05-22 13:03:55世界协调时结束，2018-06-18 10:41:01世界协调时结束。--

6月18日10:40:55 nlxxp1 realmd1609年年：* Resolving：_ldap._tcp.local.domain

6月18日10:40:55 nlxxp1 realmd1609年年：*执行LDAP DSE查找: 10.x.x.1

6月18日10:40:55 nlxxp1 realmd1609年年：*执行LDAP DSE查找: 10.x.x.30

6月18日10:40:55 nlxxp1 realmd1609年年：*执行LDAP DSE查找: 10.x.x.60

6月18日10:40:55 nlxxp1 realmd1609年年：*成功发现: local.domain

6月18日10:41:00 nlxxp1 realmd1609年年：*假定安装了软件包

6月18日10:41:00 nlxxp1 realmd1609年年：* LANG=C /usr/sbin/adcli连接-详细-域local.domain -域-领域LOCAL.DOMAIN -域-控制器10.x.x.1 -登录类型用户-登录-用户本地用户--stdin-密码

6月18日10:41:00 nlxxp1 realmd1609年年：*使用域名: local.domain

6月18日10:41:00 nlxxp1 realmd1609年年：*计算出的计算机帐户名来自fqdn: NLXXP1

6月18日10:41:00 nlxxp1 realmd1609年年：*使用域域: local.domain

6月18日10:41:00 nlxxp1 realmd1609年年：*向域控制器发送登录点: cldap://10.x.x.1

6月18日10:41:01 nlxxp1 realmd1609年年：*收到来自: dc.local.domain的NetLogon信息

6月18日10:41:01 nlxxp1 realmd1609年年：*将krb5.conf片段写入nlxxp1

6月18日10:41:01 nlxxp1 realmd1609年年：！无法进行身份验证: localuserc@LOCAL.DOMAIN: KDC不支持加密类型

6月18日10:41:01 nlxxp1 realmd1609年年：adcli:未能连接到local.domain域:无法身份验证为: localuser@LOCAL.DOMAIN: KDC不支持加密类型

6月18日10:41:01 nlxxp1 realmd1609年年：！未能加入域

我的域是一个与2003年DC混合的域。

在我进入DNS并更改了2003年DC的_ldap._tcp.local.domain记录(我给它更重的重量400)之后，它选择了一个新的(2012r2dc)，它能够将服务器加入到域。

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