Windows için MIT Kerberos altında Birden Çok Bölge ve Birden Çok TGT

Yerel bilgisayarım Windows 7 Pro kullanıyor ve AD sunucuları tarafından yönetilen bölge LR'sine ait. Bu alanın ağına bağlıyken bilgisayarıma giriş yapıyorum. TGT'yi Windows için MIT Kerberos ile görüntüleyebilirim. 4.0.1.

Yabancı bir alanda, FR kaynaklara erişmek istiyorum. LR ve FR arasında Kerberos güveni yoktur, ancak birbirleri arasında TCP trafiğine izin verirler. KDC (Red Hat IdM / FreeIPA) ile FR için TGT talep ediyorum ve sorgulandığında şifremi başarıyla giriyorum. Yine, Windows ver için MIT Kerberos ile TGT görüntüleyebilirim. 4.0.1. Artık LR kaynaklı olmasına rağmen, şifre istemeden SSH üzerinden FR'deki kaynaklara erişebiliyorum.

Sorun şu ki, FR için TGT'yi aldığımda, LR müdürüm için TGT kayboluyor. MIT Kerberos'ta sadece FR TGT görülebilir. Bilgisayarımı kilitler ve daha sonra şifremle kilidini açarsam, şimdi FR TGT artık yeni bir LR TGT ile değiştirildi.

Windows için MIT Kerberos aynı anda yalnızca bir TGT depolayabilir. Her TGT, tüm amaçları ve amaçları için kendi alanı için tamamen çalışır. MIT Kerberos'u aynı anda iki TGT'ye sahip olacak şekilde nasıl yapılandırabilirim? Her biri farklı bir KRB5_CONFIG ve yerel anahtar sekmesine işaret eden birden fazla istemci örneğiyle "bölümlere ayırmak" mümkün müdür? Eğer yapamıyorsam, bölgeler arası güven olmasa bile, istemci tarafı Kerberos 5'in alternatif bir Windows uygulaması var mı?

PS - Güven istemiyorum. Güven alamıyorum.

GÜNCELLEME: Bu ayrıntıların bazılarını daha önce hariç tutmuştum, çünkü konuyu karıştırabileceğini düşündüm. Ancak Brad'in cevabına dayanarak, garanti edilebilir. Beklediğim en yerel yazılım Kerberos yerleşik Windows'un uygulama kullanmak ve her zaman LR keytab kullanacaktır.

Ancak, benim gibi güç kullanıcıları, Cygwin altında heimdal'ı SSH'ye FR'ye kullanıyorlar. Cygwin DLL aracılığıyla heimdal kullanmak ve LR TGT (ki, en azından varsayılan olarak değil) asla görmek için bir şey bekliyoruz. Ben açıkça kinit ve devam ediyorum.

Zor kısmı, Cygwin kullanmayan ama PuTTY kullanan desteklemem gereken güç olmayan kullanıcılar için geliyor. PuTTY, GSSAPI uygulamasının kullanılacak kütüphane yolunu ve DLL dosyasını belirtmenize izin verir. Örneğin, SSH oturumlarını yerleşik Windows DLL'leri yerine MIT Kerberos DLL'lerini kullanacak şekilde yapılandırıyorum. Orada ya hiç LR TGT (heimdal gibi) bulmaya çalıştı ya da birden fazla alemlere birden fazla TGT izin bir DLL vardı umutluydu. MIT Kerberos gibi bir GUI penceresine sahip olması gerekmez, ancak yardımcı olur.

Peki, Windows ile yapılamayacağını söylemeyeceğim, ancak sınırlamanın oturum tabanlı olduğunu söyleyeceğim . O zaman sorun, her oturum için Windows'un bir bileti önbelleğe almasıdır. Bilgisayarınızı kilitledikten sonra kilidini açtığınızda başka bir oturum başlatılır ve KDC'den yeni bir anahtar istenir. Aynı şey oturumu kapatıp bilgisayarınıza tekrar açtığınızda da olur. Bu yöntem aslında sunucu oturumları için kullanıcı izinlerinin nasıl belirlendiğidir, yani anahtar / bilet önbelleğe alınabilir, böylece başlattığınız her sunucu kaynağı veya oturumun şifrenizi istemesine gerek kalmaz, ancak hiç duymadım / birden fazla önbelleğe alabilmek için okudum / araştırdım.

Şimdi, muhtemelen sorunuzda görüntülediğiniz bilginiz göz önüne alındığında, Windows'un bir TGT verildiğinde ve oturum tabanlı olduğunda aldığınız anahtarı sakladığı gerçeğine dayanarak söyleyeceğim. SADECE Windows ile mümkün olduğunu düşünüyorum. Windows için MIT Kerberos'un bir kullanıcı altında iki oturum başlatmanın bir yolu olabilir, ancak o zaman bile, eriştiğiniz kaynakların hangi bilet / anahtar çiftinin kullanılacağını nasıl bildiğinden emin değilim. bu mantıklı mı?

Windows'un TGT'leri / anahtar çiftlerini nasıl depoladığının açıklaması için lütfen buna bakın.

Bu arada çok güzel bir soru.

Tamam, biraz daha cilaya ihtiyaç duyan bir çalışma çözümü buldum, bu yüzden tüm ortamlarda çalışmayabilir.

Şununla çalışır:

