Postup overenia systému Windows. Stará chyba overovania Windows NTLM vám umožňuje deanonymizovať používateľa Ukladanie hesiel do databázy účtov

2.11.2011 Jean de Klerk

Každý správca systému Windows sa, samozrejme, viackrát musel vysporiadať s dvoma hlavnými overovacími protokolmi v prostredí Windows: Kerberos a NTLM. Tento článok sa zameriava na to, ako sú podporované Kerberos a NTLM v systémoch Windows 7 a Windows Server 2008 R2. Najprv by som však rád zdôraznil kľúčové rozdiely medzi týmito protokolmi.

Vývojári spoločnosti Microsoft prvýkrát implementovali protokol Kerberos vo Windows 2000. Protokol NTLM sa začal používať oveľa skôr, v časoch Windows NT. Kerberos je autentifikačný protokol založený na koncepte dôveryhodnej tretej strany (TTP), zatiaľ čo NTLM je založený na mechanizme výzva/odpoveď. Rozdiely medzi týmito dvoma protokolmi sú podrobnejšie popísané v tabuľke.

Pri komunikácii počas overovania NTLM serverový prostriedok (napríklad súborový server) vygeneruje požiadavku, ktorá sa odošle klientovi. Klient vygeneruje odpoveď NTLM, ktorá obsahuje hash hesla používateľa, a server overí, či je odpoveď správna. Ak klient používa lokálne konto, server overí odpoveď používateľa na základe hash hesla používateľa, ktorý je uložený v lokálnej databáze správcu bezpečnostných účtov (SAM). Ak klient používa konto domény, server odovzdá odpoveď radiču domény na overenie, pretože iba radiče domény ukladajú kópie hash hesiel používateľa vo svojich databázach služby Active Directory (AD).

V systéme Windows Kerberos je dôveryhodnou treťou stranou radič domény Windows 2000 alebo novší, ktorý je hostiteľom služby Kerberos Key Distribution Center (KDC). KDC uľahčuje autentifikáciu medzi klientom a serverom s povoleným Kerberos. Služba KDC sa automaticky inštaluje ako súčasť systému AD a pozostáva z dvoch podsystémov: Autentifikačná služba (AS) a Služba udeľovania lístkov (TGS).

Keď sa používateľ prihlási do domény Windows pomocou protokolu Kerberos, klient Windows najprv overí používateľa v radiči domény pomocou hesla používateľa. Klient zároveň požiada o udelenie lístka (TGT) autentifikačnej službe. TGT si možno predstaviť ako dočasné heslo (v predvolenom nastavení je jeho životnosť 8 hodín), ktoré nahradí heslo používateľa pri následných požiadavkách na overenie. Keď používateľ potrebuje získať prístup k zdroju servera, klient predloží TGT, aby vydal TGT na overenie voči zdroju servera. Uvedomte si, že na rozdiel od NTLM sa protokol Kerberos nepoužíva na lokálnu autentifikáciu pomocou nástroja Windows Security Accounts Manager; jeho rozsah je obmedzený na doménovú autentifikáciu na doménovom radiči.

Kerberos je štandardný overovací protokol v systéme Windows 2000 a novších verziách spoločnosti Microsoft. V týchto operačných systémoch je autentifikačný protokol definovaný pomocou vyjednávacieho mechanizmu. Ak predvolený protokol Kerberos nie je vhodný alebo podporovaný jedným z komponentov klienta alebo servera zapojených do overovania, systém Windows sa vráti k používaniu NTLM.

Prečo práve Kerberos?

Kerberos je efektívnejší ako NTLM z niekoľkých dôvodov. Pri používaní protokolu Kerberos sa hash hesla používateľa odhaľuje oveľa menej často ako pri použití NTLM. Hash hesla sa odhalí iba vtedy, keď používateľ požiada o TGT – v skutočnosti raz za osem hodín. Na druhej strane, pri NTLM sa hash hesla odhalí vždy, keď klient použije NTLM na overenie na serveri. Toto je dôležitá výhoda protokolu Kerberos oproti protokolu NTLM; faktom je, že existujú špeciálne nástroje, ktoré kontrolujú sieťovú prevádzku na prítomnosť hash hesiel. Tieto nástroje zachytávajú objavené hashe a používajú ich na obnovenie používateľských hesiel pomocou metódy hrubej sily.

