If you hadn't heard, Quest Software acquired NetPro (press release). The whole deal was done rather quickly, and I have to say I was surprised by the whole evolution of events. I figured we'd be acquired by someone at some point, but I didn't see this one coming.

As you can imagine, one of my biggest concerns has been what will happen to DEC (now TEC). Quest has been jealous of DEC for quite a while, and I've had nightmares about Quest turning it into some giant sales and marketing fiasco. But I've been informed by people up and down the organization that they want TEC to continue just as it is. One of the Quest marketing people even said something to the effect of "We don't want anything to do with it; we'll just mess it up. You've got a great thing going and we just want to leave it alone." That's certainly great to hear, and it gives Christine and me a pretty good confort level that TEC will continue to be a great event for the Microsoft IdA community to meet and learn. And in fact that's going to be my primary focus for the next several months.

I've spent a little time with the Quest product teams (product management mostly, along with some R&D guys), and I've been pleasantly surprised both at the quality of the people (they're all really sharp) and of the process of product line integration. Everyone has had an open mind, there haven't been any agendas or significant politics, and everyone is on the same page as far as bringing the best products and features forward to our customers. I really expect to see substantial improvements in the Quest product line as we go forward.

Corporate acquisitions are usually complicated, messy affairs, and often don't net out very well, but this one seems to be off to a pretty good start.

 

Quite a while ago, Brent Harman and I delivered the world-famous Guido and Gil's Masters of Disaster AD Disaster Recovery Workshop in Dallas. Things went pretty smoothly except for one mysterious behavior with authoritative restore. We figured it out after an hour or so, but I never recorded the problem before.

The lab setup included two domains, with two DCs in each domain. The first DC in the root domain was the sole DNS name server. The first DC in each domain was also a GC. Each domain contained OUs with groups and users in them, and there were domain local as well as universal groups containing members from both domains. Domains and forest were WS 2003 functional level.

The lab included two auth restore exercises. Each DC had a current system state backup. The first exercise had the student delete a user from an OU in the child domain, and then use auth restore to recover the user in the child domain, and non-auth restore and LDIFDE to recover the domain local group memberships in the root domain. The second exercise was essentially the same, except the goal was to delete and auth restore an entire OU, including the group memberships of the users in the OU. Pretty basic, if tedious, stuff.

To refresh your memory, the auth restore process in a multi-domain environment looks something like this:

1. Boot DC in child domain into DSRM
2. Use NTBACKUP to perform system state (non-auth) restore of DIT
3. Use NTDSUTIL to perform auth restore of objects to be recovered. This increases the version number on the object's attributes by 10000 for each day between the date of the backup and the date of the restore, which causes the object to replicate out to the other DCs, rather than being overwritten by the tombstoned object from the other DCs. The auth restore process also creates LDIF files containing forward link information (e.g. group memberships) and a text file containing the GUID of the restored object for use in other domains.
4. Boot the child DC into normal mode.
5. Use LDIFDE to recreate the group memberships for the restored object in the child domain (not necessary in our case since we were in WS2K3 DFL/FFL)
6. Boot a DC in the root domain into DSRM
7. Use NTBACKUP to perform system state (non-auth) restore of DIT
8. Use NTDSUTIL to create LDIF files for the root domain group memberships of the restored object, using the text file from step 3 as input.
9. Boot the root DC into normal mode.
10. Use LDIFDE to recreate the group memberships of the restored object in the root domain

There were no significant problems with the first exercise. Pretty much everyone was able to restore the deleted user, along with the user's group memberships in both domains with no trouble. The problem showed up in second exercise where we recovered the OU.

Several people ran into a problem after restoring the OU however. After restoring the OU (which happened to contain the user they recovered in the first exercise), the students discovered that the user they restored in the first exercise was gone! Even worse, when they tried to auth restore the user again, the user would appear, and then magically disappear again within a few minutes.

After making sure the students were actually doing the auth restore properly, we pondered the problem for a while until we understood what was happening. A local Dallas MSFT fellow who was sitting in on the class figured it out.

Basically, the problem occurs when you auth restore the same object from the same backup more than once in a single day. Let's just look at a single attribute of the object, say distinguishedName. the version number of the attribute is initially 1. This is the value of the version number that is stored in the system state backup as well. After the object is deleted the version number is set to 2, and the new distinguishedName value replicates out from the originating DCs. When you use NTBACKUP to non-authoritatively restore the entire DIT, the version number of the distinguishedName attribute is again 1. If you were to restart the DC in normal mode, the other DCs in the domain would overwrite the distinguishedName attribute because their version number is higher. That's why you have to use NTDSUTIL to perform an authoritative restore of the object before restarting the DC in normal mode. The authoritative restore process increments the version number of all of the object's attributes by 10000 per day since the backup, which results in a version number larger than the corresponding version numbers on the DCs in the domain. The attributes from the authoritatively restored object replicate out to the DCs replication partners, and overwrite the values there.

When the students went through the same process with the OU, they auth restored the OU subtree, including all the objects contained in the OU. Because the date of the backup and the date of the restore were unchanged, the version numbers were all incremented by 10000 again. The attributes of the OU and its contained objects all replicated out, overwriting the corresponding attributes on the other DCS, except for the attributes of the originally deleted user object. Why? Let's trace through what happened to the originally deleted user object and see.

When the object was originally created, the version number on its attributes was set to 1 (say). When it was deleted, the version numbers were incremented to 2. When the object was non-authoritatively restored from backup, the version numbers were restored to 1. When the object was authoritatively restored, the version numbers went to 10001, and that's what replicated out to the other DCs. When the OU (and the objects contained in it) was deleted for the second exercise, the version numbers went to 10002. The students did the non-authoritative restore from backup, which returned the version numbers to 1. The authoritative restore process then set the version numbers for all the restored objects to 10001. This caused the attributes for all the restored objects to replicate out to the other DCs, except for the attributes of the originally deleted object. It's version numbers on the other DCs were 10002, which is still greater than 10001. So the originally deleted object was restored, but inbound replication overwrote it, even though it had been authoritatively restored!

There are a couple of ways around this problem. One is to use the VERINC option of NTDSUTIL to increase the version numbers by more than 10000 per day. The other is to perform another backup immediately after the original authoritative restore. Or in the case of this workshop, just delete and restore a different OU :).

