Zpět na seznam článků     Číst komentáře (5)     Verze pro tisk

Problemy s kerberos autentizaci pri pouziti NAC.

Autor: Gav   
10.8.2007

Clanek neni technickym popisem samotne kerberos autentizace, ale jde o 'nakopnuti', kde hledat problem v pripade, ze by jste nekdy resili problemy s autentizaci klienta pres nejake NAC zarizeni.


Jemny uvod do problematiky.

NAC - Network Access Control

Jedna se o zarizeni, ktere se nejcasteji pripojuje do site mezi core a edge switche. Tyto zarizeni maji za ukol predevsim toto

* Overeni klienta
* Aplikovani politik
* Zjisteni stavu clienta

Dalo by se rici, ze toto umoznuje i klasicky firewall. Neumoznuje. NAC zarizeni funguje totiz tak, ze do te doby, nez se overite, nemate naprosto zadny pristup do site jako takove (dost casto funguje ve spolupraci se switchem - presmerovava vas mezi VLANy podle ruznych pravidel atp.)

Politiky jsou jasne. Tady mate ale moznost nastavit politiky napr podle typu auth (krb5 / ntlm / ...), muzete rict, ze soubor, v jehoz jmenu je napsano 'confident' bude moci ze site stahnout pouze osoba xyz atp.

Zjisteni stavu je funkce, ktera vam umoznuje zaradit uzivatele do 'role' na zakalde toho, zda mu bezi FW, ma nainstalovanou aplikacy xyz, atd.

A ted onen problem :

V prubehu autentizace se tyto zarizeni divaji na AS-REP packet, ktery obsahuje KRB ticket (v pripade, ze je autentizace uspesna). Pokud uvidi tento ticket (ve kterem je v nesifrovane forme snad jen jmeno uzivatele a DC) zahaji autorizaci a zarazovani do skupin podle pravidel.

Dlouhou dobu jsem mel problem s nekolika uzivatelskymi ucty, ktere se korektne prihlasily do domeny, nicmene zarizeni je naprosto ignorovala a automaticky hazela do 'unauth' roli. Docela velky problem.

Co to zpusobovalo? Default chovani pozadavku na KRB autentizaci a skutecnost, ze ZADNY z testovanych zarizeni si neporadilo s fragmentovanymi UDP pakety. TCP je v pohode.

Jak to tedy je? Standartni situace je totiz takova, ze klient zada NEJDRIVE pomoci UDP az v pripade, ze neprojde UDP zada pres TCP.

Zde jsou limitni velikosti.

K fragmentaci dochazi pri velikosti paketu >1480b.

Windows 2000 server se chova tak, za DO velikosti 2000b pouzije UDP => v pripade ze KRB ticket je vetsi nez 1480b, dojde k fragmentaci a NAC zarizeni ho 'neuvidi'

9 - 172.20.130.11- 172.20.130.50 - KRB5 - AS-REQ
10 - 172.20.130.50 - 172.20.130.11 - IP - [UDP segment of a reassembled PDU]
11 - 172.20.130.50 - 172.20.130.11 - KRB5 - AS-REP

Windows 2003 server se polepsil. do velikosti 1465b pouzije UDP, jinak TCP. Pokud mame tedy velky KRB ticket, automaticky ho posle pres TCP a problem nenastane.

68 - 172.20.130.11- 172.20.130.50 - KRB5 - AS-REQ
69 - 172.20.130.50 - 172.20.130.11 - TCP - [TCP segment of a reassembled PDU]
70 - 172.20.130.50 - 172.20.130.11 - KRB5 - AS-REP

Nastesti se oboje da zmenit upravou registru (resp. aplikaci GPO na domenove klienty) viz. KB http://support.microsoft.com/kb/244474

Treba to nekomu pomuze. Me to trvalo vcelku dlouho, nez jsem na to prisel ;)

Líbil se Vám článek?
Budeme potěšeni, pokud vás zaujme také reklamní nabídka

Social Bookmarking

     





Hodnocení/Hlasovalo: 0/0

1  2  3  4  5    
(známkování jako ve škole)