Ďalšou výhodou Kerberos je, že používa časové pečiatky na ochranu pred opakovanými útokmi. Preto je také dôležité mať službu synchronizácie času, ktorá bezchybne funguje v prostredí Windows orientovanom na Kerberos. Vo Windows 2000 a novších verziách systému fungujú časové služby bez predchádzajúcej konfigurácie. Ak nie sú počítačové hodiny na rôznych počítačoch synchronizované, môže to mať za následok dodatočnú premávku v procese autentifikácie Kerberos alebo v najhoršom prípade môže táto situácia spôsobiť chybu v procese autentifikácie.

Okrem vyššie uvedeného protokol Kerberos implementuje pokročilé funkcie autentifikácie, ako je vzájomná autentifikácia a delegovanie autentifikácie. Vzájomná autentifikácia znamená, že používateľ a služba sa navzájom overujú, zatiaľ čo NTLM je obmedzené na overenie používateľa. Bez tejto funkcie môžu nastať situácie, keď používatelia poskytnú svoje poverenia falošnému serveru.

Služba môže pristupovať k vzdialeným zdrojom v mene používateľa pomocou mechanizmu delegovania autentifikácie. Inými slovami, užívateľ môže udeliť sprostredkovateľskému systému právo autentifikovať sa (používateľa) na aplikačnom serveri vo svojom vlastnom mene. Výsledkom je, že aplikačný server je schopný prijímať rozhodnutia o autorizácii nie na základe identity proxy systému, ale na základe identity užívateľa. Funkcia delegovania autentifikácie je veľmi užitočná vo viacvrstvových aplikáciách, ako je napríklad prístup k databázam pomocou webového rozhrania.

Na záver treba povedať, že hoci spoločnosť Microsoft urobila kus práce na modernizácii protokolu NTLM, a to vytvorením verzie NTLMv2, ktorá je podporovaná v prostredí NT4 SP4 a novších verzií, Microsoft Kerberos implementuje väčšie množstvo moderného šifrovania. algoritmy. Podrobnejšie o tom budem hovoriť v časti o nástrojoch na šifrovanie protokolu Kerberos.

Obmedzenia protokolu NTLM

Výhody autentifikácie pomocou protokolu Kerberos sú nepochybné. Ale aj v prostredí AD Server 2008 Windows často používa NTLM, napríklad keď sa pripájate k systému Windows staršiemu ako Windows 2000 alebo keď sa pripájate k zdieľanému prostriedku pomocou príkazu net use a adresy IP (namiesto názvu NetBIOS ). Okrem toho aplikácie, ktoré nemajú správne nakonfigurované hlavné názvy služieb (SPN), budú stále používať NTLM.

Ak chcete zistiť, ktorý protokol – NTLM alebo Kerberos – práve používate, môžete si vizualizovať prevádzku NTLM pomocou pomôcky netmon alebo iného nástroja na sledovanie siete; Alternatívou je skontrolovať obsah vyrovnávacej pamäte lístkov Kerberos pomocou nástroja klist (ktorý je súčasťou systému Windows 7 a Server 2008). V systémoch Windows 7 a Server 2008 spoločnosť Microsoft implementovala nové skupinové politiky, ktoré možno použiť na monitorovanie a blokovanie používania protokolu NTLM vašimi používateľmi a aplikáciami. Celkovo existujú tri takéto politiky: jedna pre prichádzajúcu návštevnosť NTLM (sledovanie a blokovanie na úrovni servera), druhá pre odchádzajúcu návštevnosť NTLM (sledovanie a blokovanie na úrovni klienta) a tretia pre návštevnosť domény (sledovanie a blokovanie blok na úrovni radiča domény). Sú umiestnené v kontajneri Security Options Group Policy Object (CPO), ku ktorému je možné pristupovať postupným výberom položky Konfigurácia počítača, Nastavenia systému Windows, Nastavenia zabezpečenia, Miestne zásady (pozri obrázok 1). Všetky začínajú Zabezpečením siete: Obmedzte NTLM:.

