ISA 2006 SP1 – Change Tracking

So finally I can share with you some features of ISA 2006 SP1.
One of the great new features we will see is Change Tracking.
I have sent the product team my love for introducing this, this feature alone will make everyone hurry to get ISA2006 SP1. I also think that this will make selling ISA as a “serious” Firewall will be much easier.

In Enterprise Edition this feature is enabled on the Enterprise level.
You also have the option to require a description for all changes made.
I would suggest that you enable this as soon as the basic configuration of ISA is done and we are moving into production.
Enabling Change Tracking
Even though you might feel tempted to raise the number of entries to a huge number, be aware that this might cause the Change Tracking, search and filtering function to be real slow.

With Change Tracking you will be able to track every change made to ISA configuration.
Overview of Change Tracking tab
I will just LOVE this feature, it will make my life working with ISA so much easier. Imagine having solid proof when the customer complains that ISA “just stopped working” and they “haven’t done anything”.

If you drill down into the change you want to check out you will then see a very detailed view on what was changed.
Detailed view of Change Tracking entry

One of the things this feature will make me stress to my customers is to use individual accounts when working with ISA, in this way we will always know “who” made this change. If we all use the administrator account, that part will be lost.

This is the first in the series of blogs I plan on SP1 features, stay in touch for more.

ISA2006 SP1 – coming soon

So finally i got my hands on SP1 of ISA 2006.

Havent had any time to test it yet, but i can promise you all a happy moment when you are able to run it. 🙂
Still NDA on the exact featurelist but let me just give you some hints about what’s in the current build.
Hopefully none of them will be removed, but as always. You never know.
– Change tracking possibility
– Multi domain/forest KCD
– Improved support for SAN certs
– Heavy improvements on troubleshooting
and much much more…

In some parts SP1 contains more news than 2006 RTM did compared to 2004 SP2.

Stay in touch and i will tell you more as soon as possible.
The Beta period is planned to be a short one, but no release date so far.

Forefront Threat Management Gateway. Part 1 – Web Access Policy

After trying hard for a while.. and failed…to make this article readable on the web.
I decided to just give it to you as pdf until i figured out how to format it, to fit the blog page sizes.

So please download:
http://www.konab.com/tmg/TMG%20Blogg%20-%20Web%20Access%20Policy.pdf

/Kent

Nitrogen beta 1!

Äntligen har den då kommit! Smile

Första betan av Nitrogen (ISA 2008) släpptes i slutet av veckan till TAP deltagarna.

Har inte hunnit slänga upp en ännu eftersom den kräver en x64 Server 2008 i botten.
Men i början på nästa vecka skall jag sätta upp den hos min kund som är med i TAP:en.

Så fort som möjligt ska jag sedan börja bombardera produktteamet med bloggposter för att få godkänt att jag börjar skriva lite om vad ni kan förvänta Er i nästa generation av ISA Server.

Själv har jag bett om pris på en ny server (Dubbla QuadCore o 16GB RAM!) för att kunna börja virtualisera x64 på 2008 RC0’s virtualiserings plattform. När den är på plats (förhoppningsvis om ett par veckor) så kan jag på allvar börja testa den i andra scenarion än dom som min TAP-kund tänker testa för.

Det kom ett mail…

från en av mina kunder med funderingar kring varför ISA skall stå på ett DMZ och om den kan ersätta en Exchange FE server.

Jag vill här delge Er alla mitt svar. Som kanske kommer att reta någon men förhoppningsvis väcker en del tankar.

Hej!

Låt oss först konstatera vad en FrontEnd Exchange 2003 server gör för nytta…

Den behöver man om man har ”flera” mailbox servrar (BE) då man kan låta användare accessa FE och den routar / hämtar data från rätt mailbox server.

Det betyder att om man har flera mailboxservrar och vill publicera OWA, ActiveSync o RPC/HTTPs så måste man ha en FE vare sig man har ISA eller inte.

Alternativet är att användare på olika mailbox servrar måste använda olika URL:er.

Har man ”bara” en mailbox server behöver man tekniskt ingen FE utan kan publicera de webbaserade tjänsterna direkt mot BE.

ISA ersätter INTE FE de två gör inte samma sak.

ISA ser till att man säkert kan publicera tjänsterna medans FE ser till att vi bara behöver en URL även om vi har många BE servrar.

Notera nu att Edge servern i Exchange 2007 har ett helt annat syfte.

Om man vill låta användare komma åt de webbaserade tjänsterna som exchange tillhandahåller är det dock många som föredrar att göra denna publicering i en ISA, p.g.a. dess http applikationsfilter och SSL bridging förmåga.