Brian Puhl has a very lucid post at http://imav8n.wordpress.com/2008/07/20/federation-agreements/ regarding identity federation at Microsoft, and the nature of the agreements made between federating organizations. If you are contemplating establishing an identity federation with another company, you should read it.

Federation requires some level of trust (the social kind) between organizations. When you allow federated identities access to your resources, you trust the federating organization to manage their identity information in a way that is consistent with the security you require for those resources. Note that this is NOT the same as saying they should manage their identity information to the same level that you do. For instance, just because you require 10 character passwords for your Active Directory accounts, it doesn't imply that you should require your federation partner to do the same. Why not? There are two reasons:

1. First off, as Brian says, what you are really buying with federation is more accurate provisioning and deprovisioning of access to your resource. You have a choice in the matter. Your first choice is to manage your partner's identity information on your own systems. This is expensive, AND you have to accept the risk that you will not will not provision or deprovision the identities accurately or in a timely fashion. How are you going to know when someone in your partner's organization leaves or changes roles and needs to have their identity information updated?

The alternative is to use federated identities, and let your partner take the responsibility of proper provisioning and deprovisioning. Presumably they are in a better position than you are to do this. BUT, you have to accept the way that they manage their identities internally.

If the residual risk associated with managing the identities yourself (plus the cost factor) is greater than the residual risk associated with using federated identities, then federation makes sense. That's the real tradeoff that you are making.

2. The other reason you don't require your partner to manage their identities the same way that you do is that presumably your AD identities provide access to lots of things in your organization; perhaps everything. The risk associated with your AD accounts is therefore potentially very high, so you require strict controls. But the identities you trust from your partner will only have access to the specific resource that accepts those federation claims. The risk associated with compromising that resource is likely much smaller than the risk associated with the compromising all of your internal resources.

As Brian says, it all comes down to managing risks. But you have to understand what the risks really are before you can manage them.