Každé nastavenie politiky má možnosti auditu a blokovania. Keď povolíte funkciu auditovania NTLM, program vytvorí položky denníka udalostí s pôvodnými údajmi NTLM a číslami 8001, 8002, 8003 a 8004. Položky denníka sú uložené v operačnom kontajneri s prístupovou cestou Event Viewer (lokálne), Aplikácie A protokoly služieb, Microsoft, Windows, NTLM. Odporúčam vám začať auditovaním NTLM v testovacom prostredí a uistiť sa, že všetky vaše aplikácie sú tam správne zastúpené. Ak začnete svojvoľne blokovať používanie protokolu, s najväčšou pravdepodobnosťou niektoré aplikácie nebudú fungovať. Aby ste predišli strate udalostí, mali by ste si pred začatím testovania nástrojov auditovania NTLM nainštalovať riešenie na zhromažďovanie udalostí auditu; Môžete použiť vstavaný Windows Event Collector, Event Subscriptions alebo riešenie tretej strany. Tiež vám odporúčam, aby ste najskôr začali monitorovať NTLM na vašich serveroch. Klientov môžete pripojiť na podrobnú analýzu, keď bude jasné, že server používa protokol NTLM. Keď pochopíte, ktoré aplikácie používajú NTLM, môžete vyvinúť stratégiu blokovania NTLM. Táto stratégia môže zahŕňať politiku vylúčenia pre staršie aplikácie, ktoré sa nedajú prepísať alebo prekonfigurovať a vždy budú vyžadovať použitie NTLM.

Spomínané nastavenia NTLM bohužiaľ nie je možné aplikovať na staršie systémy Windows. Tieto systémy však umožňujú vytváranie verzií protokolu NTLM. Môžete napríklad zakázať útržok LM overovacieho protokolu NTLM (keďže tento útržok je vo svojej podstate slabý) alebo vynútiť NTLMv2. Použite na to nastavenie GPO Zabezpečenie siete: Úroveň overenia LAN Manager, ktoré sa nachádza v kontajneri GPO Konfigurácia počítača\Nastavenia systému Windows\Nastavenia zabezpečenia\Miestne politiky\Možnosti zabezpečenia (pozri obrázok 2).

Šifrovacie nástroje Kerberos

Kryptografické protokoly používané autentifikačnými protokolmi zohrávajú dôležitú úlohu pri ich zabezpečení. Ako som už poznamenal, v tejto oblasti je výkon Kerberos vyšší ako v prípade protokolu NTLM. Šifrovací algoritmus RC4 bol prvýkrát implementovaný v protokole Windows Kerberos v systéme Windows 2000 a je stále podporovaný na systémoch Server 2008, ako aj Windows 7 (presnejšie je podporovaná jeho verzia RC4_HMAC_MD5). V Server 2008, Windows Vista a novších Microsoft pridal podporu pre Advanced Encryption Standard, šifrovanie AES, zatiaľ čo Windows 7 a Server 2008 R2 podporujú typy šifrovania Kerberos AES (AES128_HMAC_SHA1 a AES256_HMAC_SHA1). AES je novší a výkonnejší šifrovací algoritmus ako DES. Logika Kerberos na radičoch domény migruje na štandard šifrovania AES, keď inovujete doménu AD na funkčnú úroveň domény systému Windows 2008 (DFL).

