For the past couple of years, I’ve been doing presentations at TechEd, ITForum, DEC (now TEC), and the European Identity Conference on how MSIT is using Active Directory Federation Services (ADFS). Inevitably, somewhere in my talk, I’ll go back to our initial dogfooding deployment of ADFS in Windows Server 2003 R2, back in 2005, and discuss one of the biggest mistakes we made, and the “mind shift” which had to happen for us to succeed with ADFS. That mistake, was applying “what we knew” to a new concept, rather than thinking about what we “needed” and the things which were really important to us.
I usually describe this experience, by explaining what happens when you first start to look at federation in an environment, when you’ve got nothing else to compare it to. Typically the thought process for an ADFS deployment goes something like this:
– It’s single sign-on infrastructure, so Mr. Application Owner doesn’t want to support it for everyone, this is “Infrastructure”
– It’s SSO for users, and there is this “claims” thing which is ‘Identity’ data – so this is “Identity Infrastructure”
– We already have identity infrastructure – our directory – so let’s get the directory team engaged. Oh yeah – and don’t forget, the technology has “Active Directory” in it’s name – and our directory is “Active Directory” – left hand, meet right hand.
What happens? Your AD team gets tasked with figuring out how to host resources for partners to do single sign-on. They’ve been hosting the directory that holds those partner accounts anyway, so this make sense. Of course, at the same time, we’ve been beating this “directory centric” mindset into the security organization for years, and they are participating as well. The result:
Both the team deploying ADFS, and the Security team making policies – have a directory centric slant on federation
This shouldn’t be bad right? It’s Just another identity system. Yes and no. The problem with federation, is that if you’re hosting the applications (which is the specific scenario I’m talking about here), you need to “trust” the other organizations identity infrastructure. Ok, well, trust may be a strong word – but it’s just so much easier than saying, “bind with complicated requirements wrapped up in legal framework”
Ahh – but directory guys don’t trust anyone do they? In general, we’re trusted, but that rarely (and usually only with a fight) goes in the other direction.
Let’s assume that you get over this first cultural hurdle, and decide that it’s ok to trust your business partner for authentication, to get to those applications in your Extranet/DMZ – the ones which they already have accounts in your directory for. What does the legal agreement look like when you let a bunch of directory brainstorm the requirements? Well – it contains all of the things which are important to directory folks (makes sense).
Here’s the example which actually prompted this post. 2 weeks ago I received a request from a business partner to allow MS users to authenticate via ADFS to this partners Extranet environment. This request was accompanied by a 9 page “Federation Agreement”. The first 8 or so pages were boilerplate legaleze which isn’t really relevant. The important part is copied below, with name changes to protect the innocent and minor formatting for readability:
Exhibit A Security Requirements
I. Password Policy Requirements:
User Account passwords MUST comply with all of the following requirements:
Be at least 8 characters long;
Contain upper and/or lower case letters, numbers and non-alphanumeric characters;
Be changed at least once every 60 days; and,
<COMPANY> provisioned accounts (Corporate, Partners domain, etc.) and vendor federated accounts for the same
individual must have different passwords.
User Account passwords MUST NOT:
Be cached or stored in cleartext human readable form;
Be able to reuse their previous 10 passwords;
Be shared with anyone; or,
Be set such that the password never expires. Passwords must expire in accordance with 1.c above.
II. Password Best Practices:
User Account passwords SHOULD have at least one number, symbol and/or punctuation mark.
User Account passwords SHOULD NOT:
Include words in any language or dictionary i.e. do not use a word from a dictionary;
Be changed to words that have the letter(s) “o” changed to the number(s) zero “0” or the letter “i” changed to the pipe(s)
symbol pipes “|” or the number one “1”, or vice versa;
Be a family or pet name.
III. Account Policy:
1. Access to <COMPANY>’s corporate resources MUST be through approved and valid individual account partner accounts.
Sharing of user accounts is prohibited.
2. Account partners MUST NOT impersonate anyone else or misrepresent themselves.
IV. Virus Protection
1. The Company will ensure that all systems used to access the <COMPANY> Extranet have installed an adequate,
daily updated, commercially available anti-virus scanner.
V. Screen Savers
1. Any device used to access the <COMPANY> Extranet shall have enabled a screen saver which activates after 15 minutes
of inactivity and is configured to lock the PC screen, requiring the User to re-enter their Account password in order to
re-activate the device.
Note that this is the entire list of their security requirements. The crazy ridiculous part, is that apparently this company had previously had conversations with some of the MSIT team, and based their agreement off of a very early draft of OUR OWN federation agreement! What kind of monster did we create?!?!
Have you figured out what’s wrong with this yet? I already said that this is one of the biggest mistakes that MSIT made when we were doing early drafts of our federation agreement. So what’s the issue?
Like I said earlier – this is a very directory centric view. When you manage a directory (remember, I’m also one of the directory engineers for MSIT), what kinds of things are important to you? Password policies, complexity, etc… Heck – as a community, how long did we fight to get Fine Grained Password Policy (now in Server 2008) into AD? Passwords! These are important things! And they need to be strong! And they need to be unique! And they need to be used often, like when the screen locks! All of these are great and wonderful things that we believe in!
Yes, passwords are important, but let’s step back to the things which are more important. Before we do though, let me share the response I sent to this federation request:
Thanks for sharing your requirements for federating Microsoft employees into your Extranet. Unfortunately we are not able to complete the federation onboarding request at this time, as we are not able to meet the security requirements in Exhibit A. Specifically the areas of concern are:
– Our password policy requires users to change their password every 72 days, which is greater than your required 60
– We can only ensure that users do not synch multiple passwords within our directories. Without admin access to your directory, we cannot verify that users are setting unique passwords
– There is a population of users whose accounts are set to never expire passwords
– We allow users to do federated authentication from any corpnet or Internet based machine. Therefore we cannot guarantee that the machine the user authenticates from contains any type of virus protection.
– We allow users to do federated authentication of their identity from any corporate or Internet based machine. Therefore we cannot guarantee the settings or integrity of the device from which the user is authenticated from
Let’s get back to the basics now – the things which are important. What is the whole point of doing federated authentication between business partners? DEPROVISIONING! Yes, that’s the “one big thing”. The major problem with the way that directories do Extranets and DMZ’s today, is that you’re relying on the partner to remember to deprovision one of his users, when that user is terminated. With federated identities, you are tying access to your environment to the same identity that the partner company ties access to THEIR DATA to. The one they issued.
From a federation agreement perspective, here are some of the things which I like to see:
- Figure out what the “minimum bar” for things like password policy is, not the settings which you would put in your own partner directory.
Ask yourself which is better, to have deprovisioning with a less secure password – or a more secure password on an account in your directory which may stick around for weeks after a user is terminated from their parent company?
- Determine what your acceptable bar is for deprovisioning user accounts. Within MSIT, our SLA for deprovisioning a user is to have 90% of accounts disabled within 24 hours of termination, and 98% within 48 hours.
- Don’t try to tie things like machine state to identity. Within the directory, we can say things like “domain joined machines” and “group policy application” and “patching and security requirements”. Federation isn’t meant to get you a healthy machine. Federation provides you with assurance of the most credible identity possible. Our identity is more credible than yours, because we know when the user is still employed with us.
As always, security is about risk management. Federation Agreements are the legal instantiation of a risk management policy. Don’t set your risk management bar so high, that you actually end up reducing your security posture by preventing partners from federating. You may “keep control” of the accounts in your directory – but those aren’t the most credible accounts that could be used to protect your data.