Кілька областей і декілька TGT під MIT Kerberos для Windows

Мій локальний комп'ютер використовує Windows 7 Pro та належить до області LR, керованої AD-серверами. Я входжу на свій комп’ютер, підключаючись до мережі цього царства. Я можу переглянути TGT за допомогою MIT Kerberos для Windows ver. 4.0.1.

Я хочу отримати доступ до ресурсів в іноземній царині, ФР. Немає довіри Kerberos між LR та FR, але вони дозволяють TCP-трафіку між собою. Я прошу TGT для FR з його KDC (Red Hat IdM / FreeIPA) і успішно вводите свій пароль при виникненні проблеми. Знову я можу переглянути TGT з MIT Kerberos для Windows ver. 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, яка буде, навіть якщо немає міжреальних трастів?

PS - Я не хочу довіри. Неможливо отримати довіру.

ОНОВЛЕННЯ: Деякі з цих деталей я покинув раніше, тому що думав, що це може заплутати проблему. Але виходячи з відповіді Бреда, це може бути обґрунтованим. Я вважаю, що більшість локальних програмних засобів використовуватимуть вбудовану реалізацію Windows Kerberos та завжди використовуватиме клавішу LR.

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

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

Ну, я не скажу, що це не можна робити з Windows, але я скажу, що обмеження засноване на сеансі. Проблема тоді полягає в тому, що на кожен сеанс Windows кешується один квиток. Коли ви заблокуєте комп'ютер, тоді розблокуйте його, ініціюється ще один сеанс, і новий KDC запитається новий ключ. Те ж саме відбувається, коли ви знову виходите з комп'ютера. Цей метод насправді визначається дозволом користувача для сеансів на сервері, тобто ключ / квиток можна кешувати, щоб кожен ініційований ресурс сервера або сеанс не потребував вас просити вашого пароля, але я ніколи не чув / читати / досліджувати його, щоб мати можливість кешувати більше одного.

Тепер ви, мабуть, уже знаєте, що зважаючи на ваші знання, які ви показали у своєму запитанні, тому я скажу, що виходячи з того, що Windows зберігає ключ, який ви отримуєте, коли TGT видається і заснований на сеансі, я не думаю, що це можливо з JUST Windows. У MIT Kerberos для Windows може бути спосіб ініціювати два сеанси під одним користувачем, але навіть тоді я не впевнений, яким чином ресурси, до яких ви звертаєтесь, буде знати, яку пару квитків / ключів використовувати. Чи має це сенс?

Будь ласка, дивіться це для опису того, як Windows зберігає TGT / пари ключів.

Дуже добре запитання до речі.

Гаразд, я придумав робоче рішення, яке потребує трохи полірування, тому може працювати не у всіх середовищах.

Це працює з:

1. MIT Kerberos для Windows 4.0.1 з інструментами підтримки Windows (KSETUP.EXE, KTPASS.EXE)
2. PuTTY 0,63
3. Windows 7 SP1

Я шукав джерело MIT Kerberos і натрапив на README для Windows . Особливий інтерес викликали різні значення для кешу облікових даних . Він підтримує значення API за замовчуванням 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 Lock / Unlocks. ПРИМІТКА:не забудьте повністю вийти та перезапустити Менеджер квитків між правками реєстру. Я не випробував ccname з API: поки.

Я не знаю, чи має це значення чи ні, але я також грав разом з KSETUP, перш ніж це почало працювати. Спочатку параметр KSETUP просто показав би мені інформацію про LR. Я додав інформацію про ФР на своїй місцевій робочій станції.

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

Для мене це схоже на те, що насправді є помилка в Kerberos для Windows.

Я знайшов таке:

Якщо я використовую опцію "отримати квиток" у вікні KfW 4.0.1, це просто працює (TM); Я можу натиснути кнопку "Отримати квиток" та придбати додаткові квитки до оригінальних квитків, які я отримав під час входу.

Якщо я натиснув опцію «зробити за замовчуванням» у вікні KfW, то з цього моменту щоразу, коли натискаю «отримати квиток», новий квиток замінить будь-який квиток за замовчуванням, а не додасть ще один запис до списку відомих квитків . Перевірка реєстру в цьому пункті покаже, що додано ccnameзапис (як у відповіді Тоддіуса). Видалення цього запису, на диво, відновить попередню поведінку щодо отримання декількох квитків.

Після відповіді Тоддіуса у мене є співробітник у подібній ситуації (Windows 7 Enterprise 64-розрядний, приєднався до домену AD; також працює MIT Kerberos для Windows 4.0.1): Його копія менеджера квитків Kerberos дозволяють йому мати лише одного головного / одного TGT. Щоразу, коли він використовував би кнопку "Отримати квиток", щоб отримати TGT для іншого принципала, попередній головний голова зникне.

Я розглянув README , і більшість ключів реєстру були встановлені , як і очікувалося, за винятком для ccname ключа на шляху HKEY_CURRENT_USER\Software\MIT\Kerberos5. Для цього ключа було встановлено значення MSLSA:. Наше виправлення було змінити це API:. Більш конкретно, кроки були:

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

З вищезазначеними етапами все працювало, і я, співробітник, тепер може бачити декілька принципів / TGT одночасно.

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

PS Це мій перший запис на цьому сайті, тому я не зміг додати це як коментар до відповіді Тоддіуса. Вибачте!