V systémoch Windows 7 a Server 2008 R2 sú typy šifrovania DES pre overovací protokol Kerberos predvolene zakázané. To môže spôsobiť problémy s kompatibilitou, ak je jedna zo starších aplikácií napevno zakódovaná na šifrovanie iba DES alebo ak je konto systému Windows, na ktorom je spustená konkrétna služba (konto služby), nakonfigurované na používanie iba šifrovania DES. Tieto služby alebo aplikácie zlyhajú, ak nemôžete prekonfigurovať zodpovedajúcu službu alebo aplikáciu na podporu iného typu šifrovania (RC4 alebo AES) alebo obnoviť podporu pre štandard DES.

Ak chcete zistiť, či máte aplikácie alebo služby kódované iba na šifrovanie DES, môžete spustiť sledovač siete na začiatku príslušnej aplikácie alebo služby a skontrolovať obsah polí Etype v hlavičkách autentifikácie Kerberos. Ak chcete zistiť, či je používateľ alebo počítačový účet AD alebo počítačový účet nakonfigurovaný na používanie iba typov šifrovania DES, skontrolujte, či je na karte Účet vo vlastnostiach objektu vybratá možnosť Použiť typy šifrovania Kerberos DES pre toto konto. Tieto vlastnosti sú dostupné z modulu MMC Používatelia a počítače služby AD.

Ak dokončíte kontroly uvedené vyššie a zistíte, že máte tento problém, môžete povoliť šifrovanie DES pre overenie Kerberos na počítačoch so systémom Windows 7 alebo Server 2008 R2 pomocou objektu GPO konfigurácie zabezpečenia siete: nakonfigurujte typy šifrovania, ktoré sú kompatibilné s protokolom Kerberos. štandardné; tieto nastavenia sa nachádzajú v kontajneri GPO Konfigurácia počítača, Nastavenia systému Windows, Nastavenia zabezpečenia, Miestne zásady, Možnosti zabezpečenia.

Takže z dvoch overovacích protokolov Windows je preferovaný Kerberos. Správcovia by mali vždy trvať na tom, aby používatelia a aplikácie používali Kerberos a nie NTLM. Nové obmedzenia používania NTLM zavedené vo Windows 7 a Server 2008 R2 nám poskytujú skvelú príležitosť na dosiahnutie tohto cieľa.

Jean de Klerk [e-mail chránený]) je zamestnancom bezpečnostnej kancelárie HP. Špecializuje sa na správu identity a bezpečnosti v produktoch spoločnosti Microsoft

Overenie v systémoch Windows Server 2008 R2 a Windows 7

Nedávno som narazil na tento problém: Firefox, Chrome, Opera nechcem prejsť NTLM autorizácia. Jediný, kto prešiel, bol IE. Zabudol som povedať, že tento problém je pozorovaný na Windows 7. Spôsoby riešenia týchto problémov budú popísané nižšie.

opera: nie je oficiálne podporovaná NTLM-autorizácia, aj keď v nastaveniach môžete nájsť položku, ktorá umožňuje túto možnosť povoliť alebo zakázať. Preto v nastaveniach proxy servera musíte pridať základné oprávnenie. Zakázať NTLM autorizácia(a skutočne zabezpečiť, aby tento prehliadač fungoval prostredníctvom servera proxy) vykonajte nasledovné:

1) do prehliadača zadajte about:config
2) prejdite do časti Sieť a zrušte začiarknutie možnosti Povoliť NTLM
3) reštartujte prehliadač.

Je pravda, že existuje jedna nuansa (takpovediac nepríjemnosť): pri prvom spustení budete musieť zadať prihlasovacie heslo (úplné, to znamená s doménou) a začiarknuť políčko "uložiť". Teraz sa pri každom ďalšom otvorení prehliadača objaví autorizačný štítok a stačí stlačiť "OK". Je to nepohodlné, ale čo sa dá robiť.

Poznámka: niekedy na niektorých operačných systémoch bolo naopak potrebné zapnúť NTLM autorizácia. Možno to záviselo aj od verzií prehliadača a OS.

