If you are familiar with the O’Reilly Cookbook format, which can be seen in other popular books such as the Perl Cookbook, Java Cookbook, and DNS and BIND Cookbook, then the layout of this book will be familiar to you. The book is composed of 21 chapters, each containing 10 to 30 recipes for performing a specific Active Directory task. Within each recipe are three sections: “Problem,” “Solution,” and “Discussion.” The “Problem” section briefly describes the task that the recipe focuses on. The “Solution” section contains step-by-step instructions on how to accomplish the task. The “Discussion” section contains detailed information about the problem or solution. A fourth section, “See Also,” is included in most recipes and contains references to additional sources of information that can be useful if you still need more information after reading the discussion. The “See Also” section may reference other recipes, MS Knowledge Base articles or documentation from the Microsoft Developer Network (MSDN).
When we first began developing the content for the book, we struggled with how to capture the fact that you can do things in multiple ways with Active Directory. You may be familiar with the famous computer science motto: TIMTOWTDI, or There Is More Than One Way To Do It. With Active Directory, there are often At Least Three Ways To Do It! You can perform a task with a graphical user interface (GUI), such as ADSI Edit, LDP, Active Directory Administrative Center, or the Active Directory Users and Computers snap-in; you can use a command-line interface (CLI), such as the ds utilities (i.e., dsadd, dsmod, dsrm, dsquery, and dsget), nltest, netdom, or ldifde, or freeware tools such as adfind and admod from joeware; and finally, you can perform the same task using a scripting language, such as VBScript, Perl, or PowerShell. Since people prefer different methods, and no single method is necessarily better than another, we decided to write solutions to the recipes using one of each. This means that instead of just a single solution per recipe, we include up to three solutions using GUI, CLI, and programmatic examples; in some cases you’ll find more than one option for a given solution, as in the case where there is more than one command-line utility to perform a particular task. However, in cases where one of the methods cannot be used or would be too difficult to use to accomplish a given recipe, only the applicable methods are covered.
A special note regarding PowerShell coverage in this text:
PowerShell is a command-line and scripting language
introduced by Microsoft. PowerShell’s claim to fame is its use of a
predictable Verb-Noun syntax that can be leveraged
regardless of the technology that it is managing:
Get-Mailbox, and so on. This predictable
syntax is driven by the use of cmdlets (pronounced
“command-lets”) that can be created by individuals and software vendors
alike. The first Microsoft product to rely on PowerShell was Exchange 2007, which
includes a rich set of cmdlets to perform Exchange management tasks. In
fact, there are certain tasks in Exchange 2007 that can
only be performed using PowerShell! Since Exchange
2007, virtually every major product released by Microsoft includes a
PowerShell module for management.
The challenge that Active Directory administrators faced with PowerShell, prior to the release of Windows Server 2008 R2, was that a set of PowerShell cmdlets had not yet been produced by Microsoft to support Active Directory administration tasks. However, that issue was fixed with the introduction of the PowerShell module for Active Directory. Microsoft initially released 76 cmdlets specific to Active Directory administration. Then, with the release of Windows Server 2012, additional cmdlets were introduced. In total, there are now 145 cmdlets for Active Directory administration! PowerShell has come a long way since the previous version of this book. As such, all of the Quest PowerShell cmdlets that were used in the previous version have been replaced with native cmdlets. Most of the VBScript solutions have also been replaced with simpler PowerShell solutions.
Readers who are looking for more in-depth programming coverage of these topics should consult The .NET Developer’s Guide to Directory Services Programming referenced in the Where to Find More Information section at the end of this chapter.
Another challenge with writing this book is that there are now multiple versions of Active Directory deployed on most corporate networks. The initial version released with Windows 2000 was followed by Windows Server 2003 and an incremental update to Windows Server 2003 R2, and then Microsoft released Windows Server 2008 and Windows Server 2008 R2, which provided a lot of updates and new features. With the release of Windows Server 2012, administration has changed and new functionality has been introduced again. We’ve decided to go with the approach of making everything work under the most recent version of Active Directory first, and earlier versions of Windows second. In fact, the majority of the GUI solutions will work unchanged all the way back to Windows 2000. The PowerShell solutions will work out of the box with Windows Server 2008 R2 or newer domain controllers. By using the Active Directory Management Gateway Service, the PowerShell solutions will work with domain controllers running Windows Server 2003 SP2 or Windows Server 2008. For the recipes or solutions that are specific to a particular version, we include a note mentioning the version it is targeted for. In particular, because so much has changed since the introduction of Windows Server 2008 R2, the majority of our focus will be on Windows Server 2008 R2 and later.
You’ll find a number of references to third-party command-line tools such as adfind, admod, oldcmp, findexpacc, and memberof. These tools were developed by Microsoft Directory Services MVP joe Richards, and he has made them available for free download from his website. While these tools are not native to the Windows operating system, they have become an invaluable addition to many Active Directory system administrators’ toolkits, and we include them here to showcase their capabilities.
Once you have the tools at your disposal, there are a couple of other issues to be aware of while trying to apply the solutions in your environment, which we’ll describe in the following sections.
A best practice for managing Active Directory is to create separate administrator accounts to which you grant elevated privileges, instead of letting administrators utilize the user account to access other Network Operating System (NOS) resources. This is beneficial because an administrator who wants to use elevated privileges has to log on with his administrative account explicitly instead of having the rights implicitly, which could lead to accidental changes in Active Directory. Assuming you employ this method, you must provide alternate credentials when using tools to administer Active Directory unless you log on to a machine, such as a domain controller, with the administrative credentials.
There are several options for specifying alternate credentials.
Many GUI and CLI tools have an option to specify a user and password
with which to authenticate. If the tool you want to use does not have
that option, you can use the
command instead. The following command will run the
enumprop command under the credentials of the
administrator account in the adatum.com
> runas /user:email@example.com /netonly "enumprop "LDAP://dc1/dc=adatum,dc=com""
You can also open a Windows command prompt using alternate
credentials, which will allow you to run commands using these elevated
credentials until you close the command prompt window. To open a command
prompt using the
> runas /user:firstname.lastname@example.org /netonly "mmc"
This will create an empty MMC from which you can add consoles for any snap-ins that have been installed on the local computer.
/netonly switch is
necessary if the user with which you are authenticating does not have
local logon rights on the machine from which you are running the
command, such as a user ID from a nontrusted domain.
There is another option for running MMC snap-ins with alternate credentials. In Windows Explorer, hold down the Shift key and then right-click on the tool you want to open. If you select Run As Different User, you will be prompted to enter credentials under which to run the tool.
Another issue to be aware of when following the instructions in the recipes is whether you need to target a specific domain controller. In the solutions in this book, we typically do not target a specific domain controller. When you don’t specify a domain controller, you are using a serverless bind, and there is no guarantee as to precisely which server you will be hitting. Depending on your environment and the task you need to do, you may want to target a specific domain controller so that you know where the query or change will be taking place. Also, serverless binding can work only if the DNS for the Active Directory forest is configured properly and your client can query it. If you have a standalone Active Directory environment that has no ties to your corporate DNS, you may need to target a specific domain controller for the tools to work.
One reason for the lack of native command-line tools to do this is that the command line is not well suited for manipulating numerous attributes of an object simultaneously. If you want to specify more than just one or two values that need to be modified, a single command could get quite long. It would be easier to use a GUI editor, such as ADSI Edit, to do the task instead.
The LDAP Data Interchange Format (LDIF) was designed to address this issue. Defined in RFC 2849, LDIF allows you to represent directory additions, modifications, and deletions in a text-based file, which you can import into a directory using an LDIF-capable tool.
The ldifde utility has been available since
Windows 2000, and it allows you to import and export Active Directory
content in LDIF format. LDIF files are composed of blocks of entries. An
entry can add, modify, or delete an object. The first line of an entry is
the distinguished name. The second line contains a
changetype, which can be
delete. If it is an object addition, the rest of
the entry contains the attributes that should be initially set on the
object (one per line). For object deletions, you do not need to specify
any other attributes. And for object modifications, you need to specify at
least three more lines. The first should contain the type of modification
you want to perform on the object. This can be
add (to set a previously unset attribute or to
add a new value to a multivalued attribute),
replace (to replace an existing value), or
delete (to remove a value). The
modification type should be followed by a colon and the attribute you want
to modify. The next line should contain the name of the attribute followed
by a colon and the value for the attribute. For example, to replace the
last name attribute with the value Smith, you’d use the following
dn: cn=jsmith,cn=users,dc=adatum,dc=com changetype: modify replace: sn sn: Smith -
Modification entries must be followed by a line that contains only a
hyphen (-). You can add additional modification actions after the hyphen,
each separated by another hyphen. Here is a complete LDIF example that
jsmith user object and then
sn attributes for that object:
dn: cn=jsmith,cn=users,dc=adatum,dc=com changetype: add objectClass: user samaccountname: jsmith sn: JSmith dn: cn=jsmith,cn=users,dc=adatum,dc=com changetype: modify add: givenName givenName: Jim - replace: sn sn: Smith -
This book is filled with examples. Every recipe consists of one or
more examples that show how to accomplish a task. Most CLI- and
PowerShell-based solutions use parameters that are based on the domain,
forest, OU, user, and so on, that is being added, modified, queried, and
so on. Instead of using fictitious names, in most cases we use replaceable
text. This text should be easily recognizable because it is in italics and
surrounded by angle brackets (
<>). Instead of describing what each
replaceable element represents every time we use it, we’ve included a list
of some of the commonly used ones here:
Distinguished name of the domain (e.g.,
Distinguished name of the forest root domain (e.g.,
Fully qualified DNS name of the domain (e.g.,
Fully qualified DNS name of the forest root domain (e.g.,
Single-label or fully qualified DNS hostname of the domain
Distinguished name of the user (e.g.,
Distinguished name of the group (e.g.,
Single-label DNS hostname of the computer (e.g.,
While it is our hope that this book provides you with enough information to perform most of the tasks you need to do to maintain your Active Directory environment, it is not realistic to think that we have covered every possible task. In fact, working on this book has made us realize just how much Active Directory administrators need to know.
Now that Active Directory has been around for a number of years, a significant user base has been built, which has led to other great resources of information. This section contains some of the valuable sources of information that we use on a regular basis.
If you have any questions about the complete syntax or usage
information for any of the command-line tools we use, you should first
take a look at the help information for the tools. The vast majority of
CLI tools provide syntax information by simply passing
/? as a parameter. For example:
> dsquery /?
The Microsoft Support website is a great source of information and is home to the Microsoft Knowledge Base (MS KB) articles. Throughout the book, we include references to pertinent MS KB articles where you can find more information on the topic. You can find the complete text for a KB article by searching on the KB number at support.microsoft.com/default.aspx. You can also append the KB article number to the end of this URL to go directly to the article: http://support.microsoft.com/kb/<ArticleNumber>.
MSDN contains a ton of information on Active Directory and the programmatic interfaces to Active Directory, such as ADSI and LDAP. We sometimes reference MSDN pages in recipes. Unfortunately, there is no easy way to reference the exact page we’re talking about unless we provide the URL or navigation to the page, which would more than likely change by the time the book is printed. Instead, we provide the title of the page, which you can use to search on via msdn.microsoft.com/library.
This site is the starting point for Active Directory information provided by Microsoft. It contains links to white papers, case studies, and tools.
This site is the starting point for PowerShell information provided by Microsoft. This will be an interesting site to keep an eye on as the various Microsoft product groups release new and updated PowerShell support.
This forum is a great place to ask a question and confer with other Active Directory administrators and experts. It is frequented by some of the top Active Directory experts in the business.
Webcasts are on-demand audio/video technical presentations that cover a wide range of Microsoft products. There are several Active Directory−related webcasts that cover such topics as disaster recovery, upgrading to Windows Server 2003 Active Directory, and Active Directory tools.
The DirTeam collection of blogs features content from very active members of the Directory Services MVP community.
This is the home of the joeware utilities that you’ll see referenced throughout this book; you can always download the latest version of adfind, admod, and so on, from joe’s site, as well as browse FAQs and forums discussing each utility.
This is another site that is run by a Microsoft MVP and that contains a number of valuable links and tutorials.
This site features regularly updated content from members of the Directory Services support organization within Microsoft.
This is the home page for the ActiveDir Active Directory mailing list. It includes links to Active Directory Services blogs, as well as articles, tutorials, and links to third-party tools.
Just as the ActiveDir list is crucial for AD administrators, this site is extremely valuable for AD developers. It also includes user forums where participants can post questions about AD programming topics.
The ActiveDir mailing list is where the most advanced Active Directory questions can get answered. The list owner, Tony Murray, does an excellent job of not allowing topics to get out of hand (as can sometimes happen on large mailing lists). The list is very active, and it is rare for a question to go unanswered. Some of Microsoft’s Active Directory program managers and developers also participate on the list and are very helpful with the toughest questions. Keeping track of this list is crucial for any serious Active Directory administrator.
This is a good all-purpose book on Active Directory. A few of the topics the Fifth Edition covers are new Windows Server 2012 features, designing Active Directory, upgrading from Windows 2000, Active Directory Lightweight Directory Services (AD LDS), Exchange 2013, and Active Directory automation.
Written by two notables in the Directory Services programming community, this book is a practical introduction to programming directory services, using both versions 1.1 and 2.0 of the .NET Framework.
This is a general-purpose monthly magazine for system administrators who support Microsoft products. The magazine isn’t devoted to Active Directory, but generally, related topics are covered every month.