You have probably heard about modern authentication, there’s a lot of talk about it. Especially when it comes to Office 365 and Azure. You might have seen the acronym ADAL which is the Active Directory Authentication Library which is modern authentication. So, what is modern authentication and what does it mean for Skype for Business?
Well, let’s first take a look at what modern authentication is before we start looking at how it works in Skype for Business. While modern authentication is something that is presented as something new and shiny, the corner stones and the foundation is nothing new. Modern authentication simply put, is federation. Which in the Microsoft world means AD FS.
So what does this mean for Skype for Business? Well, to be honest, not very much. It works pretty much the same as the old Passive authentication which was also based on federation. Sadly there’s no EWS integration unless you are using Office365. Hopefully this will change.
The sign in flow differs from the original behavior: An S4B client attempts to connect to the S4B server, gets redirected to AD FS where the client is presented with an authentication form, user authenticates and gets a claim and is then redirected back to the S4B server where the claim is accepted by the S4B server and the client gets the webticket. So what has changed?
From my initial tests I’ve found that they’ve changed the federation protocol to Oauth2 which comes as no surprise as it is being pushed quite heavily. Secondly, ADAL support is built into the client so unlike passive authentication the client doesn’t spawn the browser window the same way (to present the authentication form) so it looks a tad bit different.
The image below is a screenshot of the sign in using modern authentication and the PointSharp MFA to provide two-factor authentication.
If you want to test modern authentication you can follow the steps on TechNet. Just remember that you need an AD FS server as well as the scripts needed to enable Oauth2 for Skype for Business (http://aka.ms/sfbadalscripts)
The December update (version 6.2.0.24) of the Skype for Business iOS mobile app contains a bug that breaks exchange integration. It’s quite annoying as it keeps popping an error message inside the client over and over.
When the client receives the Exchange Autodiscover request and parses the response it attempts to connect to the internal URL of EWS instead of the external URL. Since the internal URL most often aren’t reachable from the external network it wont reach the Exchange server.
I can think of two workarounds to this problem
Set internalURL and externalURL to the same value. This might work for some companies depending on their DNS infrastructure but generally I think this is a bad idea.
Rewrite the response data between exchange and the client so that the internalURL value matches the externalURL value.
I was at Modern Workplace Summit in Olso a week ago and did a presentation together with Fabrizio Volpe (@fabriziovlp) about security in Skype for Business. A part of my presentation touched upon the certificate based authentication used by Lync and Skype for business. After a twitter conversation with Randy Chapman (@randychapman) and Alexander Holmeset (Holmez85) I decided to write a short post about it.
Skype4B uses an authentication method called TLS-DSK which is a certificate based authentication. No it’s not client certificate authentication, it’s certificate based authentication. There is a very big difference and from a security perspective it’s important to understand that it’s not client certificate authentication.
When a client has authenticated to the server (Kerberos or NTLM) it gets a webticket. That webticket is then used to contact the Certificate Provisioning Service and retrieve a “Skype4B/Lync certificate”. This certificate is then used for subsequent authentications using TLS-DSK.
By default this certificate is valid for 180 days. This means that the client can use this certificate to retrieve new webtickets for 180 days. When a webticket is retrieved using the certificate, no check towards Active Directory user object is done. This means a locked AD account can retrieve webtickets without any problems. It’s only when an NTLM authentication is done that the AD is involved in the authentication process.
So the obvious question here is of course; “is there any way to set how long these certificates should be valid”? Yes there is, it can be done in PowerShell. This setting is a part of the web services configuration. The command below sets the expiration time of issued certificates to 24 hours.
iOS 9 is here! And like most iPhone owners I downloaded iOS 9 yesterday and installed it. If you or your Lync users haven’t done this already you might be in for an unpleasant surprise.
After the install was done I launched Lync and and hit the sign in button. I was greeted with the following error mesage.
After doing all the normal troubleshooting I still couldn’t find the reason for the error.
Thanks to Guy Bachar’s post I first of all realized that I wasn’t alone in having this issue. Turns our that for some reason; if your regional setting on iPhone doesn’t match your iPhone language you can’t sign in to Lync if you are on iOS 9.
This worked fine in iOS 8 and to me it’s really frustrating. I prefer to have my regional settings set to Swedish to get date, currency and all that in the, for me, correct format but I still want my iPhone language set to English.
I also want to point out that for me it wasn’t enough to just set my iPhone language to “swedish”. I had to re-install the Lync app from AppStore to get it working again. I really hope this gets sorted soon.
Update: Microsoft has a KB for this https://support.microsoft.com/en-us/kb/3096704. I was a bit sad to see this: “This problem is fixed in the Microsoft Skype for Business for iOS app that will replace Lync for iPhone and Lync for iPad when it’s released. No fix for this issue is scheduled for the current releases of Lync for iPhone and Lync for iPad”.
Thanks to Marc Bertasius (@marcbertasius) for bringing this to my attention.
Hello! Those of you that read my twitter already know that I am going to Microsoft Ignite next week. Those who didn’t know would have known if they followed me on twitter (hint hint). Anyway, I’m going to Ignite with many of my PointSharp colleagues. I’ll be going to sessions, stalking various Skype MVPs and of course be in our booth (#563) and talk about Skype for Business security.
We will also be bringing our brand new version, PointSharp 4.4, to the conference which includes some nice features for Lync/Skype4B.
A new admin UI
Previously we used the IIS Manager to configure our reverse proxy, in this version we have built our own UI which makes administration and deployment much easier.
Device registration for PC
In our previous versions we created a partnership between a user and their mobile device. This ensures that credentials cannot be stolen and used on another device. Now, we are bringing this functionality to the Edge server which means that we can do the same for PCs.
Block clients
We have made it possible to block an active client. For instance if a user’s phone is stolen/lost we can block that specific device. The client becomes useless, it doesn’t even matter if the correct credentials are stored on the mobile device or PC. No more disabling the whole account.
These new features combined with application specific passwords (no need for domain passwords on devices), pre-authentication and even two-factor authentication provides a lot of extra security to Lync/Skype4B. I have to say I’m proud of what our team has has done. More info at PointSharp
Are you coming to Ignite? Come talk to me in our booth, ping me on twitter (@techmikal). I’ll also be at some of the UC oriented parties in the evenings. I hope to meet you there!
This post is going to be about what seems to be one of the least discussed features in Lync. I’m talking about the Lync Kerberos Account… No, don’t you dare close this window. We know it’s there, the Best Practice Analyzer tells us it’s considered ‘best practice’ to enable Kerberos authentication for Web traffic. Let’s keep that in mind while I try to unravel the reasons. To do so, and still make some sense, I have to start by explaining (quite) a bit about Kerberos and how it works. For any of you who are familiar with Exchange probably recognizes the Exchange Alternate Service Account (ASA), this is the Exchange equivalent of the Lync Kerberos Account. This is going to be a long post, and much won’t be specific to Lync, but I believe it’s worth reading and I believe people need to start deploying the Lync Kerberos Account.
Kerberos is complicated and most often you don’t have to care much about it, because it all happens automatically under the hood. While it’s great that it works automatically (most of the time) it shouldn’t be overlooked as it’s very important. It is the preferred authentication protocol for Windows. Most services that you access daily on your LAN are accessible to you because you have authenticated using Kerberos. Lync is no exception, it wants to use Kerberos as much as possible, if you’ll let it.
Today there are three commonly used authentication protocols in Windows. There’s basic authentication which, by itself, offers no security at all, that’s right, no security at all. Then we have NTLM, which was the preferred authentication protocol in pre-Kerberos times. It is still widely used today, because unlike Kerberos authentication, it doesn’t require that the authenticating client has access to a Domain Controller. This is the reason internal Lync clients try to authenticate using Kerberos and external clients fall back to NTLM. Finally, we have Kerberos.
If you aren’t interested in how it works and just want to deploy the Lync Kerberos account there is a TL;DR almost at the end of the post.
Great, you’re still reading. It gets a little complicated but I will do my best to explain it as simply as I can without omitting very important things.
Kerberos
Kerberos is an authentication protocol that is based on tickets that allows users and computers to authenticate in a secure manner over a non-secure network. The tickets that are used to authenticate never contains any passwords which means that a users password is never sent over the network. It uses symmetric key cryptography and requires a 3rd party that is trusted by the entity that is authenticating and the one that requires authentication. This 3rd party is the KDC (Key Distribution Center). In the Microsoft world this is the Domain Controllers. The KDC knows the secret key for all users and all computer accounts. All secret keys are a salted hash of the account password. The KDC is also trusted by all domain members, meaning that it can validate all tickets and any ticket issued by the KCD is trusted by all domain members. This is very important as we go on. As mentioned above Kerberos is based on tickets. There are different types of tickets and they are used for different things. To access a service you need a service ticket, a service ticket proves your identity to a computer that is running a service. To get a service ticket you need a Ticket Granting Ticket (TGT). To get a TGT you must authenticate yourself to the KDC.
In the following example a user wants to access an OWA (It’s a little easier to use as an example than Lync). The whole authentication process starts when the user logs on to the workstation.
The user signs in to the workstation, when they do, the workstation will contact the KDC and request a Ticket Granting Ticket (TGT). The requests consists of a plain text part which includes among other things, the username. A portion of the request is encrypted with the users password. This is called the Authentication Service Request (AS-REQ).
The KDC receives the request and inspects the plain text part where it can see who is this person claiming to be. It then looks up the user and in it’s database where it also finds the users secret key. It uses this secret key to decrypt the encrypted part of the message. If it’s able to decrypt the message it knows that the user is who they claim to be (or at least that the person is using the correct password). Now that the Domain Controller knows who the user is it will go ahead and respond with a TGT. This TGT contains information about the authenticated user and is encrypted with the KDC’s secret key which is not known to the workstation. It stores this TGT in the memory, for the sake of this example let’s call it the Kerberos memory, for as long as it is valid (10 hours by default). The response itself is called the Authentication Service Reply (AS-REP).
Now remember that step 1 and 2 happened when the user logged into their workstation. Now the sequence continues when the user decides to access the OWA. This happens, let’s say, an hour later.
The user tries to access the OWA anonymously. The server responds with a HTTP 401 status code, meaning it requires authentication. In the response there is a header named “WWW-Authenticate” with the value of “Negotiate” which tells the client which type of authentication protocol to use. In this case Kerberos. The workstation looks in its Kerberos memory, where it will notice that it doesn’t have a service ticket for the HTTP service of the machine hosting the OWA. It then contacts the KDC again with a service ticket request. The request states which service the client wants to access. This is specified by including the Service Principal Name (SPN i.e. HTTP/exchange-cas01.contoso.com). The client also attaches the TGT it received in step 2 (from the kerberos memory) to the request. This is called the Ticket Granting Service Request (TGS-REQ).
The KDC receives the TGS-REQ from the client. It reads the SPN in the request and searches it database for a user account, or computer account, with a matching SPN registered. Now that the KDC has verified that the SPN exists, it also knows which account that holds that particular SPN. To determine who the user is, it decrypts the TGT using its own secret key (the same it used to encrypt the ticket in step 2). If it successfully decrypts the ticket, it knows that it was issued by the KDC and therefore the content can be trusted. And the content contains… You’re right, it contains the users verified identity. Now the KDC knows which account that holds the SPN (the Exchange CAS) and the user who wants to access the service. It then responds to the TGS-REQ with a service ticket, which it encrypts with the secret key of the account that holds the SPN. The workstation then receives the service ticket. Note that since the service ticket is encrypted with a secret key unknown to the client, it cannot read the encrypted part of the ticket. The client stores this ticket in the Kerberos memory for as long as it’s valid. The response is called the Ticket Granting Service Reply (TGS-REP).
The workstation now connects to the OWA. It includes the service ticket, taken from the Kerberos memory, and uses it in the “authorization” header of the HTTP request.
The web server hosting OWA receives the request and inspects the authorization header. It extracts the service ticket and attempts to decrypt it using its own secret key. If it can, it means the KDC has encrypted it and it’s content can be trusted. From the ticket it is able to extract the users identity and their group memberships. The request is then authenticated and the user is served the requested contents.
I’ve made a small video that illustrates how the above example works
Important things to remember from the above example.
The server running the service (OWA) never contacted the DC. This means less load for the service and each client doing most of the job.
No password was sent over the network.
When a client has a valid ticket for a service it can be used as long as its valid, meaning no need to go through the authentication process again and again. Each request is authenticated but the client uses the same ticket.
The ticket sent to the service also includes group memberships which means authorization decisions can be made directly without contacting a Domain Controller.
NTLM
Now that we understand how Kerberos works (we do, don’t we?)… Well, at least we know the basics of how it works, which is enough for the scope of this post. Before we can get back to Lync we need to understand one more authentication protocol… I promise, its the last one for this post. We need to look into NTLM which is also used by Lync. Without understanding both protocols we can’t understand the pros and cons.
Unlike Kerberos, NTLM is not built on tickets. NTLM happens in three phases. These phases includes three different types, Type 1-3. So let use the same example as above. A client wants to access an OWA that is protected by NTLM authentication.
The client starts his browser and navigates to the OWA address.
The server responds that it requires NTLM authentication.
The client sends an NTLM Type 1 message that includes its NTLM capabilities.
The server responds with an NTLM Type 2 message that contains a generated challenge.
The client extracts the message from the server and uses it’s password to generate a Type 3 message that is sent to the server.
The server receives the Type 3 message, sends the Type 2 and Type 3 message to the DC.
The DC receives the Type 2 and Type 3 message. Validates the messages towards its database and responds back to the server with whether the user has successfully authenticated or not.
The server receives the responds from the DC and if it’s correctly authenticated it lets the client access the requested resource.
Seems a lot easier than Kerberos, right? Well, it has to do this for each request… Yes, each image, each JavaScript and each file… That’s not very efficient. There is NTLM authentication persistence that is meant to help with the above problem but it would work best with one CAS or only one Front End.
So after reading through the above we can quite safely say that we want to use Kerberos over NTLM where possible.
Load balancing
We’re getting closer now to the point of this post, the Lync Kerberos Account, and one of the reasons it’s considered best practice.
While a client dependant load balancing/fail over perhaps isn’t the most elegant solution, it makes it a lot easier to deploy. This works well for SIP traffic where the authentication is connection based. Meaning that when the connection is established and the user is authenticated the connection is kept open and marked as an authenticated connection. This way the client does not have to provide credentials with each request. There is one protocol which is not covered by DNS load balancing and still needs to be load balanced using a hardware load balancer, namely HTTP which is used for Lync Web Services. Lync Web Services is used quite a lot by the clients, which then risks falling into the NTLM trap mentioned above. Meaning each request has to be authenticated towards the DC. While this certainly works it’s not optimal at all. Why put more load on DC’s and network than necessary? Why use an inferior authentication protocol? There really is NO good reason.
How come it’s not deployed everywhere then? Because it works without deploying it and likely because Kerberos authentication is less well known and a little trickier to load balance. Hopefully it won’t be after reading this post.
While explaining Kerberos above I mentioned that it relies on SPNs to function properly. This is because tickets are encrypted with the key for the service that is known to the server hosting the service and the DC. In the following scenario we have lyncpool1.contoso.com that consists of three Front Ends (fe01-03.contoso.com). The overridden name lyncpool1-web.contoso.com DNS record points to the load balancer that is in front of all three Front Ends.
The client will connect to https://lyncpool1-web.contoso.com and from that name it will determine that it needs a service ticket for the HTTP/lyncpool1-web.contoso.com to which the DC will likely reply “no such service principal” because no such SPN exists. On some installations I’ve seen that the SPN does exist in one of the following configurations.
Registered to each Front End Servers computer account. This breaks Kerberos. Each SPN must be unique.
Registered to one Front End. This doesn’t break Kerberos but can’t be load balanced. When a client goes to the load balancer with a valid kerberos ticket and gets directed to a Front End that doesn’t have that SPN registered, it will fail. As you can see in the image below the client’s Kerberos ticket is issued to HTTP/lyncpool1-web.contoso.com. The request ends up at FE01 which does not hold that SPN.
So, what to do? Enter the Lync Kerberos Account!
The Lync Kerberos Account
The Lync Kerberos Account is a really smart idea that makes load balancing Kerberos for Lync Web Services a non-issue. Essentially it’s a computer account. When created it’s just that. Now comes the special part; when you assign it to a site the correct SPNs are registered to that account and all Front Ends in the site become aware of the account and can use it for authentication purposes. This means that each server in the pool knows the secret for that account that then can be used to decrypt Kerberos tickets. This also means that whether the client ends up at FE01, 02 or 03 it doesn’t matter because the ticket it sends is encrypted with the service key for HTTP/lyncpool1-web.contoso.com which all of them can decrypt and read because they have the secret key of the Lync Kerberos Account.
TL;DR Kerberos is an authentication protocol based on tickets. It’s better than NTLM. Always deploy the Lync Kerberos Account.
Now that we’re all on the same page (hopefully), how do we deploy this account? It’s quite simple.
First we need to create the account itself. New-CsKerberosAccount -UserAccount "Contoso\KerbAuth" -ContainerDN "CN=Users,DC=contoso,DC=com"
Then we need to assign it to our site. New-CsKerberosAccountAssignment -UserAccount "Contoso\KerbAuth" -Identity "site:Contoso"
Enable the topology Enable-CsTopology
Set the password for the account. Do NOT skip this step. Set-CsKerberosAccountPassword -UserAccount "contoso\KerbAuth"
And that’s it! The account is deployed. You can verify that the correct SPN’s has been added to the account by running. setspn -L KerbAuth
Verify that you can see the overridden internal Web Services SPN in the list (HTTP/lyncpool1-web.contoso.com). Also make sure that the DNS A record for lyncpool1-web.contoso.com is pointing to VIP on your load balancer for internal Lync Web Services.
If you receive client pop ups after you have enabled the Lync Kerberos Account it means you have missed something in the configuration.
You can verify your Lync Kerberos Account configuration by running the following command from the Lync Server Management Shell. Test-CsKerberosAccountAssignment -Identity "site:Contoso" -Report "c:\temp\KerberosReport.htm" -Verbose
I know this has been a long post, hopefully you found it interesting. Thank you for reading.
Techmikal 