Firefox, Chrome: podporujú, hoci potrebujete trochu šamanizmu. Popíšem niekoľko možností, ktoré som získal na internete, možno budete musieť vyskúšať všetko, kým nenájdete tú, ktorá vám vyhovuje.

1) budete musieť pridať do registra HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa parameter s názvom LmCompatibilityLevel typu DWORD a dať tomu hodnotu 1 . Potom bude potrebné reštartovať počítač (táto možnosť mi vyhovovala)

2) Komu Firefox mohol prejsť ntlm autorizácie, zdá sa, že stačí otvoriť about: config v paneli s adresou a zmeniť parametre na nasledovné:

network.negotiate-auth.delegation-uris = http://,https://
network.negotiate-auth.trusted-uris = http://,https://

Potom reštartujte prehliadač.

3) Otvorte editor zásad ( gpedit.msc) Konfigurácia počítača -> Konfigurácia systému Windows -> Nastavenia zabezpečenia -> Miestne zásady -> Nastavenia zabezpečenia -> Zabezpečenie siete: Úroveň overenia LAN Manager a nastavte parameter Odoslať LM a NTLM – pri vyjednávaní použite zabezpečenie relácie NTLMv2.

Potom politiku zatvoríme a reštartujeme.

Ak máte anglickú verziu, potom takto: politika počítača-> konfigurácia počítača-> nastavenie systému Windows-> miestne zásady-> možnosť zabezpečenia-> Zabezpečenie siete: Úroveň overenia LAN Manager a vyberte LM a NTLM – v prípade dohody použite reláciu NTLMv2.

4) Ďalšou možnosťou je nastavenie squid_ldap:

auth_param základný program /usr/lib/squid3/squid_ldap_auth -b "cn=users,dc=office,dc=ru" -f "sAMAccountName=%s" -h 192.168.0.74 -D "cn=administrator,cn=users, dc=office,dc=sk" -w "secpass"
auth_param základné deti 5
auth_param basic realm Môj inet Proxy
auth_param základné povereniasttl 60 minút

external_acl_type nt_groups %LOGIN /usr/lib/squid3/squid_ldap_group -R -b "cn=users,dc=office,dc=ru" -f "(&(cn=%v)(memberOf=cn=%a,cn= users,dc=office,dc=ru))" -D "cn=administrator,cn=users,dc=office,dc=ru" -w "secpass" -h 192.168.0.74

acl all src 0.0.0.0/0.0.0.0
acl group_inet externé nt_groups inet

http_access povoliť group_inet
http_reply_access povoliť všetko
icp_access povoliť všetko
http_access zamietnuť všetko

Skúste to aj tak 🙂

Vedci už roky na konferenciách hovoria o tom, aké sú technológie jednotného prihlásenia neisté. Microsoft používa tento systém jednotnej autentifikácie pre všetko naraz a už v roku 1997 sa špecialisti na informačnú bezpečnosť vyjadrili, že to nie je dobrý nápad. Zraniteľnosť jednotného prihlásenia vo všeobecnosti a najmä v prípade práce so zdrojmi SMB opäť demonštroval ruský výskumník ValdikSS. Opísal metódu, ktorá umožňuje kompromitovať Microsoft Account obete, deanonymizovať používateľov Microsoftu a zistiť dáta VPN.

V skutočnosti na úspešnú realizáciu útoku stačí, aby útočník zamaskoval odkaz na vlastný SMB zdroj (sieťové zdroje: súbory a priečinky, tlačiarne atď.), napríklad pod obrázok a prinútil obeť, aby otvorila to. Útok funguje na všetkých moderných operačných systémoch vrátane Windowsu 10 s najnovšími aktualizáciami. Navyše o týchto problémoch s NTLM autentifikáciou sa diskutovalo nielen v roku 1997, ale pravidelne sa spomínajú. Takže tento problém bol nastolený (PDF) minulý rok na konferencii BlackHat. Žiaľ, na častých referenciách sa nič nemení.

Používateľ ValdikSS na Habrahabr hovoril o tom, ako sa dnes dá zneužiť táto „chyba z 90. rokov“. Výskumník píše:

