RE: Bypass Traverse Checking?

From: Laura A. Robinson (larobins@bellatlantic.net)
Date: 01/26/03

  • Next message: Laura A. Robinson: "RE: Bypass Traverse Checking?"
    From: "Laura A. Robinson" <larobins@bellatlantic.net>
    To: "'Hall, Randy'" <randy.hall@intel.com>, <focus-ms@securityfocus.com>
    Date: Sun, 26 Jan 2003 01:01:18 -0500
    
    

    I knew I had an article on this someplace; I had to dig up the URL for it.
    This article discusses the inclusion of Authenticated Users in the access
    token for an account that connects as a guest; again, the only account that
    won't have that token in the guest context is the built-in Guest account
    itself, not a different account connecting because of the enabling of the
    Guest account. Anyway, you'll see what I mean when you read the article.

    http://www.microsoft.com/msj/defaultframe.asp?page=/msj/0299/security/securi
    ty0299.htm&nav=/msj/0299/newnav.htm

    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
    > > >
    > >
    >



    Relevant Pages

    • RE: Bypass Traverse Checking?
      ... Authenticated Users, because they are significantly different (different ... account without that SID in its token would not be able to access the ... you are affecting Anonymous Logon and the _builtin_ Guest ... account. ...
      (Focus-Microsoft)
    • RE: Bypass Traverse Checking?
      ... > without that SID in its token would not be able to access the ... > connections) and the _builtin_ Guest account (one account, ... > not the guest groups). ... >>> For anonymous access to be available for Internet users, ...
      (Focus-Microsoft)
    • Fw: Bypass Traverse Checking?
      ... Everyone includes everyone, from guest to Administrator. ... Authenticated Users don't include Guest and Everyone does. ... account, but anonymous access authenticated as IUSR. ...
      (Focus-Microsoft)
    • Special identities in XP
      ... Does not include the Guest account. ... Everyone - Includes Authenticated Users and Guest. ... connection. ...
      (microsoft.public.windowsxp.general)
    • RE: Bypass Traverse Checking?
      ... If you use the builtin Guest account and log on, ... which you can verify by looking at the SID of the account. ... So, yes, if you use the guest _account_, the Authenticated Users SID is not ...
      (Focus-Microsoft)