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

1085
Rachel Ambler

(Обязательный префикс для новичка: никогда не играл много с 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, в конечном итоге должны будут работать.

0
Все серверы являются виртуальными, мы скопировали все серверы и запустили их на разных физических хостах и ​​обеспечили маршрутизацию для перехода от .foo.local к .test. Мой вопрос не столько касается клонирования, сколько "как мы можем получить токены из домена .test" Rachel Ambler 5 лет назад 0
Я сделал вышеупомянутый комментарий, потому что пользователь спросил, как среды были клонированы. К сожалению, этот человек впоследствии удалил свой вопрос, что привело меня к болтовне. Хранение этого там, чтобы обеспечить контекст. Rachel Ambler 5 лет назад 0

1 ответ на вопрос

0
grawity

например, 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 
Спасибо за пожары после боя прямо сейчас, так что придется смотреть позже. Rachel Ambler 5 лет назад 0