Some of you have heard (or seen) that we've renamed DEC to The Expert's Conference, or TEC. Why? Well there are several reasons:

1. DEC is the acronym for the Directory Experts Conference. But DEC isn'just about directories, and hasn't been for several years. It includes ADFS, RMS, ILM, etc., etc.

2. We are also producing an Exchange expert's conference, along the same lines as DEC. But EEC and GEEC (for the Great Exchange Experts Conference) aren't great acronyms. OK, truthfully, I like them. Christine on the other hand just threw the back of her hand to her forehead and sighed dramtically. I've known Christine long enough to understand the non-verbal signal for "That ain't happening."

3. "The Experts Conference" has a good acronym: TEC. Sounds sort of, oh I don't know, technical. At least it does to a marketing person. Somtimes you have to go along to get along, know what I mean?

4. I got tired of confusing Wook. "Do you mean DEC my former company? Or DEC the conference?"

So we now have TEC for Directory and Identity, formerly known as DEC, and TEC for Exchange, formerly not known as anything, because, well, it's new. Make sense? No? Then start reading at the beginnig of the post again until you get it.

TEC/Directory and Identity and TEC/Exchange are separate conferences, but they will be colocated in 2009. TEC 2009 is scheduled for March 22-25 at the Green Valley Ranch Resort in Las Vegas (or Henderson for people with finicky travel policies) Nevada. So everyone who spent the entire year griping about Chicago in 2008, you can just shut the he** up .  We will also be hosting TEC Europe September 14-16 in Berlin (Germany, not North Dakota).

What are we going to cover? For AD, we'll focus more on real-world WS 2008 AD deployment and operational topics, what's coming in AD for Windows 7, plus the usual how-does-it-really-work type sessions. There will be lots of coverage for ILM '2' and ADFS '2' because both products will be just about ready to RTM. We will continue our coverage of RMS (which seems to be picking up a lot traction this year), and AD/LDS and GPO management will figure prominently as well. There will be 4 pre-conference hands-on workshops on Sunday, too.

For Exchange, the bulk of the sessions will be related to Exchange 2007, including Powershell, unified communications, architecting for performance and scalability, a MAPI deep-dive, and troubleshooting. We might be able to include some E14 content as well, but that will depend on the product team. We are planning on two pre-con hands-on workshops on Sunday as well.

The main TEC website is at http://www.tec2009.com, and the call for papers is now open for both conferences. Please get your session proposals in soon, because registration for the conferences goes live August 25, and I'd like to have the agendas pretty well firmed up by then.

If you have any questions, drop me an email.

See you at TEC!

Hello Secure World is a website set up by Microsoft to promote Windows security. The Microsoft Business Marketing Organization (BMO) and Tri-Digital worked with us on DEC 08 in Chicago to record some of the more security-related sessions, and they are now available on the HSW site. Start at the main page, sit through the intro (or click the Skip link), and click the "Inside the DEC" link.

IIRC, we recorded 10 of the sessions. Currently four of the RMS-related sessions are available; I believe that the BMO rotates the 10 sessions through the site.

Is this a usable format for you? Would you like to see all of the DEC content recorded this way?

 

I'll be hosting the Active Directory Disaster Recovery Workshop (based on the one that Guido Grillenmeier and I put together) at TechMentor in Las Vegas Oct 13th. It will be hands on, but you'll have to bring your own machine to run the VMs. There will be some changes in the workshop agenda as well. I want to spend a little more time on the actual DR planning process vs. the mechanics of recovering deleted data, and I want to incorporate the changes in WS08 DR as well.

If you plan on being there, please leave a comment as to whether you'd rather see VMWare or Virtual PC images.

Here's a cool promo video for TechMentor:

-g

 

 

I'm moderating a Birds-of-a-Feather session here at TechEd tomorrow on Active Directory, and I found out yesterday that it has the highest number of registrations of all the BOF sessions. I was expecting 40-50 people, and apparently almost 350 have registered. Which is not to say they're all going to show up (actualy attendence runs anywhere from 30% to 120% of registration). But 350? I wasn't expecting that. Should be fun!