Creating a broadly compatible, modern SSL certificate with Active Directory Certificate Services

After recently hitting the default two year expiration point with our SharePoint development environment’s AD CS-issued SSL certificates, I set about updating that environment with a new five year template. I took this opportunity to see if I could make it as good as possible without breaking compatibility with anything. I will discuss some of these compatibility issues along the way. I will also make the certificate exportable, make sure it’s using the SHA256 hash (SHA1 will be deprecated in the near future), change the Certificate Authority (CA) configuration so that HTTP Distribution Points will be contactable from “outside the network”, and set permissions on the template in a way that it will be generally usable.

Steve Peschka tackled some of these basics about 18 months ago, but as he notes, his posts covers the simplest updates you can make. I think a few other options are worth considering. I don’t pretend to know all that there is to know about Active Directory Certificate Services (AD CS), or PKI in general, but I do think we can advance considerably beyond the default with a few changes. This is not a well-documented subject, so I hope to pull a few disparate resources together and propose an improved template. If you think anything here can be improved further, please post in the comments and I’ll try to incorporate that feedback.

Continue reading “Creating a broadly compatible, modern SSL certificate with Active Directory Certificate Services”

Product reuse at Microsoft as seen through a FIM lens

Microsoft and other large software vendors often fall foul of criticisms that products overlap significantly, or that discreet functionality in one product has been written afresh when the facility is already mature in another technology. As I’ve grown to know it better, I think Microsoft’s Forefront Identity Manager (FIM) provides some interesting examples of the benefits and drawbacks of product re-use. I put these thoughts out as a set of considerations to counter the view that reuse is always a positive thing.

Note: I wrote this article a long time ago, and have always been on the fence about posting it because it’s an editorial rather than purely technical content. I’m not 100% certain this is the right place for this content, but I am publishing it here now rather than letting it rot. Because this was written a long time ago, some references are dated. Like this doesn’t speak of MIM, AADSync or AAD Connect in any detail, so put that knowledge to one side for now.

Continue reading “Product reuse at Microsoft as seen through a FIM lens”

The Rules of AD FS Claims Rules

Many people think of AD FS as merely a federated authentication service. And with a name like Active Directory Federation Services, it’s easy to see why. However, it also has the capacity to make authorisation decisions within its Claims Engine. This may be most familiar as the Office 365 Client Access Policies, but those policies are basically just a flavour of AD FS Issuance Authorisation Rules. An AD FS Issuance Authorisation rule provides a gate at AD FS, where permissions can be granted or denied to authentic users, per-Relying Party, before giving the user Claims for the requested Relying Party. In most cases we will think about these rules as coarse controls, to block a wide category of requests, such as those originating from outside the network, for members of a group, or for any combination of request-based, device-based and user attribute-based Claims. We can even create authorisation rules based on the user’s Identity Provider, or from additional factors of authentication. We will typically still implement most of our authorisation logic within the Relying Parties we are authenticating to, but in some cases it’s very useful to control access at this intermediary tier – especially if a large class of users, devices or networks should be treated as higher risk.

These concepts are not new, and the TechNet documentation I reference here dates back to the earliest wave of AD FS 2.0 RTW content:

Ultimately, I think these articles do answer the question of how to create an AD FS Issuance Authorisation rule, but I can’t point very clearly to the place on these pages that spells it out, and I do think there is a lot of confusing information about this in other places which may lead people astray. Namely, there is a lot of information that only concerns itself with the default Active Directory Claims Provider Rules and the Claims that come from request headers. Also, some of the most referenced AD FS + SharePoint content seems to have been written without authorisation rules in-mind. I want to try to clear some of that up in this post.

UPDATE 24/2/2015
I’ve added a fairly significant update regarding the new MFA stage in the pipeline half-way down this post.

Continue reading “The Rules of AD FS Claims Rules”

Coordinating AD FS 2012 R2 token lifetimes to reduce logon prompts, enforce revocation and limit session duration over public networks