"Akonáhle sa pokúsite otvoriť odkaz na zdroj SMB v štandardnom prehliadači (Internet Explorer, Edge) alebo akejkoľvek aplikácii, ktorá funguje prostredníctvom štandardných volaní rozhrania Windows API alebo používa Internet Explorer ako nástroj na zobrazenie HTML (Outlook, Windows Explorer) , zdroj SMB okamžite dostane informácie o vašom účte ešte predtým, ako uvidíte dialógové okno s prihlasovacím menom a heslom. Útočníkovi stačí napríklad pridať odkaz na obrázok zo servera SMB na webovú stránku alebo vám poslať e-mail, ktorý bude stačiť na otvorenie a - bum! - Informácie o vašom účte sú v rukách útočníka.

Zatiaľ čo únik hash názvu účtu a hesla domáceho počítača sa nepovažuje za katastrofu, pokiaľ ide o firemnú doménu, začína sa úplne iná konverzácia.

„Z názvu domény je zvyčajne ľahké pochopiť, ktorej organizácii účet patrí, a ak sa heslo podarí uhádnuť, môžete sa pokúsiť overiť na podnikových zdrojoch prístupných z internetu (pošta, VPN).

Heslo však nie je vždy potrebné uhádnuť. Ak vopred poznáte nejaký zdroj, kam sa môžete prihlásiť pomocou overenia NTLM, môžete v reálnom čase, hneď ako sa klient pripojí k vášmu serveru SMB, odosielať požiadavky proxy z klienta na vzdialený server a zo servera na klienta, a úspešne sa na ňom overte!“ vysvetľuje ValdikSS.

Situáciu sťažuje aj fakt, že v moderných operačných systémoch Microsoft aktívne propagujú používanie jedného účtu Microsoft, čím používateľa doslova nútia vytvoriť si ho. Pre používateľov Microsoft Account môžu byť takéto útoky dvojnásobne nebezpečné, a to nielen pre organizácie, ale aj pre jednotlivcov. Faktom je, že v prípade útoku na útočníkov server SMB sa prenesú údaje, ktoré v skutočnosti ohrozia účet Microsoft obete, a je k nemu pripojených mnoho služieb (Skype, Xbox, OneDrive, Office 360, MSN , Bing, Azure atď. Ďalej).

Výskumník tiež píše, že v niektorých prípadoch môže byť útok použitý na extrakciu údajov o prihlasovacom a heslovom hasho VPN pripojenia obete.

ValdikSS zároveň opísal množstvo spôsobov, ako využiť problémy s NTLM autentifikáciou. Okrem veľmi zrejmých vecí výskumník navrhol použiť medzeru na deanonymizáciu používateľov:

„Zaujímavejšie je využívanie na účely deanonymizácie. Účet bude odoslaný zo stránok lokality, ak obeť používa Internet Explorer, alebo kliknutím do písmena v prípade Outlooku. Takmer všetky webové rozhrania poštových služieb filtrujú obrázky pomocou schémy file:// pri výstupe správ (schéma file:// je analogická schéme \\), ale nie Yandex, ktorý to nepovažuje za zraniteľnosť (ktorú v všeobecné, je správne). Deanonymizácia pomocou pošty je nebezpečnejšia, pretože poskytuje prepojenie nielen na IP adresy s účtom Windows, ale aj s poštou.

Funguje aj schéma Chrome file://, ale iba z panela s adresou. Sťahovanie čohokoľvek s obrázkom SMB alebo kliknutie na odkaz nebude fungovať. Keďže Chrome je oveľa populárnejší ako Internet Explorer, bude potrebné použiť sociálne inžinierstvo.

