How to use ADFS for OWA access

Ken posted a great article about how to configure OWA for ADFS authentication:  http://www.theidentityguy.com/articles/2010/10/15/access-owa-with-adfs.html

ADFS 2.0 is in the house!

Released To Web:
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=118c3588-9070-426a-b655-6cec0a92c10b&utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:%20MicrosoftDownloadCenter%20(Microsoft%20Download%20Center)#tm

ADFS To the Rescue!

Thanks Laura for pointing this out!

http://blog.fpweb.net/federated-identity-and-microsoft-adfs-illustrated/

If you’re going to use the same password for everything…

At least let it be a good password:  http://www.cxo.eu.com/news/password-protected/

Invitations…

More fun in the federated cloud world.  Traditionally, with EASI ID’s, the Email As Sign In meant that your user name was your email address.  However, with federated ID’s, we’re sending a users UPN as their login ID, which may or may not map to a valid email address (in many cases, it doesn’t).

So what do you do then, if you have an application where a user can invite another person to access a resource?  This is pretty common, I want to share a file on my skydrive, so I allow foo@foobar.com access to the file, which also triggers a mail to foo@foobar.com inviting them to sign up for a new Live ID if they don’t have one already, and if they do have one, then they can log in with it and access the file.

Unfortunately now, the person ACL’ing the file knows the users email address, but NOT their login name. 

The answer will likely be some form of “click here” key in the invitation which will allow the application to associate an email address with an ID, but because this hasn’t been required in the past, it’s going to take some time for applications to adjust.

The cloud doesn’t need all your passwords (just one…)

Patrick Harding and Pamela Dingle recently posted a great article, Grounding Enterprise Passwords.  If you haven’t already looked at it, I recommend you do so.

For a moment though, let’s say that you’ve already sold your management on the benefits of identity federation, and have deployed the infrastructure, and are rockin’ and rollin’ with SSO.  It’s time to sit back and relax, comfortable in the knowledge that your users passwords are securely locked inside your directory, so you’re enterprise is “safe” right?  Uhmm, maybe not.  Go grab your local CISSP and ask them when the enterprise is safe, and they’ll spout a bunch of stuff about risk management, defense in depth, and mitigating controls such as firewalls, virus scanners, and yes – your identity system & passwords.  If you dig in though, they often aren’t talking about protecting the “enterprise” – because that’s sort of an ambiguous amalgamation of many things – one of which is “enterprise data”.

Enter the cloud.  Do you care about applications moving to the cloud?  Absolutely (so does your CxO by the way)!  Do you care about how users are getting to that data?  Of course, as Patrick, Pamela, and others point out – it’s critical to ensure the identity of your users.  But we also have to be concerned about the data that resides in the cloud, and what that means to the rest of the enterprise.  Quick illustration:

Cloud Collaboration Vendor:  Move your data to my service, and I’ll save you bazillions of dollars over your on-premise suite, plus I’ll give you these value added features like letting your users view their data directly through my service from anywhere (without having to download everything locally), powerful indexing, blah, blah, blah…

CIO:  Ok, so let me play back to you what I heard, “I sign here, my users quit complaining about our VPN solution AND you save me bazillions of dollars” – GREAT!  Go work with my team and make it so…

CCV:  Ok IT guys – your CIO has signed off, now here’s the migration plan:  Train your users, copy the data, and…oh yeah – we need the private key that you used to encrypt any of that data so we an index it and decrypt it for your users when they ask…

IT Guy:  Como say WHAT?!?  That’s the key we use to encrypt ALL of our enterprise data, not just the stuff we’re hosting with you

Does your business require data encryption for some things, like high-business-impact data?  If so, how do you reconcile this with pushing the data out to a cloud service?  Or do you not?  How many instances of your data protection infrastructure do you have (is there more than one key?)  Does your vendor support data encryption at all, and if so – do they use their keys or is there a dependency on your service?  In my experience, most cloud services are loath to take too many dependencies on customer infrastructure, SLA discussions become big finger-pointing exercises. 

Back to data encryption though.  The conversation becomes even tougher when you start to talk about the “cross-premise” scenario, which is where you maintain a set of infrastructure on-premise, and host the rest of it in the cloud.  I should be able to protect my on-premise data – that a vendor should never have access to anyway – from the vendor, right?  Of course I should – so I need to have data protection FOR the vendor, and data protection FROM the vendor. 

In this thought exercise, there is an interesting tension about “who” are you protecting the data from.  In the on-premise world, the reason you protect data is so outsiders (and even some insiders) can’t get to it.  Where on the scale of trusted entities, does your vendor fall?  Even if you’ve done your due diligence, and funded new Ferrari’s for an army of lawyers, what data do you give access to?  Let’s assume you give your vendor access to all the data that is “relevant to their service”, so the vendor can decrypt any data which is hosted in their site.  What’s the process for re-encrypting the data in the case of a breach, either of the on-premise key or of the cloud key?  Often times this is a herculean task, which requires knowing/finding all of the encrypted data, and then re-encrypting it with a new key. 

