For the GUI and CLI solutions to mean much to you, you need access to the tools that are used in the examples. For this reason, in the majority of cases and unless otherwise noted, I only used tools that are part of the default operating system or available in the Resource Kit or Support Tools. The Windows 2000 Server Resource Kit and Windows Server 2003 Resource Kit are invaluable sources of information, along with providing numerous tools that aid administrators in their daily tasks. More information on the Resource Kits can be found at the following web site: http://www.microsoft.com/windows/reskits/. The Windows 2000 Support Tools, which is called the Windows Support Tools in Windows Server 2003, contain many “must have” tools for people that work with Active Directory. The Microsoft installer (MSI) for the Windows Support Tools can be found on a Windows 2000 Server or Windows Server 2003 CD in the \support\toolsdirectory. The Appendix A contains a complete list of the tools used within this book, where they can be found, and what recipes they are used in.
Once you have the tools at your disposal, there are a couple other issues to be aware of while trying to apply the solutions in your environment, which I’ll now describe.
A best practice for managing Active Directory is to create separate administrator accounts that you grant elevated privileges, instead of letting administrators use their normal user account that they use 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, then 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 to
authenticate with. If the tool you want to use does not have that
option, you can use the
runas command instead. The
following command would run the
from the Resource Kit under the credentials of the administrator
account in the rallencorp.com
> runas /user:firstname.lastname@example.org[RETURN] /netonly "enumprop \"LDAP://dc1/dc=rallencorp,dc=com\""
To run a Microsoft Management Console (MMC) console with alternate
credentials, simply use
mmc as the command to run
> runas /user:email@example.com /netonly "mmc"
This will create an empty MMC console 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 you
are authenticating with does not have local logon rights on the
machine you are running the command from.
There is another option for running MMC snap-ins with alternate credentials. Click on the Start menu and browse to the tool you want to open, hold down the Shift key, and then right-click on the tool. If you select Run As, you will be prompted to enter credentials to run the tool under.
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, I 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 what 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.