The annoying thing about cross-forest
authentication is that the client frequently fails
to locate the correct DC in a trusted forest and is
instead authenticated by a random DC—often
not the DC you prefer the client to use. The good
news is that you can easily solve this problem.
Similar to the cross-domain DC location
process that I already described, when a client
accesses a resource across a forest trust, the client
also queries the trusted forest’s DNS servers
for the correct DCs for authentication purposes.
The key thing to understand here is that the
client queries DNS again for the site-specific
Kerberos service records. The client does so by
combining the site name from its own domain
(MyCompany.net) with the domain name of
the trusted forest’s domain (OtherCompany
.net) and would thus query in the following DNS
hierarchy: _kerberos._tcp.BranchSite._sites.dc._
msdcs.OtherCompany.net. If no such AD site
exists in the trusted forest, which is highly likely
for a forest designed by a different AD team, the
DNS query fails and the client must request the
generic DC locator records. The client might
then be authenticated by DCs of the trusted
forest that are less than ideal to use, which will
effectively slow down the cross-forest access to
data and applications.
To prevent this problem, simply ensure
that you create AD sites with the same names
in both forests. Consider these new sites to be
“shadow” sites of the trusted forest. You don’t
need to add new IP subnets to these sites for
this solution to work, nor do the shadow sites
need to contain real DCs. Instead, create a
dedicated site link between each “shadowsite-
for-MyCompany” and the closest “realsite-
of-OtherCompany” connecting the two
sites. Make sure no other sites are joined to this
site link and that the shadow sites themselves
aren’t joined to any other site links. Doing
so will guarantee that the proper DC of the
OtherCompany.net forest adds the required
SRV records to the respective shadow site via
AutoSiteCoverage. These shadow sites will
now ensure that your clients leverage the correct
and closest DCs for authentication when
accessing resources across a forest trust.
Enhancing the Usability of
the Least Privilege Model
As companies have become more sensitive
to IT security, AD administrators have begun
to use at least two accounts with different
privileges: one account for logon to clients and
to perform regular office tasks (this account
doesn’t have any administrative rights in AD)
and another account with sufficient privileges
in AD to perform administrative tasks such
as user and group management. As is often
the case, increasing security doesn’t make the
processes more user friendly for the end user.
In this case the end user is the AD administrator.
Handling multiple accounts can be a hassle
even when using the different OS features, such
as right-clicking the MMC Active Directory
Users and Computers snap-in and selecting Run as to start the tool with the administrator
account. Although this method works, I find it
particularly annoying that the Run as dialog
box used to enter the administrative credentials
never remembers my AD account—I need
to enter it for every situation in which I need to
elevate my privileges.
My favorite solution to this challenge is
to set up a centrally hosted terminal server
where all relevant administration tools are
installed. AD administrators can then connect
to this terminal server, authenticate with
their administrator account, and perform all
required administrative tasks through the terminal
server session. There’s no requirement
to use Run as, and I can even use RDP files on
my desktop that are preconfigured with the
correct account name. Of course you shouldn’t
opt to store the administrator’s account password
when saving the RDP files. Administrators
can also use a central terminal server
to connect from any client to perform their
duties—the Windows Server Administration
Tools Pack (adminpak.msi) tools don’t have to
be installed locally on the client. Many environments,
however, might be too small to allow implementation of
a terminal server
purely for administrative
purposes, or
other reasons might
exist for running the
AD management
tools from your local
machine.
Another option
to avoid the tedious
and error-prone
task of right-clicking
the icons and
entering your credentials
is to create
your own shortcuts
that execute the Runas utility directly, fully
leveraging its command-line options as well
as those of the snap-ins themselves. And if
your administrator accounts have a clear
prefix or postfix added to the normal user
account, you can leverage simple things such
as the expansion of the USERNAME environment
variables to further simplify managing
shortcuts for multiple users.
As an example, my normal (unprivileged)
user account might be called GUIDOG, whereas
my administrative account is ADM.GUIDOG.
To allow multiple administrators to use the
same shortcut on different machines, I need to
expand various environment variables in the
shortcut I create, which is achieved by enclosing
the respective environment variables between
two percent signs. The following is a sample
command for a shortcut I’d use to start the
Active Directory Users and Computers snap-in
with the administrative account and request
that it binds to a specific DC in my domain:
%windir%\system32\runas /env /
user:%userdomain%\adm.%username%
“mmc %windir%\system32\dsa.msc /
server=w2k8core01”
When I create the shortcut for this command,
I can further enhance the warning effect
and notify myself that I’m switching to a higher
privileged account by using the color options of
the shortcut itself—as for any command prompt,
you can also configure background and font colors
for a shortcut. Figure 2 shows the window that
appears if I double-click the user GUIDOG shortcut.
The command prompt’s red background
color warns me that I’m about to elevate my
privileges. Because the Run as command in the
shortcut appropriately expands %userdomain% ADM.%username%, I no longer have to enter my
account name. Instead I’m prompted to enter
my password for the CORP\ADM.GUIDOG
account right away.
Because Windows shortcuts are real files
(with .lnk extensions), you can copy them to
an appropriate share that’s available to any
other administrator in your AD forest. So if a
different user, JOER for example, also has an
administrative account using the same naming
convention, he can use the same shortcut
for launching the Active Directory Users
and Computers snap-in and will be asked to
authenticate as CORP\ADM.JOER.
64-Bit Windows Challenges
The current trend is a strong move toward
64-bit Windows versions, especially for applications
that can benefit from the increased
memory space that 64-bit OSs offer. AD is one
of those applications—if your AD database
doesn’t fit within the memory limitations that
it incurs on 32-bit Windows Server versions
(which Table 1 shows), upgrading your DCs
to 64-bit Windows on hardware with sufficient
physical memory can greatly improve AD’s
performance, as well as the performance of
dependent applications (e.g., Exchange).
I won’t go into the details of when and
where you should consider leveraging 64-
bit Windows for your DCs. In general, you
won’t run into any problems combining 32-bit
DCs with 64-bit DCs in your AD forest (e.g.,
leveraging Windows Server 2003 x64). No 64-
bit–specific schema extensions are required,
and 64-bit DCs replicate just fine with their
32-bit counterparts. Of course you need to
ensure that you have proper versions of your
drivers, antivirus software,
and monitoring agents
that support your 64-bit
Windows OS. However,
some of the Microsoft ADrelated
management tools
that used to run on your
DCs might no longer function.
The most important
ones that I know of are the
AD Replication Monitor
support tool (Replmon),
the Group Policy Management
Console (GPMC),
and the Active Directory
Migration Tool (ADMT)
Password Export Server
(PES) service. Most 32-bit applications run
with no problem on a 64-bit Windows OS
because they leverage the OS’s Windowson-
Windows 64-bit (WoW64) compatibility
feature. Replmon, GPMC, and ADMT PES
are true exceptions to this rule because they
have other dependencies that WoW64 can’t
meet. Replmon and GPMC run without a
problem on a 32-bit member server and can
thus be further leveraged in a pure 64-bit AD
forest and connect remotely to the 64-bit DCs.
ADMT PES must be installed on a DC, so you
either need to have a 32-bit DC that you can
leverage for this service, or you need to wait for
the upcoming ADMT release—which is slated
for release with Windows Server 2008 and will
include a 64-bit version of the PES service.
Forewarned Is Forearmed
AD is a powerful directory and authentication
service. Its multi-master replication model
ensures the high availability that companies
request from such an important service. But
sometimes the small things that might not
work as expected are the ones that cause the
most pain for an administrator. Knowing about
some of these annoyances ahead of time will
hopefully help you avoid them in your own
infrastructure.
End of Article
Register
