Share via

Authentication pop-up, Outlook-Anywhere, NTLM authentication

  • Article

Rég nem írtam. Ennek több oka is van de talán az egyik legfontosabb az, hogy beszippantott a rengeteg feladatom. Ma hajnalban kicsivel 5 után a forróságban azonban éreztem hogy ez egy olyan történet amit meg kell írni.

A probléma

Képzeletben gondoljunk az Outlook Anywhere szolgáltatásra. Az Outlook Anywhere szolgáltat helyes muködéséhez elengedhetetlenül hozzátartozik az Exchange Server Autodiscover. Valószínu, hogy minden Exchange adminisztrátor számára ismeros a következo profil konfigurációs oldal:

De nézzük csak meg közelebbrol egy kicsit. Az egyes beállításokat hol tudjuk szabályozni az Exchange-ben? Ehhez készítettem egy újabb képet:

A színkódok jelentése:

  • Piros: get-outlookanywhere és a set-outlookanywhere cmdletek segítségével manipulálható a beállítás ami Exchange szerverenként történik.
  • Fekete: get-outlookprovider és a set-outlookprovider cmdletek segítségével manipulálható a beállítás ami Exchange organizáció szintu. Több OutlookProvider létezik az Outlook Anywhere szabályozására az EXPR szolgál.

A fentiekbol a probléma megértéséhez két beállítás részletes ismertetése szükségszeru.

  • "Only connect to proxy servers that have this principal name in the certificate": a név kötelez. A beállítás a mutual-authentication be / kikapcsolására szolgál. Az Outlook akkor és csak akkor kapcsolódik a szerverhez ha a tanúsítványban szerepel a szövegdobozban meghatározott security principal. A tanúsítványban ez szerepelhet a Subject vagy a Suject Alternate Name (SAN) mezoben is, azonban Windows Vista SP1 elotti munkaállomások a SAN mezoben nem keresik ezt az értéket. A security principalnak két formája létezik: msstd és fullsic. Errol bovebben itt olvashattok: https://msdn.microsoft.com/en-us/library/aa374385.aspx. A mutual-authentication kikpacsolását ha szükségszeru akkor a NONE érték megadásával érhetjük el. Erre egy példa:

  • Proxy Authentication Settings: ez a beállítás azt határozza meg, hogy az Outlook kliens az RPC Proxy szerver oldali végpont eléréséhez milyen azonosítást használ. Jelenleg elérheto a Basic, az NTLM és a Negotiate. Az NTLM az elérheto legmagasabb azonosítási szint jelenleg. A Basic gyengébb azonosítási módszer mint az NTLM. A Basic azonosításról mindenki tudja, hogy dialógus ablakban kéri el a felhasználótól a credentialt míg az NTLM azonosítást szokták Windows Integrated azonosításnak hívni. Az NTLM esetében a bejelentkezett felhasználó jelszavából származtatott hash az alapja az azonosításnak ami integrált módon muködik. Az Outlook-t a helyes azonosítási módszer beállítására a CAS szerveren a set-outlookanywhere parancs segítségével konfigurálhatjuk. Két tulajdonság létezik amivel konfigurálhatjuk a klienseket:
    • ClientAuthenticationMethod: az Outlook kliens erre az értékre fogja a profilt beállítani. Ezt látod a profilban. Ez egy single value érték.
    • IISAuthenticationMethod: a CAS szerveren az IIS RPC virtual dir azonosítási beállítását szabályozhatjuk itt. Ez egy multi-value érték.

Miután tisztáztuk a fenti pontokat térjünk rá a tényleges hibára. Az egyik általam tervezett Exchange környezetben egy jelentos változtatást végzünk jelenleg. Elég összetett az is hogy honnan jövünk és az is hogy hova tartunk. Menetközben azonban ki kellett kapcsolni a mutual-authentication funkciót az összes Outlook Anywhere kliensnél. Ennek a hátterében alapvetoen a használt tanúsítványok és a névtér racionalizálása all. Másként nem tudtuk megoldani csak úgy, hogy a mutual-authenication-t letiltjuk. Nem gondoltuk hogy ezzel bármi komoly problémát okozunk. Az összes Outlook kliens frissítette a profilját és beállt erre a konfigurációra:

Ez így rendben is van. Azonban annak ellenére, hogy a profilban NTLM azonosítás szerepel minden Outlook kliens az indításkor jelszót kér:

 

Összegezve: tehát miután kikapcsolt a mutual-authentication funkciót és a kliensek frissítették az Outlook profil beállításukat annak ellenére, hogy NTLM azonosítást szerettünk volna használni az Outlook indításkor jelszót kér. Természetesen a gép és a felhasználó is tartományi tag, a gépre a felhasználó a tartományi felhasználójával jelentkezik be és a tartomány egészséges megfeleloen muködik. Vajon miért történik ez? Több mint 11000 felhasználó esetében ez nem vicces jelenség. Gyakorlatilag napokig égtek a telefonvonalak.

 

A magyarázat

