☰

Несколько областей и несколько TGT в MIT Kerberos для Windows

tag-icon • tag-icon kerberos
Несколько областей и несколько TGT в MIT Kerberos для Windows

Мой локальный компьютер использует Windows 7 Pro и принадлежит к области LR, управляемой серверами AD. Я вхожу в свой компьютер, будучи подключенным к сети этой области. Я могу просматривать TGT с помощью MIT Kerberos для Windows версии 4.0.1.

Я хочу получить доступ к ресурсам в чужой области, FR. Между LR и FR нет доверия Kerberos, но они разрешают трафик TCP между собой. Я запрашиваю TGT для FR с его KDC (Red Hat IdM / FreeIPA) и успешно ввожу свой пароль при запросе. Опять же, я могу просмотреть TGT с MIT Kerberos для Windows версии 4.0.1. Теперь я могу получить доступ к ресурсам в FR через SSH без запроса пароля, несмотря на то, что я исходил из LR.

Проблема в том, что когда я получаю TGT для FR, TGT для моего принципала LR исчезает. В MIT Kerberos виден только FR TGT. Если я заблокирую свой компьютер, а затем разблокирую его с помощью пароля, то FR TGT исчезнет, ​​заменившись новым LR TGT.

Похоже, MIT Kerberos для Windows может хранить только один TGT за раз.Каждый TGT полностью работает для своей области для всех намерений и целей. Как мне настроить MIT Kerberos, чтобы у меня было два TGT одновременно, по одному для каждой области? Возможно ли «разделение» с несколькими клиентскими экземплярами, каждый из которых указывает на свой KRB5_CONFIG и локальный keytab? Если я не могу, есть ли альтернативная реализация Windows для клиентской стороны Kerberos 5, которая будет, даже если нет межобластных доверительных отношений?

PS - Мне не нужен траст. Не могу получить траст.

ОБНОВЛЯТЬ:Я опустил некоторые из этих деталей ранее, потому что я думал, что это может запутать вопрос. Но основываясь на ответе Брэда, это может быть оправдано. Я ожидаюбольшинстволокальное программное обеспечение будет использовать встроенную в Windows реализацию Kerberos и всегда использовать клавишу LR.

Однако опытные пользователи, такие как я, используют heimdal под Cygwin для SSH-подключения к FR. Я ожидаю, что все, что проходит через библиотеки DLL Cygwin, будет использовать heimdal и никогда не увидит LR TGT (чего не происходит, по крайней мере по умолчанию). Я явно использую kinit и иду дальше.

Сложность возникает для неопытных пользователей, которых я должен поддерживать, которые не используют Cygwin, но используют PuTTY. PuTTY позволяет вам указать как путь к библиотеке, так и DLL, для которой реализация GSSAPI должна использоваться. Например, я настраиваю сеансы SSH для использования DLL MIT Kerberos вместо встроенных DLL Windows. Я надеялся, что есть DLL, которая либо никогда не пытается найти LR TGT (например, heimdal), либо разрешает несколько TGT из нескольких областей. Она не обязательно должна иметь окно GUI, как MIT Kerberos, но это помогает.

решение1

Ну, я не буду говорить, что это НЕВОЗМОЖНО сделать с Windows, но я скажу, чтоограничение основано на сеансе. Проблема в том, что для каждого сеанса Windows кэширует один билет. Когда вы блокируете компьютер, а затем разблокируете его, инициируется другой сеанс, и из KDC запрашивается новый ключ. То же самое происходит, когда вы выходите из системы и снова входите в нее. Этот метод на самом деле определяет разрешения пользователя для сеансов сервера,это означает, что ключ/тикет можно кэшировать, так что каждый ресурс сервера или сеанс, который вы инициируете, не должен будет спрашивать ваш пароль, но я никогда не слышал/не читал/не исследовал, чтобы можно было кэшировать более одного.

Теперь, вы, вероятно, уже знаете это, учитывая ваши знания, которые вы продемонстрировали в своем вопросе, поэтому я скажу, что, основываясь на том факте, что Windows хранит ключ, который вы получаете при выпуске TGT, и основан на сеансе, я не думаю, что это возможно ТОЛЬКО с Windows. MIT Kerberos для Windows может иметь способ инициировать два сеанса под одним пользователем, но даже в этом случае я не уверен, как ресурсы, к которым вы обращаетесь, будут знать, какую пару билет/ключ использовать. Имеет ли это смысл?

Пожалуйста, ознакомьтесь с описанием того, как Windows хранит пары TGT/ключей.

Кстати, очень хороший вопрос.

решение2

Хорошо, я придумал работающее решение, которое нуждается в некоторой доработке, поэтому может не работать во всех условиях.