Môžete kradnúť účty pre svoje dobro. Niektorí poskytovatelia VPN používajú rovnaké používateľské mená a heslá na prihlásenie do účtu aj na overenie VPN. Účet patriaci konkrétnej službe môže byť určený podľa IP adresy prichádzajúceho pripojenia používateľa. A ak máte účet Microsoft a našli ste heslo z hashu, potom vám blahoželám – máte prístup k súborom v cloude OneDrive, k pošte Outlook, účtu Skype, ak je prepojený s účtom Microsoft, a k mnohým ďalším.

Na záver ValdikSS píše, že pred takýmito útokmi sa môžete chrániť napríklad obmedzením prístupu k portu TCP 445 pre všetky rozsahy adries okrem:

• 192.168.0.0/16
• 169.254.0.0/16
• 172.16.0.0/12
• 10.0.0.0/8
• fd00::/8
• fe80::/10

Používatelia tiež v komentároch k článku navrhli nasledujúcu metódu:

Editor databázy Registry systému Windows, verzia 5.00

"RestrictReceivingNTLMTraffic"=dword:00000002
"RestrictSendingNTLMTraffic"=dword:00000002

Okrem toho výskumník vytvoril špeciálnu stránku, ktorá vám umožní skontrolovať zraniteľnosť vášho systému voči tomuto typu útoku.

Úspešne som nakonfiguroval autentifikáciu ntlm. Bohužiaľ, konfigurácia vám umožňuje získať semiprimárnu autorizáciu. Napríklad, keď používam webové prehliadače korytnačka svn1.8.4 (privilegovaná knižnica), chrome alebo IE, úspešne ukončia NTLM bez toho, aby sa o niečo pýtali. V súbore denníka vidím overených používateľov. Bohužiaľ, keď používam napríklad nenakonfigurovaný FireFox alebo Maxthon, tento prehliadač odo mňa žiada prihlasovacie údaje. Nepotrebujem to, pretože rovnaká situácia nastáva, keď sa pokúšam o prístup z počítača bez počítača.

Používam Windows server ako doménový radič, windows7/8 ako systémového klienta, linux/debian ako webový server. Nakonfiguroval som kerberos z linuxu do windows AD, winbind pre lokálnu NTLM autentifikáciu a apache 2.2 sériu. Na autentifikáciu apache lepidlom používam modul mod_auth_ntlm_winbind.so apache2 a v kontexte config/ntlm na podporu komunikácie s winbind. Toto funguje správne, napríklad pre Apache:

#defaults pre hlavný www adresár Možnosti Indexy FollowSymLinks MultiViews AllowOverride None #upravené, zabrániť akémukoľvek prístupu ip, pre budúce pridanie authless access od špecifikovaných hostiteľov Zamietnutie objednávky,povoliť odmietnutie všetkým #povoliť z IP/masky #nastavenia pre overenie NTLM pomocou pomocníka winbind AuthName "NTLM Authentication" NTLMAuth on NTLMAuthHelper "/usr/bin/ntlm_auth --domain=MY.WINDOWS.DOMAIN --helper-protocol=squid-2.5-ntlmssp" NTLMBasicAuthoritative on Authentic NT is required- default- uspokojiť akékoľvek

Dúfal som, že možno môžem urobiť nejaké presmerovanie pomocou premennej apache authtype a potom pridať do vyššie uvedenej konfigurácie prepisu:

RewriteEngine na RewriteRule ^ /cgi-bin/TestAuth.pl?DollarOne=1&AUTH_TYPE=%(AUTH_TYPE)&REMOTE_USER=%(REMOTE_USER)

A príklad skriptu TestAuth.pl ako obsah cgi:

#!/usr/bin/perl použite prísne; používať varovania; použite Dáta::Dumper; #jednoduchý spôsob tlače systémových premenných print "Typ obsahu:text/obyčajný\r\n"; #respectint tlač protokolu HTML "\r\n"; print "Prostredie obsahuje:\r\n"; vytlačiť "x\r\n"; print Data::Dumper->Dump([\@ARGV,\%ENV],); #vytlačí všetky argumenty skriptu a procesné premenné

