RE: Bypass Traverse Checking?

• Previous message: Laura A. Robinson: "RE: Bypass Traverse Checking?"
• Next in thread: Wilson, Kevin W. (WIL) : "RE: Bypass Traverse Checking?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

From: "Laura A. Robinson" <larobins@bellatlantic.net>
To: "'Hall, Randy'" <randy.hall@intel.com>, <focus-ms@securityfocus.com>
Date: Fri, 24 Jan 2003 19:50:46 -0500

One last P.S. and then I'm off for the evening. <G>

For those who aren't familiar with anonymous access, what it's all about and
what the ramifications of not restricting it are, I'd highly recommend a
perusal of Thor's site.

http://www.hammerofgod.com

Very enlightening. :-)

Laura

> -----Original Message-----
> From: Laura A. Robinson [mailto:larobins@bellatlantic.net]
> Sent: Friday, January 24, 2003 5:34 PM
> To: 'Hall, Randy'; 'focus-ms@securityfocus.com'
> Subject: RE: Bypass Traverse Checking?
>
>
> BTW, as a quick side note, I do not wish to imply that Domain
> Users = Authenticated Users, because they are significantly
> different (different types of groups, different membership,
> different capabilities in terms of population), and if an ACL
> contains only the SID for Authenticated Users, an account
> without that SID in its token would not be able to access the
> resource.
>
> So, to reiterate, by changing "Everyone" to "Authenticated
> Users" in an ACL, you are affecting Anonymous Logon (null
> connections) and the _builtin_ Guest account (one account,
> not the guest groups). That's it. You are not affecting
> Guests, nor are you affecting Domain Guests.
>
> Just wanted to make sure I wasn't being unclear. :-)
>
> Laura
>
> > -----Original Message-----
> > From: Laura A. Robinson [mailto:larobins@bellatlantic.net]
> > Sent: Friday, January 24, 2003 5:05 PM
> > To: 'Hall, Randy'; 'focus-ms@securityfocus.com'
> > Subject: RE: Bypass Traverse Checking?
> >
> >
> > Not to drag this out further, and Brett is a friend of mine
> > so I don't want to sound like I'm disagreeing, but there's a
> > significant distinction that isn't in his article, and there
> > is a small incorrect statement, as well.
> >
> > Note: Guest != Guests
> >
> > If you use the builtin Guest account and log on, this is what
> > your access token looks like (the guest account in this
> > domain is renamed "Administrator", which you can verify by
> > looking at the SID of the account. That was done for easy
> > searches in auditing.):
> >
> > User : SOMEDOMAIN\Administrator
> > (S-1-5-21-839522115-484763869-1343024091-501)
> > Owner : SOMEDOMAIN\Administrator
> > (S-1-5-21-839522115-484763869-1343024091-501)
> > Primary Group SID SOMEDOMAIN\Domain
> > Users(S-1-5-21-839522115-484763869-1343024091-513)
> > LUID for this instance of token 141654864
> > LUID for this logon session 140666464
> > Token is type PRIMARY
> > Token source is <User32 Äv>
> >
> > Retrieving Group information from current process token
> > SID 0 Group: SOMEDOMAIN\Domain
> > Users(S-1-5-21-839522115-484763869-1343024091-513)
> > SID 1 Group: \Everyone(S-1-1-0)
> > SID 2 Group: BUILTIN\Guests(S-1-5-32-546)
> > SID 3 Group: BUILTIN\Users(S-1-5-32-545)
> > SID 4 Group: NT AUTHORITY\INTERACTIVE(S-1-5-4)
> > SID 5 Group: NT AUTHORITY\NONE_MAPPED(S-1-5-5-0-1406586)
> > SID 6 Group: \LOCAL(S-1-2-0)
> > SID 7 Group: SOMEDOMAIN\Domain
> > Guests(S-1-5-21-839522115-484763869-1343024091-514)
> >
> > Privileges associated with this token (1)
> > SeChangeNotifyPrivilege - (attributes) 3
> >
> > So, yes, if you use the guest _account_, the Authenticated
> > Users SID is not added to your access token. The _Users_ SID,
> > however, is, contrary to Brett's article, as is Domain Users.
> > Since Domain Users are, by definition, authenticated users,
> > it becomes irrelevant that the Authenticated Users SID is not
> > in the access token. _However_, if you create an account,
> > make it a member of Domain Guests (and Guests, should you
> > have the burning desire to do so), _remove_ it from the
> > domain users group, then log on with the account, this is
> > what your access token looks like:
> >
> > User : SOMEDOMAIN\guestmember
> > (S-1-5-21-839522115-484763869-1343024091-2611)
> > Owner : SOMEDOMAIN\guestmember
> > (S-1-5-21-839522115-484763869-1343024091-2611)
> > Primary Group SID SOMEDOMAIN\Domain
> > Guests(S-1-5-21-839522115-484763869-1343024091-514)
> > LUID for this instance of token 159218764
> > LUID for this logon session 153701964
> > Token is type PRIMARY
> > Token source is <User32 ÷s>
> >
> > Retrieving Group information from current process token
> > SID 0 Group: SOMEDOMAIN\Domain
> > Guests(S-1-5-21-839522115-484763869-1343024091-514)
> > SID 1 Group: \Everyone(S-1-1-0)
> > SID 2 Group: BUILTIN\Guests(S-1-5-32-546)
> > SID 3 Group: BUILTIN\Users(S-1-5-32-545)
> > SID 4 Group: NT AUTHORITY\INTERACTIVE(S-1-5-4)
> > SID 5 Group: NT AUTHORITY\Authenticated Users(S-1-5-11)
> > SID 6 Group: NT AUTHORITY\NONE_MAPPED(S-1-5-5-0-1536850)
> > SID 7 Group: \LOCAL(S-1-2-0)
> >
> > Privileges associated with this token (2)
> > SeChangeNotifyPrivilege - (attributes) 3
> > SeMachineAccountPrivilege - (attributes) 0
> >
> > Note the membership in the Authenticated Users group and the
> > inclusion of that SID in the access token. I should have been
> > very careful to note this difference, but again,
> > Authenticated Users _does_ include Guests. The rest of
> > Brett's article says the same things that I said in my post
> > (right down to the differentiation between the IUSR_ user and
> > Anonymous Logon <G>).
> >
> > I encourage you to duplicate my tests, as even though my
> > testing has been consistent, I'd like to see it validated
> by another.
> >
> > Laura
> >
> > > -----Original Message-----
> > > From: Hall, Randy [mailto:randy.hall@intel.com]
> > > Sent: Friday, January 24, 2003 12:28 PM
> > > To: focus-ms@securityfocus.com
> > > Subject: RE: Bypass Traverse Checking?
> > >
> > >
> > > I thought I would weigh in on this discussion, mostly
> because I see
> > > some dangerous assertions being made.
> > >
> > > A very good web article that clears the distinction between
> > > Everyone, Users, and Authenticated Users is at:
> > >
> > >
> >
> http://www.windowswebsolutions.com/Articles/Index.cfm?ArticleID=23581
> > >
> > > I read it and agree with its findings.
> > >
> > > Cheers,
> > >
> > > --R
> > > --
> > > Randy Hall MCSA, MCSE (randy.hall@intel.com)
> > > Network/Web Manager, Corporate Demos
> > > Intel Corporation, Santa Clara, CA USA
> > > All views expressed herein are MINE MINE MINE!!!
> > >
> > >
> > > -----Original Message-----
> > > From: Laura A. Robinson [mailto:larobins@bellatlantic.net]
> > > Sent: Friday, January 24, 2003 5:35 AM
> > > To: 'Shane Brooks'; 'Williamson, Scott';
> focus-ms@securityfocus.com
> > > Subject: RE: Bypass Traverse Checking?
> > >
> > > As an additional item, since I've been challenged on this one via
> > > e-mail, I would encourage reading of this:
> > >
> > > http://www.microsoft.com/windows2000/techinfo/reskit/en-us/def
> > > ault.asp?u
> > > rl=/ windows2000/techinfo/reskit/en-us/distrib/dsbc_nar_lmxa.asp
> > >
> > > or
> > >
> > > http://tinyurl.com/4ubt
> > >
> > > Particularly this:
> > > "Note
> > > For anonymous access to be available for Internet users,
> anonymous
> > > access must be enabled on the Internet Information Services (IIS)
> > > Web server."
> > >
> > > Again, note that Authenticated users does _not_ include anonymous.
> > >
> > > Laura
> > >
> > > > -----Original Message-----
> > > > From: Shane Brooks [mailto:shane@floridacomputerservices.com]
> > > > Sent: Monday, January 20, 2003 7:11 PM
> > > > To: Williamson, Scott; focus-ms@securityfocus.com
> > > > Subject: Re: Bypass Traverse Checking?
> > > >
> > > >
> > > > You should definately make this change. If anything, the other
> > > > admin is confusing Anonymous access of web-pages by the
> > > > IUSR_[computername] account. However, IIS manages the
> password of
> > > > this account automatically and the account is therefore a
> > member of
> > > > "Authenticated Users", since IIS authenticates every
> page as IUSR
> > > > automatically if Anonymous access is enabled. The only
> > account that
> > > > is affected by Everyone is the guest account which is
> disabled by
> > > > default. Hope this helps, Shane
> > > > ----- Original Message -----
> > > > From: "Williamson, Scott" <scott.williamson@htcinc.net>
> > > > To: <focus-ms@securityfocus.com>
> > > > Sent: Wednesday, January 15, 2003 1:10 PM
> > > > Subject: Bypass Traverse Checking?
> > > >
> > > >
> > > > > I'm working on procedures for servers in our
> > organization. I keep
> > > > > coming across the recommendation to set the following on
> > > a Windows
> > > > > 2000 Server.
> > > > My
> > > > > problem is I have another administrator who believes this
> > > > could cause
> > > > > problems in IIS. What are the lists opinions? Anyone
> > > heard of this
> > > > causing
> > > > > problems?
> > > > >
> > > > > User Rights Assignment - Set "Bypass Traverse Checking"
> > - Remove
> > > > > Everyone and Replace with Authenticated Users.
> > > > >
> > > > > Thanks in advance for your time,
> > > > >
> > > > > Michael Scott Williamson
> > > > > Systems Administrator
> > > >
> > >
> >
>

• Next message: Daniel Peterson: "Re: Win2k log management"
• Previous message: Laura A. Robinson: "RE: Bypass Traverse Checking?"
• Next in thread: Wilson, Kevin W. (WIL) : "RE: Bypass Traverse Checking?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]