Hiába az NTLM azonosítás engedélyezése a kliensen ha a mutual-authentication kivan kapcsolva akkor elojöhet az azonosítási ablak. Elsosorban Windows XP gépeken, de az újabb operációs rendszerek sincsenek túlságosan kiváltságos helyzetben. De nézzük kicsit korábbról. Az NTLM az egy challange-response authentikációs protokoll. Elodje a LanMan. A challenge response auth protokollok sajátossága, hogy hash-t használ a tényleges jelszó helyett. A Hash-rol azt kell tudni, hogy egyirányú. A nyílt szövegbol egyszeruen eloállíthatunk Hash-t, de a Hash-bol az ígéret szerint nem lehet eloállítani a nyílt szöveget. A LanMan által használt Hash funkció hihetetlen egyszeru és nem biztonságos. Az NTLM második verziójáról is már 10+ éve az akkori TechNet magazin hasábjain írtam és bebizonyítottam, hogy Windows 98-ban az NTLMv2 nem teljesen úgy muködik ahogy azt leírtuk. Rég volt. Sicc. De hogy kapcsolódik ez ide? Nos az említett környezetben minden kliens Windows XP SP3 és bizony a használt challange-response authentikációs protokollok használata nem volt szabályozva. A Windows által használható challange-response auth protokollokat és azok sorrendjét az LMCompatibilityLevel érték módosításával szabályozhatjuk vagy használhatjuk az idevonatkozó Group Policy beállítást (preferált).

Az LMCompatilbityLevel elérheto értékei a következo táblázatban vannak kiválóan összefoglalva (forrás: https://technet.microsoft.com/en-us/library/cc960646.aspx):

 

Value

Meaning

0

Clients use LM and NTLM authentication, but they never use NTLMv2 session security. Domain controllers accept LM, NTLM, and NTLMv2 authentication.

1

Clients use LM and NTLM authentication, and they use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication.

2

Clients use only NTLM authentication, and they use NTLMv2 session security if the server supports it. Domain controller accepts LM, NTLM, and NTLMv2 authentication.

3

Clients use only NTLMv2 authentication, and they use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication.

4

Clients use only NTLMv2 authentication, and they use NTLMv2 session security if the server supports it. Domain controller refuses LM authentication responses, but it accepts NTLM and NTLMv2.

5

Clients use only NTLMv2 authentication, and they use NTLMv2 session security if the server supports it. Domain controller refuses LM and NTLM authentication responses, but it accepts NTLMv2.

 

Minden olyan esetben amikor a kliens LanMan HASH-t is küldene ÉS nincs engedélyezve a mutual-authentication akkor az Outlook hiába van NTLM azonosításra beállítva kérni fogja a jelszót és nem küldi el önjáró módon a távoli szervernek. És ezt nagyon helyesen teszi mivel az LM Hash nagyon sérülékeny. Gyakorlatilag percek alatt köpi vissza a legegyszerubb eszköz is az LM Hash-bol a felhasználó jelszavát. A mutual-authentication pontosan arra szolgál, hogy biztosak legyünk abban, hogy az Outlook ahhoz és csak ahhoz a végponthoz csatlakozik amiben mi megbízunk.

Az érintett környezetben az összes Windows XP gépen az lmcompatibilityLevel értéke 0 vagy 1 volt. A beállítás normalizálásával és az LM Hash küldésének tiltásával a felmerült problémát megnyugtató módon tudtuk kezelni.

Zárszó

Néhány gondola zárszóként:

  • attól hogy NTLM még jöhet jelszókéro ablak
  • lmcompatibilitylevel 0 és 1 esetében és ha nincs mutual-authentication akkor jön a jelszókérés
  • ne kapcsold ki a mutual-authentication beállítást csak akkor ha nagyon jó okod van rá -- az nem jó ok ha nem ismered
  • az alapoktól kell indulni egy hibakeresésnél ezért nem szabad az alapokat elfelejteni
  • az alap infrastruktúrális komponensek legyenek rendben a környezetedben úgy mint azonosítás, névfeloldás, IP routing még mindig a problémák legalább fele ezekbol ered...
  • 2012-ben végre kapcsoljuk ki örökre az LM-t
  • Group Policy beállítás az LmCompatibilityLevel-hez
  •  
  • Egy értheto cikk 2000-bol a TechNet magazin hasábjairól ami témáját tekintve még mindig aktuális: https://www.isaserver.hu/zoltanh/Publications/2000/2000-11-Zoltanh-Auth.pdf
  • Bovebb információ arról, hogy miért gyenge az LM Hash: https://www.isaserver.hu/zoltanh/presentations/2009/Security360-Authentication0.34.xps

Comments

  • Anonymous
    January 01, 2003
    Köszi. :)Nem hittem volna, hogy az lmcompatibilitylevel -ről még tudok bőrt lehúzni. Emlékszem amikor 1997-1998-ban az NTLM-et próbáltam NetMon-al kimérni és megérteni majd felfedeztem a Windows9x DsClient-ben a hibás működést és eszkaláltam Redmondba. :) Ott kezdődött el valami megmagyarázhatatlan szerelem. Szeretem. :)
  • Anonymous
    July 02, 2012
    Ez nagyon fontos cikk, betettem a kedvencek közé.Amúgy nem gondoltam volna, hogy valaha fogok még olvasni az LmCompatibilityLevel-ről! Hihetetlen, hogy ez az alapvetően nem bonyolult téma hány ügyfél problémát okozott az elmúlt 15 évben.Köszi,Z