Mój komputer lokalny korzysta z systemu Windows 7 Pro i należy do dziedziny LR zarządzanej przez serwery AD. Loguję się na komputerze, gdy jestem podłączony do sieci tego królestwa. Mogę wyświetlić TGT za pomocą MIT Kerberos dla Windows wer. 4.0.1
Chcę uzyskać dostęp do zasobów w obcym królestwie, FR. Nie ma zaufania Kerberos między LR i FR, ale zezwala na ruch TCP między sobą. Proszę o TGT dla FR z jego KDC (Red Hat IdM / FreeIPA) i z powodzeniem wprowadzam moje hasło, gdy jest kwestionowane. Ponownie mogę wyświetlić TGT z MIT Kerberos dla Windows ver. 4.0.1 Mogę teraz uzyskiwać dostęp do zasobów w FR przez SSH bez pytania o hasło, mimo że pochodzi z LR.
Problem polega na tym, że kiedy otrzymam TGT dla FR, TGT dla mojego głównego LR znika. Tylko FR TGT jest widoczny w MIT Kerberos. Jeśli zablokuję komputer, a następnie odblokuję za pomocą hasła, teraz FR TGT zniknie, zastąpiony nowym LR TGT.
Wygląda na to, że MIT Kerberos dla Windows może przechowywać tylko jeden TGT na raz. Każdy TGT całkowicie działa dla swojego królestwa dla wszystkich celów i celów. Jak mogę skonfigurować MIT Kerberos, aby pozwolić mi mieć dwa TGT jednocześnie, po jednym dla każdej dziedziny? Czy jest możliwe „podzielenie na przedziały” z wieloma instancjami klienta, z których każda wskazuje na inny KRB5_CONFIG i lokalny klucz? Jeśli nie mogę, czy istnieje alternatywna implementacja systemu Windows dla Kerberos 5 po stronie klienta, która będzie działać, nawet jeśli nie ma zaufania między domenami?
PS - Nie chcę zaufania. Nie mogę zdobyć zaufania.
AKTUALIZACJA: Pominąłem niektóre z tych szczegółów wcześniej, ponieważ myślałem, że może to pomylić problem. Ale w oparciu o odpowiedź Brada może to być uzasadnione. Oczekuję, że większość lokalnego oprogramowania użyłaby wbudowanej implementacji Kerberos w systemie Windows i zawsze używała klawiatury LR.
Jednak zaawansowani użytkownicy, tacy jak ja, używają heimdal pod Cygwin do SSH do FR. Oczekuję, że wszystko, co przechodzi przez biblioteki DLL Cygwin, będzie używać heimdal i nigdy nie zobaczy LR TGT (czego nie robi, przynajmniej domyślnie). Wyraźnie gram i ruszam dalej.
Trudna część pojawia się dla użytkowników bez mocy, których muszę wspierać, którzy nie używają Cygwin, ale używają PuTTY. PuTTY pozwala określić zarówno ścieżkę biblioteki, jak i bibliotekę DLL, dla których ma być używana implementacja GSSAPI. Na przykład konfiguruję sesje SSH, aby używały bibliotek DLL MIT Kerberos zamiast wbudowanych bibliotek DLL systemu Windows. Miałem nadzieję, że istnieje tam biblioteka DLL, która albo nigdy nie próbowała znaleźć LR TGT (jak heimdal), albo dopuszczała wiele TGT z wielu dziedzin. Nie musi mieć okna GUI takiego jak MIT Kerberos, ale pomaga.
Odpowiedzi:
Cóż, nie powiem, że nie można tego zrobić w systemie Windows, ale powiem, że ograniczenie dotyczy sesji. Problem polega na tym, że dla każdej sesji system Windows buforuje jeden bilet. Po zablokowaniu komputera, a następnie odblokowaniu, inicjowana jest kolejna sesja i od KDC żądany jest nowy klucz. To samo dzieje się, gdy wylogujesz się, a następnie ponownie zalogujesz na komputerze. Ta metoda w rzeczywistości określa uprawnienia użytkowników również dla sesji serwera, co oznacza, że klucz / bilet może być buforowany, dzięki czemu każdy zasób serwera lub sesja, którą zainicjujesz, nie będzie musiała pytać o hasło, ale nigdy nie słyszałem / przeczytaj / zbadaj go, aby móc buforować więcej niż jeden.
Prawdopodobnie już wiesz, że zważywszy na twoją wiedzę, którą przedstawiłeś w swoim pytaniu, więc powiem, że w oparciu o fakt, że Windows przechowuje klucz, który otrzymujesz po wydaniu biletu TGT i jest oparty na sesji, ja nie myślę, że jest to możliwe dzięki JUST Windows. Kerberos MIT dla Windows może mieć sposób na zainicjowanie dwóch sesji pod jednym użytkownikiem, ale nawet wtedy nie jestem pewien, w jaki sposób zasoby, do których uzyskujesz dostęp, mogłyby wiedzieć, której pary biletów / kluczy użyć. Czy to ma sens?
Zobacz to, aby zobaczyć, jak Windows przechowuje TGT / pary kluczy.
Nawiasem mówiąc, bardzo dobre pytanie.
źródło
OK, opracowałem działające rozwiązanie, które wymaga nieco dopracowania, więc może nie działać we wszystkich środowiskach.
Działa to z:
Szukałem źródła MIT Kerberos i natknąłem się na README dla Windows . Szczególnie interesujące były różne wartości pamięci podręcznej poświadczeń . Opowiada się za domyślną wartością API :, ale nieoczekiwanie znalazłem mój rejestr za pomocą MSLSA: zamiast tego.
Bawiłem się z różnymi wartościami ccname poniżej
HKEY_CURRENT_USER\Software\MIT\Kerberos5. Próbowałem najpierw MEMORY: co prowadziło do interesujących zachowań. Podczas otwierania sesji PuTTY moje okno Menedżera biletów MIT Kerberos zostanie przywrócone i przejdzie na pierwszy plan, prosząc mnie o podanie poświadczeń. Łał! To się nigdy wcześniej nie zdarzyło, ale niestety PuTTY to odrzuci. Wartość, która mi pomogła, toFILE:C:\Some\Full\File\Path. Nie jestem do końca pewien, jak zabezpieczyć dostęp do określonego pliku, więc zostawię to jako ćwiczenie dla czytelnika. Mam takie samo zachowanie okna od pierwszego planu, tym razem tylko PuTTY go lubiło. Okno Menedżera biletów wreszcie wreszcie wyświetlało bilety LR i FR. Udowodniono, że bilety można przekazywać i przetrwają wiele blokad / odblokowań systemu Windows. UWAGA:pamiętaj, aby całkowicie zamknąć i ponownie uruchomić Menedżera biletów między edycjami rejestru. Nie próbowałem się do ccname z API: jeszcze.Nie wiem, czy to robi różnicę, czy nie, ale bawiłem się z KSETUP, zanim to zaczęło działać. Na początku bezparametrowy KSETUP pokazywałby mi tylko informacje o LR. Dodałem trochę informacji o FR na mojej lokalnej stacji roboczej.
źródło
Dla mnie wygląda trochę na błąd w Kerberos dla Windows.
Znalazłem następujące:
Jeśli użyję opcji „zdobądź bilet” w oknie KfW 4.0.1, to po prostu działa (TM); Mogę nacisnąć przycisk „Kup bilet” i uzyskać dodatkowe bilety do oryginalnych biletów, które dostałem po zalogowaniu.
Jeśli kliknę opcję „Ustaw jako domyślną” w oknie KfW, to od tego momentu za każdym razem, gdy kliknę „Pobierz bilet”, nowy bilet zastąpi domyślny bilet, zamiast dodawać kolejny wpis do listy znanych biletów . Sprawdzenie rejestru w tym momencie pokaże, że dodano
ccnamewpis (jak w odpowiedzi Toddiusa). Usunięcie tego wpisu, co zaskakujące, przywróci poprzednie zachowanie polegające na dopuszczaniu wielu biletów.źródło
Zgodnie z odpowiedzią Toddiusa mam współpracownika w podobnej sytuacji (64-bitowy system Windows 7 Enterprise, dołączony do domeny AD, również z uruchomionym programem MIT Kerberos dla systemu Windows 4.0.1): Jego kopia Menedżera biletów Kerberos pozwól mu mieć tylko jednego głównego / jeden TGT. Ilekroć użyje przycisku „Get Ticket”, aby uzyskać bilet TGT dla innego zleceniodawcy, poprzedni zleceniodawca zniknie.
Sprawdziliśmy README , a większość z kluczy rejestru zostały ustawione zgodnie z oczekiwaniami, except dla ccname klucz na ścieżce
HKEY_CURRENT_USER\Software\MIT\Kerberos5. Ten klucz został ustawiony na wartośćMSLSA:. Naszym rozwiązaniem była zmiana naAPI:. W szczególności kroki były następujące:HKEY_CURRENT_USER\Software\MIT\Kerberos5zmień klucz ccname naAPI:(API, a następnie dwukropek).Dzięki powyższym krokom wszystko działało, a ja współpracownik jest teraz w stanie zobaczyć wielu zleceniodawców / TGT jednocześnie.
Nawiasem mówiąc, MIT Kerberos dla Windows wprowadza własny zestaw programów wiersza poleceń (takich jak klist), a te programy obsługują wiele pamięci podręcznych poświadczeń. W moim 64-bitowym systemie, gdy uruchamiam
"C:\Program Files\MIT\Kerberos\bin\klist.exe" -A"po otrzymaniu wielu TGT, widzę moją nazwę główną usługi Active Directory w pamięci podręcznej MSLSA, a następnie mam jedną pamięć podręczną interfejsu API dla każdej dodatkowej jednostki głównej.PS To mój pierwszy wpis na tej stronie, więc nie mogłem go dodać jako komentarza do odpowiedzi Toddiusa. Przeprosiny!
źródło