Macun Kerberos / GSSAPI kimlik doğrulaması

RHEL6'da sssd kullanarak Active Directory Kerberos ile kimlik doğrulaması yapmak için birkaç Linux sunucusu yapılandırdım. Ayrıca şifresiz oturum açma umuduyla GSSAPI kimlik doğrulamasını etkinleştirdim.

Ancak Putty (0.63) 'ü şifre olmadan kimlik doğrulaması yapamıyorum.

GSSAPI, GSSAPI'yi etkinleştirmek için .ssh / config ayarlarını kullanarak AD kimlik doğrulaması için yapılandırılmış Linux sistemleri (openSSH istemcisi) arasında çalışır.

Ayrıca bilet almak için kinit komutunu çalıştırmanın yanı sıra aynı .ssh / config ayarlarını kullanarak Cygwin'den (openSSH istemcisi) çalışır.

Ayrıca, ev dizinleri de dahil olmak üzere tüm Linux sistemlerindeki Samba paylaşımları, parola gerektirmeden Windows Gezgini'nden çalışır (GSSAPI'nin orada devreye girip girmediğinden emin değilim)

Bu sorunu gidermek için ne tür şeyler deneyebilirim? Kullanıcılarımın çoğu Putty kullanıyor. Ayrıca, Windows Yöneticisi değilim, bu nedenle etki alanı denetleyicilerinde hiçbir şey yapamıyorum. Hesabımın yalnızca AD Alan Adı'na sunucu ekleme ayrıcalıkları var.

Macun SSH paket günlüğünü açtım. Bu tür ilginç buldum, bu bilgilerle ne yapacağımdan henüz emin değilim:

Event Log: Server version: SSH-2.0-OpenSSH_5.3
Event Log: Using SSH protocol version 2
Event Log: We claim version: SSH-2.0-PuTTY_Release_0.63
Outgoing packet #0x0, type 20 / 0x14 (SSH2_MSG_KEXINIT)
Incoming packet #0x0, type 20 / 0x14 (SSH2_MSG_KEXINIT)
Event Log: Doing Diffie-Hellman group exchange
Outgoing packet #0x1, type 30 / 0x1e (SSH2_MSG_KEX_DH_GEX_REQUEST)
Incoming packet #0x1, type 31 / 0x1f (SSH2_MSG_KEX_DH_GEX_GROUP)
Event Log: Doing Diffie-Hellman key exchange with hash SHA-256
Outgoing packet #0x2, type 32 / 0x20 (SSH2_MSG_KEX_DH_GEX_INIT)
Incoming packet #0x2, type 33 / 0x21 (SSH2_MSG_KEX_DH_GEX_REPLY)
Outgoing packet #0x3, type 21 / 0x15 (SSH2_MSG_NEWKEYS)
Event Log: Initialised AES-256 SDCTR client->server encryption
Event Log: Initialised HMAC-SHA1 client->server MAC algorithm
Outgoing raw data at 2014-11-25 00:21:08
Incoming packet #0x3, type 21 / 0x15 (SSH2_MSG_NEWKEYS)
Event Log: Initialised AES-256 SDCTR server->client encryption
Event Log: Initialised HMAC-SHA1 server->client MAC algorithm
Outgoing packet #0x4, type 5 / 0x05 (SSH2_MSG_SERVICE_REQUEST)
Incoming packet #0x6, type 51 / 0x33 (SSH2_MSG_USERAUTH_FAILURE)
...%gssapi-keyex
,gssapi-with-mic
,password.
Event Log: Using SSPI from SECUR32.DLL
Event Log: Attempting GSSAPI authentication
Outgoing packet #0x6, type 50 / 0x32 (SSH2_MSG_USERAUTH_REQUEST)
Incoming packet #0x7, type 60 / 0x3c (SSH2_MSG_USERAUTH_GSSAPI_RESPONSE)
Event Log: GSSAPI authentication initialised
Outgoing packet #0x7, type 61 / 0x3d (SSH2_MSG_USERAUTH_GSSAPI_TOKEN)
Incoming packet #0x8, type 61 / 0x3d (SSH2_MSG_USERAUTH_GSSAPI_TOKEN)
Event Log: GSSAPI authentication initialised
Event Log: GSSAPI authentication loop finished OK
Outgoing packet #0x8, type 66 / 0x42 (SSH2_MSG_USERAUTH_GSSAPI_MIC)
Incoming packet #0x9, type 51 / 0x33 (SSH2_MSG_USERAUTH_FAILURE)
...%gssapi-keyex
,gssapi-with-mic
,password.

