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.
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 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.
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.
So after reading through the above we can quite safely say that we want to use Kerberos over NTLM where possible.
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.
Updated 12/6 – Added answers to some questions at the end.
Time for another blog post! As promised, on twitter, I’ll give you all some more information about pre-authentication and device partnership but first I would like to give a little background to this functionality.
Our first solution for Lync 2013 (described in the Lync active two-factor authentication post) raised the security bar considerably, especially by providing an application specific password and the option to use two-factor authentication without the need for passive authentication.
This done, we still felt that we wanted to do even more to further enhance the security. Coming from the security field, one of the things I dislike about Lync is the fact that the reverse proxy just passes the traffic anonymously to the Front-End server for external clients. That combined with the fact that we already built a reverse proxy (PointSharp Mobile Gateway) specialized for Exchange ActiveSync made it quite clear what we needed to do.
So we set out to bring some of the most popular features that we have for Exchange ActiveSync to Lync 2013, namely user/device partnership and pre-authentication. This resulted in an extended Mobile Gateway with specialized support for Lync 2013.
The authentication is moved from the trusted LAN to the DMZ. This means that authentication takes place on the Mobile Gateway and requiring a successful authentication before passing the traffic to the Lync Front-End. The authentication used is NTLM and it support application specific passwords as well as two-factor authentication. An authentication request is then sent to PointSharp ID that verifies the credentials and decides whether to accept or reject the user. Just to be clear, this has nothing at all to do with passive authentication.
User/device partnership. So what does this mean? Simplified it means that only the correct user with the correct device is allowed to use the service. The device is registered to the user so that if the credentials are stolen they cannot be used without the correct device. What it does is that it inspects the device when it has authenticated and sends an authorization request to the PointSharp ID server which then tells the Mobile Gateway whether the device should be accepted or rejected. Apart from this it is also possible only allow certain types of devices as well as limit the number of devices that can be used.
I know this is mostly an overview that does not go into all technical details but I wanted to keep my twitter-promise and give you all some more information on the subject. More will surely come.
I also have to add; Designing, developing, testing and generally working on this project with all my fantastic colleagues has been great and extremely rewarding.
I also want to give a special thanks to Tom Arbuthnot (@tomarbuthnot) and Graham Cropley (@grahamcropley)for answering my desperate questions on twitter!
* Update 12/6: I received questions regarding how this affects clients, if any special client is needed and whether Mobile Gateway takes over the reverse proxy role. The answer is no, no special client is needed and the clients are not affected in any way. The Mobile Gateway is a reverse proxy, therefore no other reverse proxy is needed.
Twitter and blogs have been buzzing about the update for the Lync mobile client for android. It was released on the 12th of May and demoed on the same day by Modality System’s Justin Morris (@justimorris) at this year’s TechEd NA.
The update includes the following features:
– Tablet support
– Add participants into an ongoing conversation (IM or Lync Meeting)
– Start an ad-hoc group conversation
– Bug fixes
These are great changes to the android client, bringing its functionality closer to its Windows Phone and iOS siblings. You have most likely read this already since it has been all over the Internet. So why am I writing yet another blog post about this? Well, the simple answer is that this update contains more than meets the eye. Specifically there are two changes that I find particularly important.
– Security improvements through tightened SSL validation.
– Authentication protocol changed to NTLM
While these features might not sound as shiny and extravagant as the previous list they are very important from a security perspective.
Any change to strengthen the validation of certificates is a good change. The tightened SSL validation means that the client must be able to validate the certificate and its chain. A valid certificate must therefore meet the following criteria’s:
• Certificates cannot be expired.
• The certificate chain must be validated, and certificates must meet one of the following requirements:
o Certificates must be trusted (that is, signed by a trusted authority).
o Certificates (and chain) have to be installed on the device.
• The DNS Name certificate property has to match the URL.
The second feature much appreciated. I spent the entire TechEd EU 2013 asking presenters and Microsoft employees why the Android client was sending its credentials in clear text (no, Base64 is not encrypted, it’s encoded) while the other mobile clients used NTLM. I never got an answer. But with this update the authentication protocol for the Android client has changed to NTLM which means that no more credentials are being sent in clear text.
Last night James Cussen, from the well known blog My Lync Lab, released a wireshark plugin for Lync to be able to decode even the “specialties” that Microsoft has added to protocols that Lync uses. I just tested it and it works great! A handy tool for any Lync professional. You can get it here: http://www.mylynclab.com/2014/05/microsoft-lync-wireshark-plugin.html and I also recommend that you follow him on twitter (@mylynclab).
A short post, but I really wanted to share this. Now back to my reverse proxy testing for Lync 2013.
Hello everyone. Time for another blog post. As you might have noticed, if you have read my other posts, I have been very focused on the security aspects of Lync. Today’s post is not any different in that aspect but it will focus on the standard Lync web service configuration when using any two-factor authentication for Lync.
As you probably know most Lync clients retrieve a certificate upon a successful authentication towards the Lync front-end server. This certificate, like any, has a validity time and by default this is set to 180 days. If we take a step back and analyze that we can clearly see how that doesn’t go well with two-factor authentication. We implement two-factor authentication to raise the security bar and most importantly to be absolutely sure that the user logging in to our Lync really is who he or she claims to be.
A user signs in using two-factor authentication. Then Lync provides the user with a one-factor authentication (the certificate) to be used for upcoming authentication purposes for 180 days. Kind of defeats the purpose to demand one two-factor authentication for 180 days. The tricky part is that upon an authentication the user is first given a webticket (by default valid for 15 minutes for external users and 8 hours for internal users), this webticket is then used as authentication to get the certificate. This certificate can then be used to get a new webticket and yes the webticket can then be used to get a new certificate… See where this is going?
So what can we do? Well first and foremost we can change the validity time of the certificates that Lync creates. The following command shows your current configuration.
This will not stop a client from using either the webticket or the certificate to renew itself, however the time frame is much more limited. This is important because, from my experience, only the PC client is able to keep signed in for a very long time (if kept powered on and never is rebooted). The mobility clients are often in sleep state where this “renewal” does not happen and as such they are prompted for the two-factor again.
I’ve met quite some Lync customers that has a policy that state that the Lync PC client has to connect over VPN to get Lync access. Quite a nice policy.
Hello everyone, time for another post. A post that won’t be showing you how to do something technical but hopefully something that, if nothing else, can start a discussion. Don’t worry, more technical posts will follow.
I have started getting quite some questions about Lync mobility, both in my daily work and through other means such as this blog. There seem to be a lot of Lync deployments that haven’t deployed mobility. It seems that security departments are reluctant to allow it.
If you are or have been in this situation you probably recognize one or more of these arguments:
– We can’t allow storing of domain passwords on mobile devices.
– Our policy requires the use of two-factor authentication for external access.
– We don’t want to expose infrastructure if we can’t limit it to certain clients.
Those are the most common I come across and they are all valid points. Those are the arguments I would use myself. In fact, they are excellent arguments and should be asked by any security department. The thing is that you can fulfill all these requirements for Lync.
You can use an application specific password or you can use 2-factor authentication and you can limit the clients accessing Lync from the outside.
What I’m getting at here is that Lync is truly a great application (but you already knew that) and while mobility might just be a small part, it is an awesome part. Don’t cripple your Lyncers, empower them!