Мой локальный компьютер использует 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 исчезает. Только FR TGT виден в MIT Kerberos. Если я блокирую свой компьютер, а затем разблокирую его с помощью своего пароля, то теперь FR TGT исчезает, заменяется новым LR TGT.
Кажется, MIT Kerberos для Windows может хранить только один TGT за раз. Каждый TGT полностью работает для своей цели во всех смыслах и целях. Как я могу настроить MIT Kerberos, чтобы позволить мне иметь два TGT одновременно, по одному для каждой области? Можно ли «разделить» несколько клиентских экземпляров, каждый из которых указывает на разные KRB5_CONFIG и локальную таблицу ключей? Если я не могу, есть ли альтернативная реализация Windows Kerberos 5 на стороне клиента, которая будет работать, даже если нет доверительных отношений между сферами?
PS - я не хочу доверия. Не могу получить доверие.
ОБНОВЛЕНИЕ: я пропустил некоторые из этих деталей ранее, потому что я думал, что это может запутать проблему. Но, основываясь на ответе Брэда, это может быть оправдано. Я ожидаю, что большинство локального программного обеспечения будет использовать встроенную в Windows реализацию Kerberos и всегда использовать LR keytab.
Тем не менее, опытные пользователи, такие как я, используют Heimdal под Cygwin для SSH в FR. Я ожидаю, что что-нибудь, проходящее через библиотеки Cygwin, будет использовать heimdal и никогда не видеть LR TGT (чего не происходит, по крайней мере, по умолчанию). Я явно kinit и двигаться дальше.
Сложная часть приходит для неопытных пользователей, которых я должен поддерживать, которые не используют Cygwin, но используют PuTTY. PuTTY позволяет вам указать и путь к библиотеке, и DLL, для которой будет использоваться реализация GSSAPI. Например, я настраиваю сеансы SSH для использования библиотек MIT Kerberos вместо встроенных библиотек Windows. Я надеялся, что существует библиотека DLL, которая либо никогда не пыталась найти LR TGT (например, heimdal), либо позволяла использовать несколько TGT из нескольких областей. Не обязательно иметь окно с графическим интерфейсом, как MIT Kerberos, но это помогает.
Ответы:
Ну, я не скажу, что это НЕ МОЖЕТ быть сделано с Windows, но я скажу, что ограничение основано на сессиях. Проблема в том, что для каждого сеанса Windows кэширует один тикет. Когда вы блокируете свой компьютер, затем разблокируете его, начинается другой сеанс и запрашивается новый ключ от KDC. То же самое происходит, когда вы снова выходите из системы на свой компьютер. На самом деле этот метод определяет, каким образом пользовательские разрешения определяются и для сеансов сервера, то есть ключ / тикет можно кэшировать, чтобы каждый ресурс или сеанс сервера, который вы инициируете, не запрашивал ваш пароль, но я никогда не слышал / читать / исследовать его, чтобы иметь возможность кэшировать более одного.
Теперь вы, вероятно, уже знаете, что, учитывая ваши знания, которые вы отображали в своем вопросе, поэтому я скажу, что исходя из того факта, что Windows хранит ключ, который вы получаете, когда выдается TGT и основан на сеансе, я не думаю, что это возможно только с Windows. MIT Kerberos для Windows может иметь способ инициировать две сессии под одним пользователем, но даже тогда я не уверен, как ресурсы, к которым вы обращаетесь, узнают, какую пару билет / ключ использовать. Имеет ли это смысл?
Пожалуйста, посмотрите это для описания того, как Windows хранит пары TGT / key.
Кстати, очень хороший вопрос.
источник
Хорошо, я придумала рабочее решение, которое нуждается в некоторой полировке, поэтому может работать не во всех средах.
Это работает с:
Я искал в источнике MIT Kerberos и наткнулся на README для Windows . Особый интерес представляли различные значения для кэша учетных данных . Он поддерживает значение по умолчанию API:, но я неожиданно обнаружил, что мой реестр использует MSLSA: вместо этого.
Я играл с разными значениями 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 на моей локальной рабочей станции.
источник
Для меня это выглядит как ошибка в Kerberos для Windows.
Я нашел следующее:
Если я использую опцию «получить билет» в окне KfW 4.0.1, это просто работает (TM); Я могу нажать кнопку «Получить билет» и приобрести дополнительные билеты на оригинальные билеты, полученные при входе в систему.
Если я выберу опцию «сделать по умолчанию» в окне KfW, то с этого момента каждый раз, когда я нажимаю «получить билет», новый билет будет заменять любой билет по умолчанию, а не добавлять другую запись в список известных билетов. , Проверка реестра в этот момент покажет, что
ccnameзапись (как в ответе Тоддиуса) была добавлена. Удаление этой записи, к удивлению, восстановит предыдущее поведение разрешения нескольких билетов.источник
После ответа Тоддиуса у меня есть коллега в аналогичной ситуации (64-разрядная версия Windows 7 Enterprise, присоединенная к домену AD, также работающая с MIT Kerberos для Windows 4.0.1): его копия Kerberos Ticket Manager будет Позволить ему иметь только одного основного / одного TGT. Всякий раз, когда он использовал кнопку «Получить билет», чтобы получить TGT для другого участника, предыдущий участник исчезал.
Я рассмотрел README , и большинство ключей реестра были установлены , как и ожидалось, за исключением для ccname ключа на пути
HKEY_CURRENT_USER\Software\MIT\Kerberos5. Этот ключ был установлен в значениеMSLSA:. Нашим решением было изменить это наAPI:. Более конкретно, шаги были:HKEY_CURRENT_USER\Software\MIT\Kerberos5измените ключ ccname наAPI:(API, затем двоеточие).С помощью описанных выше шагов все работало, и мой коллега теперь может видеть несколько принципалов / TGT одновременно.
Кстати, MIT Kerberos для Windows содержит собственный набор программ командной строки (например, klist), и эти программы поддерживают несколько кэшей учетных данных. В моей 64-битной системе, когда я запускаю
"C:\Program Files\MIT\Kerberos\bin\klist.exe" -A"после получения нескольких TGT, я вижу своего участника Active Directory в кэше MSLSA, а затем у меня есть один кэш API для каждого дополнительного участника.PS Это моя первая запись на этом сайте, поэтому я не смог добавить ее в качестве комментария к ответу Тоддиуса. Извиняюсь!
источник