Kerberos authentication és Outlook Anywhere esete

Egy nagyon érdekes problémát sodort elém a sors és az Exchange Product Group tegnap elott. A megoldást is megtaláltam amit most meg is osztok veletek is.

A probléma a következo: több CAS szervert egy UAG segítségével publikálunk. Az UAG és a CAS szerverek között KCD (Kerberos Constrained Delegation) delegációt használunk. A hibajelenség az, hogy a sok CAS közül néhány elutasítja a bejövo Outlook Anywhere kéréseket. Az IIS logban a CAS szerveren HTTP 401.1-es http hibakód látszik. Valamint a 2148074254 –es hiba. Minden más az Outlook Anywhere-n kívül helyesen muködik. A kollegák Redmondban arra is rájöttek, hogyha a látszólag meghibásodott CAS szerveren, az RPC IIS application pool-t átállítják a Default APP Pool-ról mondjuk az OWA App Pool-ra akkor attól megjavul az Outlook Anywhere és muködik tovább. Ez azonban nem túl megnyugtató és a végére kellett annak járni, hogy mi okozza a problémát és azt hogyan lehet megjavítani.

Hosszas hibakeresés után sikerült megtalálnom a probléma okát. A probléma szerencsére nem az Exchange-ben lakik. Jó ha tudjátok, hogy a Windows Server 2008 R2 IIS-en az ApplicationPoolIdentity használhatatlanná válik akkor ha a gép megváltoztatja a tartományban a jelszavát majd ezt követoen újra indítjuk az IIS-t. Hogy kapcsolódik egymáshoz a két eset? Az RPC virtual directory alapértelmezésben a Default APP Pool-t használja, ami pedig az Application Pool Identity-t használja.

Tehát ha az Outlook Anywhere esetében Windows Integrated (Kerberos vagy NTLM) azonosítást használunk és Kerberos azonosítást szeretnénk használni (mint pl. a KCD esetében) akkor az 30 nap után kíméletlen módon megfog állni. Ezek után csak az NTLM azonosítás muködik, a Kerberos sajnos nem.

Napjainkban csak azok az Exchange rendszerek érintettek ahol pre-authentication-t használnak az ügyfelek és a pre-authentication-t végzo eszköz és a CAS szerverek között Kerberos authentication szükséges. Minden más esetben amikor a kliensek közvetlenül a CAS-hoz fordulnak ez nem probléma, mert legfeljebb csak NTLM azonosítást tud az Outlook, Outlook Anywhere esetében. De késobb ez komoly problémákat okozhat majd.

Addig is jó ha tudjátok, hogy a probléma nem az Exchange rendszerben van. Ez egy Windows hiba, amire van javításunk és ami a Windows Server 2008 R2 SP2-ben lesz majd bent eloször. Addig a javítás telepítése szükségszeru. A javítás itt érheto el: Users cannot access an IIS-hosted website after the computer password for the server is changed in Windows 7 or in Windows Server 2008 R2

Comments

• Anonymous
  January 01, 2003
  Nem is gondoltam, hogy ilyen gyorsan hasznát veszi bárki is. :) Ráadásul Te nem is "bárki" vagy. :)AppPoolIdentity használata nem rossz irány. Szóval érdemes a fixet feltenni és visszaállítani az App Poolokat. Persze előtte azért teszteld!Mindenkinek: lehet hogy túlságosan sebbtében készült az írás. Ha nem volna tiszta, akkor ez messze nem csak az Exchange Outlook Anywhere-t érinti. Minden olyan webes alkalmazás érintett ami olyan Application Pool-t használ ami az AppPoolIdentity biztonsági kontextusában működik.
• Anonymous
  January 01, 2003
  Hú, ez nagyon szép fogás. Én eddig átírtam az apppool identity - t (Network Service), jogokat állítottam, SPN - t, és általában megjavult. Csak nem értettem ...