Microsoft Lync/Skype for Business has revolutionised the way people can communicate and collaborate in the workplace. With light weight and portable form factors coming into their own, devices have enabled businesses to rethink their communication strategy. Lync not only enables users to communicate using great device form factors, but also from wherever they may be located. The sense of a roaming lync identity brings freedom to how people choose to collaborate and office spaces, desks and name tags mounted above them, seem like a necessity of the past. The enablement of remote connectivity across these devices is pivotal in a Lync deployment, but sometimes isn’t entirely understood. In some circumstances security is of high concern for all forms of connectivity that can be done over the public internet, but you wouldn’t want to go without it. To remove remote access for users would be crippling the UC strategy that you were trying to put in place.
When we think about Lync/SFB with external authentication we first must articulate that there’s more than one form of authentication a user can attempt and there is many device types they can attempt authentication with. Therefore it can also be said that there is more than one endpoint and port on the edge of the corporate network listening, waiting and proxying these forms of authentication. What we need to do is make sure that each case is in a controlled and known measure to best suit your deployment.
Question: “So Arran what is secure?”
Answer: “Well the security policy should govern what is and isn’t classified as secure for you.”
The common device(s) attempting authentication are:
- Lync Office Client
- Mobile/Tablet app
- Windows 8 Store App
With these authentication types:
- NTLM
- TLS-DSK
- Passive (ADFS)
We aren’t going to talk about Kerberos cause we are concerned with external logins.
NTLM
NTLM is usually well understood as a simple challenge/response authentication but if we look at it in Lync it means that every time a web ticket expires the same challenge authentication must be presented. Usually to make this simple to the end-user we allow them to cache/save the password to the device for re-authentication on our behalf.
TLS-DSK
NTLM will generally be a big ‘NO’ straight away if these conversations have started with a security team, so let’s look at Transport Layer Security Derived Session Key (TLS-DSK) as a certificate based authentication. Every Lync Front End Server is issuing a Lync User Certificate upon initial successful authentication and once the certificate is saved, the stored AD Credentials aren’t needed for the validity of the certificate which can range from 8 hours to 365 days (your choice). A key point to make about TLS-DSK is that if I have multiple devices I will receive my certificate for each. I will then use my certificate on each device to authenticate to Lync as me. Additionally the certificate I have stored is only trusted by Lync, not my entire domain or ADFS and can’t be used across other application or services.
TLS-DSK allows us to move away from the simple challenge authentication and subsequent re-authentications all together.
TLS-DSK is great!
By disabling NTLM on external registration (shown in the diagram above with Green – Internal and Blue -External) we can then understand that a client has to have obtained a Lync certificate from the internal Front End Servers when on-premises and not provisioned through an Edge proxy. The certificate can NOT be issued from external locations due to the authentication process breaking when the client requests a web ticket to start the process. Currently Skype for Business does not do this natively. The client NTLM authentication against the web services is via the Simple URLs which is controlled via a Reverse Proxy. Currently there are only a few out the box solutions for this, Lync Solutions and Skype Shield are worth investigating.
If you go the extra mile to not allow NTLM authentication from your external network, you are then protected via additional forms of on-premises security;
- The individual has gotten physical access to a site location through a perimeter locked entrance
- The individual has gotten network layer 2 connectivity with a device on a access switch
- The individual has an approved domain joined computer to gain access to domain services on the appropriate VLAN
- The individual has supplied correct credentials of a provisioned Lync user account.
Sounds like a job for Tom Cruise hanging from the roof if you ask me. The end result is a Lync user certificate in the user store of the trusted machine. We should now be happy for the user to go out in the world with this device knowing that themselves and the managed device are who we think.
Passive
What if you would NOT like Lync to do any authentication.
“I have a centralised authentication services called Active Directory Federation Services (ADFS) and I would like to use it with Lync”.
Lync can be integrated with ADFS as your Secure Token Service (STS) and also provide a second factor if needed. You can then leverage forms based authentication or smart cards. There are a few tricks to enabling Lync Server with passive authentication, first of all to enable passive we must disable all other forms of authentication. As this is a ‘big bang’ approach to effectively disable all other authentication protocols per pool make sure you plan and test appropriately.
Lync Mobile Clients
Lync is a free download in each of the mobile stores and we can’t control if a trusted or untrusted device downloads it. So for our external access of the Lync 2013 mobile client we must feel comfortable with the authentication, which comes in the 3 forms that are available;
- NTLM
- Lync Certificate
- Passive
NTLM once again maybe too basic to meet our requirements and we need to look at what else is on offer, James Frost has a great comment at the bottom of this post about products that can be used. As James points out that the certificate web service URL is exposed to the internet via the reverse proxy you are using. Depending on what type of device you are using will indicate what might be possible for you to achieve with validation of approved devices or authentication attempts. The reverse proxy is breaking the connection from front to backend and this is a perfect time to inspect it if necessary. ADFS can be a big leap just to comply with remote authentication with the Lync app, instead we can protect our users and devices via whipping the initial NTLM credentials from the devices disk and memory via PowerShell mobility in band provisioning policy;
[code]
Set-CsMobilityPolicy -AllowSaveCredentials <$true/$false>
[/code]
We can also disable EWS requests which does simple NTLM requests to exchange inside the app also;
[code]
Set-CsMobilityPolicy – AllowExchangeConnectivity <$true/$false>
[/code]
Where does the authentication happen?
When I stated that there is “more than one endpoint on the edge of the corporate network, waiting and proxying these forms of authentication” this is because clients behave differently. Lync Office Client directs its authentication requests to the Lync Edge servers with SIP over TLS, while all mobile device apps will use a reverse proxy that has a published URL rule as all its signalling traffic is SIP over HTTPS while on a 3G/4G data network. So there is more then one ingress point for authentication to monitor. The Edge Server is inspecting all packets, while a Reverse Proxy can inspect the HTTPS traffics as it’s also splitting the traffic from frontend to backend.
Summary
Options are available to change the way Lync can authenticate to your network. A greater understanding of the authentication endpoints, protocols and flows will aid you in being on top of your environment and smoothly rolling out external devices that are secure and trusted.
Great information. Thanks for sharing.
What happens when a non-domain joined computer tries to join into a Lync meeting while on your internal network (so its hitting the FEs directly, instead of the Edge servers)?
The user will authenticate to the internal web services via NTLM (1st time), Certificate and away they go.
Hi Arran,
Nice article. I would just clarify your point about blocking NTLM on the Edge server preventing external access to the S4B environment without the machine having first obtain a certificate when on-premises.
At a customer deployment I was involved a while ago (Lync 2010), I went through the process of blocking down NTLM on the Edge, but subsequently found out that the cert provisioning web service (published through the Reverse Proxy) is what actually issues the cert in the first place. Therefore any strategy to block issuing of new certificates to external users actually has to take into consideration the reverse proxy component as well.
I validated this at the time with Rui Maximo, creator of the Lync Security filter – a 3rd party Edge filter which blocks NLTM and DDoS attacks – who confirmed this was the case, and that his product would be updated to include a Reverse Proxy component to prevent this specific threat. I believe LyncShield another 3rd party solution also mitigates this risk by including a custom Bastion reverse proxy server.
The described behaviour may be different in Skype for Business, I’m not sure.
Great comment James, thanks for your input. I will update accordingly.
Arran, fantastic swim lane diagrams! Makes the authentication scheme easily understood! Thanks!
Hi Arran,
Great article ! Thanks for the given details.
Does anyone have news about the “Security Fitler” of Rui Maximo ? Is it compatible with S4B 2015 Edge Server ? Because it solves a big issue by preventing from internal Active Directory account locking !
Thank you,
GH
Hi GreyHat,
I believe it does
http://mbcorp-public.sharepoint.com/SitePages/Products/edge-filter.aspx
The installation guide clearly talks about Skype for Business Edge Servers.
LyncShield also supports SfB 2015 Edge servers as well as Front end servers. We’ve been using them for a while and upgraded to SfB recently.
Hi,
We have a problem with SfB 2016 client. It is asking for Exchange credentials. We see the message on a domain joined machines running externally (outside of the office) when the VPN is NOT used. When the domain user is on a VPN connection at home everything is OK. After OS reboot, when the domain user logs into his laptop OS (domain joined, with cached credentials) at home and he is NOT using VPN, Exchange needs your credentials message appears.
Client side is Win7SP1, Outlook16, SfB16, computer is domain joined.
Another important thing is that there are NO credentials in a Windows Credential Manager under Generic Credentials
In Skype client configuration information, Exchange URLs are OK. EWS Information is EWS Status OK. But UCS Connectivity State is Exchange connection DOWN.
We see this when we HAVE Exchange credentials error message.
Server side is Exc13 and SfB15 server with configured integration between them. Only Unified Contact Store feature is used. We are NOT using Exchange Unified Messaging and Outlook Web App feature. SMTP and SIP domains are the same.
After weeks of troubleshooting, reading dozens of articles (with comments!), level 400 client sign-in deep dives and checking again configuration of Exchange, Skype server and Windows client and trying different settings, issue is narrowed down to NTLM over HTTPS authentication from the client side. What I see now in a Fiddler trace on a client side is that the Skype client is requesting from EWS (https://mail.domain.com/ews/exchange.asmx) a lot of things like GetUnifiedGroupsSettings (remember that one), ConvertId, FindFolder, GetImItemList, GetFolder, FindItem, SyncFolderItems and Subscribe in a dozens of XML messages. Most of them are rejected by EWS with result 401 anonymous request disallowed. Some of them are answered with 200 OK. One of them (GetUnifiedGroupsSettings) results with 500 Internal Server Error (XML RequestServerVersion Version = ”Exchange2015”, XML response ErrorInvalidServerVersion). Now, when I look for the Authentication part in each message (not in 200 results) I DO SEE NTLM challenge/response with the correct domain user and pass, but ONLY for the first request GetUnifiedGroupsSettings answered with 500 result. In all the other 401 results Skype client is not even trying to send NTLM Authorization Header with Negotiation type.
Is it possible that the Skype client does NOT know a logged on user and pass?
If I just open Exchange credentials prompt and hit cancel Skype client WILL authenticate to https://mail.domain.com/rpc/rpcproxy.dll?… with correct user, but the Outlook integration ERROR still remains.
If I type in the user and pass in Exchange credentials prompt and do NOT hit save everything will be OK.
If I type in the user and pass in Exchange credentials prompt and hit Save my password everything will also be OK and those credentials will be saved in Credential Manager under Generic Credentials. That will create another problem in the future, because, when the domain password is changed Generic Credentials will NOT be updated with new password and Skype client will use that saved (cred man) outdated password for Exchange authentication (EWS will start responding with 401 unauthorized and Exchange Security log will show Failed log on with bad password reason).
I somehow believe that Skype client have enough data in order to authenticate to EWS so users do not experience Exchange credential prompt. For GetUnifiedGroupsSettings request Skype was able to authenticate with correct user and pass. Another argument is the Outlook client. Outlook is able to authenticate without prompts. Maybe he is keeping user and pass in the local Outlook profile. Why is Skype client not using existing credentials (from security hive or LSASS) for subsequent authentication to EWS? (just the first request) I know he is using TLS-DSK with Web Ticket Service for Skype server. Can we use TLS-DSK on Exchange server?
Did you get this solved? if so, how?
Great article ! A lot has been explained. Huge thanks!!!
Since external user would hit the reverse proxy based on Lyncdiscover. record and then the traffic would be forwarded to the front end pool. where does it leave the edge server in terms of authentication?
Arran,
Just to keep it for everbody clear :
DisableNtlmFor2010AndLaterClients
UseCertificateForClientToProxyAuth
UseKerberosForClientToProxyAuth
UseNtlmForClientToProxyAuth
Running this against Edge server HAS no effect.