Mar 222013
 

So I’m sure we’ve all had to contemplate this at some point in our development lifetime – when is it appropriate to grant developers and architects the key to the domain? 

There are quite a range of developers and software engineers out there, and for various reasons they do, from time to time, require elevated permissions to do their work.

Recently a situation occurred on a friend’s project where one of the team’s senior members needed Domain Admin rights to install and configure some off-the-shelf enterprise software in a combined development/test environment. 

Now, as long time readers of this blog will know, I’m generally uncomfortable with developers and engineers (and testers for that matter) having Domain Administration rights unless it is essential to their tasking – and even then, for a limited time. 

The temptation to not thoroughly document (or indeed, understand) the configuration due to the more relaxed (less prohibitive) nature of having administration rights can lead to larger issues and mistakes when it comes time to deploy work into a controlled environment. 

Personally, I don’t disable UAC on my local machine and instead elevate permissions when and as needed.  I do run with local Administrator permissions (from time to time), but generally I prefer to have a separate account (Rob.Admin, for example) and try to limit how often I need to use Administration rights.

Now, returning to the recent scenario – the request to be granted Domain Admin permissions was only for the duration of installing and configuring a tricky piece of enterprise software, which uses a plethora of services and certificates which do require some configuration at the domain level.  It will require a few hours of debugging and testing and verification.

It’s not something that is necessarily done right the first time (which is why it’s done in a test environment first) and shouldn’t require the time or resources from infrastructure support.  As I mentioned, this is a test environment, and the project team should be trusted to carry out the required installation and configuration – following the standards of the platform.

So now we have to request the equivalent of hand holding from system support to perform all the tasks we need, bearing in mind the main point of this exercise is to document and test an installation guide to be reviewed by system operations staff to promote to the next environment.  I can’t see the system support folks staying back after hours to help the team debug the configuration, so what benefit is there in enforcing this policy?

What do you think?  Should a team have Domain Admin rights for a development/test environment, even if it is just to test out and debug the installation and configuration of software?  Do you think this is reasonable?   

Looking forward to your thoughts (leave a comment).

Jan 062013
 

This is sort of a follow-up to my first article on Active Directory Federation Services 2.0 (ADFS 2.0).  This afternoon I spent far too many hours troubleshooting an issue I didn’t really have.

Part of this complete and total waste of my time stems from what I now believe to be a fake or phantom error which is logged into the Windows Event log when the ADFS Windows Service in started.  Until I’ve been able to fully process tokens, I can’t reasonably discount the error as being invalid, but my gut tells me all is swell – and I’ve lost about 3 hours of my precious time for nothing.

To hopefully help people avoid wasting their time, I’m going to write up some of my experiences with ADFS 2.0, including some of the issues I faced.  On the up side, I did reconfigure ADFS 2.0 with a named service account (which I generally prefer to do).

I’m going to assume that you have installed ADFS 2.0 to some degree, and that you’re generally comfortable configuring servers.  My test environment is Windows Server 2008 R2 x64 (virtualized) – I haven’t tested or installed ADFS 2.0 on Windows Server 2012 as yet.

Verifying Your Installation

Why this isn’t made clearer, I don’t know.  Instead of building up a valid WS-FED request which can take a while to configure, there’s a faster way to sanity check your installation and configuration.  I found this information courtesy of a thread on the Geneva forum on MSDN:

If I hit the link https://<server>/adfs/fs/federationserverservice.asmx and generates the XML, That means my setup is right.

To double check, after you’ve attempted to resolve the URI above, check the Windows Event log under “Applications and Service Logs\AD FS 2.0\Admin”

In the Event ID column, look for event ID 100. If the federation server is configured properly, you see a new event—in the Application log of Event Viewer—with the event ID 100. This event verifies that the federation server was able to successfully communicate with the Federation Service

For the record, an entry with a Event Code of 100 looks like this:

image

You’ll notice that the General tab lists a whole bunch of URIs. 

Understanding STS/ADFS Architecture

The next step is to understand the architecture of Windows Identity Foundation (WIF) and STS (Security Token Service).  Scanning the WWW, I came across this diagram on MSDN which illustrates a very simple scenario (I intend on something much more complicated.. and fun).

WIF Basic Claims Aware WCF Service

There’s a couple of things to call out here. 

The first is that an STS makes heavy use of certificates, so if you’re going to do this properly, get your certificates sorted out up front.  My approach is to install and configure an Enterprise Certificate Authority and issue certificates from there.  Then, it’s just a matter of trusting the root CA (signing) certificate in your environment, and your cert chain should be valid.

Another point – it’s worth the time to get everything running over IIS (if you’re using it instead of a self hosted WCF application) – even in development.  Throw the Visual Studio web service (formerly Cassini) to one side and get everything running over IIS or IIS Express.

Kerberos – If you use a custom domain identity for services and the IIS app pool, make sure you remember to run the setspn utility to ensure that the domain account can register and unregister service SPNs properly. 

See this article for more on using setspn for an ADFS identity account.

