Mitt nyårsfirande fick ett gott avslut då jag fick reda på att jag är tilldelad MVP (Most Valuable Professional) inom Microsoft Forefront ännu ett år!
Önskar alla läsare ett riktigt gott nytt 2012 där vi garanterat kommer få se många nya produkter och snygga säkerhetslösningar!
Jag har tidigare skrivit om hur vi kan nyttja Microsoft Forefront för att supportera olika typer av mobila enheter så som smartphones och plattor. (Video och Artikel) En del av detta handlar om hur vi skall kunna synkronisera information så som e-post, kalender med mera till dessa enheter men samtidigt vidhålla en hög säkerhetsnivå i vår infrastruktur.
Det finns alltid risker med att ha för mycket information i dessa mobila enheter och det bästa är att kunna kontrollera exakt vilken information som skall få finnas på vilken enhet och för vilken användare.
Det finns flera bra plugins till både Forefront TMG och UAG. Vi har bland annat ett svenskt företag vid namn PointSharp vars plugin ger funktioner som flerfaktorautentisering och utökad säkerhet för Micrsosoft Exchange ActiveSync.
Till skillnad från flera andra tredjepartsprodukter så kräver inte den här någon som helst installation eller handpåläggning på själva klienten utan alla enheter som kan kommunicera med Exchange ActiveSync kommer fungera precis som vanligt, med undantag av några säkerhetsmässiga fördelar.
Med hjälp av PointSharp kan vi skapa ett separat lösenord som enbart används för ActiveSync, det här lösenordet kan vi spara i befintligt Active Directory så vi behöver ingen separat databas för detta ändamål.
En stor fördel är också att vi kan automatisera mycket av det här flödet och även ge användaren möjlighet att hantera sitt ActiveSynclösenord och sina mobila enheter på egen hand genom en självbetjäningsportal. Alternativet är också att en servicedeskorganisation behöver involveras för att godkänna nya enheter för att på så sätt få kontroll över vilka enheter som får synkronisera företagets information.
När användaren loggar in på självbetjäningsportal med sitt vanliga AD konto första gången autoskapas ett PointSharpkonto med motsvarande namn som användarkontot i ADt, användaren kan sedan själva autogenerera ett lösenord.
Med hjälp av PointSharps TMG Filter och en produkt som heter PointSharp Secure ActiveSync kan vi även sätta upp ett regelverk över vilka Exchange-funktioner som får synkroniseras ut till vilken typ av enhet. På det sättet kan vi säkerhetsklassa de enheter som finns i miljön och därefter sätta upp regler för att exempelvis en viss telefonmodell enbart får synkronisera mail och kalender men inga bifogade filer medans en viss typ av platta kan ta emot alla bifogade filer så länge det inte är ett säkerhetsklassat dokument.
Rent tekniskt bygger autentiseringstekniken på Kerberos Constrained Delegation (KCD) där TMG servern har rätt att delegera autentisering bak mot Exchange och då istället autentisera användaren med sitt PointSharpkonto.
Det här höjer säkerheten på flera plan. Dels så finns inte något AD-lösenord lagrat på telefonen och sedan finns det heller inte risk att felaktiga påloggningsförsök låser det riktiga AD-kontot. En snygg funktion för att inte själva PointSharpkontot skall bli utlåst av en felaktigt konfigurerad telefon är att den registrerar flera påloggningsförsök med samma lösenord som ett enda försök.
En annan säkerhetsaspekt på det hela är att all kontroll av vilka funktioner och vilken information som får synkroniseras ut till telefonerna baserat på telefonmodell och användare och kontrolleras redan på edge-nivå, innan någon som helst information når fram till Exchange.
Genom att integrera PointSharps lösning kan du även nyttja funktioner för att få flerfaktorautentisering mot både webbpubliceringar och VPN lösningar. Ett tänkbart scenario är att även autentisera Outlook Web App (OWA) med PointSharpkontot för att på så sätt undvika att ange ett AD-lösenord från ett Internetcafe.
Det här var bara exempel på några scenarier över hur man kan kombinera dessa produkter för att få en säkrare ActiveSynclösning. Det första man bör göra är att se till vilka verksamhetsbehov man har och vilken information man vill skydda och sedan anpassa den tekniska lösningen utefter de behov som finns.
Under veckan påträffades ett ganska ovanligt problem där man avinstallerat Service Pack 1 på en Forefront Threat Management Gateway Enterprise-lösning baserat på en EMS server och två TMG Servrar.
Miljön körde för närvarande Service Pack 1 och av någon anledning så avinstallerades Service Pack 1 på samtliga servrar. TMG lösningen fungerade funktionellt efter detta men när man startade TMG Management Consol så var arrayen helt tom och det visades ingen konfiguration.
Nu finns det egentligen ingen anledning att avinstallera Service Pack till TMG, men i det här fallet gjordes det i en felsökning. Frågan är snarare, vad är det egentligen som hade hänt här när vi inte såg någon konfiguration?
Avinstallationen gjordes via Program and Features (snabbkommando appwiz.cpl) vilket är helt korrekt. Där emot uppstod ett problem då man inte längre kunde se array konfigurationen grafiskt längre. Det hela visade sig bero på att själva TMG programvaran hade avinstallerat SP1 och var tillbaka på RTM nivå men ADLDS databasen som tillhandahåller konfigurationen i sig var fortfarande på SP1 nivå.
Hur identifierades detta då?
För att identifiera vilken patch-nivå ADLDS databasen har så öppnar du denna via ADSI EDIT där du ansluter med nedanstående uppgifter:
Där Connection Point är cn=fpc2 och ”Computer” skall vara namnet på TMG servern följt av :2171 (såvida du inte ändrat default port.)
Gå sedan ner i strukturen till Array-Root och under CN=Arrays välj egenskaper på den du vill inspektera. Attributet msFPC=AdminMinorVersion visar vilken version du använder och om den skiljer sig från versionnumret på TMGn.
(I mitt fall demar jag exemplet från min labbmiljö där jag har en icke publik version)
Lösningen?
För att komma runt problemet var den absolut enklaste lösningen att helt enkelt få upp TMGn till SP1 version igen vilket då gjorde att den kunde läsa in konfigurationen och visa den grafiskt på nytt.
Jag har inte testat detta, men det är högst sannolikt att samma fel skulle kunna uppstå på en UAG där man avinstallerar TMGns Service pack på samma sätt.
Slutsatsen blir också att man bör undvika att avinstallera service pack till TMG/UAG, (vilket i det här scenariot var en del av en annan felsökning)
Häromdagen kom det ut en ny kb om ett eventuellt problem man kan stöta på i Forefront TMG när en proxy klient överför en större mängd data mot en webbsida över SSL där TMG stänger sessionen. Det finns en fix för det här problemet som beskrivs i kb-artikeln:
En annan bra blogg-artikel kommer från två MVP kollegor som identifierade ett scenario efter TMG Service Pack 2 installation. Om man manuellt har raderat standard nätverksregeln “Internet Access”. Vid installation av SP2 återställs nämligen den här regeln vilket kan ge konstiga effekter om man exempelvis har valt att TMG skall routa trafik mot Internet.
Jag kommer framöver köra några kurser på Cornerstone, initialt är det en Forefront TMG kurs som är på G och kommer köra igång i början på nästa år.
Så skall “jag lära dig allt jag kan” om TMG så är det bara att boka in en kurs. Naturligtvis kontrar man med “Nåja, det går väl ganska fort” vilket stämmer, kursen är planerad till tre dagar 
http://www.cornerstone.se/sv/Om-Cornerstone/Instruktorer/Anders-Olsson/
Allt för ofta när jag kommer ut till en befintlig Forefront TMG eller UAG lösning hittar jag larm som ser ut enligt bilden nedan och får även höra att det är problem att nå vissa enheter eller tjänster.
Därför tänkte jag reda ut hur man hanterar interna nät och routing en gång för alla.
I både TMG och UAG får man specificera vilka nät som skall klassificeras som interna nät. Problematiken i det här har att göra med det saknas en intern gateway på det interna nätverkskortet då det enbart går att ha en default gateway och den skall alltid vara konfigurerad på det externa nätverkskortet. Det här gör att det krävs ett extra moment där man specificerar en route över hur TMG/UAG skall nå det här nätverket från det interna nätverkskortet.
Felmeddelandet ovan beskriver det här klart och tydligt. Det finns ett specificerat internt nät där det saknas routing från det interna nätverkskortet vilket då betyder att det är det externa nätverkskortets default gateway som då kommunicerar med detta subnät, vilket blir tokigt.
För att se till att de här uppgifterna alltid stämmer när man skall lägga till ett nytt nät finns det ett bra tillvägagångssätt att följa:
Steg 1.
Definiera routing till det nya nätet.
I tidigare ISA/IAG lösningar var man tvungen att använda “Route Add kommando” på varje ISA/IAG i exempelvis ett kluster men i TMG finns nu ett mer enkelt och användarvänligt sätt att hantera Steg 1 i detta tillvägagångsätt.
I TMG konsolen gå in under Networking och fliken Routing där du klickar på Create Network Topology
Definiera nät och subnät samt den gateway som är nåbar från det subnät som är specificerat på det interna nätverkskortet.
Tryck Apply och vänta någon minut så ändringarna slår igenom.
Det kommer nu läggas till en route för detta nät och är det en Enterpriselösning med flera TMG/UAG så sker detta på samtliga servrar med automatik.
Steg 2.
Se till att det nya nätet som du specificerat routing för också definieras som ett internt nät av TMG/UAG.
I TMG konsolen gå in under Networking och fliken Networks. Dubbelklicka på Internal Network och till fliken Addresses, välj Add Adapter..
Klicka på Internal och klicka på Ok. Alla nät kommer nu läggas till under Internal Addresses.
Under Network adapter details i bilden ovan specificeras alla nät som är routade från det interna kortet.
Fördelen med det här tillvägagångssättet är att TMG själv bygger upp IP Adresslistan baserat på vilka nät som den kan routa till och på det sättet kommer konfigurationen alltid att fungera.
Observera att det kan komma en Alert om IP spoofing eller Configuration Error under tiden som steg 1 har genomförts då det finns routing för ett icke specificerat internt nät under den tidpunkten. Såvida steg 2 genomförs kan detta ignoreras.
Jag fick nyligen förfrågan att göra en inspelning för MEET gällande ett aktuellt ämne inom säkerhet. Något som vi på Onevinn ofta stöter på när vi är ute och träffar ett (för oss) nytt företag, är att det sitter en eller flera runt bordet med någon form av platta, smart phone eller dyligt. När sedan den naturliga frågan kommer upp om vilka utmaningar de står inför, så kommer diskussionen förr eller senare alltid fram till hantering av icke managerade enheter.
Det som många missar är att du faktiskt kan nyttja Microsofts säkerhetslösningar i exempelvis Forefront för att supportera även övriga enheter.
En tydlig trend som vi ser just nu är att Microsoft satsar mer och mer på att supportera övriga enheter än sina egna. Ett exempel är senaste uppdatering till Forefront Unified Access Gateway (UAG) där vi fått utökad stöd för både Apples och Androids enheter (http://technet.microsoft.com/en-us/library/hh490321.aspx)
Jag har skrivit en artikel över hur du kan nyttja Microsofts teknik för att både supportera fler enheter i din infrastruktur men också för att skydda företagsinformation från icke managerade enheter.
Artikeln kan du läsa på Microsoft TechNet
Tillsammans med Michael Bohlin på Microsoft spelade vi även in en video om samma ämne
Klicka på bilden för att komma till videon
