Learn AD in 15 Minutes a Week: Active Directory Domains and Trusts MMC, Part 2
May 16, 2003
Welcome to the 20th installment of "Learn Active Directory Design and Administration in 15 Minutes a Week," a weekly series aimed at current IT professionals preparing to take the new Windows Active Directory Design and Administration exams (70-219 and 70-217 respectively), as well as newcomers to the field who are trying to get a solid grasp on this new and emerging directory service from Microsoft.
This installment is going to take a further look at the Active Directory Domains and Trusts Microsoft Management Console and offer a review of some of the concepts surrounding the tool's use and functionality.
[NOTES FROM THE FIELD] - I have gotten some email recently about how I am going to address Active Directory articles as far as the changes that have been implemented in Windows Server 2003. For now I am going to keep the main course of these articles in this column focused on the 70-217 AND the 70-219 exams.
Any Active Directory articles that are going to be totally centered on Windows Server 2003 Active Directory features will be found on the Windows Server 2003 page for the time being.
The Active Directory Domains and Trusts Microsoft Management Console (MMC) is part of the administrative tools that are installed by default on systems that have been configured as domain controllers.
The tool can also be installed on a Windows 2000 Professional or Windows XP Professional workstation in order to administer the domain from a console other than the domain controllers themselves by installing and utilizing the proper ADMINPAK administrative tools (Adminpak.msi) .
[NOTES FROM THE FIELD] - In order to maintain either a Windows 2000 domain or a Server 2003 domain from a Windows 2000 Professional or an XP Professional workstation, you should download and install the appropriate Adminpak (Adminpak.msi) when the CDROM you need is not available.
Windows Server 2003 Administration Tools cannot be installed on a Windows 2000-based computer.
The Adminpak.msi tools can NOT be installed on any earlier operating system such as NT4.
The Windows Server 2003 ADMINPAK can be found on the Windows Server 2003 CD which will allow you to install the Administration Tools onto computers that are running the following operating systems:
With the RC2 version of ADMINPAK you can manage the following operating systems:
When you install the Administration Pack, all of the available tools in the Administration Pack are installed by default. You can also opt to install individual, specific Server Administration Tools by using Windows Installer command line switches
msiexec /i adminpak.msi ADDLOCAL=<TOOLNAME> /qb
TOOLNAME is the name of the Server Administration Tool that you want to install singly.
In order to install the Active Directory Domains and Trusts Microsoft Management Console you would enter
msiexec /i adminpak.msi ADDLOCAL= FeADTools /qb
This would actually install all three of the Active Directory Tools at once;
The Active Directory Domains and Trusts Microsoft Management Console allows you to set UPN (User Principal Name) suffixes for a domain by right clicking "Active Directory Domains and Trusts" (not the domain itself) and choosing properties.
This will bring up the UPN Suffixes property page where you can add alternate logon names for users.
For example, if the name of a domain is ZANDRI.NET, users could logon to systems by using one of two formats.
The user could log on the traditional "legacy" way by entering a user name such as JUSER, supplying a password in the password field and setting the proper domain in the "Log on to:" field via the drop down box.
The user also has the option of logging on by entering JUSER@ZANDRI.NET and entering a password.
The JUSER section of the UPN name is the actual username and the section after the "@" symbol is the domain name.
You will notice that when this is done the "Log on to:" becomes grayed out so that it cannot be set, the domain choice of ?@ZANDRI.NET? has done this for us automatically so the "Log on to:" field is no longer needed.
By setting other optional UPN suffixes you allow users from different domains in the same forest to logon on with one simple logon naming convention.
Let's say for example your domain looks like it does in the diagram below:
In order for JUSER3 to log into southamerica.gunderville.com using a UPN name they would have to enter JUSER3@southamerica.gunderville.com. JUSER6 from the northamerica domain would have to enter JUSER6@northamerica.gunderville.com.
If UPN names had been set up so that all users in the gunderville domain and the two child domains could use @gunderville.com logins would be simpler as all users would only have to enter @gunderville.com after inputting their username.
[NOTES FROM THE FIELD] - Users in gunderville.com are already going to be logging in with JUSER@gunderville.com as that is where their actual user accounts exist.
User accounts in the two respective child domains are not located in gunderville.com but by using UPN suffixes they would be able to log into the domain where their user account existed by simply entering @gunderville.com.
UPN names must be unique in the forest.
If there is an actual user account named "Jason" in gunderville.com there can also be a user account of "Jason" in northamerica.gunderville.com, however, Jason@gunderville.com would most likely be used by the "Jason" user account in gunderville.com.
The user of the "Jason" account in northamerica.gunderville.com would have to use some other @gunderville.com log on name (for example Jasonz@gunderville.com) in order to make the UPN name unique in the forest.
Well, that wraps up this section of "Learn Active Directory Design and Administration in 15 Minutes a Week." I hope you found it informative and will return for the next installment. If you have any questions, comments or even constructive criticism, please feel free to drop me a note. I want to write good, solid technical articles that appeal to a large range of readers and skill levels and I can only be sure of that through your feedback.
Until then, best of luck in your studies and remember,
I used to think that "Legally Drunk" was the funniest oxymoron I had heard until I heard someone mention something about "Business Ethics."
Jason Zandri, MCT, MCSE, Security+ Certified Professional, Certified Information Systems Security Professional (CISSP), currently holds the position of Technical Account Manager at Microsoft Corporation and has worked as a technical trainer and consultant for a variety of corporate clients in Connecticut over the past six years. He is available to work on an independent contract basis for technical authoring and editing, including books, articles, and whitepapers as well as customized corporate training and Microsoft CTEC training.