Мой локальный компьютер использует 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 и локальный ключ? Если я не могу, есть ли альтернативная реализация Windows для клиентского Kerberos 5, которая будет работать, даже если нет межсферных доверительных отношений?
P.S. - Я не хочу доверия. Не могу получить доверие.
ОБНОВИТЬ: Я упустил некоторые из этих деталей ранее, потому что думал, что это может запутать проблему. Но, судя по ответу Брэда, это может быть оправдано. Я жду большинство локальное программное обеспечение будет использовать встроенную реализацию Kerberos в Windows и всегда использовать вкладку LR.
Однако опытные пользователи, такие как я, используют heimdal под Cygwin для перехода по SSH в FR. Я ожидаю, что все, что проходит через библиотеки DLL Cygwin, будет использовать heimdal и никогда не увидит LR TGT (чего нет, по крайней мере, не по умолчанию). Я явно кинит и двигаюсь дальше.
Сложная часть возникает для неопытных пользователей, которых я должен поддерживать, которые не используют 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 / ключи.
Кстати, очень хороший вопрос.
Хорошо, я нашел рабочее решение, которое требует дополнительной доработки, поэтому может работать не во всех средах.
Это работает с:
Я искал в источнике 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. В окне диспетчера билетов также, наконец, были отображены билеты 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
Для меня это похоже на ошибку в 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 для другого принципала, предыдущий принципал исчезал.
Я просмотрел ПРОЧТИ МЕНЯ, и большинство ключей реестра были настроены должным образом, Кроме для ccname ключ на пути HKEY_CURRENT_USER\Software\MIT\Kerberos5. Этот ключ был установлен на значение MSLSA:. Нашим решением было изменить это на API:. В частности, шаги были:
HKEY_CURRENT_USER\Software\MIT\Kerberos5, изменить ccname ключ к API: (A-P-I, затем двоеточие).С указанными выше действиями все сработало, и теперь мой коллега может видеть сразу несколько принципалов / TGT.
Между прочим, MIT Kerberos для Windows включает в себя собственный набор программ командной строки (например, klist), и эти программы поддерживают несколько кешей учетных данных. В моей 64-битной системе, когда я запускаю "C:\Program Files\MIT\Kerberos\bin\klist.exe" -A" после получения нескольких TGT я вижу свой участник Active Directory в кэше MSLSA, а затем у меня есть один кеш API для каждого дополнительного участника.
P.S. Это моя первая запись на этом сайте, поэтому я не смог добавить ее в качестве комментария к ответу Тоддиуса. Извинения!