Back in February, I posted a question on the Geneva forum about Adjusting token lifetimes at the Web Application Proxy (WAP) for external access:

Does the Web Application Proxy or AD FS have any separate controls for adjusting token lifetimes to a different value via WAP than directly at AD FS? I can see there’s a session cookie for EdgeAccessCookie that WAP issues but this seems to be entirely undocumented at present. I’ve poked around in C:\Windows\ADFS\Config\microsoft.identityServer.proxyservice.exe.config (also undocumented as far as I can tell) but I’m not finding anything there either. We used to have some of these controls (sort of) with TMG/UAG. Are they totally gone now? With the AD FS Proxy this was less of an issue because it was only publishing AD FS but this is something that I’d hope to be able to control with a Reverse Proxy. Any ideas?

I didn’t get any replies, but after carrying out some tests of my own, I noticed the EdgeAccessCookie, and found a bit of information on TechNet:

After the user is authenticated, the AD FS server issues a security token, the ‘edge token’, containing the following information and redirects the HTTPS request back to the Web Application Proxy server:

  • The resource identifier that the user attempted to access.
  • The user’s identity as a user principal name (UPN).
  • The expiry of the access grant approval; that is, the user is granted access for a limited period of time, after which they are required to authenticate again.
  • Signature of the information in the edge token.

Web Application Proxy receives the redirected HTTPS request from the AD FS server with the edge token and validates and uses the token as follows:

  • Validates that the edge token signature is from the federation service that is configured in the Web Application Proxy configuration.
  • Validates that the token was issued for the correct application.
  • Validates that the token has not expired.
  • Uses the user identity when required; for example to obtain a Kerberos ticket if the backend server is configured to use Integrated Windows authentication.

If the edge token is valid, Web Application Proxy forwards the HTTPS request to the published web application using either HTTP or HTTPS.

This quickly became one of those things where there was insufficient documentation and limited project time, so I had to put this inquiry on hold. Then in July, I posted a question on the Application Proxy blog (a great resource), to see if this is something that they planned to document. The response that I got from Ian Parramore was unexpected and pleasing:

Continue reading “Coordinating AD FS 2012 R2 token lifetimes to reduce logon prompts, enforce revocation and limit session duration over public networks”

A secure alternative to flashlight apps

A month or two ago I read an eye opening presentation called Shining  the  Light  on  Flashlight  and  the  Security  of  Thousands  of  Mobile  Apps. It’s worth a quick read, especially pages 42 onwards, where the risks of flashlight apps are unveiled. Although the presentation focuses on security risks among the most popular Android and iOS apps, I noticed that pretty much all of the Windows Phone flashlight apps have similarly questionable requirements.

Why does a flashlight need to know where I am? Or have access to my files? Or send a raft of data all over the place? Needless to say, I got rid of my flashlight app.

Fast forward a week or two, and I needed a flashlight (or a torch, as we say in the UK). I decided to use my screen, which was pretty week, and then it occurred to me that I could enable the flash on my camera while in video mode, which does precisely what a flashlight app would do, without the app. It’s not many more “clicks” than launching and enabling an app (especially if I use the hardware key for the camera), and achieves the same result. I don’t know how well this work on other platforms, but I’m struggling to see why it wouldn’t. Hope this helps someone.

Things that don’t update when changing an AD FS URL in Windows Server 2012 R2

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.

Continue reading “Things that don’t update when changing an AD FS URL in Windows Server 2012 R2”

Moving an Office 365 DirSync/ADFS domain from one Azure AD tenant to another

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.

Continue reading “Moving an Office 365 DirSync/ADFS domain from one Azure AD tenant to another”

Significant Identity and Access Management Improvements in Windows Server 2012 R2

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.

Continue reading “Significant Identity and Access Management Improvements in Windows Server 2012 R2”

Editing the Host Name field for wildcard SSL certificate bindings in IIS 7

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:

Continue reading “Editing the Host Name field for wildcard SSL certificate bindings in IIS 7”