Last point – spend a good amount of time verifying and testing your installation and configuration.  This is a valid point for all environments (not just the production environment) – it’s just as important that your development and test environments are configured and work properly, so spend the time and make sure you get it fully configured.

Helpful Sites and Links

Of course, I did this all on my own – not.  This involved literally hours of searching the Web for answers, and many times I found some help.  Here’s some links which proved helpful while I tried to troubleshoot ADFS 2.0.

Installation

Troubleshooting

Dec 062012
 

Introduction

This is going to be a multi-part series of articles with the end goal of producing a solution which handles security/identity claims across domain boundaries using WCF services and Active Directory Federation Services 2.0 (with a federation trust) and Active Directory.  In order to demonstrate an approach to handling claims, we need an environment which is capable of supporting the infrastructure configuration we require.

Network Design

I strongly recommend that you put the time and effort into understanding the network topography.  When designing a key foundation of your approach to security, it’s critical that you have a working knowledge of the kind of trust you are placing in your trusted sub-systems.  For the next few articles, I’m going to rely on the following network design, which you can (not without some effort) establish for yourself using virtual machines:

image
Basic Network Design

Host Configuration

To keep resource usage to a minimum, I’ve designed my test environment to reuse hosts for key roles.  In practice, you might not normally mix roles in a production environment – refer to the appropriate ‘best practices’ to properly plan your infrastructure and deployment of critical roles!  Here’s a view of what is on each host:

image
Host Configuration

Installation and Configuration

You’ll need a minimum of two server installs to make this happen, although I’m using four to separate ADFS 2.0 and to configure an Enterprise Certificate Authority rather than a standalone CA.  You’ll also need the Windows Identity Foundation (WIF) SDK installed with your copy of Visual Studio (Visual Studio can be installed elsewhere – not on your test servers). 

I’ll be using Visual Studio 2010 for this, but I’m sure there’s a solution for Visual Studio 2012.  To streamline your configuration, I’ve provided links two some excellent walkthroughs on the MSDN blog site – the one you need to pay attention to is the ADFS 2.0 installation and configuration.

My Mobile Configuration

Since this is a fairly intensive number of operating systems, I’ve put together a fairly decent local configuration which I can take with me.  I’m using a 480 GB SanDisk SSD in an eSATA external enclosure (my laptop does not support USB 3 at the moment).  I’m running VM images off the SSD and getting very respectable performance.  No problems running four VMs in parallel.

 

Kit

How to Get Up and Running

My best advise is to follow the links below.  You’ll need a fair amount of stuff downloaded, so better jump on that.  Once you have some clean OSes and the installation packages, my best advise is to follow the walkthroughs.  Be careful not to accidentally skip anything, the configuration is a bit tricky at times, but if you follow the walkthrough closely you should have a working environment in about half a day or less.  My configuration varies to the walkthrough (as I have two domains), but if you duplicate the configuration for two different directories you should have something which can work.

Links Galore

If you’re going to build a test environment (frankly, just do it – it’s the best way) budget at least a day to get everything configured properly.  Don’t cut corners, it’ll only hurt you later.
Check back soon for the next article, where we’ll start to get familiar with the environment, and build a claims-aware application.

Important Downloads

.NET Framework 4.0 Runtime
http://www.microsoft.com/en-au/download/details.aspx?id=17718

.NET Framework 4.0.3 Update
http://www.microsoft.com/en-au/download/details.aspx?id=29053
Update 4.0.3 for Microsoft .NET Framework 4 – Design-time Update for Visual Studio 2010 SP1
http://www.microsoft.com/en-au/download/details.aspx?id=29054

Active Directory Federation Services 2.0 (RTW)
http://www.microsoft.com/en-us/download/details.aspx?id=10909&hash=Hx4OGpwvFzmf7%2bC7rR1nq18CYhcY%2bSE4ok1ifL%2fvSkYIpezfAxg6ePR2zpfAplmm6g%2fUyL1VU7RtmnuR6T4NWg%3d%3d

Windows Identity Foundation (Runtime)
http://www.microsoft.com/en-us/download/details.aspx?id=17331

Windows Identity Federation SDK
http://www.microsoft.com/en-us/download/details.aspx?id=4451

 

Installation and Configuration Walkthroughs

ADFS 2.0 Installation Walkthrough
http://blogs.msdn.com/b/alextch/archive/2011/06/27/installing-a-stand-along-adfs-service.aspx
Establishing a Federation Trust Walkthrough
http://blogs.msdn.com/b/alextch/archive/2011/06/27/establish-federation-trust.aspx

Building a Claims-aware Web Application Walkthrough
http://blogs.msdn.com/b/alextch/archive/2011/06/27/building-a-test-claims-aware-asp-net-application-and-integrating-it-with-adfs-2-0-security-token-service-sts.aspx

These walkthroughs really helped! 

Finally.. If you hit problems with your STS certificate – check the HTTPS bindings of your local IIS:

http://www.shutuplaura.com/journal/2010/1/5/adfsv2-rc-iis-certificates.html