Lync Android client updated

Posted on December 12, 2014 by techmikal

Today Microsoft released an update for its Lync Android client. This new release brings some quite significant changes.

* Support for Passive Authentication
* Support for certificate authentication

These two changes brings the Android client up to speed to the other mobile clients when it comes to authentication. This is a necessary step to support Android as a full fledged mobile client.

* Contact management
This option is only available in the cloud… Which is a little dissapointing but fear not, it will be available in the next on-premise version.

One of the minor but very appreciated difference in this new version is that the calendar is changed to cover more days than just today.

What are you waiting for? Go grab it at the store.

For more information: http://blogs.office.com/2014/12/11/new-android-lync-features-anonymous-join-passive-authentication-contact-management/

Lync Day 2014

Posted on October 16, 2014 by techmikal

Hello everyone, it’s been quite some time since I last posted due to the fact that my schedule has been crazy the last couple of months. It still is and its filled with Lync so that is great but I will try to update more often.

So as an easy come back I’m going to share my thoughts on Lync Day 2014 which was held in Oslo by Ståle Hansen and the Knowledge Factory team. I attended the event as an exhibitor but I still had the chance to attend some of the sessions. More on those later in the post.

The event as a whole was a success I must say. Speaking to various attendees gave me the impression that it was a much appreciated event with very interesting sessions and professional speakers. Well, talking about speakers… There were at least 6 MVPs that had their own session. On top of that the UC architects did a live recording which included even more MVPs. Suffice to say the speakers knew what they were talking about.

I had the pleasure of attending two sessions.
First up was “Lync Mobile sign in process and media flow” with MVP Tom Arbuthnot as speaker. This session was really interesting for me as it is one of the areas of Lync that I’m very interested in. Tom did an excellent job of explaining how it works, what to think of when deploying mobility and even pointing out some typical pitfalls in deployment and troubleshooting.

Then I went on to “SIP and media in Lync explained” by MVP Johan Delimon. This was a deep dive into the SIP protocol and how it works in Lync. Johan was very thorough in his explanations. I must say all the examples from snooper was much appreciated where he could show us the SIP dialog and also how SDP works and helps the clients decide which codecs to use.

Last but not least by any means I went to the live recording of the UC Architects podcast with Pat Richard as the host. It felt like a privilege to be present during the recording. It was also great to see how relaxed the discussion was. I guess most of the panel are very used to talk in front of the masses but it still impresses me how professional they were while still keeping it relaxed. Before the end of the podcast Steve Goodman summarized the day saying “I had a good Lync Day today”, I think that was spot on.

I big thanks to Ståle for arranging this event, I hope there will be a 2015 version.

Device partnership and pre-authentication for Lync 2013

Posted on June 11, 2014 by techmikal

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.

Lync mobile update for Android – More than meets the eye

Posted on May 14, 2014 by techmikal

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.

This means I must update the table from my first blog post about the Lync authentication process to reflect this.

Client	Authentication protocol
PC-client (internal network)	Kerberos
PC-client (external network)	NTLM
Windows Phone	NTLM
iOS	NTLM
Android	NTLM (Versions prior to 5.4 use SOAP)
Lync Web App (domain user)	SOAP
Lync Web App (guest)	SOAP (Anonymous)

It should be noted that the Android client still doesn’t request a certificate like Windows Phone, iOS and the PC client does. Perhaps in the next update!

As always, thank your for reading. I hope you enjoyed the read.

Listen to your edge – Lync Wireshark Plugin!

Posted on May 8, 2014 by techmikal

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.

Lync certificates and two-factor authentication considerations

Posted on April 22, 2014 by techmikal

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.

Get-CsWebServicesConfiguration |DefaultValidityPeriodHours

DefaultValidityPeriodHours : 4320
By issuing the following command you set the validity period to 8 hours.

Set-CsWebServicesConfiguration –DefaultValidityPeriodHours 8

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.

Before wrapping up I would like to take a second and thank Graham Cropley (@grahamcropley) for an excellent blog post about Lync certificate provisioning and beyond – http://www.lyncexch.co.uk/lync-certificate-provisioning-service-deeper-dive/.

Thanks for reading! Stay tuned for more.

Lync mobility – One small step for Lync, a giant leap for Lynckind

Posted on March 14, 2014 by techmikal

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!

Have a good weekend!

Lync active two-factor authentication

Posted on March 13, 2014 by techmikal

Hello everyone (and a special hi to Tom if you’re reading this)!

