James D. Stallardblog

Yesterday, I had the privilege to attend an invite-only AD Design Seminar, being run by Microsoft at their Reading Campus. The seminar was hosted by Mark Cribben and "Dave the Demo Dolly". Mark and I worked together for almost a year on implementing Windows .NET Server (the originally planned name for Whistler/Windows Server 2003) into Elsevier Science, so it was nice to catch up and see what he'd been up to since. Dave was new to me and if he's reading this, perhaps he could remind me of his surname (sorry Dave)!

The seminar covered a wide range of topics, including the history of LDAP and Microsoft's RFC compliance status on LDAP and Kerberos. However the really interesting bits for me where these:

Best Practices are now Recommended Practices
Introduction to MIIS/IIFP
Introduction to ADAM

Best Practices are now Recommended Practices (and things have changed)
Since releasing the Deployment and Operations Guides for Windows 2000, Microsoft's view on the function and design of Active Directory has moved on.

Microsoft no longer deals in the fabled "Microsoft Best Practices" and now refers to "Recommended Practices". This recognises the fact that there are multiple solutions to each design problem, and what is written in the Deployment Guides may not necessarily work for every client. As Mark so eloquently put it - Not every branch office deployment goes into a retail bank.

An interesting departure was the old recommendation of an empty Forest Root Domain for every deployment being dumped. The old recommendation stated that each implementation of AD should consist of an empty Forest Root Domain and one or more Child Domains. The Forest Root provides some limited protection for the Enterprise and Schema Admins and the Domain Admins and Standard Users would live in the Child Domain. This model supports the acquisition/divestiture model of some businesses, and so is not entirely defunct - provided one is aware of the risks. It is now well known that a Domain Admin in the Child Domain can escalate their privileges easily to that of Enterprise Admin in the Forest Root and with this realisation the point of a Forest Root PURELY to protect the Enterprise and Schema Admins is no longer made. In other words the Security Boundary for Active Directory is NOT the Domain, it is the Forest. Consideration of this fact must be made when considering an AD design in environments where certain entities must remain secure from wider organisation.

While on the subject of security; it is worth noting that even an unskilled techie, with physical access to a domain controller can "own" the box and then the whole forest) with a leasurely afternoons work. This is the biggest reason why DCs MUST be physically secured from unauthorised access. The ever-professional Mr Cribben, of course refused to elaborate on the techniques involved, and I shan't go any further either.

A further departure is that of domain naming. The old recommendation is to go with .local as the TLD. This was because .local was being proposed as a new TLD at the time and you would be able to register your company name to help guarantee uniqueness in case of acquisition or interoperability requirements. .local was never actually ratified, so much of the benefit of using it was lost. The new recommendation from Mark (and many will disagree with this) is to delegate a subdomain from the existing company presence. For instance, for leafgrove.com, the delegation might be ad.leafgrove.com. The logic here is that leafgrove.com IS a publicly registered domain and therefore will remain unique. The fact that I have used a delegation means that I will not fall foul of the old split horizon DNS issues that plague those who use the same domain name internal and externally without the delegation. Of course, we are still able to use .local and any internal name for our AD we wish, but combining this with the potential loss of the unnecessary enpty Forest Root and we can see that the potential for rows over Domain naming standards drops significantly. Hallejuia to that.

Introduction to MIIS/IIFP
MIIS and IIFP are Directory Synchronisation Tools. They are designed to allow changes in one database or directory to be automatically piped into another database or directory, with the ability to modify the data or apply business rules along the way.

For instance, HR could create a new entry in their database for a new member of staff. This would cause MIIS to create a new user account (with application of naming standards) in the AD and in other systems and perhaps generate an email to the purchasing team to buy a new computer. This process is referred to as provisioning and is one of the goals of every IT department.

MIIS and IIFP are actually the same tool. IIFP is the cut down and currently free version used to work within purely Microsoft environments. MIIS is the enterprise version (currently in SP1) and enables interoperability between a number of different directory services and databases, including AD/AM.

The only real problem is the fact that MIIS needs an enterprise Windows 2003 and SQL Server licence and is already an expensive product - so it's only really suitable/affordable for the large installations that can afford it and will see real saving from its use.

Introduction to AD/AM
AD/AM is Active Directory in Application Mode. AD/AM is a scaled down version of the Active Directory with support for O= and C= x500 notation. There is no authentication module and no domain naming or DNS contexts, but it can be secured with AD and multiple instances can be run on one machine (a la SQL2000) - each with it's own, independant schema.

The old idea that Active Directory would be the only Directory Services product you would ever need has clearly not been borne out by real life implementations and it is obvious now that you don't necessairly want to 'pollute' your Infrastructure Directory with a load of application data that is then replicated to all the DCs in the Domain (or even Forest). AD/AM to the rescue.

The only thing that concerned me about AD/AM, was it's apparent need to be backed up offline. AD/AM has the ability for each instance to be restarted (they run as services) independantly and without the need for a reboot, but offline backup seems like a missing feature. A possiblility would be to create replicas and then offline the replica, but this would require scripts to automate the shutdown, backup, restart actions.

Other concerns with AD/AM is the lack of GUI support for building a replication topology (as in Active Directory) and the resulting requirement for a special version of ADSIEdit (provided) to perform almost all your administration.

In Microsoft's defence AD/AM is free and clearly pitched at vendors looking to use it in their products as the backend, but even with this in mind some GUI tools and online backup are certainly in order.

I can certainly see a use for AD/AM as the backed to a single list type tool, that allows you to extend the functionality of AD and integrate all those other apps that you wouldn't really want talking to you live infrastructure directory. In combination the MIIS AD/AM is a powerful tool indeed.

Overall, the seminar was excellent, with relevant content and highly knowledgeable hosts. My only request would be for Microsoft partners to have access to the internally available IDS builds of new operating systems. We would all love to have a play with Longhorn!

The day has finally arrived.

After countless hours in design and numerous go/no go decisions made, reversed and made again; it is finally time to perform the upgrade from Windows NT4 to Windows 2003.

I write this on the train home, on my last weekday before Sunday 22nd May - go live day. Normally, an in-place upgrade shouldn't be a big a deal, even for 20+ sites, but this one has been complicated by so many external influences that the risk register now looks like a horror novel.

We have management washing their hands of oversight and developers refusing to support their apps after the cutover. We have not enough time and not enough budget (sound familiar?), and the project manager is starting to flag. The support teams have been trained and given an overview and the machines with fixed IP addresses have been addressed for DNS settings. I finally managed to get ActiveRoles behaving in the way I wanted and the Delegation of Admin design finally works. Every day for the last few weeks has been a new drama and what's left of the team are all getting tired.

The pressure is starting to tell just a little and after 6 months of 5am starts I will be glad when it's over.

Come Monday, we will have a brand new Active Directory and the task of migrating the regions and deploying the supporting services begins.

Here's hoping for an easy run.