Это работает с:

  1. Массачусетский технологический институт Kerberosдля Windows 4.0.1 с инструментами поддержки Windows (KSETUP.EXE, KTPASS.EXE)
  2. Шпатлевка0,63
  3. Windows 7 SP1

Я искал в исходниках MIT Kerberos и наткнулся наREADME для WindowsОсобый интерес представляли различные значения дляКэш учетных данных. Он поддерживает значение по умолчаниюAPI-интерфейс:, но я неожиданно обнаружил, что мой реестр используетМСЛСА:вместо.

Я поигрался с разными значениямиccnameпод HKEY_CURRENT_USER\Software\MIT\Kerberos5. Я попробовалОБЪЕМ ПАМЯТИ:сначала, что привело к интересному поведению. При открытии сеанса PuTTY мое окно MIT Kerberos Ticket Manager восстанавливалось и выходило на передний план, предлагая мне ввести учетные данные. Ого! Раньше такого никогда не случалось, но, увы, PuTTY отклонял его. Значение, которое сработало для меня, было FILE:C:\Some\Full\File\Path. Я не совсем уверен, как защитить доступ к указанному файлу, поэтому оставлю это в качестве упражнения для читателя. Я получил то же самое поведение окна на переднем плане, только PuTTY это понравилось на этот раз. Окно Ticket Manager также наконец-то отобразило оба билета LR и FR. Было доказано, что билеты можно пересылать, и они выдерживают многократные блокировки/разблокировки Windows.ПРИМЕЧАНИЕ:обязательно полностью выйдите и перезапустите Ticket Manager между правками реестра. Я не пробовалccnameизAPI-интерфейс:еще.

Я не знаю, имеет ли это значение или нет, но я также поигрался сKSETUPдо того, как это начало работать. Сначала KSETUP без параметров просто показывал мне информацию о LR. Я добавил некоторую информацию о FR на моей локальной рабочей станции.

ksetup /AddKdc FOREIGN.REALM KDC.FOREIGN.REALM
ksetup /AddRealmFlags FOREIGN.REALM TcpSupported Delegate NcSupported

решение3

Мне кажется, что в Kerberos для Windows действительно есть ошибка.

Я нашел следующее:

Если я использую опцию «Получить билет» в окне KfW 4.0.1, это просто работает(TM); я могу нажать кнопку «Получить билет» и получитьдополнительныйбилеты на оригинальные билеты, которые я получил при входе в систему.

Если я нажму на опцию «Сделать по умолчанию» в окне KfW, то с этого момента каждый раз, когда я нажму «Получить билет», будет создаваться новый билет.заменятьлюбой билет по умолчанию, а не добавлять еще одну запись в список известных билетов. Проверка реестра в этот момент покажет, что ccnameзапись (как в ответе Тоддиуса) была добавлена.Удалениеэта запись, как ни странно, восстановит прежнее поведение, разрешающее использование нескольких билетов.

решение4

В продолжение ответа Тоддиуса, у меня есть коллега в похожей ситуации (Windows 7 Enterprise 64-bit, присоединенный к домену AD, также работающий с MIT Kerberos для Windows 4.0.1): его копия Kerberos Ticket Manager позволяла ему иметь только одного принципала/один TGT. Всякий раз, когда он использовал кнопку «Получить билет», чтобы получить TGT для другого принципала, предыдущий принципал исчезал.

Я рассмотрелПРОЧТИ МЕНЯ, и большинство ключей реестра были установлены так, как и ожидалось,кромедляccnamekey at path HKEY_CURRENT_USER\Software\MIT\Kerberos5. Этот key был установлен в значение MSLSA:. Наше исправление состояло в том, чтобы изменить его на API:. Более конкретно, шаги были следующими:

  1. Закройте Kerberos Ticket Manager и все остальные приложения (так как вам предстоит перезапуск).
  2. В разделе «Путь реестра» HKEY_CURRENT_USER\Software\MIT\Kerberos5изменитеccnameключ к API:(API, затем двоеточие).
  3. Выйдите из regedit и перезапустите его.
  4. После повторного входа в систему запустите Kerberos Ticket Manager и нажмите кнопку «Получить билет», чтобы получить TGT вашего принципала, не являющегося AD.

Благодаря вышеописанным шагам все заработало, и мой коллега теперь может видеть нескольких руководителей/TGT одновременно.

Кстати, MIT Kerberos для Windows предлагает свой собственный набор программ командной строки (например, klist), и эти программы поддерживают несколько кэшей учетных данных. В моей 64-битной системе, когда я запускаю "C:\Program Files\MIT\Kerberos\bin\klist.exe" -A"после получения нескольких TGT, я вижу своего принципала Active Directory в кэше MSLSA, а затем у меня есть один кэш API для каждого дополнительного принципала.

P.S. Это моя первая запись на этом сайте, поэтому я не смог добавить ее как комментарий к ответу Тоддиуса. Извините!

Связанный контент