Mark Minasi's Windows Networking Tech Page
Issue #44 February 2005
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
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 2005 Mark Minasi.
- Active Directory and Security Seminars On Their Way
- The Software Conspiracy is Now a Free Download
- Three-peat on "Favorite Technical Author"
- Tech Section
- Adjusting 2003's TCP/IP Stack For Maximum Throughput
- SubInACL Doesn't Work? Here's Why
- How to Control Who Can See Your Logs
- Security Descriptor Definition Language (SDDL) Explained:
How It Works And Why You Care
- Bring a Seminar to Your Site
Many thanks for all the letters you sent me on my last newsletter, I'm
glad you liked it so much. I hope this one will be as popular!
This month, I've got a free book for you to download, my 1999
book The Software Conspiracy: Why Software Companies Put Out Faulty
Products, How They Can Hurt You, And What You Can Do About It.
You'll also get a little TCP/IP tweaking advice and a set of related
articles, one of which explains the SDDL, something you'll really need
to understand if you want to control security and Active Directory
delegations. But first, a word from our sponsor...
My Seminars are Coming to Seattle, Dallas, Chicago and Philadelphia
This year, I need time to do some large writing projects, so thus far
I'll only be running my Security and Active Directory seminars in
Seattle (March), Dallas (April), Chicago (June) and Philly (June).
Seminar: Securing Your Windows Desktops and Servers
Everyone wants to secure their network, but many don’t feel that they
have the time. I find that a lot of people have a general idea about what
they should be doing to secure their networks -- they've heard terms like
SMB signing, null session, secure channel, LM hash, and so on -- but
haven't the time to sift through the often-contradictory knowledge base
articles and the welter of group policy settings, Registry hacks, patches
and the like. In just one day, I go through what the big security issues
mean and help attendees understand the exact step by step methods that you
need to know to make your system more secure.
If you'd like to find out more, please visit
Running a 2003/2000-Based Active Directory
AD's great, but it can be a fragile flower if not built and maintained
properly. Find out how to build, implement, maintain, and repair Active
Directory at "Running a 2003/2000-Based Active Directory;" information at
My Book The Software Conspiracy is Now a Free Download
Do computer bugs bug you? Find out why they're so prevalent and what
you can do about them by grabbing a copy of my 1999 McGraw-Hill book
The Software Conspiracy: Why Software Vendors Produce Faulty Products,
How They Can Harm You, And What You Can Do About It. It's a PDF you
can download for free. If you've read my other books then you know my
technical writing -- but this book is aimed at both techies and
non-techies. The much-respected Kirkus Reviews said of that it was "A
lucidly written, eminently practical guide to fighting back against the
modern scourge of software 'bugs' ... An absorbing, easily
understandable, and inspiring book..." Get your copy at
Three-Peat On "Favorite Technical Author"
Okay, I'm bragging a bit, but I'm so proud of this... for the third
year, CertCities.com has run a poll asking for favorite certifications
and the like of thousands of their members. They also ask who's
their favorite author, and for the third year in a row they voted the
title to me. I cannot thank those of you who voted enough.
It's so cool, thanks!
Server 2003's TCP Stack Can Be Too Slow
Sometimes an old tip becomes useful again...
Techie instructor Roger Grimes passed along this tip about Server 2003's FTP
server from KB article 891371. Apparently they set the TCPWindowSize -- an
important TCP tuning parameter that I discuss in my Tuning CD and talk -- to a
too-small value, with the result that downloading something from a 2003-based
FTP server would be slower than you'd expect. (In fact, it appears to me
that any TCP-based downloads would be affected by this parameter,
including HTTP file transfers.)
Fix this by going to HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Services\ Tcpip\ Parameters,
and look for TCPWiindowSize. If it's not already there, then create a
REG_DWORD entry named TCPWindowSize. Set that parameter to its maximum
value of FFFF hex or decimal 65535. Reboot and you should get better
throughput. But there may be a few gotchas...
First, you may see no difference. In Windows 2000, you also needed to
create and set another REG_DWORD, "GlobalMaxTCPWindowSize," and give it the same
value. I'm not sure that's not still a good idea in 2003. Similarly,
2000 had a problem in that if you set the window to its maximum size -- 65535 --
then 2000 ignored you. According to another KB article, the largest value
for TCPWindowSize/GlobalMaxTCPWindowSize that would work is 64240. Try
different sizes and see which yield the best transfer speeds. By the way,
you want to set these values both on the server and the client system.
2003's Subinacl Doesn't Work, Download A Newer One
This tip may save you from beating your head against a wall, as I did.
I've written in the past about SubInACL, a nice Resource Kit tool that's sort
of the "Swiss army knife" of permissions. It lets you do neat stuff like
record something's permissions -- and here "something" means a file, directory,
share, Registry, Active Directory object or service permission, among others -- and restore it later, or restore it to
a different object. It'll also let you set ownership and primary group
values for an object. It'll also clean out permissions that no refer to
accounts that no longer exist, and will swap permissions referring to an old
domain with ones referring to a new domain -- quite handy for migrating member
servers from one domain to another. You can read the two long articles I
wrote on it at Windows IT Pro Magazine's Web site,
www.windowsitpro.com, and when I last
checked they're a no-charge read.
But if you happen to be trying out Subinacl from 2003's Resource Kit,
then nothing will work right. Microsoft released a fixed version last
June; you can find it at
www.microsoft.com/downloads and search on "subinacl."
Controlling Who Can Read a Log File in 2003
I've been asked a few times, "how can I grant someone the ability to look at
a computer's event logs?" For example, someone might want to grant a help
desk person the ability to look at any user's Security log file. The easy
way, of course, is to make that help desk person a local administrator on every
workstation, but that may mean granting the help desk a bit more power than you
might want. How, then, to say that a particular group or person has the
power to read an event log?
A member of our online forum found KB article 323076 which answers the
question by offering a Registry key:
In this key, create a REG_SZ string called CustomSD. In that key, you
set the permissions that you want for the Security log. (There is also,
not surprisingly, a key for Application, System, and whatever other logs your
system contains.) There's just one problem, though... you must set the
security using an obscure language for describing permissions that Microsoft
calls the Security Descriptor Definition Language, or SDDL. Here's an
example of an SDDL permission from the article:
O:BAG:SYD:(D;; 0xf0007;;;AN) (D;; 0xf0007;;;BG) (A;; 0xf0007;;;SY)
(A;; 0x5;;;BA) (A;; 0x7;;;SO) (A;; 0x3;;;IU) (A;; 0x2;;;BA) (A;; 0x2;;;LS)(A;;
Don't run away, I'm going to explain SDDL in the next article. CustomSD only works on Windows Server 2003; it doesn't work on XP or earlier
systems. Many thanks to Willem Kasdorp (wkasdo on the Forum) for some
Decoding an SDDL string
Where did that SDDL string thing come from, anyway? Well, you need to
understand it in order to create the CustomSD entry in the Registry.
You'll also need to understand SDDL strings if you want to use the DSACLS command-line
tool to control Active Directory delegations, or to read or modify a security template.
All of those things describe permissions in SDDL format. So here's a basic
tutorial on SDDL strings -- it's not complete, but it'll get you started, make
you able to understand most SDDL strings and points you to more references.
Anyone who's been watching Windows security for the past few years has
noticed that Microsoft doesn't just put permissions on files and folders, it
puts them everywhere. You control who's affected by a group policy
with GPO permissions. You control who can turn services on and off with
service permissions. You delegate power within an AD with permissions.
What kind of permissions a given object can have varies from object to object:
for example, the "execute"
permission would make sense on a file, but not on a user account, just as the
"change password" permission that makes sense on a user account would be
meaningless on a file. (And Microsoft doesn't make things easier to
understand when they make the "execute" permission for a file act as the
"traverse folder" permission on a directory.)
Objects Have Security Descriptors
But no matter what the nature of the particular permissions are, all
objects with permissions have the same four components -- an owner, a primary
group, a DACL and a SACL. Together, those four things are called the
object's "security descriptor."
You may be familiar with the notion of an owner, but in case you need a
refresher, an object's owner is an account that
has one very great power: it can modify permissions on an object. If
I were the owner of a file and you, an administrator, were to remove all of my
permissions, so that I could not even read the object, then I could still
reverse your action and give myself whatever permissions I wanted on that
Then there's a primary group. Most of us are unaware and uncaring about
the fact that objects have a primary group that they're a member of, but that
characteristic is there. In my experience it's really only relevant if
you're running POSIX apps or setting up shares for Macintosh access, which is
probably why most folks don't know that primary groups exist.
DACLs and SACLs
Then there's the DACL and the SACL, the Discretionary Access Control List and
the System Access Control List. Right-click any file or folder on an NTFS-formatted
drive and choose Properties, then Security, and you'll see a list of people
and/or groups that have varying levels of access to that file or folder.
For example, I've got a file on my hard disk called acctinfo.dll, a file that
comes with the Resource Kit. (It's a file that adds information to Active
Directory Users and Computers pages, but that's a story for another day.)
If I right-click on that file and choose Properties/Security then I get a dialog
box labeled "acctinfo.dll Properties" with General, Version, Security and
Summary tabs. If I click the Security tab, then I get a field "Group or
user names:" atop a box that can contain one or more entries. On this
file, however, there's only one entry -- Everyone, which refers to the Everyone
group. Looking in the bottom part of the Security page, I see another
section, "Permissions for Everyone" and it appears that Everyone has full
control, and can do anything.
In short, I'm looking here at a list -- again, a list with just one entry,
but a list nonetheless -- of permissions on this object. You've probably
seen something like this before, and probably refer to it in the way that most
of us in the Windows world do, as an "ACL," pronounced "ackel,"
which rhymes with
"cackle." ACL means Access Control List and strictly speaking, the list
of permissions itself is the ACL. Every entry in it is called an Access Control Entry or
ACE. Most of us, however, would look at an access control list with a
bunch of entries and say that the object has a "bunch of ACLs on it" or the
like. To be precise, however, it's more correct in Microsoft-ese to say
that the entire list is an ACL that contains a number of ACEs. Again, this
particular ACL has only a single ACE. For reasons known only to Microsoft,
an ACL like this is called a "Discretionary" ACL, or DACL. It has that
name to distinguish the DACL from another, optional, access control list, the
System Access Control List or SACL.
Objects on your system have SACLs if you've enabled object auditing and want
to audit some level of access to that particular object. To tell your
system, "make a note of every time that Joe reads this item," then you must
create an entry in the SACL (I've seen them called "AACEs" in some Microsoft
literature, as opposed to a "PACE" in a DACL) to that effect.
As I've not seen too many people actually use object auditing, I'll skip most
discussion of the SACL here.
There isn't really a single place in the GUI that lets you examine and change
all of the security descriptor, but you can see most of it from the Security tab
when you click the Advanced button in the Security tab. That'll give you a
property page labeled "Advanced Security Settings for [whatever you're looking
at]." On that page are tabs labeled Permissions, Auditing, Owner, and
Effective Permissions. (That last one first appeared in XP, so you won't
see it in 2000.) The Permissions tab lets you view and control the
permissions -- the DACL entries -- on the object. The Auditing tab lets
you control the SACL entries on the object. The Owner tab lets you view
and change the owner. There's no Primary Group tab.
Taken together, a security descriptor has a potentially-large amount of stuff
in it. Most of us haven't spent much time thinking about security
descriptors until the past few years, though, because until a
few years ago almost no one spent much time talking about Windows
security, and Microsoft's default security values in those days were pretty much
Everyone/Full Control on just about everything. But now that Microsoft's a
bit more security-conscious, they needed a way to succinctly list everything in
an object's security descriptor. That's what SDDL does. For example,
acctinfo.dll's SDDL is this:
That's SDDL-ese for "this object is owned by the local administrator, has
'local system' as its primary group, and has granted full control to the
Everyone group. It doesn't have any auditing permissions." Clear as
crystal, eh? Well, fear not, it will be, once you know the code.
SDDL strings include four items: the object's owner, its primary group, its DACL
and, if it has one, its SACL. The owner's name is prefixed by "O:," the
primary group's name is prefixed by "G:," the DACL by "D:" and the SACL by "S:."
There are no spaces, and the DACL and SACL are surrounded by parentheses.
Referring to my earlier example,
The Owner and Primary Group
Start picking this apart at the O:, which tells us that the owner's name
follows. Keep reading until you see a G: -- that's the end. The owner part of the
string, then, is "O:BA," which means that it's owned by something called "BA."
BA is one of a dozen or so pre-defined abbreviations for common accounts and
groups; these abbreviations are called "SID strings." A few you'll find
You can find them all at
or go to http://msdn.microsoft.com and
search on "SID strings." This object's owner, then, is the local
Administrators group. You can also specify an actual SID if you don't
have a SID string for a particular account or group. If, for example, this
object's owner had the SID S-1-5-21-33-44-55-1002, then its SDDL string would
- AO: account operators
- BA, the local ("Built-in") Administrators group
- DA: domain admins
DU: domain users
- AU: authenticated users
- EA: enterprise admins
- WD: Everyone
- CG: Creator group
- CO: Creator Owner
- LA: local Administrator account
- SY: the local System account
Next, we can see that its primary group is defined by "G:SY." As "SY" is
the local System account, apparently that's the file's primary "group."
Cracking the DACL
we're ready for the DACL, the file permissions. It's the group surrounded
by parentheses and starting with the D: prefix, "(A;;FA;;;WD)." That is
called an "ACE string," as, recall, all access control lists are made up of
access control entries, and (A;;FA;;;WD) is just one ACE. ACE strings have
their own strange format, which you can find at
or, if that URL doesn't work any more, then just Google "ACE string" and "SDDL"
and you should find it.
ACE strings have six parts, each separated by a semicolon. They are, in
- The first part describes the type of ACE -- generally "allow" or "deny,"
in the case of files. This corresponds to the "allow" and "deny" check
boxes that you see in the GUI for security permissions.
- If the object is a container, like a directory, then you may want to say
whether this ACE applies to the container itself, or its contents. The
second part lets you do this and is called the "ACE flags."
- The third part describes the exact permission conferred by this ACE --
read, write, full control, that sort of thing.
- The fourth and fifth parts refer to the GUIDs of the object -- first the
object, then what inheritance if any this object gets. This appears
unnecessary for file and directory operations and appears to only apply to
Active Directory delegation, which is a particular form of permissions.
- The sixth part is the name of the account or group that's getting this
permission. It's either a SID string or a SID in the standard
Note that (A;;FA;;;WD) leaves a number of pieces empty; that's why you see
semicolons next to each other. The six pieces are, then,
- ACE type is "A."
- No ACE flags.
- The permission granted here is "FA."
- No object GUID.
- No object GUID inheritance information.
- The account that gets this permission is "WD."
Now let's decode that. As the ACE Strings writeup that I referred to
says, "A" means that this is an "allow" ACE. The permission "FA" means
"all file access rights," which is another way of saying "full control."
"WD" is the SID string for the "Everyone" group.
But I chose a pretty easy example -- Everyone/Full Control is about
as simple as it gets. But what about a somewhat more complex one?
Suppose we change the permissions on my acctinfo.dll example to remove
the Everyone/Full Control ACE and add two new ones. Let's give
Domain Administrators Full Control, and Domain Users only Read access.
That leads to a SDDL string like this:
The O: and G: part hasn't changed, but now notice two things.
First, there are some letters right after the D: but before the
parenthesized DACL, and, second, there are two parenthesized
DACLs. The PARAI after D: are called DACL flags. They
appeared after I changed acctinfo.dll's permissions. You see, I'd
wanted to remove the Everyone/Full Control permission, but it had been
inherited from its parent folder. To get rid of it, I had to go
into the Advanced Security dialog and un-check the box labeled "Inherit
from parent the permission entries that apply to child objects.
Include these with entries explicitly defined here." Apparently
un-checking that causes the file system's permissions to enable the
three flags P, AR, and AI as defined at
Take a look at the first ACE string, (A;;FA;;;DA). It's an
"allow" ACE because of the "A," and it grants full control because of
the "FA." It gives this permission to the Domain Admins group
because "DA" is the SID string for the Domain Admins group.
Similarly, the second ACE string is an "allow" ACE that grants full read
permissions ("FR") to the Domain Users group ("DU.")
You can take the complexity and number of ACE strings as far as you
like. Permissions are internally stored as sequences of bits, so
if you need some very particular set of permissions then you can first
figure out what sequence of bits corresponds to that set of permissions
(which is a topic beyond the scope of this article), and then just use
the hexadecimal equivalent value in the ACE string. For example,
by turning on random sets of low-level permissions on the Domain Users
ACE, I got a SID string of "(A;;0x1a00a4;;;DU)."
An SDDL Tool: Subinacl
But how did I create that last ugly ACE? I cheated:
I used Subinacl. The version of Subinacl that came with Server
2003 and that you can download, as mentioned above, from Microsoft's
site. It works on 2000 Server, XP, or Server 2003. Subinacl
lets you look at permissions on files, directories, user accounts,
groups, cluster shares, Registry keys, services, processes, printers,
kernel objects, and IIS metabase items. Subinacl can do many
things, but it's most basic function is the /display option. You
can choose to display permission data in several formats, and one is "SDDL"
format. I told Subinacl to show me the SDDL form of the file
permissions for acctinfo.dll like so:
subinacl /file acctinfo.dll /display=sddl
Used in this way, Subinacl can make your SDDL learning curve a bit
less steep. And yes, SDDL is an obscure "language," but
we've got to be at least a bit familiar with it. (You might think
of it as Microsoft's 21st Century answer to that strange ARC language in
Join me at ...
New England Information Security Group Meeting: "Crossing
the Line." The February 17, 2005 meeting of NEISG (www.neisg.org)
hosts a panel discussion on ethics in the computer security biz --
should be a lot of fun! I'm on a panel with an FBI
counterterrorism guy, a criminologist, and a federal prosecutor.
(I'm not sure what I'm doing on a panel with folks who are that smart,
but it'll be interesting.) They hold meetings in Microsoft's
Waltham office. Info at
www.neisg.org. See you there!
Techmentor Spring 2005: 101 Communications's semi-annual
geekfest comes to Orlando this spring. I'm doing a keynote and a
techie talk on Windows' SMTP service. The fun starts on Monday,
April 4th! Info at
Windows Connections Spring 2005: my magazine's
twice-per-year tech-o-rama starts a couple of weeks after Techmentor, on
17 April in San Francisco! Our new program chair, Amy Eisenberg,
has put on a pretty neat schedule ... but heck, don't believe me, check
it out yourself. Info at
Bring Mark to your site to teach
I'm keeping busy doing Active Directory and Security seminars and
writing, but I've still got time to visit your firm. In just two
days, I'll make your current NT techies into 2000, XP, Active Directory
and 2003 experts. (And better yet they won't have to sit through any
Redmondian propaganda.) To join the large educational,
pharmaceutical, agricultural, aerospace, utility, banking, government,
telecommunication, law enforcement, publishing, transportation, and other
organizations that I've assisted, either take a peek at the course
outlines at www.minasi.com/presentations.htm, mail our assistant
Jean Snead at Assistant@Minasi.com, or call her
at (757) 426-1431 (only between noon-5 Eastern time, weekdays, please).
Until Next Month...
Have a quiet and safe month.
Please share this newsletter; I'd like very much to expand this
periodical into a useful source of NT/2000/2003/XP information.
Please forward it to any associates who might find it helpful, and accept
my thanks. We are now at over 36,000 subscribers and I hope to use
this to get information to every single Mastering 2003, XP, NT and 2000
Server reader. Thanks for letting me visit with you, and take care.
Many, many thanks to the readers who have mailed me to offer suggestions,
errata, and those kind reviews. As always, I'm at http://www.minasi.com/gethelp and
please join us at the Forum with technical questions at www.minasi.com/forum.
To subscribe, visit http://www.minasi.com/nwsreg.htm.
To change e-mail, format, etc., link to http://www.minasi.com/edit-newsletter-record.htm.
To unsubscribe, link to http://www.minasi.com/unsubs.htm.
Visit the Archives at http://www.minasi.com/archive.htm.
Please do NOT reply to this mail; for comments, please link to http://www.minasi.com/gethelp.
All contents copyright 2005 Mark Minasi. You are encouraged to quote
this material, SO LONG as you include this entire document;