Re: Windows 2000 SP2 local policy settings not stored using SIDs?

From: Tony Chow (tchow@BLUETENTACLE.COM)
Date: 08/17/01 

Message-ID:  <50B30C640EC48648ABAA34F00D737A9605A3DF@leto.bluetentacle.local>
Date:         Fri, 17 Aug 2001 10:54:51 -0700
From: Tony Chow <tchow@BLUETENTACLE.COM>
Subject:      Re: Windows 2000 SP2 local policy settings not stored using SIDs?
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM

Hello everyone, if I may chime in.

In my experience a security template in Windows 2000 always stores an
account/group by its SID given the account/group can be found on the
system/domain on which the template is created.

To see for yourself, simply open up any relevant security template file.
Here's a sample:

[Privilege Rights]
SeNetworkLogonRight = *S-1-5-11
SeDebugPrivilege = *S-1-5-32-544
SeDenyNetworkLogonRight = *S-1-5-32-546
SeTcbPrivilege = *S-1-5-32-544

In this example, S-1-5-32-544 is the built-in local administrators group
on every Windows 2000/NT domain and local account database. Here it is
perfectly represented by its SID.

But some of us suspect, or have directly observed in security templates,
that sometimes account/group names are stored literally. How come?

This is what happens when you add a group entry under the User Rights
Assignment portion of a security template: you can either type in the
name manually or browse the domain and local machine for the group. If
you choose to browse and select, the editor retrieves the SID of the
group and stores it under the entry. If you choose to manually type in
the account/group name, then the editor will search the local account
database or domain (provided the account/group name is prefixed with the
domain name as in "domain\name") for an account/group matching this
name. If a match is found, the editor writes an entry in the template
with the SID associated with the account/group.

But here's the catch: if you choose to type in the account/group name
manually and the editor CANNOT find a match for it anywhere, it will
simply reference the account/group in the security template by its
literal name, without warning. As an example, let's deny network logon
to a group called "hill billies" by manually typing it in the editor.
This group doesn't exist anywhere in the local system or the domain.
When we save the security template and open it with notepad, we see the
following entry:

SeNetworkLogonRight = hill billies

At first this may seem like a bug, but in fact it makes perfect sense;
you may be specifying a local group that exist on systems to which the
security template will apply but does not exist on the system on which
you are creating the template, and the editor is merely taking this
scenario into account. Nonetheless, the security template editor
doesn't give a warning when it does this, and if you mistype an
account/group name on a critical entry, such as one that limits the
local logon right to the administrators group, you've got a problem.

To make sure this doesn't happen, I suggest a few rules to follow when
creating security policies:

1) Always browse for the account/group name when adding references to
accounts/groups in the security template editor, rather than manually
typing it in. This will prevent disasters resulting from misspelling of
the account/group name.
2) Always edit the security template on a system from which all groups
you will specify in the template are visible.
3) Always create security policy as a security template *outside* of
GPOs, and then import the template into the GPO, this way policies will
not propagate until you've had a chance to...
4) Verify the security template in a text editor before it is deployed.

In conclusion, security templates in Windows 2000 behave exactly the way
they are supposed to. They are, nonetheless, an extremely flexible
tool, and as such must be used with care and attention.

Cheers,
Tony Chow

======================================
Delivery co-sponsored by Trend Micro, Inc.
======================================
TREND MICRO SCANMAIL FOR EXCHANGE 2000 -- SECOND to NONE

If you are worried about email viruses, you need Trend Micro ScanMail for
Exchange. ScanMail is the first antivirus solution that seamlessly
integrates with the Microsoft Exchange 2000 virus-scanning API 2.0. ScanMail
ensures 100% inbound and outbound email virus scanning and provides remote
software management. Download a FREE 30-day trial copy of ScanMail and find
out why it is the best:
http://www.antivirus.com/banners/tracking.asp?siBI;$0&UL;=/smex2000
======================================