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:larobinsbellatlantic.net]
> Sent: Friday, January 24, 2003 5:05 PM
> To: 'Hall, Randy'; 'focus-mssecurityfocus.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.hallintel.com]
> > Sent: Friday, January 24, 2003 12:28 PM
> > To: focus-mssecurityfocus.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.hallintel.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:larobinsbellatlantic.net]
> > Sent: Friday, January 24, 2003 5:35 AM
> > To: 'Shane Brooks'; 'Williamson, Scott'; focus-mssecurityfocus.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:shanefloridacomputerservices.com]
> > > Sent: Monday, January 20, 2003 7:11 PM
> > > To: Williamson, Scott; focus-mssecurityfocus.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.williamsonhtcinc.net>
> > > To: <focus-mssecurityfocus.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
> > >
> >
>

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]