Mark Minasi's Windows Networking Tech Page
Issue #56 October 2006
To subscribe, visit http://www.minasi.com/nwsreg.htm.
To unsubscribe, link to http://www.minasi.com/unsubs.htm.
To change e-mail address, switch between HTML or text format, etc., link
to http://www.minasi.com/edit-newsletter-record.htm.
Visit the Archives at http://www.minasi.com/archive.htm.
Please do NOT reply to this mail; for comments, please link to www.minasi.com/gethelp. Document
copyright 2006 Mark Minasi.
What's Inside
- News
- New Two-Day Seminar "Supporting Vista" Comes to DC, NY, Dallas,
Seattle in December
- Mastering Windows Server 2003, Upgrade Edition for SP1 and R2
has arrived
- Tech Section
- DCPROMO Failing? Not Getting GPOs? Could Be "Token Bloat!"
- SP1 Offers a Nice DNS TEST in DCDIAG
- Conferences
- Bring a Seminar to Your Site
News
This month, I've got three announcements: the Vista seminar is
coming in December, the new Server 2003 book is out, and I've put
together a utility that lets you play with a part of Vista that most
folks haven't been able to touch, until now. Then I've got a
couple of tips on fixing and maintaining your Active Directory via some
Registry fiddling on your domain controllers and some changes to DCDIAG
that SP1 wrought. All useful stuff, I hope ... but first, a word from our sponsor.
New Two-Day Seminar "Supporting Vista" Comes to DC, NY, Dallas,
Seattle in December
Now that I've finished writing my upcoming book Administering
Vista Security: the Big Surprises, I finally had the time to
put together my two-day "Supporting Vista" seminar, and I'm bringing it
to New York (well, Mahwah, actually, but it's close), the DC area (out
by Dulles airport), Seattle (downtown) and Dallas (downtown). In
two days of lecture and demonstrations, I'll show you how installing,
configuring, managing, securing and troubleshooting Vista is different
from doing the same things for XP... and you'll learn all that without
falling asleep.
You can see a course outline for the new Vista class at
www.minasi.com/vista/vsupport.htm and you can find the links to sign
up for Mahwah (November 30/December 1), Dallas (December 4-5), Seattle
(December 7-8), or DC (December 11-12). Even if you're not
planning on rolling out Vista any time soon, come to this seminar to
find out about the pains and gains of Vista!
Mastering Windows Server 2003, Upgrade Edition for SP1 and R2
has Arrived
As I explained in an earlier newsletter, I chose not to create a
second edition of Mastering Windows Server 2003, but instead to
create a whole new book that picks up where Mastering left off.
This new 744-page volume covers all of the new features in 2003 SP1,
covers the major downloadable 2003 modules (SharePoint, Unix
integration, Active Directory Application Mode), and the handful of
features that are only available on 2003 R2 (DFSR, the new quotas and
file filters, the Printer Management Console and more). This book
is intended to enhance your skill set whether you're using the original
Windows Server 2003 with SP1 added, or if you're running Windows Server
2003 R2. And Bookpool's advertising it at $19.95! Find out
more at
www.minasi.com/sp1r2book.
My New Free "chml" utility Available to Work With Windows Integrity
Controls
Windows
Vista includes a new notion of what were
originally called "Mandatory Integrity Controls" but eventually
became "Windows Integrity Controls." Under WIC, every object
that have permission can also have a label that identifies its
"integrity level." There are five integrity levels, from highest
trustworthiness to lowest:
- System
- High
- Medium
- Low
- Untrusted
Files and folders can have integrity levels, and
administrators can change those levels between untrusted and
high -- admins can't set integrity levels higher than "high"
because admins run at the "high" integrity level and no one can
elevate an object's integrity level higher than him or herself.
(And yes, I've already tried running it from the Scheduler,
which runs at System level, but no dice. Microsoft
anticipated me and created a brand-new cryptic message just for
smart-alecs like me.)
(Jargon alert: as Microsoft has messed with these names quite
a bit as they work on Windows Vista, you might a number of
alternative phrases. What was once "Mandatory Integrity Control"
is now "Windows Integrity Control" or, in at least one source,
"Windows Integrity mechanism." The integrity levels themselves
are sometimes called "Windows Integrity Levels" or "Mandatory
Integrity Levels." The integrity levels are implemented on
objects as a system access control entry (SACE) that is called a
"Mandatory Label" and shows up with a name like "Mandatory
Label\Medium Mandatory Level." I am praying that they'll sort
this out by the time that Vista ships!)
The basic use of integrity levels in Vista is put a fence
around any files gotten from the Internet. Things downloaded
automatically from the Internet get an integrity level of "low."
Normal users and their files get an integrity level of "medium."
That's useful because WIC's Prime Directive is, "you cannot
modify an object with a higher integrity level."
I needed a tool to let me change integrity levels, mandatory
labels, Windows integrity levels or mandatory integrity levels
-- whatever you want to call 'em! -- on files and folders to
write the WIC chapter in my book Administering Vista
Security: the Big Surprises, coming out in December, but
none worked in Vista. (There is a command "icacls" that will
change integrity levels, but it didn't work as of the post-RC1
build 5728.) So I
wrote chml. You can download it
here.
Just typing "chml" and pressing enter will provide several
pages of syntax and examples. To run this, you'll need Vista and
you must give your account the new Vista privilege "modify
object labels." You can find that in the "User Rights" part of
Group Policy on a Vista machine.
Tech Section
DCPROMO Failing? Not Getting GPOs? Could Be "Token Bloat!"
Now and then, I run into problems at large client sites wherein all
of a sudden noticeable numbers of users can no longer log onto Active
Directory. It's baffling because the error messages tend not to run along the
lines of the standard "no domain controller found" or "no logon servers
were available to process your request" kinds of errors.
Instead, some users -- just some -- notice that they're not getting
their GPOs. And some administrators are absolutely unable to do a
DCPROMO and make it work... but others can.
Mysterious, eh? Well, I'll spare you the long
tales of smoking this out, because in the end, the cause was simple:
the users (or administrators, in the case of the DCPROMO problem) were
members of too many groups.
When Microsoft implemented Kerberos in Active Directory back in
Windows 2000, they were careful to "color within the lines," so to
speak, and build their Kerberos along the lines of RFC 1510, which
describes Kerberos as a standard. Now, Microsoft clearly needs to
put data in its Kerberos authentication packets that RFC 1510's
designers would not have foreseen or, probably, cared about.
Things like the security token that you get when you successfully log
onto a resource like a print server. But RFC 1510 provides for
such data with an area set aside for implementation-specific
information, and that's where Microsoft puts your token.
Unfortunately, Microsoft set aside a particular amount of space for
that token and, well, tokens can grow. Recall that Windows
security tokens mainly comprise
- Your user SID (security ID).
- Your user privileges. We tend to call them "user rights"
because that's what the NT and Windows GUI have called them since NT
3.1, but in fact what we call user rights actually break down into
two parts. The first part is "logon rights," which are
that group of rights that include "deny access across the network,"
"right to log on locally" and the like -- anything pertaining to
letting you log on in some manner (interactively, over the network,
as a batch file, etc.) The second part, the remaining rights,
are called "privileges." The ability to shut down a system or
change its time are two examples of privileges. Your token
contains just your privileges, not your user rights.
- Your groups: the SIDs of whatever groups your user account
belongs to.
- Your SID history, if implemented. This is a useful tool
when migrating users from one domain to another, and allows you to
hang onto your old SIDs for authentication purposes. They show
up as group SIDs and so live in the "groups" part of the token.
- Your Windows integrity level, if you're running Windows Vista.
This basically identifies how "trustworthy" you are to the system. The integrity level also shows up as
looking like a group SID.
In terms of token size, it's easy to plan for space for the user SID,
as it's always the same size, and privileges, as there are only a little
over two dozen possible user privileges. But how many group SIDs
to plan for? There's no way to make a really good guess, as an
Active Directory user can quite literally be a member of hundreds of
groups. (I once ran into a client who'd messed with migrations so
much that their users had 50 SIDs just in their SID history!)
In the case of the Kerberos field, Microsoft decided to leave enough
space for about 70 groups. Now and then, I run into clients who
have users who have exceeded the magic number... and that's when
Kerberos authentication fails. And that's when things get
strange. You may recall that if Active Directory can't log you on
via Kerberos, then it'll log you with NTLM and no, I know of no way to
stop that failover behavior, and, further, there's no obvious way to
know how you were logged on, by Kerberos or NTLM. That could mean
that you'd seemingly get logged in for most of your needs, as an NTLM
login provides almost the same things as does a Kerberos login, but not
for all... like when you try to run a DCPROMO as a domain/enterprise
administrator, or when you notice that you didn't get your group
policies.
What to do about it? Well, there's a couple of options.
First, you can go digging in the Registry and tell Kerberos to set aside
more space for SIDs. Fire up Regedit and navigate to
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters.
Then create a new key -- yes, that's a key, a folder, not a value entry
-- called "Parameters." Inside that key, create a new REG_DWORD
value entry called "MaxTokenSize." The default token size in
decimal is 12,000; you can set it as high as 65,535.
Alternatively, Knowledge Base article 280830 points to a hot fix that
render the Registry fiddling unnecessary. KB article 327825
discusses the hotfix in greater detail.
SP1 Offers a Nice DNS TEST in DCDIAG
Whenever I help someone set up Active Directory so that it works as
trouble-free as possible, I always insist on the same thing: a
well-set-up DNS infrastructure. If AD starts getting strange,
chances are good it's a DNS problem. But how to know if you've got
DNS set up right?
Well, I discuss that in some detail in my books and lectures, but
here's an interesting short-cut. 2003 Service Pack 1 changed
DCDIAG just a bit by adding the /test:dns option and a few others.
Prior to running DCPROMO on a system in anticipation of making it a
domain controller, you can tell DCDIAG to check that DNS is ship-shape
by running DCDIAG on the soon-to-be DC like so:
dcdiag /test:dcpromo /dnsdomain:domainname /newforest|/newtree|/childdomain|/replicadc
Where domainname is the Active Directory domain's DNS name, as
in "bigfirm.com" -- the NetBIOS name like "BIGFIRM" won't work, and then
follow it with one of these four options; use
- /newforest if the DC will be the first DC in the first domain in
the forest;
- /newtree if the DC will be the first DC in the first domain in a
new tree in an existing forest;
- /childdomain if it's the first DC in a new domain that lives in
an existing tree;
- /replicadc if it's a new DC in an existing domain.
For example, to check for DNS obstructions to creating a second
domain controller in the AD domain bigfirm.com, I'd sit at the machine
that I intend to become that second DC and type
dcdiag /test:dcpromo /dnsdomain:bigfirm.com /replicadc
DCDIAG also lets you verify that a given DC can properly register its
SRV and CNAME records in DNS by typing
dcdiag /test:registerindns /dnsdomain:domainname
|