When helping our clients with Office 365 deployments, we sometimes find that DirSync has been associated with a trial tenant that is about to expire and/or was originally created with a provisional name, or similar. In any case, a public DNS name can only be verified once in Office 365, which associates that namespace with the Office 365 and Azure AD tenancies. So if we want to move DirSync (which is also a prerequisite for ADFS) to a new tenancy, then we need to back it out from the first tenant and re-associate it with the second. Unfortunately, that process isn’t exceptionally quick, but there are some manual steps that you can carry out in order to accelerate the change. As we do this more often, our list of things to check is growing, so this list may change, but this is where we’re at today. Please feel free to comment if you feel we’re overlooking anything.
Last week, Microsoft released Windows Server 2012 R2 Preview. Some information about new features like the Web Application Proxy role began to emerge from recent industry events, but there isn’t an awful lot to absorb at the moment. Having played around with the preview for a few days, I’m pleased to report that the new features look good. While there are always niggles and unsupported scenarios, the features themselves are bringing Microsoft’s Identity and Access Management (IAM) offerings nearer to parity with the industry leaders. These changes should be of particular interest for SharePoint on-premises and Office 365 customers, as a number of scenarios that were on the bleeding edge of ADFS/UAG capabilities have been brought into the fold with some important enhancements to ADFS, which isn’t just for federation anymore.
In short, we get a new Claims-Aware Reverse Proxy, Device Claims in and outside of the network, Multiple-Factor Authentication and other enhancements for making access control decisions on more than just a username and password. I’ve discussed all of these topics routinely over the last couple of years in SharePoint on-premises and Office 365 contexts, but the current provisions in ADFS and UAG are not as elegant as what we find in the preview, so I’m keenly exploring the new functionality and will try to keep the content flowing. In this post I will focus on the features themselves, as there’s a lot of new stuff and the implementation of this functionality will only be clear with a bit more information than what you’ll find online today. I’m kind of rushing this out after limited use because I know there’s a big appetite for knowledge about the Microsoft Reverse Proxy roadmap, so apologies for the incompleteness in advance.
Over the last year I’ve spent a decent chunk of my time shaping and delivering Identity and Access Management workshops for Office 365 projects at Content and Code. This is generally underpinned by Active Directory Federation Services v2.0 (ADFS). In fact I don’t think we’ve done a single Office 365 project without it. Along the way I’ve become acquainted with many of the nuances of the sign on and sign out experiences as they differ across Office 365 services, client applications and different (valid) network perimeter technologies. In this post I will mainly focus on the security implications of publishing ADFS through ISA or TMG Reverse Proxies in the place of ADFS Proxy servers. In the majority of our engagements we’ve considered this option (potentially allowing our clients to consolidate infrastructure) since ISA, TMG or similar Reverse Proxies are commonly deployed. Yet we need to evaluate with full awareness of how ADFS operates without a Claims-aware Reverse Proxy such as the ADFS Proxy. This gets pretty technical, so I’m assuming some high-level familiarity with ADFS, Reverse Proxies and Office 365.
- Office 365 Identity Service Description
- Claims-Unaware Reverse Proxies
- Outlook Web App Sign Out Experience
- Sign Out from Other Office 365 Web Applications
- One Minute Reverse Proxy Session Lifetime
- Mitigations for Perceived Security Risks
- Using this Information
Following my last post on Lync, Strings and Cans I need to report further detail on my test findings, wherein I identified that some Lync Online traffic would route peer-to-peer. This was an exciting finding for us, and remains so, although we’ve also uncovered some initially-unexpected nuances. To this end, my first post describes a model for understanding Lync traffic and details the default experience. In this post, I’ll talk about how in some cases, a two-person session will switch from peer-to-peer routing to a conference mediated by the Lync Online Edge servers. In these cases, Lync traffic routes in the same way as a multiple-participant conference, even though there are only two users involved. Put another way, in these cases all traffic will route via Office 365’s Lync Online Edge servers, even if all the internal ports are open for peer-to-peer communications.
NAT Traversal and Candidate Testing
To understand what’s going on, you first need to understand what to look for. Part of the reason for the delay producing this second post is that I’ve been trying to explain this by picking apart network monitor data. At first these captures were nothing more than an attempt to validate assumed behaviour, but it’s quite a bit more complicated than I expected. Thankfully, there are some excellent resources that describe precisely what I’ve seen with greater precision and detail than I could hope to reverse engineer. Having spun my wheels for a bit, I would recommend some healthy RTFM – getting to grips with Lync topology and possibly even consulting protocol documents, if you’ll spend any amount of time trying to decipher Lync network traffic. I cite some of these resources at the bottom of this post, but for the immediate considerations I’m focusing on some key descriptions from Bernd Ott’s How Communicator Uses SDP and ICE To Establish a Media Channel article.
Like a lot of people in the Microsoft partner community, I’ve been catching up with Lync this year and digging in to the finer details with a few of my colleagues. One thing we wanted to understand better was the routing between two users over a LAN, a private WAN, or some other connection where all the necessary network ports would be open. Would these clients communicate peer-to-peer? If so, does it always behave the same way, how is it accomplished and what might go wrong?
First, consider an organisation with offices across multiple floors or buildings. Lync may be a very effective means of connecting these employees despite their relatively close proximity. If this traffic can route locally it can be a big plus – especially if there’s lots of media traffic. Second, consider an organisation with multiple branches. They invested in private WAN links to connect these branches and don’t necessarily want to route Lync traffic over their internet connections if they can avoid it. For some organisations these will be non-issues, since Lync traffic is optimised for the WAN, but for other organisations this may be important – particularly if they’re in a part of the world where internet connections are slow or expensive (or both). So we went about testing this with the Lync 2010 client and Office 365 users (the behaviour is the same with Microsoft Online IDs or federated users).