I de flesta fall skulle jag vilja påstå att huruvida det står en brandvägg framför/bakom ISA servern är helt egalt ur säkerhets synvinkel då trafiken som släpps fram till ISA är SSL och den trafiks om går mellan ISA och Exchange är SSL, ingen brandvägg som inte i likhet med ISA kör SSL bridging adderar något säkerhetsvärde. Den släpper ju bara fram TCP443 utan vidare analys.

Om man vill publicera andra exchange tjänster så beror ISAns värde på om den har ett applikationsfilter eller inte för trafiken.

Den har ju t.ex. ett ”basalt” SMTP filter där man t.ex. kan blockera VRFY kommandot, om den ”yttre” brandväggen saknar appfilter för SMTP utan bara släpper fram TCP25 till ISAn gör den i detta läge ingen nytta och adderar enligt min mening ingenting till säkerheten.

—Ang Single NIC—-

Det är ett väldigt tjafsande med att sätta ISA på DMZ och bara ha ett NIC.

Att trafiken går upp o vänder i ISA är ju bra om det för att utnyttja ISAns filter, därför stödjer man bara trafik som baseras på webproxy filtret i single nic läge.

Dessutom är det så att de flesta ju vill låta ISA autentisera emot ett AD. Detta kan man naturligtvis göra i ISA 2006 utan att ISA är med i domänen men det ökar komplexiteten och man kan då t.ex. inte välja att delegera med Kerberos. Att då låta ISA vara med i domänen är enligt klassiskt synsätt att kortsluta sitt DMZ, jag brukar därför rekommendera kunder som ”måste” har en brandvägg framför ISAn att sätta den med ett ben i den yttre brandväggens DMZ och ett ben in i LANet så att den kan vara med i domänen. Helst skall då också ISAns externa interface vara ett routat interface i den yttre så att man har full frihet att utnyttja ISAns alla funktionaliteter om man så önskar.

När den är placerad så kan man sedan välja att den används för utgående trafik, VPN osv om man så önskar utan att ändra infrastrukturen.

Att ”kräva” att trafiken till LAN:et från ISA går genom ytterligare en brandvägg som ändå bara är en ”dum” portgenomsläppare adderar inget till den ökade säkerheten.

Men kan ibland bli ett ”krav” som man uppfyller genom att låta ISA’n inre interface ta vägen via den ”stora” (dumma o dyra 😉 ,,) brandväggen man har på vägen till LAN:et.

—Varför då två brandväggar…—

Detta är den stora frågan.

I de flesta fall sätter man flera brandväggar av ”gammal” vana, men det är också så att man inte kan opponera sig mot att även en ”dum” brandvägg som ”bara” släpper fram en port inte faktiskt kan addera värde i form av att t.ex. kunna stoppa denial of service attacker.

Frågan brukar ju till stor del handla om att man inte ser ISAns som en av de bästa brandväggarna på marknaden utan som en ”proxy”.

Be dom berätta hur deras brandvägg löser ISA 2006s ”Flood Mitigation” eller hur de gör för att i deras brandvägg skanna SSL trafik.

(Idag finns till ISA addon som gör detta även för utgående trafik!)

Den har ju inte prioritering säger då belackarna. Nä inte inbyggt men köp till t.ex. Digirains Quota hanterare och se om inte de flesta klarar sig med det.

Hoppas du blivit lite klokare och som du förstår så är detta mina privata åsikter och ingen ”officiell” syn på saken från Microsoft.

Mvh

/Kent

ISA 2006 Supportability Update

Microsoft verkar ha dragit ut på SP1 till ISA 2006, men släpper nu en supportability pack för ISA 2006 så att vi kan få samma “snygga” logg och felsökning som i ISA 2004 med SP3.

http://www.microsoft.com/downloads/details.aspx?FamilyId=6F629EAC-D8C6-4437-9D20-B47B02DB413A&displaylang=en

Bara att installera!

Nitrogen TAP Kickoff

First let me apologize for writing this in English.

I will do all my blogging around Nitrogen in English due to the fact (NDA) that i need to send it to the product team for approval before I publish it.

Finally the TAP for Nitrogen is started :-,,)

During three nice days in Berlin, Microsoft ISA Team presented all the new stuff to expect in Nitrogen and off course opportunity for us to give input on features and functions.

Due to the NDA I will NOT, for the moment, be able to tell you much, but one thing is clear.
You are going to like it, many of the features we were hoping for in ISA 2004 and 2006 are now being implemented.

