IT-Säkerhetsguiden

Under förra veckan kom jag i kontakt med ett mystiskt certifikatfel där enbart vissa enheter klagar på gammalt certifikat. Jag uppmärksammade också en intressant sak när jag åtgärdade det här felet, nämligen hur ISA servern hanterar sina SSL sessioner. Det här ledde till ett långt blogg-inlägg som dock kan vara intressant för andra som hamnar i trubbel med Certifikat och ISAns Certifikathantering.

ISA Miljö
En ISA 2006 med alla uppdateringar på Windows 2003 std server (R2, SP2) med ett köpt Verisign Certifikat. Certifikatet är tidigare installerat på en annan 2003 server och sedan exporterat till ISAn. Certifikatet ser helt ok ut både i Certificates MMC och i ISA gränssnittet. Inte heller ISA BPA påvisade något fel.

Symptom
Problem med Exchange publiceringarna OWA och EAS för vissa datorer och telefoner. Datorer som befinner sig i samma domän som ISA servern samt SonyEricsson telefoner larmar om att certifikatet har utgått. Övriga datorer och telefoner fungerar felfritt och Certifikatet ser korrekt ut.
Vid felsökning testades certifikatet med Verisigns testverktyg vilket påvisade att Intermediate Certifikatet gick ut 2004.

Lösning
Som ni kan se i exemplet från en memberdator klagar den på Intermediate certifikatet som ingår i pathen för certifikatet. Intermediate är alltså issuing certifikat, utgivare som måste vara giltigt för att datorerna skall lita på certifikatet.
Enligt Verisign kan detta fel uppstå när man exporterar certifikatet från en server till en annan. Ofta för att man inte får med alla certifikat som skall ingå. Det visade sig dock finnas både ett gammalt och ett nytt Intermediate certifikat på servern men beroende på klient användes olika.

Jag raderade därför det gamla certifikatet och importerade det senaste Intermediate certifikatet på ISA Servern.

SSL hantering
Certifikatåtgärderna gjordes under drift eftersom företaget inte ville ha något avbrott.
Efter dessa åtgärder visade testverktyg exakt samma fel även fast certifikatet inte längre fanns på servern. Jag testade även att skapa en helt ny lyssnare parallellt som jag knöt till certifikatet, samma symptom fortfarande.
Det här var nytt för mig, så länge du har en aktiv SSL förbindelse (alltså en lyssnare med certifikat) är det den sessionen som används när klienten ansluter. ISAn förhandlar alltså inte på nytt med installerat certifikat för varje ny anslutning, därav visades det gamla certifikatet fortfarande.

För att få den att använda det nya certifikatet måste du bryta befintlig tunnel, antingen:
– Genom att starta om servern
– Ta bort lyssnaren (se till att det inte finns någon session med hjälp av netstat) och skapa en ny.

En bra ny artikel om att byta ut certifikat finns här och som sagt, var noga med att inaktivera lyssnaren innan du byter ut certifikatet http://technet.microsoft.com/en-us/library/dd547090.aspx

Ännu ett argument för övertyga att Internet Security & Acceleration (ISA) Server är en enormt säker och kompetent brandvägg.

ISA 2006 har nämligen blivit utnämnd till Common Criteria Evaluation Assurance Level 4+ vilket är den absolut högsta certifiering man kan få inom Common Criteria (CC) framework.
De har alltså under en längre tid testat ISAn på djupet med tuffa säkerhetstester och utvärderingar.

Det är dock inte fel att Microsoft varit tvungna att överbevisa sig gång på gång, det håller bara kvalitén på topp.

Det här kom passande för mig då jag (Logica) i skrivande stund åker runt i Sverige tillsammans med Microsoft med Forefront Roadshow, för att informera om Forefront och kommande Stirling.

Vill ni läsa fullständig dokumentation på den här certifieringen så har ni rapporten här: http://www.bsi.de/zertifiz/zert/reporte/0453a.pdf

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.

I en ny artikel från Microsoft kan vi nu läsa att dom numera supporterar både ISA och TMG i en virtuell miljö. Tidigare har enbart Hyper-V supporterats men nu nämns även 3-part där vi bl.a. finner VM-ware. Det är fortfarande inte rekommenderat att köra ISA/TMG i en virtuell miljö, men det framgår ingen anledning om skälet till detta. Det har pratats om att man inte kan garantera säkerheten för eventuell säkerhetshåll mellan host och virtuell maskin, något sådant har dock inte påträffats oavsett virtualliseringsverktyg.

Det kan snarare vara en fördel att virtualisera en ISA för redundansen skull. Att kunna flytta maskinen mellan flera fysiska hostar, patcha utan avbrott och även kunna återställa en tidigare snapshot.

Observera dock att om fel skulle uppstå i din virtuella miljö och du inte kan återskapa felet i en fysisk miljö så supporteras det inte från Microsoft, istället får man hoppas på att leverantören av den virtuella plattformen tar på sig detta.

Läs mer om detta i artikeln: http://technet.microsoft.com/en-us/library/cc891502.aspx

Jag fick precis ett samtal från portwise. Dom håller nu på att utveckla en plug-in till ISA 2006 för fler autentiseringsmetoder. Portwise har redan idag funktioner för att autentisera; via kod över SMS, Java-applet med slumpade siffror för webbläsare och även för mobiltelefon. Inom kort kommer dessa funktioner integreras med ISAns autentiseringar. Detta innebär flervägsautentiseringar för klient VPN vilket är väldigt efterfrågat.

Till en början är det fokus på ISA 2006 men även TMG finns med på kartan.
Förhoppningsvis kommer jag få en demomiljö att visa upp.