active-directory – 在MIT Kerberos和Active Directory之间设置跨领域信任时,“KDC不支持加密类型”

前端之家收集整理的这篇文章主要介绍了active-directory – 在MIT Kerberos和Active Directory之间设置跨领域信任时,“KDC不支持加密类型”前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我目前正在建立一个环境,我有一套Solaris和 Linux机器,使用专用的Krberos 5领域(MIT,在Solaris 11上,krb5-config –version返回:Solaris Kerberos(基于MIT Kerberos 5版本1.6). 3)).我们还有一个用于单独领域的Active Directory(Windows 2003)服务器.

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

假设如下:

> Unix领域:EXAMPLE.COM
> AD领域:AD.EXAMPLE.COM

我根据Microsoft documentation设置了AD跨领域信任,具有双向信任.

发生的事情是跨领域认证仅在一个方向上起作用.从AD到Unix的工作原理:

# 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的调用甚至无法在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
    }

解决方法

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

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

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

据我所知,当将票证发送到AD服务器时,MIT KDC使用最安全的编码类型. AD服务器无法处理该编码,因此回复不支持加密类型的错误.通过仅为主体提供单一编码类型,MIT服务器将在与AD服务器通信时使用该类型.

猜你在找的Linux相关文章