As I mentioned in my post about increasing lync security there is another option to enable two-factor authentication or application specific passwords for Lync, apart from passive authentication. For most of you who attended Lync conference 2014; you have most likely already heard of this option. Why do we need another option? Well, for some organizations this option might be a better fit. There are some limitations to the passive authentication solution that this option does not have; like the below examples.

Passive authentication is site wide
When Lync passive authentication is enabled, it is enabled site wide, more correctly it is set on the Lync web services level (Get-CsWebServiceConfiguration).

Exchange integration is not supported
The integration between Lync and Exchange is lost which in turn means that features are lost in the clients, for instance the meeting calendar.

Client support
Some clients does not support passive authentication such as the Mac client or several conferencing hardware products.

AD FS must be deployed and configured
While this isn’t a problem itself, it is quite a task to add to a Lync deployment if AD FS is not deployed already within the organization.

Enter the PointSharp authentication module. This is a third-party solution that integrates into the Front-End server’s IIS and takes over the authentication of the users. To get a bit more technical this solution protects the Webticket application externally and/or internally by presenting either a custom NTLM authentication or a SOAP based authentication. It uses the Windows APIs to create a Windows identity and then presents a valid user token to the Lync server.
While keeping the Lync sign-in experience intact it provides the option for an application specific password or a true two-factor authentication using tokens.

I was asked to do a demo with Lync and two-factor authentication without using domain passwords and in this case the passive authentication was not an option. There was also a requirement that only external clients have to use two-factor authentication. On top of this they also wanted to make use of the EWS integration. To get all this working I had to get a little creative. Let’s walk through it!

I’ll start with a network overview as I believe that will make my ramblings easier to understand. For those of you who read lync passive authentication with two-factor authentication will recognize the image with some small changes. Specifically that the AD FS server is gone and an Exchange server is added for Exchange web services integration.

First I had to install the authentication module on the Lync Font End server and configure it on the WebTicket web application on the Lync external web site. The configuration is done in the IIS management console and basically consists of pointing out the authentication server, to use NTLM and enable Lync support. Lync part done, on to the exchange integration.

Since the Lync client uses the credentials entered for both the access to Lync, Autodiscover and EWS all three had to accept the authentication being sent by the client (yes, I know there is an exchange credentials option but it isn’t very user friendly). I didn’t want to “disturb” any internal clients so I used the same approach as Lync does and created an external website on one of the CAS servers. I configured the bindings to be host based using a name that isn’t DNS resolvable on the LAN.

I then learned the hard way that creating new virtual directories for the autodiscover and EWS service by default points them to the same location as the original one, meaning that changes made on the external web application is also set on the original one. You don’t want to do this, trust me.

So instead I needed to create new virtual directories, completely separated from the original ones. I first copied some directories.
C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\ews -> C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\ext-ews
C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\autodiscover -> C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\ext-autodiscover

Then I created the virtual directories using the –Path switch.
New-WebServicesVirtualDirectory –Server cas01.domain.com –Path “C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\ext-ews” –ExternalUrl “https://ext-ews.domain.com/EWS/Exchange.asmx”

New-AutodiscoverVirtualDirectory –Server cas01.domain.com –Path “C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\ext-autodiscover”

Then I installed the authentication module and used the same configuration both virtual directories as I did on the Lync server, except that I didn’t enable the Lync features.

When this was done I had to configure the ARR to handle requests for the EWS and autodiscover and proxy these request to this newly created external web site on the CAS. First and foremost I had to add ext-web.domain.com to the host file of the ARR and point it to the IP-address of cas01.domain.com.
Then I created two new server farms, one for autodiscover and one for the EWS.

autodiscover.domain.com -> ext-web.domain.com
ext-ews.domain.com -> ext-web.domain.com

I also needed the ARR to rewrite the host header to match the configured binding. This is done in the URL rewrite module.
First I had to add a server variable named HTTP_HOST. Then I edited the autodiscover rule to rewrite the header like in the image below.

After this I did the same host rewrite change to the EWS rule and I was all set! The demo went perfect and everyone who does demos knows how good it feels when everything is spot on.

Phew! long post, I guess i need one of these.
TL;DR I configured stuff, made Lync authentication more secure, demo went perfect.

For those of you who actually read all of it; thanks for your time, I hope you enjoyed it!

Lync Passive Authentication with two-factor authentication – Part II

Posted on February 27, 2014 by techmikal

* Updated 2014-04-17
Added two-factor authentication explanation and updated the image showing the mobile sign in experience. Thanks to Shawn Harry (@shawnharry on twitter, you want to follow him) for pointing this out

Welcome back to part II in this series about “Lync Passive Authentication with two-factor authentication”. In part I we looked at the configuration of passive authentication both on the Lync server and on the AD FS side. Today we’ll take a look at how to add two-factor authentication to this.

