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 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 2005 Mark Minasi.

What's Inside

• News: 
  • 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
• Conferences
• Bring a Seminar to Your Site

News

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 www.minasi.com/secoutln.htm.

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 www.minasi.com/2003outln.htm .

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 www.softwareconspiracy.com.

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!

Tech Section

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:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Eventlog\Security

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;; 0x2;;;NS)

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 enlightening hints!

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 object.

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.

Introducing SDDLs

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:

O:BAG:SYD:(A;;FA;;;WD)

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,

O:BAG:SYD:(A;;FA;;;WD)

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 useful are

• 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

O:S-1-5-21-33-44-55-1002G:SYD:(A;;FA;;;WD)

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

Now 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 http://msdn.microsoft.com/library/en-us/secauthz/security/ace_strings.asp 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 order:

• 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 S-1-whatever format.

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.

Uglier DACLs

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:

O:BAG:SYD:PARAI(A;;FA;;;DA)(A;;FR;;;DU)

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 http://msdn.microsoft.com/library/en-us/secauthz/security/security_descriptor_string_format.asp page.

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 www.microsoft.com/download 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 boot.ini!)

Conferences

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 www.techmentorevents.com.

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 www.winconnections.com.

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; thanks.