Kerberos Constrained Delegation

När det handlar om web publicering och ISA Server kan man läsa i bland annat MS dokumentet "Publising Exchange with ISA 2006" att konfigurera Authentication Delegation till Exchange Servern med Basic Authentication. Kan nog mycket väl handla om att den här typen av konfigurering är den som standard fungerar utan problem.
Tar vi diskussion med en säkerhetsmedveten tekniker lär det rynkas på näsan över den autentiseringen. Även web-utvecklarna har nog ett och annat att säga till om det här när det kommer till att skicka vidare autentiseringen mellan olika system.

Både av säkerhetsaspekter och möjligheten att låta applikationspooler utnyttja singel sign on lösningar är Kerberos den bästa autentiseringsmetoden.

Det är dock ingen dans på roser att få det här att lira men jag skall försöka gå igenom ett scenario som publicerar en singel MOSS portal och en clustrad Exchange Client Access Server lösning. Dock kommer ni märka att detta inte konfigureras helt utan problem 😉

ISA Konfiguration

Jag kommer inte gå in på hur man skapar lyssnare och själva publiceringen utan vi går direkt till autentiserings-hardcore.
På Sharepoint publiceringsregeln går vi in på "Authentication Delegation" och väljer "Kerberos constrained delegation". För att det här skall fungera gäller det att vi har ett Service Principal Name (SPN) för den här tjänsten. i de allra flesta fall så är detta FQDN till vår Server och skrivs ut enligt detta sätt: http/<fqdn>

När vi kommer till en klustrad lösning som i mitt fall är klustrade CASar så blir det lite knepigare eftersom det får inte finnas mer än ett SPN och i det här fallet har vi ju fler CAS Servrar. Kruxet här är att använda ett användarkonto med definierat SPN.
På Exchange publiceringsregeln för OWAn anger vi nedanstående inställningar där alltså SPNet inte är ett servernamn utan ett unikt namn enbart för kerberos autentiseringen.

Active Directory

Efter våra regelförrändringar är det dags att gå in i Active Directory för att ställa in så våra ISA objekt har rätt delegera authentiseringen. På datorkonto objekten i ADt går du in under fliken Delegation och här anger du de SPN som du tidigare angett i dina publiceringsregler. Vad det gäller Sharepoint portalen är detta alltså FQDN till Servern och publicerad portal, medan mail.ad.company.com är SPNet till det userkonto som kommer använda. Sista raden är från tidigare konfiguration, ursäkta min opedagogik 😉

Jag skapar sedan ett användarkonto vilket iofs snarare är ett servicekonto med allt vad det innebär. Lättaste sättet att sätta SPN är med kommando SET SPN men i mitt fall använder jag ADSI Edit där jag letar upp kontot och på dess egenskaper finner "Attribute Editor" och "ServicePrincipalName". Här anger jag det SPN som jag angett i min publiceringsregel samt på ISA Serverobjekten.

Exchange

Nu är det dags att tala om för IIS på CASarna vilken autentisering dom skall acceptera. För Kerveros (oavsett om det är NTLM eller Constrained delegation) är det Integrated Windows authentication som gäller.

Applikationspolen i IIS på CAS servrarna skall nu även acceptera detta konto. Därför letar vi upp rätt applikationspool, som för OWAns del heter MSExchangeOWAAppPool och under egenskaper hittar vi fliken Identity där vi konfigurerar poolen att köra på detta användarkonto.

Sharepoint

När det gäller inställningar för Sharepoint behöver vi in i Sharepoint Central Administration gränssnittet. Gå in under Application Management, Authentication Providers och välj Edit Authentication. Notera att du även gör det här för rätt sajt. Se även till att din sajt har rätt namn som matchar det certifikat som du använder (som även är samma som ditt SPN).  Under IIS Authentication Settings anger du även här "Integrated Windows authentication" och "Negotiate (Kerberos)"

Vi behöver egentligen inte ändra så mycket i applikationspoolen för sharepoint men för säkerhetsskull går vi in och ser till att det ser korrekt ut.
För att se vilken applikationspool som används går vi in under den Web Site som din sharepointportal använder och under "Home Directory" fliken finner du rätt pool.

Under applikationspoolen ser vi att den har Identity som kör med kontot. "Network Service" vilket är korrekt när vi enbart har en Server.

Aha funkar det nu då?

Nja, Sharepoint portalen fungerar klockrent och nu kan de säkerhetsmedvetna och programmerarna slappna av. Där emot har vi problem med Outlook Web Access som nu kommer generera väldigt konstiga felmeddelanden. Det här har att göra med att kontot som applikationspoolen körs med inte har tillräckliga rättigheter. Det jag vet är att den skall vara med i den lokala gruppen IIS_WPG på CASarna. Det kommer dock inte fungera nu heller. Jag testar och lägger med användaren i lokala administratorgruppen på CASarne dock med samma resultat.

Då jag råkade ha en aning bråttom under den här labben och ville bara se om kerberos bitarna mellan ISA och Exchange fungerade tog jag inga risker utan gjorde kontot till Enterprise Admins och admin för alla Exchange funktioner.

Nej jag vet, total idioti men det här är ju Exchange-freakarnas ansvar att styra upp 😉
Kommentarer från er Exchange folk är mer än välkommet!

Faktum är att det lirade utan problem efter denna något radikala grupptilldelning.

En brasklapp bara, när det kommer till Service Pack 1 funktionaliteten "Test Rule" för dessa regler kommer ni se något mystiskt. Det kommer nämligen att fungera klockrent från den nod du sitter på medan den andre noden kommer faila och sitter du på CSS servern eller annan management server kommer det se ut som det inte fungerar alls. Vilket då är galet eftersom det fungerar klockrent.