Integrating strong authentication into Microsoft technologies

One of the interesting parts of blogging is that when you aren't blogging on a consistant basis, regular readers sometimes check in to see that everything is alright. I appreciate such emails, and just want to say thanks to the people that have asked if I am alive or not in one form or another.

Don't fret, I am indeed alive. Just extremely busy working on some stuff in the strong authentication field, and researching how strong authentication can be part of identity management solutions. Learning more about things like InfoCard, it is becoming more clear to me that as we move to the next generation of identity management we are still thinking 30 years back on how the passwords associated with those credentials are used and managed.

In the world we live in today, normal username/password credentials are just not enough. We all know that. Hell, even Bill Gates knows that, stating passwords would be dead in the coming years. Yet we still hang our 'assets' on the line using it. As a SBSer I am in LOVE with the one unique Microsoft killer feature... Remote Web Workplace (RWW). But using RWW shows me there is some unnecessary risk that can be plugged with strong authentication.

If you don't know, RWW allows a user on a SBS domain to access email (OWA/Exchange), the corporate intranet and databases (sharepoint) and corporate desktops and Terminal Servers (proxied Remote Desktop) from external computers outside of the network via a browser. Thats right, they can access all office resources from home via their browser. Or the computer at their inlaws. Or that Internet cafe while on vacation in Europe. As long as they know their Active Directory username and password, they can access all the corporate resources they are authorized to access. Wow... what amazing productivity enhancements this can provide. Access whenever, and whereever you need it.

One flaw with that thinking. It also means that an adversary that can capture those credentials can also access the same things. There is no way to associate that the person (or automated machine!) that is entering those credentials is really Bob or Alice. It could be Gregor, the pesky Russian hacker that installed that software keylogger via his Trojan botnet. Or Stephen the slimeball, who shoulder surfs passwords while you check email at the airport kiosk. Point is... if someone can get or guess your username and password... it is all over. And the attacks to this can be low tech social engineering, which is quite easy to do.

This is something that has bothered me for some time. As great as RWW is, you have to have ABSOLUTE trust of the machine you are at, or you simply shouldn't consider connecting to your corporate network in this way. The risks just aren't worth it. At least on my network. Your risk tolerence is probably different than mine.

But what if we could add another form of authentication that would ensure that the person at the computer connecting in is actually Bob or Alice? Or at the very least, that the user on the other end has more than just the AD credentials? If we could do that, we could significantly reduce the risks of such attack vectors. And that gives me a lot of comfort.

So knowing RWW couldn't do that, I went and wrote an authentication and login system for RWW that DOES do this. By using RADIUS to communicate with a strong two-factor authentication server, we can add two-factor auth on top of the regular AD credential login for RWW. From a login perspective, its not very disruptive... you simply have to add your passcode coming from your two-factor authentication token. The login page for RWW now looks like this:

One of the benefits of the approach I used was the fact you can use the same auth token for other accounts. As such, although you would normally associate the token with your normal login account, you could ALSO use it verify the Administrator account (if you configure it that way). In one environment where this is installed, the SBS admin decided they didn't want ANY of the normal users to have to use two-factor auth, but that the Administrator HAD to. Using their RSA SecurID token associated with a user NOT named Administrator, this was easily done. The advanced login looks like this:

As you can see, this isn't very disruptive to the RWW login sequence, but offers a level of magnitude greater security when logging in from potentially hostile computers. Even if a machine has a keylogger installed or someone shoulder surfs your password, they won't be able to replay the login since the one time passsword used as part of two-factor auth would not match. Walla. We eliminate the attack vector of simple credential login capturing, adding strong authentication directly to RWW. On top of that, I added detailed audit logging so you can now get alot more intelligence about your login metrics. The dashboard an administrator can see to evaluate this looks like this:

This is now in the process of going through testing towards the commercialization phase and should be released sometime this fall. Until then, I am busy working hard on finding other ways of integrating strong authentication into the Windows stack for small business. Who knows... maybe in the future you might be able to use your Infocard built into Vista to login to your RWW session.

I love doing this stuff.

Should Microsoft Forefront work with SBS?

With the recent announcement of Microsoft Forefront, I have had a few people now ask if this will be available for SBS. To be honest, I don't know the answer, and I don't believe Microsoft does either. Those pesky SBS devs stay very tight lipped about such things.

Could Forefront work on SBS? Of course. Although Forefront is presented as "enterprise security" bits, the core pieces all exist or can play with the SBS platform:

• Forefront Client Security (formerly called Microsoft Client Protection)
  
• Forefront Security for Exchange Server (currently called Microsoft Antigen for Exchange)
  
• Forefront Security for SharePoint (currently called Antigen for SharePoint)
  
• Antigen for Instant Messaging
  
• Microsoft Internet Security and Acceleration Server 2006 Release Candidate
  