Žiaľ, vo všetkých prípadoch pri použití overenia ntlm založeného na systéme Windows a výzvy na zadanie poverení vždy vidím, že AUTH_TYPE je vždy NTLM. Potom neexistuje spôsob, ako zistiť, čo prehliadač robí. V tejto situácii môžem pristupovať od klientov z domény.

Skúsil som zabaliť ntlm hepler strace. Nanešťastie nevidím nič dôležité v mojom štvorstrannom výpise úspechu/neúspechu a prístupu IE vyvolanom požiadavkou FF ant. Myslím, že rovnaká situácia nastane, keď sa pomocník ntlm overí na lokálnom serveri samba, ale nikdy som to netestoval.

Teraz sa pokúšam urobiť nejakú konfiguráciu s viacerými typmi auth, Basic a NTLM. Najprv sa pokúsim urobiť Basic a filtrovať to, keď vždy zlyhá, a presmerovať ho na informačnú stránku. Bohužiaľ momentálne bez úspechu s mixom NTLM:(NTLM sa vždy robí ako prvý.

Potom má niekto nápad, ako zabrániť povereniam? Ako zruším prístup pozvaným zákazníkom? Ako rozpoznať poverenia z výzvy alebo z okna klienta api?

0

2 odpovede

Momentálne som tento problém vyriešil prepnutím NTLM na overenie Kerberos. Všetky pripravené na winbind bežia priamo pod kerberos, pretože som predtým nakonfiguroval kerberos pre winbind s komunikáciou so serverom AD. Keďže kerberos je otvorený, vývojári predpovedali rôzne sub-autentikátory na koncovom bode používateľa. Veľmi užitočný príznak je v module kerberos apache2.2:

KrbMethodNegotiate on KrbMethodK5Passwd off

Toto chcem. Prehliadač dostane rámec krb s atribútom „Nevyskakovať používateľské poverenia“, potom to klient jednoducho neurobí. Ale ak áno (nejaký druh nekompatibility?), modul servera Apache by to mal zistiť a mal by zrušiť autentifikáciu.

Pri použití NTLM od spoločnosti Microsoft to nie je možné, pretože protokol je poškodený. Prvý rámec NTLM po vrátení kódu webovej lokality 201 nemá možnosť pridať atribút „nevyzvať používateľa na prihlasovacie údaje“. Potom môžem filtrovať tento rámec po vyskakovacom okne alebo podpísaní kľúča relácie operačného systému. Tento prehliadač vždy zobrazuje kontextové okno, keď kľúč relácie OS nie je k dispozícii.

Koniec koncov, toto je ďalšia šanca. Používateľovi chvíľu trvá, kým zadá poverenia alebo akceptuje, keď sú poverenia uložené v prehliadači. Dokážem spočítať čas medzi odoslaním autorizačného rámca do prehliadača a zostavením rámca z klienta. Keď je čas príliš dlhý, môžem ho zrušiť. Bohužiaľ to môže spôsobiť falošnú autorizáciu na vyťažených počítačoch alebo sieťach.

V budúcnosti použijem oba spôsoby :) Bolo by zábavné, keby sa všetko dalo urobiť s modulom apach winbind auth. Celá konfigurácia môže byť potom zapuzdrená pod apache, rovnako ako pre kerberos auth.

Ďakujem všetkým za zaujímavosti, výskum a pomoc :)

Použitie autentifikácie NTLM nezaručuje autorizáciu bez poverenia. Ak máte platné poverenia systému Windows, ktoré server dokáže rozpoznať, výzva na zadanie hesla sa nezobrazí.

Ak používateľ nemá platné vynechané poverenia NTLM, bude vyzvaný, aby ich poskytol. Toto nie je spôsob, ako sa vrátiť k „základnej“ autentifikácii.

Žiaľ, neexistuje spôsob, ako zistiť, či používateľ poskytol poverenia alebo prešli systémom.

Možno položte novú otázku o tom, čo chcete, aby vaši používatelia zažili (t. j. rôzne stránky pre interných a externých používateľov) a niekto iný vám môže pomôcť.