COMMAND

    SCM

SYSTEMS AFFECTED

    WinNT 4.0

PROBLEM

    Raymond P. Galloni found following.  The SCM has some deficiencies
    when  it  comes  to  setting  up  auditing  on specific files, and
    directories.   (Presumably, this  also extends  to configuring the
    auditing on specific Registry keys, as well).  The issues occur in
    that when  auditing is  configured on  a file  or directory,  that
    basic properties of the file  or directory ACL will be  changed to
    inherit  the  ACL  of  it's  parent  directory.   Because  of this
    inheritance, the targeted ACL configuration can become corrupt  if
    this  inheritance  is  not  taken  into  consideration.  Many firm
    beliefs are that every subdirectory or file within a  subdirectory
    that  is  to  receive  a  different  ACL  should have this inherit
    property turned off.  However, if  it is turned off and you  would
    like to audit user/group  actions on this particular  entity, then
    the SCM will  munge your intended  permission scheme.   While this
    work-around  should  only  be  temporary,  as  Microsoft  has been
    notified of the problem, it  can become tedious when editing  many
    SCM templates.

SOLUTION

    The work-around involves  editing the resulting  inf file that  is
    created when an SCM  template is made.   Within an inf file  there
    is a  section labeled  "[File Security]".   Under this  section is
    the list of all files and  directories that have some form of  ACL
    being  applied  to  them.   If  we  look  closely at the data that
    follows a file name we will  be able to interpret the type  of ACL
    that is being applied

    Format and Interpretation of File System ACL:
    Syntax:

        "<Filename>",<Object Configuration>,"<Scope>(ACL settings;;;Group/Username)"

        <Object Configuration> value range = 1 or 2:
        1 = Ignore  -  the   ACL  is  applied once and ignored  in all
            subsequent configurations or analyses.
        2 = Overwrite - the  ACL is applied on all  configurations and
            is used during analyses.

        <Scope> all values described below:
        D: = This  indicates the actual  permissions ACL that  will be
             applied  on  the  entity,  inheritance  from  the  parent
             directory is turned on.
        D:P = This indicates that  the permissions on this entity  are
              not inherited by the parent directory.
        S: = This  indicates the presence  of auditing on  the object,
             this will  also inherit  audit settings  from the  parent
             directory.
        S:P = This indicates that the auditing settings on the  object
              will not be inherited from the parent directory.

    (ACL settings;;;Group/Username):
    ACL settings = This indicates  the permissions that are being  set
    or the type  of auditing that  is being performed.   This will  be
    determined  by  the  preceeding  scope  value.   Group Name = This
    indicates the target group that  the permission is being set  for.
    The following is a quick list for some common groups:

        DA = Domain Admins, or local Administrators group
        WD = World or better known as Everyone
        AU = Authenticated Users
        SY = System
        CO = Creator/Owner
        PU = Power Users
        BO = Backup Operators
        IU = Interactive User
        RP = Replicator
        AG = Guests

    User Name = Specific users and some group accounts are referred to
    using  their  SID,   therefore  one  will   see  a  large   number
    representing these specific entities.  Take the following  excerpt
    as an example:

        "%SystemRoot%",2,"D:P(A;CIOI;0x001f01ff;;;WD)"
        "%SystemRoot%\explorer.exe",2,"D:(A;CIOI;0x001f01ff;;;WD)S:(SA;CIOIFA;0x001f01ff;;;WD)"

    Here  we   see  a   directory  %SystemRoot%   (C:\Winnt  in   most
    installations).  We can tell that entity will have permissions  on
    it defined for the Everyone group.  Because of the presence of the
    "P" we also  know that inheritance  has been turned  off therefore
    this  entity  is  not  inheriting  any  properties from the parent
    directory.

    The second item is Explorer executable.  We can determine that  it
    is going to  set some permissions  on the object  for the Everyone
    group,  in  addition  it  will  also inherit any other permissions
    from  it's  parent  object.   We  also  notice the presence of the
    "S:".  This means that this object will also have auditing  turned
    on for some actions performed by the Everyone group.

    Now that we understand what  is being done within the  contents of
    the  inf  file,  we  can  force  our templates to behave properly.
    Essentially,  we  will  want  to  search  the  inf  file  for  all
    instances of  file system  auditing.   A universal  search on "S:"
    will suffice  to identify  the files  or directories  that contain
    audit settings.   Next, we  will want  to disable  the inheritance
    that results when  auditing is turned  on, bringing us  to a known
    and desired ACL configuration.   For all objects that contain  the
    "S:" item, just add the  "P" character after all instances  of the
    "D:" and "S:".  For instance, the Explorer.exe example from  above
    would  be  changed  to  look  like  the following:  (Items in bold
    indicate the added items.)

        "%SystemRoot%\explorer.exe",2,"D:P(A;CIOI;0x001f01ff;;;WD)S:P(SA;CIOIFA;0x001f01ff;;;WD)"

    The final step  is to save  the inf file  and then to  apply them.
    NOTE:  If any changes are  made, using the SCM GUI, to  a specific
    file or directory that has been modified in this manner, then  the
    inheritance will be turned back on for that object.  This  process
    will then need to be repeated to force the proper behavior.