by Pat Bloodwel
Technical Support Representative, Executive Software

This is the third article in our series on Windows NT permissions.  In this
one, I wish to address the basic difference between the workgroup and the
domain which may offer a solution when you need to access a remote domain,
i.e., a domain other than the one that your system is a member of. 

The way we got here is interesting -- it began as a question from one of our
customers:  "On a server which has a number of shares, (SERVER), there is a
local account called 'localmanager'.  Another PC, (WORKSTATION), running
Windows NT workstation also has a local account named 'localmanager' and it
has the same password as the server.  When I log in on WORKSTATION with
domain WORKSTATION (login is local), then
I can browse to machine SERVER and see the shares there, but....I have the
same rights to change and delete files, as if I were logged on at that
server SERVER as if I were the local user on SERVER.  So the local-accounts
are not so local as they seem to be.  My question is why [does this occur],
when the security does not use the security ID's, but only the
username/password combination without any domain/global-group/local-group
information?"

What the user describes is completely correct.  The key is that you must
have the same username and password on both the local system and the domain.
You can also do this same type of access to connect to a remote domain, as I
do to access partitions on a separate domain than the one that my system is
a member of.  I make sure I am using the same username and password on my
local domain as I have on the remote domain.  Thus I can connect seamlessly
from one domain to the other.

What we are talking about here really boils down to a workgroup.  In a
workgroup, you can have seamless access to another system if there is an
account on that remote system that has the same username and password as the
local account that you are using.  Any access and permissions granted on
that remote system to this account are available to you when you connect to
that system using this account, which is exactly what is described about the
domain account in the above question.  The disadvantage is that you must
maintain both accounts, as opposed to a single domain account.  This can be
useful to solve some issues, but in the long run it can get more complex due
to the same issues you have in workgroups, i.e., the need to maintain the
same username and password on both sides of the connection.

CACLS

On another topic, CACLS (Change ACLs, as described in the article "Add CALCS
to Your Windows NT Toolbox", eLetter Volume 4, Issue 8), I recently came
across a potentially dangerous issue.  Fortunately, the solution is quite
simple.

I was working on a computer which had the Group SYSTEM with READ access to
all of the files on the partition and used CACLS to set the group SYSTEM to
FULL CONTROL.  Here is what happened.

When originally looking at the partition's permissions at the Command
Prompt, the command:

X:\>CACLS EXECSOFT

displayed the following data:

X:\ExecSoft BUILTIN\Administrators:(OI)(IO)F
            BUILTIN\Administrators:(CI)F
            NT AUTHORITY\SYSTEM:(OI)(IO)(special access:)
                                        GENERIC_READ
                                        GENERIC_EXECUTE

            NT AUTHORITY\SYSTEM:(CI)R

SYSTEM was then changed from READ to FULL CONTROL by this command:

X:\>CACLS * /e /t /c /g SYSTEM:F

After this, the command:

X:\>CACLS EXECSOFT

Displayed the following:

X:\ExecSoft NT AUTHORITY\SYSTEM:(OI)(IO)(special access:)
                                        STANDARD_RIGHTS_ALL
                                        DELETE
                                        READ_CONTROL
                                        WRITE_DAC
                                        WRITE_OWNER
                                        SYNCHRONIZE
                                        STANDARD_RIGHTS_REQUIRED
                                        GENERIC_READ
                                        GENERIC_EXECUTE
                                        FILE_GENERIC_READ
                                        FILE_GENERIC_WRITE
                                        FILE_GENERIC_EXECUTE
                                        FILE_READ_DATA
                                        FILE_WRITE_DATA
                                        FILE_APPEND_DATA
                                        FILE_READ_EA
                                        FILE_WRITE_EA
                                        FILE_EXECUTE
                                        FILE_DELETE_CHILD
                                        FILE_READ_ATTRIBUTES
                                        FILE_WRITE_ATTRIBUTES

            NT AUTHORITY\SYSTEM:(CI)F
            BUILTIN\Administrators:(OI)(IO)F
            BUILTIN\Administrators:(CI)F

Attempting to display the permissions from Windows NT Explorer (by
right-clicking the root folder, then selecting Properties, Security,
Permissions) resulted in an error message "The parameter is incorrect".

The issue appears to be that altering the group SYSTEM from READ access to
FULL CONTROL causes an over-saturation of data.  Not only do you see "The
parameter is incorrect" but all NTFS access restrictions are completely
removed, allowing any local user or network share essentially FULL CONTROL
access.

The way to fix this, and also the way to prevent it from occurring in the
first place, is to remove the group SYSTEM using CACLS:

X:\>CACLS * /e /t /c /r SYSTEM

then re-add the group SYSTEM with FULL CONTROL:

X:\>CACLS * /e /t /c /g SYSTEM:F

It is possible you may get similar results when you use CACLS to modify any
existing user.  If you ever make a change using CACLS and begin to see
unusual or unexpected behavior on your system, try going to CACLS and
removing then re-adding that user.

 This information was provided by Executive Software, maker of the Diskeeper defragmenter and Undelete for Windows NT. Visit their web site at
http://www.executive.com

@Macarlo, Inc.
@Macarlo's Shareware & Web
OS/2
Java Lobby Member
Java Site Accredited

[TOP] [HOME] [INDEX]