If you decide to cancel your contract with a vendor – is that roughly equivalent to a compromise of the key?  Everyone I talk to says yes, that somebody with protected content and the ability to decrypt it, who is not authorized to do so – is a security problem.  As far as I can see, this is going to need to be something that the lawyers cover, otherwise the off-boarding costs of a vendor skyrocket.

These are just a few, there are a bunch of hard questions when it comes to the cloud – which is what makes this space so much fun! – I don’t have all the answers.  Here in MSIT, where we classify and encrypt A LOT of data, we’re having conversations with everyone, business owners, security folks, lawyers.  I can’t say we always tread carefully, sometimes we just “go for it”, but when it comes to adopting cloud services, we’re looking hard as we’re taking the next step, and part of that is how we protect our enterprise data IN the cloud, as well as FROM the cloud.

EASI ID (pt. 2)

Back in March, I posted EASI ID (pt 1.5), posting a question about who owns the rights to resources within a namespace, specifically email addresses.  The reason was to stimulate some braincells, about what could happen if users chose to protect personal content with a digital identity that they thought they owned, but which later they found out the didn’t (in this case their work email address).

Ariel Gordon, one of the rock stars on the Microsoft Identity Strategy team (along with Kim Cameron and others…), recently posted this comment:

Ariel Gordon said

August 7, 2009 at 2:34 pm e

Contoso owns the domain and any identifier in its realm.
Email addresses bear a claim of employment. I.e. my @contoso.com address shows (with a certain level of certainty) that I work for Contoso. Using this address after I leave the company is akin to keeping distributing business cards with the address on it.

Today, 99% websites leverage email providers’ infrastructure for user authentication: you type your email address as a login then create a password that can be reset/resend via email, effectively handing the keys to the account to anyone who controls the mailboxn including the new guy–Jerry Smith in your example.

