I was rereading one of my posts in this blog today - Active Directory Backup? Don't rush - you'll get more time - and realized that not everyone might be aware what a Tombstone is.
As we know Active Directory is a multi-master directory: Every DC is usually able to write into the directory. Examples of single-master directories are classical DNS (only one primary server per zone, and the primary server is the one who writes updates to the zone, many secondaries are able to pull those informations and provide them to other clients/servers) or a Windows NT 4.0 Domain with one Primary Domain Controller (PDC) and multiple Backup Domain Controllers (BDC) (same thing here - only the primary is allowed to write).
One of the things to consider when designing a multi-master directory are how content will be deleted. If we would delete something completely and right away, how would another domain controller figure out that it was deleted and that he needs to delete the same object in his database?
And that's where the tombstones fit into the picture. If we delete a object it is not immediately deleted but "converted" into a tombstone. When replication occurs the other DCs note the change of the object and convert their local copies in the database into tombstones by replicating the changes of the object. So what happens to the object when it is deleted?
The object will be marked as deleted, meaning the isDeleted-Attribute is set to true. It will be also moved to the "Deleted Objects"-container. Also all Attributes which are not supposed to remain in a tombstone will be stripped from the object. So most data is not there anymore, but the most important ones like the Global Unique Identifier (GUID) and the Security Identifyer (SID) will remain. There are additional attributes being kept in the tombstone, e.g. in Windows Server 2003 there is also the SID-History kept in the tombstone. Which attributes will remain in the tombstone is defined in the schema, in the definition of the attribute. If the fourth bit in the searchflags (= decimal 8) is set the attribute will remain in the tombstones. You are able to configure additional attributes to remain in the tombstone by setting this bit as well.
Using the following command you are able to retrieve most attributes which remain in the tombstone (everything in one line):
dsquery * cn=schema,cn=configuration,dc=yourcomain,dc=com
-filter "(&(objectClass=AttributeSchema)(searchFlags:1.2.840.113556.1.4.803:=8))"
-scope subtree -attr name
~eric reminded me that this query will not necessarily return all attributes which are preserved in a tombstone - some critical objects and changes of the list are hardcoded and will remain in the tombstone no matter what the searchflags state. SidHistory in Windows Server 2003 SP1 is one of them which won't appear in the schema unless you change it yourself, but will remain in the tombstone. The reason for this approach is to not require a update in the schema partition when installing SP1. However I wouldn't call changing the searchflags of an attribute a major change in the schema (you are able to reverse it, and especially the change of tombstone behavior has not this much of an impact), but that's another topic. I do understand why Microsoft used that approach.
To see the tombstones in your AD you can use LDP.exe in the support tools. Instructions for this are in the Windows 2000 Resource Kit in the Distributed Systems Guide: Searching for Deleted Objects
After a object is tombstoned it will remain in the directory for the tombstone-lifetime (60 or 180 days by default, see Active Directory Backup? Don't rush - you'll get more time). The tombstone-lifetime assures that the tombstone will be replicated to every DC, so that every DC knows that the object is deleted. This is the reason why you can not use a backup to restore Active Directory which is older than the tombstone-lifetime - it would reintroduce objects which have been deleted prior.
The garbage collection process one every domain controller takes care that tombstones which are older than the tombstone-lifetime are deleted permanently. The garbage-collection process runs by default every 12 hours on each DC. You can also configure other periods by modifying the garbageCollPeriod Attribute of the CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=yourdomain,DC=com Object. However this should not be necessary, and I encourage nobody to modify it.
However, the object is permanently deleted now, but the NTDS.dit-Databasefile which contains the Active Directory will not decrease it's size. Instead the new "Whitespace" will be used for new objects. The only possibility to release the Whitespace in the database is to perform a offline defragmentation using NTDSUtil in the Directory Services Restore Mode. See the Knowledgebase-Article (315131) HOW TO: Use Ntdsutil to Manage Active Directory Files from the Command Line in Windows 2000 on how to perform the offline defragmentation. However this is usually not necessary that often, but should definitely been done after upgrading a domain from Windows 2000 to Windows Server 2003. You may also want to do that after you deleted a lot of objects and the tombstone-lifetime is over.
You can check whenever the garbage collection process runs and how big the amount of whitespace in the database-file is. After you set the following registry-key on your domain controller (usually no need to set it on every DC since the size and whitespace should be about the same on every DC of the domain) you'll get events in the directory services eventlog when the garbage-collection is started, stopped and how much whitespace it detected in the NTDS.dit:
HKLM\System\CurrentControlSet\Services\NTDS\Diagnostics
"6 Garbage Collection" = 1 (reg_dword)
Be careful with the logging-levels underneath that key, they are by default all 0, and you can increase them up to 5 to increase the logging-level. However as higher as the level is you might get performance issues and the eventlogs are flooded with a lot of informations. Keep them at 0, and only increase them slightly if you have specific reasons.
OK, that's it for now, but I'll have some follow-ups on related topics soon.
Windows Server 2003 R2 is supposed to be released this year, and I haven't had time to blog about it yet. So here we go, let's start.
Windows Server 2003 R2 is based on Windows Server 2003 SP1 and does not change the basis of the OS, but provides a lot of new components which you can optionally choose to install. It also requires to to make some changes to the schema, but those are only to provide AD-Extensions for some of the new components.
ADFS - or Active Directory Federation Services - is one of the new technologies which ship with that release of Windows. As Directory Services MVP I'm very existed about ADFS. What is does? Lets assume you have a existing business relationship with another company, and many of your employees need to access resources like Websites for ordering stuff which is provided by your business partner. Without ADFS the business partner needs to maintain a directory of all your users being able to access their site. The users will have to remember another logon-name and password. And those credentials need to be maintained, e.g. if a user forgets his password, new user joins your company, or another user leaving your company. So theirs a lot of maintenance to do. ADFS enables you to provide your accounts to the business partner, and they do not need to maintain another store of credentials. I believe it's getting more clear if you look at how ADFS works:
- A user of your company (= account partner) tries to access e.g. the business partners (= resource partner) website.
- The website is redirecting the browser to it's own Federation Server (of the resource partner, = FS-R).
- The Federation Server is either able to find out to which company the user belongs, or it will prompt to ask. Then it's redirecting the browser to the Federation Server of the account partner (your company).
- The Federation Server of the account partner (FS-A) tries to verify the users identity, either by using integrated authentication (based on the token created when the user logged onto his Windows Client) or by prompting the user for username and password.
- After the FS-A authenticated the user, it creates a token (aka claim) which contains the information configured on the FS-A, e.g. if the user belongs to a special group which defines which rights the user should have on the website (e.g. to order stuff, to verify other orders, to cancel orders,…), or if his name, e-mail or other information should be transferred to the resource partner.
- After the FS-A provided the users browser with the token it redirects the user back to the FS-R.
- FS-R reads the token and changes it to a format which is used at the resource site, then redirects the browser to the website.
- The website is able to verify the token and to give the user the appropriate rights.
Note:
-
As long as the Federation Server on the Resource side was able to figure out to which account partner the user belonged (e.g. separate Websites for each account partner), and the FS-A was able to use integrated authentication, the user was never prompted for anything and had a single-sign-on experience.
-
All traffic is between the client of the user and the different servers, no direct communication between the resource and account partners servers is necessary. The Term about the agreement between the Resource- and the Account partner is "Trust", however I'm not happy with this terminology. If we talk about trusts companies think of loosening up firewalls. Always remember that ADFS only requires HTTPS-Communication from the users browser to the Federation Servers and Web-Servers.
-
All traffic is via SSL on port 443, no special or additional ports are required.
-
The traffic and the token is protected with certificates. Be prepared that you need SSL-Certificates and Code Signing Certificates for the servers.
-
The username and password are never leaving the account partners network. He's issueing a token which the resource partner trusts (done via a code signing certificate).
What else to say? Using ADFS you can also enable access to other than Web resources. E.g. The new Sharepoint Services 2.0 in Windows Server 2003 work with ADFS, and they still require a Windows token. You can use ADFS internally and externally, if you want use it only internally and you are later able to expand it externally easily. Also remember that ADFS might be a great solution to work internally if you have multiple forests.
Here are some links about ADFS:
I've registered for IT-Forum in Barcelona, and I'm looking forward to it. I'll be in the Ask-the-Experts-Area again, probably some Windows Server, Directory Services or R2 related booth. I loved to be able to have a lot of interesting talks at those events in the past, and can't wait for IT-Forum to start.
New Released to Web on Micorosoft.com:
(note: Localized Versions are also available)
The Active Directory Migration Tool version 3 (ADMT v3) simplifies the process of restructuring your operating environment to meet the needs of your organization. You can use ADMT v3 to migrate users, groups, and computers from Microsoft® Windows NT® 4.0 domains to Active Directory® directory service domains; between Active Directory domains in different forests (interforest migration); and between Active Directory domains in the same forest (intraforest migration). ADMT v3 also performs security translation from Windows NT 4.0 domains to Active Directory domains and between Active Directory domains in different forests.
Some of the new features are:
- new backend database
- support for simultaneous migration tasks
- multiple ADMT consoles with delegation
- agent enhancements
- full object rename
Whether you are designing a new Active Directory logical structure, deploying Active Directory for the first time, upgrading an existing Windows environment to Windows Server 2003 Active Directory, or restructuring your current environment to a Windows Server 2003 Active Directory environment, part one of this book will assist you in meeting all of the Active Directory design and deployment goals for your organization. (..)
Let's see - apart from my projects at my customers, doing some technical reviews, community work and other voluntary stuff as setting up portals for knowledge-sharing I've been traveling to Berlin (teaching WS2k3), Düsseldorf (intra-company community work), Hannover (I was presenting stuff in a company event), Redmond (attending the MVP-Summit, see the
MS.com/press coverage, I really enjoyed to talk to the Directory Services Product Group, also see
Erics Blog) and will be traveling to Düsseldorf this week. For some reason I'm sick of airplanes right now, and I expect more this year.