Today, if you want to use Dynamics CRM from a tablet there are some special considerations that have to be taken into account. Specifically the need for an additional server meant to be used as nothing more than an authentication gateway. ADFS or Active Directory Federation Services is a more secure way to communicate your login credentials. However, it can be frustrating to understand and even implement. I hope I can explain some of the more confusing parts and help you get ready to deploy CRM for your mobile users.
Active Directory Federation Services. Lets start with what it is, because while the name is descriptive, it doesn’t actually provide a full picture of what it does. In simple terms, it allows someone to log on to a system without handing over their specific user login and password to that system.
Here’s an example that will be very accessible to all of us. When was the last time you had the option to “Login with Facebook?” Probably something like 5 times this week. That’s a form of federation with Facebook. Basically, the website making that offer will let you log in to their system on the basis of trust they have in Facebook. When you click the button, the website fires off a message to Facebook that says, “Hey, this person wants to log in and I don’t know who they are, but whoever you say they are, I’ll trust that and let them in.” So Facebook asks you for your login and password, generates a secure trusted token that says, “Jim Bob is a-ok with Facebook, so let him in.” This is federation in action and there are a lot of benefits to this federation business. Going back to our example, you just got to log into a website without having to make another account for another site. The site gets to know that you’re a real person, from an authority they trust without you handing over any personal information. This means all of your Facebook data is still out of reach and one login can potentially get you into a lot of places. All of this happens without that website ever having received an actual login and password.
So what in the world does this have to do with Dynamics CRM? Well, Microsoft, for good reason likes the idea of a token swap over you handing out your login and password. That’s where ADFS steps in. So lets walkthrough what happens when it’s enabled.
You type in your company URL for CRM. Configured to use ADFS, the website immediately directs you to a secure server to capture your login. You log in with your domain credentials, ADFS generates a secure token and passes that token back to you. Your browser is sent back to CRM with the token and allowed access to the system. Now if you’re paying attention, you might be just as frustrated about this as I was. Why am I using a second server, to log in using my domain credentials, to get a token that will allow me to log into CRM, which simply proves I am a domain user?
It’s all about security. Now, whenever CRM might need to check your credentials again, that encrypted secure token (that’s only useful to CRM and ADFS) is the only thing that’s bouncing around the internet to identify you. Never again during the time in which the token is valid will your user name and password be required. This significantly reduces your vulnerability window and makes connections via mobile devices even more secure. Which is exactly why it’s required to use the Outlook CRM add-in from outside your organization or any of the mobile apps for Dynamics CRM which are published by Microsoft.
ADFS itself is free and included with your Windows Server 2012 software, or as a free download for previous versions. While it will serve you best to configure a separate server for it to live on, it can co-exist with CRM if configured carefully. Additionally you’ll want to obtain a wildcard SSL certificate if you don’t have one already. In the end, the cost is worth the benefit.