The ISA 2006 piece isn't something we will be getting ever. In Cougar (Longhorn Server version of SBS) though, we should be getting ISA 2007. So, what does that mean for Forefront? Let's take a look at the ForeFront roadmap:

As you can see, Forefront is also going to be adding ISA 2007. So theoretically, that might be a time frame where integration with ForeFront might make sense. But here is the kicker, when weighing features vs cost, it is highly unlikely that most SBSers would embrace a higher priced SBS platform to get the Forefront bits. We already see an unprecendented unbalance between SBS Standard and Premium... where so many people are missing out on the benefits of ISA 2004. Adding the rest of this is probably just not in the cards.

A heterogeneous solution with Forefront on SBS for security all tied into Active Directory makes a lot of sense... but its a solution most small businesses just won't understand... yet. And if they can't see the value proposition in the offering, it makes it extremely difficult for resellers to position it.

So SHOULD Forefront work with SBS. Yes. Will it? Doubtful.

Dan Geer on Silver Bullet

Just finished listening to the latest Silver Bullet Security Podcast with Gary McGraw over lunch. On the show is none other than Dan Geer, Chief Scientist at Verdasys.

This recent podcast is interesting in that Dan and Gary show the disconnect between business and security, and show how corporate information assets are of the utmost importance. Nice to hear the term "corporate wealth" and "information assets" be used in the same sentence. And thats just the start. You will need to tune in and check it out for yourself.

Where fore art thou NGSCB?

A few years back, all the rage was the new advancement in trusted computing, and the "next generation secure computing base" (NGSCB).... Microsoft's software architecture to increase the security and privacy of computer users.

As we all know, most of the "Longhorn vision" of NGSCB that was talked about in 2003 has been pulled. Vista is not expected to contain much of the Next-Generation Secure Computing Base technology, owing to significant difficulties in getting third-party developers to work with the new platform. And that's sad, since some of the hardware vendors are now distributing product with the TCG chip.

Yet like the Phoenix, the vision of NGSCB just won't die. Which, to be honest, is a good thing. Microsoft has butched the NGSCB group a few times, and I recently found out they are now calling themselved the "Systems Integrity Team". And they have a blog!

There isn't a lot of content there as of yet, but their last couple of posts have shown some constructive thoughts. Will be interesting to follow their progress in the coming years.

So NGSCB isn't dead. It's just been renamed.

Pachelbel's Canon on the Electric Guitar

One of my all time favorite songs would have to be Pachelbel's Canon in D Major. You haven't heard anything if you can't feel the strings vibrate through to your bones. You know... when it sends a shiver down your spine and you go all tingley. It is one of the few songs I have heard in my life that has actually made me almost come to tears, when I heard it played by the Calgary Philharmonic Orchestra as a kid.

Today I came across an amazing interpretation done on a guitar on YouTube. And no, this isn't a classical acoustic one. Some guy in his bedroom playing his rendition on an electric guitar. You have to go check it out.

All I can say is "WOW".

Quote of the Day

Taken from an email sent by Susan:

"If you think installing patches and security updates is expensive, try not installing them."

Update: Original credit goes to Mark Crall, Charlotte SBS Group Lead. Thanks for the clarification Susan!

Using virtualization to help swing an Exchange upgrade

Over at InfoWorld, Keith Schultz points out a good method in doing an Exchange (or SBS for that matter) upgrade from one machine to another. It's called "Swing Migration", and its a method developed by my friend and fellow MVP, Jeff Middleton.

If you ever have a need to move an SBS box from one piece of hardware to another, this is the method to try. Jeff sells some great documentation and scripts to make this process go by quite cleanly, and his expertise that you get if something goes wrong can't be matched by anyone, INCLUDING Microsoft PSS. You owe it to yourself to spend the couple of bucks and buy his Swing Migration Kit.

Now Susan has a poll going on trying to determine if Keith should have credited Jeff. I vote yes. Swing Migration is Jeff's baby and credit should go to the source. Then again, some say that plagerism is the most sincere form of flattery. I dunno if Keith did it on purpose or not, but it only takes about a two second google search to see this isn't original thought. Come on Infoworld editors... make sure your writers are crediting the source!

Vista RC1 will be Reducing Elevation Prompts

After my rant about Microsoft needing to eat its own dogfood when it came to UAC, I was happy to see Steve Hiskey from the Windows Security Core team blog about the fact that UAC prompting in RC1 of Vista will be MUCH better.

Their plan makes a lot of sense:

1. Make changes in the OS to create safe scenarios for the Standard User to accomplish tasks that used require an elevation prompt.
   
2. Apply application compatibility fixes (“shims”) for the applications that need help running as Standard User.
   
3. Work with ISVs to update the applications that can’t be shimmed and to design the future applications so that the next generation run well as Standard User.

This is all old stuff, but you need to read his post to see that they get the problem, and are working to resolve it. I can't wait to see how the UAC experience differs in RC1.