Re: XP Group/File Permissions (Possible BUG found)
anonymous_at_discussions.microsoft.com
Date: 02/16/04
- Next message: Ed Whitfield: "Software installs very slowly when logged on to network."
- Previous message: Jupiter Jones [MVP]: "Re: deleting an administrator account"
- In reply to: Colin Nash [MVP]: "Re: XP Group/File Permissions (Possible BUG found)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Sun, 15 Feb 2004 15:07:06 -0800
Well you see, thats my whole point, the facility is
lacking and to me the goal of making it known is to make
it better, more reliable, and functional.
Do not worry, my goal was not to convince you, but rather
share my thoughts on the matter in hopes of maybe someone
else searching these archives, may have an understanding
if they encounter the same issue.
Anyway I am sure if this issue is of concern to others,
they too might make it known....:)
Cheers!
>-----Original Message-----
>His SID hasn't changed but his token contains his SID
and the SID of all the
>groups he is part of.
>
>The ACL is checked against the token, not the user's
account (SID) directly.
>
>I don't work for Microsoft so convincing me that there
is a better way to do
>this won't do much.
>
>I can tell you that in my experience, this hasn't caused
any real problem.
>Users needs access to something? OK add them to the
group and tell them its
>available next time they log in.
>
>Want to look at the flip side? Remove them from the
group but they still
>have access until they reauthenticate. That's a bit
more of a concern.
>
>
><anonymous@discussions.microsoft.com> wrote in message
>news:101f401c3f414$73d3a7c0$a101280a@phx.gbl...
>> And that is the aspect that is lacking, because if the
>> SID of the user account has not changed, and was
granted
>> permission to create the new security context, why then
>> is there a need to re-authenticate?
>>
>> >-----Original Message-----
>> >
>> ><anonymous@discussions.microsoft.com> wrote in message
>> >news:101cb01c3f410$11d74300$a101280a@phx.gbl...
>> >> > I mean, it appears that once the ACL's are
associated
>> >> with the group, or vice versa, that the security
>> >> attributes in force are not made known to the
system,
>> >> unless further manual interaction is performed.
>> >>
>> >
>> >This is immediate. You need to re-authenticate when
the
>> user is associated
>> >with the group.
>> >
>> >
>> >
>> >
>> >> This is undesirable, because logging off and back
on or
>> >> rebooting causes much pain especially, when many
tasks
>> >> need to be performed in series, verifying the
success
>> >> through each. For example one may want to secure
many
>> >> objects, but verify the success of each along the
way.
>> >>
>> >> Having to manually re-authenticate seems much like a
>> >> burden.
>> >
>> >The only way to implement your solution would be for
the
>> system to check
>> >with the domain controller see if the user's token has
>> changed each time a
>> >resource is accessed. Maybe this could occur silently
in
>> the background but
>> >the performance hit on a large network would be
massive,
>> with each
>> >workstation constantly hitting the domain controllers.
>> >
>> >I've read some good technet/msdn articles about this
>> that really explained
>> >the reasons for the design quite well. I looked and
>> looked but can't find
>> >them for you.
>> >
>> >You could always send an email to mswish@microsoft.com
>> with your suggestions
>> >:)
>> >
>> >
>> >
>> >>
>> >> >-----Original Message-----
>> >> >Yes I am aware of that (I even did that exact
>> experiment
>> >> before typing my
>> >> >previous reply to make sure I understood what was
>> >> reported)... the newly
>> >> >added users in the group will have access the next
>> time
>> >> they authenticate.
>> >> >Once again, a full reboot is overkill.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> ><anonymous@discussions.microsoft.com> wrote in
message
>> >> >news:101ac01c3f40a$81fae660$a101280a@phx.gbl...
>> >> >> I understand In a domain that contains more than
one
>> >> >> domain controller, Active Directory information
>> takes
>> >> >> time to propagate from one domain controller to
>> >> another.
>> >> >>
>> >> >> however to prove there is a lacking capability in
>> the
>> >> >> design of authentication and verification just do
>> the
>> >> >> following on a standalone machine that uses no
>> domain
>> >> >> controllers for authentication.
>> >> >>
>> >> >> Create a group on a standalone machine, then add
>> some
>> >> >> users to the group. next, use cacls and modify
the
>> >> ACLs
>> >> >> for a given directory to permit full access to
that
>> new
>> >> >> group.
>> >> >>
>> >> >> Then, go ahead and see if you can access the
>> directory.
>> >> >>
>> >> >> You will see that you will not be able to, but if
>> you
>> >> >> reboot, you can.
>> >> >>
>> >> >>
>> >> >> >-----Original Message-----
>> >> >> >You don't have to reboot, just re-authenticate.
>> >> >> >
>> >> >> >And its only when you add someone new to a
group--
>> not
>> >> >> when you change file
>> >> >> >permissions. (Giving a new group access to a
>> resource
>> >> >> will work immediately
>> >> >> >for people who are already in the group.)
>> >> >> >
>> >> >> >http://msdn.microsoft.com/library/default.asp?
>> >> >> url=/library/en-
>> us/security/security/access_tokens.asp
>> >> >> >
>> >> >> >
>> >> >> >"adbdollar"
<anonymous@discussions.microsoft.com>
>> >> wrote
>> >> >> in message
>> >> >> >news:10f1401c3f402$d6057660$a501280a@phx.gbl...
>> >> >> >> Hmmm, so from your response you seem to
support
>> this
>> >> >> >> feature of having to reboot every time one
>> modifies
>> >> >> >> groups and permissions. I guess thats the
easy
>> >> >> solution
>> >> >> >> to call it by design, but it does not change
the
>> >> fact
>> >> >> that
>> >> >> >> the feature sucks, and causes disruption in a
>> >> >> production
>> >> >> >> environment.
>> >> >> >>
>> >> >> >> I think I will stay with UNIX, as it just does
>> not
>> >> have
>> >> >> >> these problems. Oh, and its on the UNIX
>> >> certification
>> >> >> >> exams as well.
>> >> >> >>
>> >> >> >>
>> >> >> >> LOL FRUITCAKE!!!
>> >> >> >>
>> >> >> >>
>> >> >> >> >-----Original Message-----
>> >> >> >> >When a user logs into a system, they are
issued
>> a
>> >> >> token
>> >> >> >> which essentially
>> >> >> >> >contains a listing of all the groups they
are a
>> >> part
>> >> >> of.
>> >> >> >> >
>> >> >> >> >Adding a user to a group requires them to log
>> off
>> >> and
>> >> >> >> back on (to either the
>> >> >> >> >local system or the domain, depending on your
>> >> >> situation)
>> >> >> >> to receive the
>> >> >> >> >updated token.
>> >> >> >> >
>> >> >> >> >I think that's what's causing your problem.
>> >> >> >> >
>> >> >> >> >This is well documented and by design.
Common
>> test
>> >> >> >> question on MCP exams
>> >> >> >> >too ;)
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >--
>> >> >> >> >Colin Nash
>> >> >> >> >Microsoft MVP
>> >> >> >> >Windows Printing/Imaging/Hardware
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >"adbdollar"
>> <anonymous@discussions.microsoft.com>
>> >> >> wrote
>> >> >> >> in message
>> >> >> >> >news:108a301c3f3f8$4dca5310
$a001280a@phx.gbl...
>> >> >> >> >> The machine runs:
>> >> >> >> >> Windows XP Professional Service Pack 1 with
>> all
>> >> the
>> >> >> >> >> recommended and security patches
>> >> >> >> >> as of 02/15/2004
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> Example of the problem:
>> >> >> >> >>
>> >> >> >> >> After creating a group lets say
called "Apps",
>> >> and
>> >> >> then
>> >> >> >> >> adding a few users, like "Administrator"
>> >> >> >> >> or "user1", "user2" etc... to this new
group
>> >> >> >> >>
>> >> >> >> >> Then assigning Permissions to a directory
so
>> that
>> >> >> >> >> group "Apps" has full Access, and of course
>> all
>> >> >> members
>> >> >> >> >> of this group should also have full access.
>> >> >> >> >>
>> >> >> >> >> However, this new permission scheme will
not
>> be
>> >> >> >> reconized
>> >> >> >> >> and take effect, unless the system is
>> rebooted.
>> >> >> >> >>
>> >> >> >> >> What I mean is, the system will prevent any
>> user
>> >> in
>> >> >> the
>> >> >> >> >> new group from accessing the directory with
>> the
>> >> new
>> >> >> >> group
>> >> >> >> >> permissions, until a system reboot.
>> >> >> >> >>
>> >> >> >> >> After I reboot, the new permission strategy
>> is in
>> >> >> >> force,
>> >> >> >> >> and every thing works fine.
>> >> >> >> >>
>> >> >> >> >> This is not very useful, as not everyone
can
>> >> afford
>> >> >> to
>> >> >> >> >> reboot machines, everytime they need to
>> secure a
>> >> >> >> >> directory or application.
>> >> >> >> >>
>> >> >> >> >> This seems like a bug, as one would expect
it
>> to
>> >> be
>> >> >> >> >> enforce, the moment one changes the
>> permissions.
>> >> >> >> >>
>> >> >> >> >> However, I am also aware that some features
>> that
>> >> >> seem
>> >> >> >> >> like a bug, are really features by design,
and
>> >> >> although
>> >> >> >> >> that may be reasonable in some cases, this
>> >> certainly
>> >> >> >> can
>> >> >> >> >> not be one of those.
>> >> >> >> >>
>> >> >> >> >> Well, one would expect it would not be.
>> >> >> >> >>
>> >> >> >> >> I can repeat this process as many times as
one
>> >> >> likes,
>> >> >> >> and
>> >> >> >> >> have even re-installed with the same
outcome.
>> >> >> >> >>
>> >> >> >> >> Any suggestions?
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >.
>> >> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >.
>> >> >> >
>> >> >
>> >> >
>> >> >.
>> >> >
>> >
>> >
>> >.
>> >
>
>
>.
>
- Next message: Ed Whitfield: "Software installs very slowly when logged on to network."
- Previous message: Jupiter Jones [MVP]: "Re: deleting an administrator account"
- In reply to: Colin Nash [MVP]: "Re: XP Group/File Permissions (Possible BUG found)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
