Re: Default file/folder security permissions for a new user




<renegade_master_12121@xxxxxxxxxxx> wrote in message
news:ac3b06b6-1d46-4302-987b-84d4683b24cc@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On 13 Jan, 19:53, "Paul Baker [MVP, Windows Desktop Experience]"
<paulrichardba...@xxxxxxxxxxxxxxxx> wrote:
In what way? I absolutely agree with Al on all his points.

Paul


Oh dear, I am not making myself understood.

Not really, we understand you perfectly - you are the one with the
understanding issue... (and I mean no disrespect in saying so).

OK Paul --- you agree
with these two points:

o The membership of Authenticated Users is determined when that user
has been authenticated --- I take this to mean that when he is not
logged on then he is NOT in the Authenticated Users group

First, let's get this straight: he is NEVER a member of the authenticated
users group - because there is no such group. But he WILL attain all the
rights and privileges allocated to "authenticated users" when he attains the
status of an authenticated user, which he does simply by logging in.

"Authenticated users" is not a "group", but a security principal or entity
that is known to the system as "NT AUTHORITY\Authenticated Users
(S-1-5-11)". This object is defined, and exists in this manner, because it
was created for the purpose.

Imagine for a moment what it would be like if you could only grant (or
exclude) resource access to user accounts that you knew about and/or were
guaranteed to be members of some arbitrary security group of your own
creation.

o The membership of INTERACTIVE obeys this same logic.

So, what is your answer to the question:

Where do all the permissions for C:\paper come from for Bob
when I look at him, given that I am logged on as FOLDINGSTUFF\simono.
as I look at him?


You are not looking at HIM, you are looking at the permissions associated
with a resource, namely the folder "C:\paper". Similarly, you are not
looking at "authenticated users" or "interactive" either, you are just
looking at the permissions associated with the resource.

i.e. Bob at that point is NOT a member of Authenticated Users or
INTERACTIVE ?

As long as you continue to assume that Bob's association with those two
objects is equivalent to his membership in static security groups, you will
have difficulty with this.

When you propose Bob's account in the effective permissions tab, you are not
enumerating "authenticated users" or "interactive" and finding him a member
there, you are simply finding out that, whether or not bob is logged in or
interactive at this moment, that he will acquire these permissions when he
becomes so.

The system is not telling you that, at this particular moment bob is
accessing the resource, just that there is no impediment to him accessing
the resource once he acquires authenticated status. I don't know about you,
but my account has no access to anything when it is not logged in.
Similarly, I as an individual have no access unless I am logged in with the
credentials of some user account.

If you were to add a deny permission for bob (or for some actual group he is
a member of) and have another look, you would see that the effective
permissions tab reflects this. And what is it reflecting? It is reflecting
the actual access the account has (or would have) when logged in. Whatever
magic might be involved is beside the point; this tells you precisely what a
particular user's effective permissions are.

One thing we have not mentioned in this thread is how permissions are
actually processed. When a user logs on, a security token is created in his
process that basically encodes all of the group memberships that were in
effect at the moment of logon. At this point his status as an authenticated
user is factored in as well.

When he attempts to access a resource, his level of access is calculated
using the permissions on the resource and the security token associated with
his logon process. The logic that does this DOES NOT LOOK AT HIS GROUP
MEMBERSHIPS at all. This is why when you add a user to a group or take him
out of one, it cannot have any effect on his access until he next logs in.

It should be noted that, because this security token is a property of a
logon process, it cannot exist outside of that context.

Are we clear yet?


/Al


.



Relevant Pages

  • Re: Determine what permissions a group has?
    ... The permissions are stored in the ACL of the resource, not the group, so it's difficult. ... You could query AD for printQueue objects to get your list of printers and roll through those or you could put each of those printer-membership groups into a master-printer group, so that you could poll the membership of one master list to get the complete list of printer-membership groups, then compare that to the user's membership. ...
    (microsoft.public.scripting.vbscript)
  • Re: Determine what permissions a group has?
    ... For AD permissions, you need DSACLS.exe. ... The permissions are stored in the ACL of the resource, not the group, ... your list of printers and roll through those or you could put ... so that you could poll the membership of one master list to get the ...
    (microsoft.public.scripting.vbscript)
  • Handling ACL Groups
    ... membership in multiple groups. ... Whenever they accessed a resource, ... effective permissions were a sum of all the groups' permissions plus ... and if a linux client passes all ...
    (alt.os.linux)
  • Group ACLs
    ... membership in multiple groups. ... Whenever they accessed a resource, ... effective permissions were a sum of all the groups' permissions plus ... and if a linux client passes all ...
    (comp.os.linux.networking)
  • Resource-based security with IPermission?
    ... The permissions should be assigned to the resource and the ... So I looked into extending the PrincipalPermission. ... GrantedPermissions, this is easy enough, however I wondered how or if ...
    (microsoft.public.dotnet.security)