Active Directory etki alanının parçası olan Windows makinelerinde, kullanıcılar Windows'da oturum açtıklarında Kerberos bilet veren biletlerini alırlar ve PuTTY, PuTTY Yapılandırma Bağlantısı | SSH | Auth | GSSAPI'da GSSAPI kimlik doğrulaması etkinleştirilmişse kimlik doğrulaması için bunu kullanabilir. (ve Pageant aracılığıyla ortak anahtar gibi GSSAPI'den önce denediği diğer kimlik doğrulama yöntemleri Bağlantı | SSH | Yetkilendirme'de kurulmaz veya devre dışı bırakılmaz).

[Ayrıca bilet yetkilendirmesine de ihtiyacınız varsa (örneğin, oturum açtıktan sonra sunucuya kerberized dosya sistemlerini bağlamak için), GSSAPI temsilcisinin PuTTY'de de etkinleştirildiğinden ve oturum açtığınız sunucuların Temsilci sekmesinde Active Directory'de işaretlendiğinden emin olun. " Bu bilgisayara herhangi bir hizmet için temsilci seçme konusunda güvenin (yalnızca Kerberos) ". AD'deki son güven ayarı garip bir şekilde yalnızca temsilci seçmenin PuTTY gibi Windows istemcilerinden çalışması için gereklidir; Linux "ssh -K" istemcileri için gerekli değildir.]

Active Directory etki alanının parçası olmayan, kendi kendini yöneten (kişisel) Windows makinelerinde, PuTTY aracılığıyla Kerberos / GSSAPI kimlik doğrulamasını (ve bilet yetkilendirmesini) kullanmaya devam edebilirsiniz, ancak bileti kendiniz almanız gerekir. Ne yazık ki, Windows 7 kinit programının herhangi bir eşdeğeri ile birlikte gelmez (manuel olarak bir bilet talep etmeniz için) ve PuTTY, biletiniz yoksa Kerberos şifrenizi de istemez. Bu nedenle, Windows için MIT Kerberos'u yüklemeniz gerekirhem normal kinit / klist / kdestroy komut satırı araçlarını hem de düzgün bir GUI aracı "MIT Kerberos Ticket Manager" içeren paket. Biletinizi almak için bunları kullanın, ardından PuTTY otomatik olarak Microsoft SSPI yerine MIT GSSAPI kitaplığını kullanacaktır ve her şeyin çalışması gerekir. "MIT Kerberos Ticket Manager" çalışıyorsa, PuTTY'nin bir bilete ihtiyacı olduğunda Kerberos şifrenizi otomatik olarak soracaktır, bu yüzden Başlangıç ​​klasöründen bağlamak iyi bir fikirdir.

İlk olarak PuTTY çalıştıran Windows kutusundaki klist çıktınızın geçerli bir TGT gösterdiğini iki kez kontrol edin. Ardından, PuTTY oturumunuzun yapılandırmasında GSSAPI kimlik doğrulamasını dene seçeneğinin etkinleştirildiğinden emin olun Connection - SSH - Auth - GSSAPI. Son olarak, kullanıcı adınızla otomatik olarak oturum açacak şekilde yapılandırıldığından emin olun Connection - Data. Kullanıcı adını açıkça belirtebilir veya Sistem kullanıcı adını kullan için radyo düğmesini seçebilirsiniz .

Tarihsel olarak, şifresiz SSH girişinin Kerberos üzerinden çalışması için tek yapmam gereken bu.

Sorun Windows Kerberos kurulumundaydı. Active Directory'mizin korkak kurulduğunu düşünüyorum, Windows yöneticisi olmadığımı gerçekten bilmiyorum.

Ancak Windows 7 CLI'de ksetup kullanarak Kerberos'u elle yapılandırarak sorunu çözdüm.

Uzak iş istasyonumu yeniden başlattıktan sonra bilgisayarıma giriş yapamadım. Bunun nedeni, orijinal yapılandırmada bölge alanımın TLD bölümünün her zaman mevcut olmaması (etki alanı \ kullanıcı), ancak el ile yapılandırdıktan sonra, giriş etki alanımı tam bölge etki alanı adını (domain.TLD \ kullanıcı) yansıtacak şekilde değiştirmek zorunda kaldım ve Şimdi kimlik doğrulamam daha uzun sürse de Windows bilgisayarımda oturum açabildim.

Değişikliklerden önce ksetup çıktısı yalnızca varsayılan bölgemi gösterdi ve küçük harfti.

Benim alanım için tüm kdc sunucularını almak için "nslookup -type = SRV _kerberos._tcp.domain.TLD" kullandım.

Hiç bayrak belirlemedim.

"Ksetup / mapuser user@domain.TLD kullanıcısı" kullanıcı adımı eşledim

Kullandığım kaynaklar: https://wiki.ncsa.illinois.edu/display/ITS/Windows+7+Kerberos+Login+using+External+Kerberos+KDC

https://www.cgl.ucsf.edu/Security/CGLAUTH/CGLAUTH.html

Herkes herhangi bir öneri varsa ben bunu nasıl düzeltebilirim (kırık mı?) Windows yönetici millet verebilir.