So when are you guys going to have some details. Well basically we will not see public betas until the end of the year. But hopefully I will be allowed to drop some details during the TAP period.

Please keep your eyes on my blog and i will keep you updated and if you think that you have important features you would like to see in the next version of ISA, please drop me an email.

ISA 2004 SP3 o Nitrogen

Microsoft har beslutat släppa en SP3 till ISA Server 2004. Detta ser jag som ett litet bakslag eftersom det antagligen innebär att man upptäckt, precis som jag, att kunderna inte skyndat att uppgradera till ISA 2006.

Någon kod finns ännu inte att testa men det talas om förbättrad diagnostisk hantering. Dvs förbättrad logghantering och felsökning.

Eller som det står i den engelska texten:
“ISA Server 2004 SP3 provides increased security, new troubleshooting options and tools available directly from the ISA Server Management console, new diagnostic logging functionality, and enhanced log viewer and log filtering options for ISA Server 2004 Standard Edition and Enterprise Edition. In addition, this service pack adds support for publishing Microsoft Exchange Server 2007 with ISA Server 2004.”

Man kan väl också misstänka att detta kommer att innebära att vi får se en SP1 till ISA 2006 med ungefär samma innehåll.

Så fort jag fått kod och hunnit testa återkommer jag med rapport om de faktiska förbättringar som ingår.

TAP programmet för ISA 2008 (Nitrogen) är också i startgroparna, även där hoppas jag löpande kunna rapportera om de nyheter som kommer. Jag deltar i detta på två fronter, dels själv men också som tekniskt ansvarig tillsammans med en  kund.

Verisign och ActiveSync

De flesta väljer att köpa ett certifikat från t.ex. Verisign när man börjar prata om att köra ActiveSync.

Tanken är att man inte ska få några problem med att telefonen inte “litar” på certifikatet.
Döm om förvåning när det visar sig att man kan få samma problem även med ett köpt certifikat!

Detta kan inträffa om man t.ex. köper ett certifikat utfärdat att “VeriSign Class 3 Secure Server CA”, detta är nämligen en s.k. intermediate CA och har en RootCA som heter “VeriSign Class 3 Public Primary CA”

Root CA”n finns i Mobile 5 som trusted men inte den intermediate som utfärdat den.
Detta gör att Mobile 5 kan uppfatta certifikatet som icke trusted.

Om man ska publicera ActiveSync i ISA och har ett sådant certifikat (kan tänka mig att det gäller för fler som använder intermediate CA) MÅSTE man i ISA lägga in “VeriSign Class 3 Secure Server CA” som en Intermediate CA i samband med att man imorterar certifikatet.

När man exporterar Certifikatet från den IIS där man gjorde requesten bockar man lämpligen i att ta med alla certifikat i pathen så får man med sig både intermediate certifikatet och rootcertifikatet att installera på ISA”n.

ISA kan nu ge Mobile 5 “hela” pathen för certifikatet och telefonen kan se att den kommer från en “trusted” root CA.

Kan man ha för många regler?

En kund undrade i veckan om man kunde ha för många regler och jag sa lite “självsäkert” att antalet regler inte spelar någon roll i ISA Server. Dom påstod då att “någon” sagt att vid ca 250 regler så “bryter” den ihop.

Upp till bevis tänkte jag och har igår testat.

Jag gjorde ett litet script (maila om ni vill ha en kopia) som genererade ett antal regler av normal karaktär (specifikt protokoll, UserSet med 2 st domänkonton, internal to external).
Jag satte det att på min ISA Server 2006 (P4 2,8Ghz, 1GB RAM) generera 500 regler.
Det tog lite tid för jag gjorde apply efter varje ny regel så vartefter tog det längre och längre tid att skapa nya regler.
Totalt jobbade skriptet i ca 2 timmar och datorn låg då på en jämn 50-70% CPU belastning.

Under skapandet satt jag och surfade, lyssnade på radio kikade på mediasändningar och fick inte ens ett hack i en film. Jag kunde alltså inte se att jag fick någon prestanda-påverkan.

När det var klart kontrollerade jag återigen prestandan och kunde då se att den inte drog nämnvärt mer RAM än innan och inga prestandaproblem trots att den regel som jag nu använde för att t.ex. kunna surfa var regel nr. 520.

En liten försämring kunde man se när man gjorde ändringar i regelverket, apply tog nu lite längre tid 15-20 sek.

Jag kan sammanfattningsvis bara konstatera att antalet regler inte spelar någon som helst roll för prestandan i en ISA Server.

Att administrera 500 regler däremot är en helt annan sak Wink