Websites who implement authentication delegation (aka federation in the consumer sense of the term), could be informed by the IdP of user account deprovisionning and, as best practice, take action to close the account, prompt the user to create alternate credentials (if they have a fallback email address or phone #), etc.

Thoughts?
-Ariel.

I started to reply with a bit of the backstory in the comments, but figured I’d give this it’s own post, if for no other reason than (I think) it’s a fun look into some of the dynamics of digital identity…not to mention internal politics… So here is my response:

 

Hi Ariel!

Thanks for replying.  Yes, you’re correct, this is exactly what happens, and I agree with you.

The motivation for this post, was a series of conversations that I was in with an internal group here at Microsoft, about who "owned" the @microsoft.com namespace for user identities.  Historically, the internal identity management team has owned corp.microsoft.com, but the actual microsoft.com namespace was owned by the team that supports the www.microsoft.com website.  However, way back when, somebody in the Live ID team also decided that the microsoft.com namespace was theirs (in the Live ID sense)

It turns out, that today, there are approx. 2.5 million Windows Live ID’s in the @microsoft.com namespace.  Obviously we haven’t had that many employees.  But back in the day, there was a time when the Live ID team believed that @microsoft.com would be a good namespace for customers to use, similar to @hotmail.com or @live.com.  This isn’t really as crazy as it sounds, because it’s analogous to users creating a Yahoo ID in the @yahoo.com namespace. 

However many years later though, as we enter the age of federation, the challenge is that Microsoft Corporation uses @microsoft.com as our corporate namespace.  In contrast, Yahoo Corporation uses @yahoo-inc.com for their corporate email addresses.  So Yahoo can choose to give @yahoo.com to their customers, whereas Microsoft had a conflict.

This was a fun debate at the time, and ultimately we came to the decision that @microsoft.com is our corporate identity.  The question though, of what should come to those 2.5 million user ID’s.  Fortunately the Live ID team has the solution for this, and added a flag into the federation setup so that a company can choose to “evict on reserve” or “allow merge” of any existing users when they federate.

Allow Merge means that anyone with an existing user account in a namespace that’s federated, will have the option of associating their existing WLID with their new federated ID.  In Live ID speak, it means they keep the same PUID.  The result is that you keep anything you had access to, but you do so with your new corporate-account-backed, federated Live ID rather than your older, separate username/pw WLID.

Evict on reserve is just what it sounds like, where any user accounts which exist in a namespace when it’s reserved, will be moved into a “forced rename” state.  This means that the next time the user logs on with their separate user name and password, they will be forced to change their user name (keeping the same account/PUID) to a different email address, one which is hopefully their personal address.

For Microsoft employees, we chose evict-on-reserve, and are in the process of working through the details of implementation.  Our thinking behind this, is that even though they are in the @microsoft.com namespace, any existing accounts are all “personal use” accounts.  Therefore, we should protect the personal data, and have a user rename their account to a personal account.  When a user logs in with their “new” federated @microsoft.com account, they will be doing “business” work with an account that is backed by their corporate credentials (and which goes away when their employment ends).  And yes, we’re working with the Live ID team to get some controls put in place for companies that federate, so that they can limit where corporate backed WLID’s are used.

So that’s where we’re at.  Hopefully this gives other folks who are federating something to think about as well, as they integrate with service providers such as Live ID.

I’d love to hear what you, or anyone else thinks about these fun, “moving to the cloud” challenges!

~Brian

Federation Services and Direct Access

Now here’s an interesting combination.  What do you do when you have a service which has both an internal and internet facing components, with different behavior for each, and then you deploy Direct Access?

Quick aside:  For those not aware, Direct Access is a feature which allows domain joined Win7 laptops to behave as though they were on the corporate network and have full access to internal resources, regardless of where they are.

The important detail here, is that one of the control mechanisms is an idea of split DNS.  Internal domains are flagged as such, so that clients route that traffic internally, and everything else is considered “internet”.

So the question is, if you have your ADFS servers deployed in a unique namespace (we use *.sts.microsoft.com), then do you call that an internal namespace or an external one?  I’m not sure of the right answer at this point, but I’ve been bouncing around and just recently (this past week) requested a change.

Another quick note:  Remember, that we’ve got ADFS deployed so that users who are on corpnet get integrated authentication – no prompts – when they hit the ADFS servers.  Users on the internet get forms based auth, and have to enter credentials

So for your DA users, what kind of experience should they have?  Initially, when we first started rolling out DA, it made sense to me that DA enabled clients on the internet should have the “corpnet” experience.  In other words, even though I’m at home, I should still get integrated authentication. 

Just recently though, we ran into some issues where DA enabled users would be in situations (client issues, behind firewalls, etc…) where they were able to traverse the internet but were not able to get the DA connection back to corpnet.  In these cases, users were actually able to hit the internet based, federated resource.  But because the client thought that the ADFS servers were internal (and DA wasn’t working), they were failing to authenticate.  They could see the app, just not get into it.

So we had the DNS policy on DA clients changed, and now our DA clients believe that the ADFS servers are external.  This takes us back to our pre-DA behavior, where clients physically on corpnet (DA or not) will get integrated auth, but clients on the internet (DA or not) will always get FBA.  At least with FBA though, they can get access to the resources.

The change hasn’t been in place long enough, and we don’t have a critical mass of users on our DA pilot yet, so I haven’t heard the rumblings about the change to see whether anyone has noticed. Yet.  I’m sure this won’t be the last time we need to think about ADFS and DA, but all other things considered, right now I think the best thing to do is keep the 2 separate.

PoSH for ADFS

* This post applies to the Beta 2 release of ADFS and may or may not apply to the final product *

Some useful snippets from the ADFS/PowerShell world  (by no means exhaustive, just enough to get you going):

PS C:\Users\bpuhl> get-pssnapin -registered

Name        : Microsoft.IdentityServer.PowerShell
PSVersion   : 1.0
Description : This powershell snap-in contains cmdlets used to manage Microsoft Identity Server resources.

PS C:\Users\bpuhl> get-pssnapin -registered | add-pssnapin
PS C:\Users\bpuhl> get-command get-GS*

CommandType     Name                                                Definition
———–     —-                                                ———-
Cmdlet          Get-GSAttributeStore                                Get-GSAttributeStore [[-Name] <String[]>] [-Verb…
Cmdlet          Get-GSCertificate                                   Get-GSCertificate [[-CertificateType] <String[]>…
Cmdlet          Get-GSClaimType                                     Get-GSClaimType [[-Name] <String[]>] [-Verbose] …
Cmdlet          Get-GSDelegate                                      Get-GSDelegate [[-Name] <String[]>] [-Verbose] […
Cmdlet          Get-GSEndpoint                                      Get-GSEndpoint [[-Address] <String[]>] [-Verbose…
Cmdlet          Get-GSIdentityProvider                              Get-GSIdentityProvider [[-Name] <String[]>] [-Ve…
Cmdlet          Get-GSInformationCard                               Get-GSInformationCard [[-CardName] <String[]>] […
Cmdlet          Get-GSProperties                                    Get-GSProperties [-Verbose] [-Debug] [-ErrorActi…
Cmdlet          Get-GSProxy                                         Get-GSProxy [-Verbose] [-Debug] [-ErrorAction <A…
Cmdlet          Get-GSProxyProperties                               Get-GSProxyProperties [-Verbose] [-Debug] [-Erro…
Cmdlet          Get-GSRelyingParty                                  Get-GSRelyingParty [[-Name] <String[]>] [-Verbos…

PS C:\Users\bpuhl>

But I will throw out one really useful tidbit for those of you who are playing with the proxy component of the ADFS beta release and are pulling your hair out trying to get it to talk back to your full server (this is assuming you’ve already got the proxy certificates in place):

Disable CRL checking on STS servers

set-gsproperties –proxyCertRevocationCheck “None”

Even if you have access to the CRL’s and everything *should* work for you.  In the Beta release, you need to disable CRL checking on the proxy certificate…

Laura’s Rule for ADFS Troubleshooting

“If your ADFS is broken, it’s PKI. If it’s not PKI, you’ve got a typo. If it’s not a typo, it’s PKI.” – Laura Hunter