например, 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 @ пароль теста:
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], вам понадобятся как _kerberos._udp.testминимум записи SRV . (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в разделе «Кэш билетов» или задано в переменной среды $ 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