1. Windows destek araçları ile Windows 4.0.1 için MIT Kerberos (KSETUP.EXE, KTPASS.EXE)
2. PuTTY 0,63
3. Windows 7 SP1

MIT Kerberos kaynağına bakıyordum ve Windows için README ile karşılaştım . Kimlik Bilgileri Önbelleği için farklı değerler özellikle ilgi çekiciydi . API: varsayılan bir değer benimser , ama şaşırtıcı bir şekilde MSLSA: yerine kullanarak benim kayıt bulundu .

Altında farklı ccname değerleri ile oynadımHKEY_CURRENT_USER\Software\MIT\Kerberos5 . BELLEK'i denedim : ilk başta, bazı ilginç davranışlara yol açtı. Bir PuTTY oturumu açarken, MIT Kerberos Ticket Manager pencerem geri yüklenir ve ön plana gelir ve kimlik bilgilerini girmemi ister. Vaov! Bu daha önce hiç olmadı, ama ne yazık ki PuTTY bunu reddedecekti. Benim için hile yapan değer oldu FILE:C:\Some\Full\File\Path. Belirtilen dosyaya erişimi nasıl güvenli bir şekilde yapacağımdan tam olarak emin değilim, bu yüzden bunu okuyucu için bir egzersiz olarak bırakacağım. Aynı pencere-ön plan davranış var, sadece PuTTY bu kez sevdim. Bilet Yöneticisi penceresi sonunda LR ve FR biletlerini de görüntüledi. Biletlerin önlenebilir olduğu kanıtlandı ve birden fazla Windows Kilidi / Kilidi açıldı. NOT:kayıt defteri düzenlemeleri arasında Bilet Yöneticisi'nden tamamen çıkıp yeniden başlattığınızdan emin olun. Ben denemedim ccname ait API: Henüz değil.

Bunun bir fark yaratıp yaratmadığını bilmiyorum, ancak çalışmaya başlamadan önce KSETUP ile de oynadım . İlk başta, parametresiz bir KSETUP bana LR hakkında bilgi verecektir. Yerel iş istasyonuma FR hakkında bazı bilgiler ekledim.

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

Bana göre, Windows için Kerberos'ta aslında bir hata var gibi görünüyor.

Aşağıdakileri buldum:

KfW 4.0.1 penceresinde "bilet al" seçeneğini kullanırsam, Just Works (TM); "Bilet al" düğmesine basabilir ve oturum açtığımda aldığım orijinal biletler için ek biletler edinebilirim .

KfW penceresindeki "varsayılan yap" seçeneğine basarsam, o zaman "bilet al" düğmesine her bastığımda, yeni bilet bilinen biletler listesine başka bir giriş eklemek yerine varsayılan biletin yerini alacak . Bu noktada kayıt defterini kontrol etmek, bir ccnamegirişin (Toddius'un cevabında olduğu gibi) eklendiğini gösterecektir. Bu girişin kaldırılması , şaşırtıcı bir şekilde, birden fazla bilete izin vermenin önceki davranışını geri yükleyecektir.

Toddius'un cevabını takiben, benzer bir durumda bir iş arkadaşım var (Windows 7 Enterprise 64 bit, bir AD etki alanına katıldı, ayrıca Windows 4.0.1 için MIT Kerberos da çalıştırıyor): Kerberos Bilet Yöneticisi'nin kopyası sadece bir müdür / bir TGT'ye sahip olmasına izin verin. Farklı bir anapara için bir TGT almak için "Bilet Al" düğmesini her kullanışında, bir önceki anapara kaybolurdu.

İnceledim README ve kayıt defteri anahtarlarını çoğu beklendiği gibi belirlenmiştir hariç için ccname yolda anahtarın HKEY_CURRENT_USER\Software\MIT\Kerberos5. Bu anahtar değere ayarlandı MSLSA:. Bizim çözümümüz bunu değiştirmekti API:. Daha spesifik olarak, adımlar şunlardı:

1. Diğer tüm uygulamalarla birlikte Kerberos Bilet Yöneticisi'nden çıkın (yeniden başlayacağınızdan beri).
2. Kayıt Defteri yolunda HKEY_CURRENT_USER\Software\MIT\Kerberos5, ccname anahtarını API:(API ve ardından iki nokta üst üste) olarak değiştirin.
3. Regedit'ten çıkın ve yeniden başlatın.
4. Tekrar giriş yaptıktan sonra Kerberos Ticket Manager'ı çalıştırın ve AD olmayan yöneticinizin TGT'sini almak için Bilet Al düğmesini kullanın.

Yukarıdaki adımlarla, her şey işe yaradı ve ben iş arkadaşım şimdi birden fazla prensibi / TGT'yi aynı anda görebiliyor.

Bu arada, Windows için MIT Kerberos kendi komut satırı programlarını (klist gibi) getirir ve bu programlar birden çok kimlik önbelleğini destekler. 64-bit sistemimde, "C:\Program Files\MIT\Kerberos\bin\klist.exe" -A"birden fazla TGT aldıktan sonra çalıştırdığımda , MSLSA önbelleğinde Active Directory sorumlumu görüyorum ve her ek ilke için bir API önbelleğim var.

Not: Bu sitedeki ilk girişim, bu yüzden Toddius'un cevabına yorum olarak ekleyemedim. Özür!