Windows Server 2012 R2 introduces a number deep changes to the way that AD FS works, which means that as practitioners, we need to look for solutions to problems in new, unexpected places. For instance, in the old world, if AD FS was completely unresponsive, the first place I would look after AD FS itself would be IIS. In AD FS 2012 R2, IIS doesn’t play a role. Requests are still served by the HTTP.SYS kernel driver but we interact with it using NETSH HTTP, which connects to the driver via the User Mode HTTP Server API. IIS and other familiar components would also interact with this API previously, but they provided a friendlier layer of abstraction between an administrator and the API. Interacting with HTTP.SYS using NETSH HTTP brings a learning curve with it, particularly when it comes to understanding what is and is not controlled here. Also, there is no GUI and the security that HTTP.SYS enforces is stricter than the abstracted layer that IIS has historically opened up. This web server architecture change and other new differences add to the difficulty of tracking down problems when things don’t work as expected, as detailed in this post.
Not only is this the thing that I always forget, it’s the thing that I’ve just learned I didn’t really understand. My colleague Ben just absolutely pwned me about an SSL certificate’s “Friendly Name” field and how it’s used when editing SSL binding in IIS. I was certain that Friendly Name couldn’t possibly be related to getting an editable host name field when you bind multiple Web Applications on the same IP address (assuming you have a wildcard certificate to handle this multiplicity). How it works with SAN certificates I don’t really know, but that’s a topic for another post. At any rate, in this case, I was bashing my head because I couldn’t get an editable Host Name field for my newly-extended Web Application:
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.
Working with software developers, I’ve probably seen SelfSSL used more often than in most lines of work, and also misuse of it. The purpose of this article is to draw some boxes around the different areas that come in to play when a site is self-certified.
Most obviously, the user requests the page through the browser, but the browser also warns of Certificate/DNS name mismatches. Unless the certificate was issued to the address through which the site is being browsed, the browser will produce certification warnings. This behaviour is expected and desirable as part of browser security. Continue reading “The stuff around SelfSSL”