Настройка файла krb5.conf Kerberos для работы с основным и вторичным ‘клонированным’ доменом.

(Обязательный префикс для новичка: никогда много не играл с Kerberos, так что обращайтесь ко мне мягко!)

У нас есть два домена foo.local и .test.

.test был клонирован из foo.local, и, зайдя на сервер внутри .test, домен думает, что он является доменом foo.local.

Например, myserver.foo.local имеет IP-адрес 10.250.20.10, а myserver.test имеет IP-адрес 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: 
kinit: krb5_get_init_creds: невозможно достучаться до KDC в домене test, пробовал 0 KDC

Итак, вопросы:

1) Какие шаги я пропустил, чтобы аутентифицироваться против тестового домена – как мне настроить kinit, чтобы использовать сервер домена foo-dc02.test для аутентификации (или даже, нужно ли это, учитывая, что мой Windows LoginId и пароль одинаковы)?

2) Как только я это сделаю, как я могу убедиться, что при подключении к myserver.test он использует токен, полученный из kinit mylogin@test при попытке подключения?

Информация о системе: Все серверы AD работают на Windows, сейчас мои тесты POC проводятся с моего MacBook, но клиенты, работающие на Windows, Mac и Linux, в конечном итоге тоже должны будут работать.

Например, myserver.foo.local имеет IP-адрес 10.250.20.10, а myserver.test имеет IP-адрес 10.253.20.10, находясь внутри домена foo.local, но видит себя как 10.250.20.10, находясь внутри домена .test.

Адресация обычно не имеет значения для Kerberos, пока клиенты могут разрешать имена DNS и общаться с серверами (отправлять/получать IP-пакеты).

myLogin$ kinit -V mylogin@test
Пароль mylogin@test:
kinit: krb5_get_init_creds: невозможно достучаться до KDC в домене test, пробовал 0 KDC

Вы пытаетесь аутентифицироваться в домене test. Для Kerberos это не то же самое, что и домен TEST, который у вас в krb5.conf – в отличие от доменов DNS или доменов AD, имя домена Kerberos чувствительно к регистру.

Поскольку домен в нижнем регистре test не находится в [realms] в вашем krb5.conf, kinit использует другие методы для поиска KDC сервера – он ищет DNS SRV _kerberos._udp.<realm> записи после того, как переведет домен обратно в DNS домен.

Например, когда вы аутентифицируетесь по адресу …@test или …@TEST, и нет соответствующего подраздела [realms], вам нужны SRV записи по адресу _kerberos._udp.test по меньшей мере. (Active Directory должен добавлять их автоматически.)

Либо используйте kinit mylogin@TEST с правильным регистром, либо отрегулируйте конфигурацию [realms], либо убедитесь, что в вашем DNS домене test есть SRV записи, указывающие на контроллер домена.

(Кроме того: Если вы решите использовать строчную версию kinit mylogin@test, KDC Active Directory признает строчную форму, но возвращаемые билеты имеют домен в каноническом верхнем регистре, и большинство версий kinit отклонит несоответствующий ответ. Вы сможете разрешить канонизацию, используя kinit -C.)

Если ваше клиентское ПО – MIT Krb5, используйте export KRB5_TRACE=/dev/stderr, чтобы получить больше информации о том, что именно оно делает. (На macOS, вероятно, используется Heimdal.)

2) Как только я это сделаю, как я могу убедиться, что при подключении к myserver.test он использует токен, полученный из kinit mylogin@test при попытке подключения?

Проверьте, какой тип кеша учетных данных используется (как показано командой klist в “Кеш билетов” или установленным в переменной окружения $KRB5CCNAME).

Традиционный кеш учетных данных “FILE:” может содержать только билеты для одного клиента в первую очередь. Если вы выполните kinit как mylogin@TEST, вы всегда будете использовать билеты для 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, затем переключить ‘активный’ принципал, используя kswitch или даже определить пользовательские правила в файле ~/.k5identity (man 5 k5identity).

К сожалению, некоторые важные программы (такие как smbclient или Apache Directory Studio) пока не понимают кеши “DIR:” (или что-либо, кроме FILE: на самом деле).

При использовании macOS, то же самое применимо, но я считаю, что тип кеша учетных данных по умолчанию – “KCM:”, который может вероятно содержать несколько принципалов клиента. Или может и нет ¯\_(ツ)_/¯

Windows работает иначе; кеш билетов жестко связан с вашей сессией входа и (опять же) поддерживает только одного принципала клиента. Чтобы запустить программы от имени другого принципала без полного выхода из системы, используйте runas /netonly:

runas /netonly /user:mylogin@test cmd