☰

配置 Kerberos krb5.conf 文件来处理主域和辅助“克隆”域

tag-icon • tag-icon networking domain kerberos
配置 Kerberos krb5.conf 文件来处理主域和辅助“克隆”域

(新手必备前缀：从来没有玩过 Kerberos，所以在这里请对我温柔一点！)

我们有两个域foo.local和.test。

.test被克隆foo.local，并且一旦登录到域内的服务器，.test它就会认为是域foo.local。

例如，myserver.foo.localIP 地址为10.250.20.10其myserver.testIP 地址为10.253.20.10在域内时foo.local，但将自己视为10.250.20.10当在域内时.test。

此外myserver.foo.local可以伸手可及myserver.test但相反则不然。

此外，myserver.foo.local当联系myothersever.foo.local确实击中了域内的服务器时foo.local，但是当myserver.test连接到myotherserver.foo.local它时，它仍然停留在.test域内。

综上所述，这是我的/etc/krb5.conf文件（我很高兴得知它的配置很糟糕）：

[libdefaults]
  default_realm = FOO.LOCAL

[realms]
    FOO.LOCAL = {
        kdc = foo-dc01.foo.local
    }

    TEST = {
        kdc = foo-dc02.test
    }

当连接到内部服务器时，生活很美好foo.local，事实上我的kinit工作也是一种享受。Test但并非如此。

myLogin$ kinit -V  mylogin@test
mylogin@test's password: 
kinit: krb5_get_init_creds: unable to reach any KDC in realm test, tried 0 KDCs

因此，问题是：

1）我缺少哪些步骤来针对测试域进行身份验证 - 我如何配置kinit使用foo-dc02.test域服务器进行身份验证（或者，假设我的 Windows LoginId 和密码相同，我是否应该这样做）？

2）完成后，如何确保在连接时使用从尝试连接时myserver.test派生的令牌？kinit mylogin@test

系统信息：所有 AD 服务器都是 Windows，目前我的 POC 测试来自我的 MacBook，但运行在 Windows、Mac 和 Linux 上的客户端最终都需要工作。

答案1

例如，当位于 foo.local 域内时，myserver.foo.local 的 IP 地址为 10.250.20.10，而 myserver.test 的 IP 地址为 10.253.20.10，但当位于 .test 域内时，它将自己视为 10.250.20.10。

只要客户端能够解析 DNS 名称并与服务器通信（发送/接收 IP 数据包），寻址通常与 Kerberos 无关。

myLogin$ kinit -V mylogin@test
mylogin@test 的密码：
kinit：krb5_get_init_creds：无法到达领域测试中的任何 KDC，尝试了 0 个 KDC

您正在尝试验证该test领域。对于 Kerberos 来说，这是不是TEST与krb5.conf 中的领域相同– 与 DNS 域或 AD 域不同，Kerberos 领域名称区分大小写。

因为小写的testrealm 不在你的 krb5.conf 中的 [realms] 中，基尼特使用其他方法来查找 KDC 服务器 -_kerberos._udp.<realm>将领域转换回 DNS 域后，它会查找 DNS SRV 记录。

例如，当您针对…@test或进行身份验证…@TEST并且没有匹配的 [realms] 子部分时，您至少需要 SRV 记录_kerberos._udp.test。（Active Directory应该自动添加这些。

请使用kinit mylogin@TEST正确的大小写，或者调整 [realms] 配置，或者确保testDNS 域中有指向域控制器的 SRV 记录。

（此外：如果您选择使用小写的kinit mylogin@test，Active Directory KDCs将要识别小写形式，但返回的票证无论如何都具有规范大写的领域，并且大多数 kinit 版本将拒绝不匹配的响应。您将使用 允许规范化kinit -C。）

如果您的客户端软件是 MIT Krb5，请使用它export KRB5_TRACE=/dev/stderr来获取有关其正在执行的操作的更多信息。（不过 macOS 可能使用 Heimdal。）

2）完成后，如何确保在连接到 myserver.test 时，它在尝试连接时使用从 kinit mylogin@test 派生的令牌？

检查正在使用的凭证缓存类型（如klist“票证缓存”中所示或在 $KRB5CCNAME 环境变量中设置）。

传统的“FILE:”凭证缓存首先只能有一个客户端主体的票证。如果你以mylogin@TEST的身份进行kinit，你将总是使用 mylogin@TEST 的票证。在这种情况下，您必须通过将 $KRB5CCNAME 设置为不同的路径来手动在不同的缓存之间切换。

$ export KRB5CCNAME="FILE:/tmp/krb5cc_1000_prod" && kinit user@PROD && klist
$ export KRB5CCNAME="FILE:/tmp/krb5cc_1000_test" && kinit user@TEST && klist

$ kset() { export KRB5CCNAME="FILE:/tmp/krb5cc_$(id -u)_$1"; }
$ kset prod && kinit user@PROD && klist

使用 MIT Krb5 时，“DIR:”和（在 Linux 上）“KEYRING:”凭证缓存可同时支持多个客户端主体。您只需多次 kinit，然后使用文件 (man 5 k5identity)kswitch中的自定义规则切换“活动”主体即可~/.k5identity。

不幸的是，一些重要的程序（例如 smbclient 或 Apache Directory Studio）还不理解“DIR：”缓存（或者实际上除了 FILE：之外的任何内容）。

使用 macOS 时，与上述相同，但我相信默认凭据缓存类型是“KCM:”，它可以大概持有多个客户主体。或者可能不是¯\_(ツ)_/¯

Windows 的工作方式不同；票证缓存与您的登录会话紧密绑定，并且（再次）仅支持一个客户端主体。要以另一个主体身份启动程序而无需完全注销/登录，请使用runas /netonly：

runas /netonly /user:mylogin@test cmd

相关内容