Настройка файла Kerberos krb5.conf для обработки основного и дополнительного «клонированного» домена

Question

(Обязательный префикс для новичка: никогда не играл много с 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's password: 
kinit: krb5_get_init_creds: unable to reach any KDC in realm test, tried 0 KDCs

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

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

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

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

Answer 1

например, 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 в тесте области, пробовал 0 KDC

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

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

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

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

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

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

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

Проверьте, какой тип кэша учетных данных используется (как показано в klist в " Tache cache" или в переменной среды $ 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