Lync passive authentication cannot do two-factor authentication by itself. It relies on AD FS to do the actual authentication. In turn AD FS requires a third-party authentication solution to bring two-factor authentication to the table. Let’s set the table!

First we need to set up a Security Token Service (STS) that can do the authentication and get the correct claims and pass them to the AD FS which in turn will send us to Lync with claims that is trusted by the Lync 2013 server. In this setup I’m using PointSharp Identity Federation which includes an STS which I have installed on the AD FS server. Please note that the actual STS configuration depends on the STS you use but it should be similar for many.

The configuration of this STS is done in the IIS Management console in a “snap-in” on the PointSharpSTS web application.

There’s a few settings you need to configure for this to work. In this case we need to tell the STS where the authentication server is, which authentication method to use, who the issuer of the claims is, the URI of the issuer, the relying party URL and a signing certificate that the AD FS trusts.

By looking at the above image and at the network topology image from part I of the series you will know what names should be put where. In my case the STS is installed on the AD FS server itself so the certificate used for signing the claims is the same as the AD FS uses.

We also need to configure the claims the STS should create and pass on to the AD FS. Lync 2013 wants the primarySID claim. In this case we tell the STS to collect the attribute values of userPrincipalName and objectSID from the authenticated user and send the values as claims to the AD FS.

The next step is to tell the AD FS that the STS is a trusted claims provider. The steps to do this differs a little between different STS’s. You can either use the <code>Add-AdfsClaimsProviderTrust cmdlet<code> in powershell or the AD FS management console. In my case the only thing I had to do was to point out the URL to the STS and give it a name (PointSharp ID in my setup for reference).

When the STS is added it will be listed as a claims provider. We now need to make a claim rule to pass the primarySid claim through. This can be done in the management console but the below example is for powershell.

1. Create a text file on your AD FS server using your favorite editor and paste the lines below into it.
@RuleTemplate = "PassThroughClaims" @RuleName = "Pass through primary SID" c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid"] => issue(claim = c);
2.Save the file as C:\ClaimsProviderRules.txt.
3. Start Windows PowerShell.
4. Attach the claim rule to the claims provider.
Set-AdfsClaimsProviderTrust –TargetName "PointSharp ID" -AcceptanceTransformRulesFile "C:\ClaimsProviderRules.txt"

The final step is to force users who want to use Lync to use the STS that we just configured. This is done by modifying settings on the relying party which is the Lync server.
1. Start PowerShell on the AD FS server
2. Modify Lync relying party (note that “PontSharp ID” is the name of my claims provider in the AD FS console).
Set-AdfsRelyingPartyTrust -Targetname Lync-Ext -ClaimsProviderName @("PointSharp ID") Set-AdfsRelyingPartyTrust -Targetname Lync-Int -ClaimsProviderName @("PointSharp ID")

The table is now set and this is what it looks like when the dinner is served:

Lync mobile client:
1. Enter SIP-address.
2. Enter username and app-password (not domain password)
3. Enter a valid OTP (One-Time Password)
4. Logged in!

In the above example a hardware token was used to generate the OTP that provides the second factor in our two-factor authentication. As Shawn mentions in his comment, an SMS could also be used to provide the OTP.

Lync PC-client:

The sign in process is the same as on mobile clients, only the graphics differ.

I hope you have enjoyed this series about Lync passive authentication with two-factor authentication”. This part concludes the series but stay tuned for more Lync security.

Exchange 2013 SP1 released

Posted on February 26, 2014 by techmikal

Yesterday Microsoft released SP1 for Exchange 2013. Apart from bug fixes this release brings new interesting features. Some of them stand out a bit more.

S/MIME support in OWA
Finally the OWA will support S/MIME encryption. This is a much needed and sorely missed feature from Exchange 2010. For me it’s an absolute requirement for any Exchange client I use. Excellent!

AD FS claims support for OWA
This means that the OWA will have support for claims based authentication. This was possible in 2010, but I don’t think it was a supported configuration.

MAPI over HTTP
A new protocol has been released and it seems like it will be the default protocol for Outlook. You probably remember MAPI from older Exchange versions but it could not be transported using HTTP. The only way to use HTTP was to use Outlook anywhere which uses RPC over HTTP. In Exchange 2013 Outlook clients left MAPI for RPC over HTTP. I look forward to looking into this new protocol.

Download SP1 for Exchange 2013 here: http://www.microsoft.com/en-us/download/details.aspx?id=41994

Techmikal

Author Archives: techmikal