Shares, Named Pipes, and Registry for Anonymous Remote Access

I have a trojan I am fighting that replicates by establishing a null
connection to IPC$ on any member server that has File & Printer Sharing
enabled. It then repeatedly tries to invoke one of several buffer
overloads in order to execute code in the SYSTEM context of the targeted
machine. I would like to know how can I safely prevent null connections on
IPC$. I have all five of the enable/disable settings in GPO security set
that forbid anonymous access. Setting those to forbid anonymous is NOT
preventing the trojan from successfully establishing the null connection.
I can see this quite clearly by following its progress in a sniffer on the
attacking machine, and then when the IPC$ connection is established, on the
Windows 2003 DC I quite clearly get an eventviewer message that shows
ANONYMOUS CONNECTION, and the IP of the eventviewer message matches the
attacker's IP.

Group Policy for Windows XP/2003 contains the following Security Settings
(these names are approximate):

Named Pipes that can be accessed anonymously

Remote access registry paths

Remote access registry paths and subpaths

Shares that can be accessed anonymously

I have the following questions regarding the above:

1) For a domain controller, is it required that any of these be enabled, and
what is the minimum subset of entities that must be exposed?

2) For a member server, same question

3) For Windows 2000 DCs, are most of these just enabled by default and you
cannot change the specific settings?

4) When you deselect the checkbox on this group policy, and simply fail to
define any entities, then what are the defaults that will be in effect?
When I ran RSOP.MSC on one Windows 2003 DC, it had none of these defined
even through its local policy and GPO did not select checkboxes for any of
these.

If the lack of any settings in RSOP.MSC means that nothing is being allowed
for anonymous access, then would I get the same result by enabling the
checkbox, and simply forcing the list of each GPO setting above to be empty?

I'm not clear on what steps if any I should take here to absolutely be sure
that there are no anonymous connections allowed to the member server / DC.
Any insights on this are appreciated.

--
Will

You cannot really prevent null-connection attempts... So the question is -
how system responds? The GPO that you need is "Named Pipes that can be
accessed anonymously", and it must e set to Disable. I don't quite remember
what the default value is, think it's now secure.

And most recently (W2K3 SP1) there are no named pipes you can possibly
connect to anonymously:

https://blogs.msdn.com/spatdsg/archi...15/598260.aspx

Now, get rid of that trojan.

--
Svyatoslav Pidgorny, MS MVP - Security, MCSE
-= F1 is the key =-

"Will" <westes-usc@noemail.nospam> wrote in message
news:bcadnTFfYIIqC0PYnZ2dnUVZ_qCmnZ2d@giganews.com...
>I have a trojan I am fighting that replicates by establishing a null
> connection to IPC$ on any member server that has File & Printer Sharing
> enabled. It then repeatedly tries to invoke one of several buffer
> overloads in order to execute code in the SYSTEM context of the targeted
> machine. I would like to know how can I safely prevent null connections
> on
> IPC$. I have all five of the enable/disable settings in GPO security
> set
> that forbid anonymous access. Setting those to forbid anonymous is NOT
> preventing the trojan from successfully establishing the null connection.
> I can see this quite clearly by following its progress in a sniffer on the
> attacking machine, and then when the IPC$ connection is established, on
> the
> Windows 2003 DC I quite clearly get an eventviewer message that shows
> ANONYMOUS CONNECTION, and the IP of the eventviewer message matches the
> attacker's IP.
>
> Group Policy for Windows XP/2003 contains the following Security Settings
> (these names are approximate):
>
> Named Pipes that can be accessed anonymously
>
> Remote access registry paths
>
> Remote access registry paths and subpaths
>
> Shares that can be accessed anonymously
>
> I have the following questions regarding the above:
>
> 1) For a domain controller, is it required that any of these be enabled,
> and
> what is the minimum subset of entities that must be exposed?
>
> 2) For a member server, same question
>
> 3) For Windows 2000 DCs, are most of these just enabled by default and you
> cannot change the specific settings?
>
> 4) When you deselect the checkbox on this group policy, and simply fail to
> define any entities, then what are the defaults that will be in effect?
> When I ran RSOP.MSC on one Windows 2003 DC, it had none of these defined
> even through its local policy and GPO did not select checkboxes for any of
> these.
>
> If the lack of any settings in RSOP.MSC means that nothing is being
> allowed
> for anonymous access, then would I get the same result by enabling the
> checkbox, and simply forcing the list of each GPO setting above to be
> empty?
>
> I'm not clear on what steps if any I should take here to absolutely be
> sure
> that there are no anonymous connections allowed to the member server / DC.
> Any insights on this are appreciated.
>
> --
> Will
>
>

"S. Pidgorny <MVP>" <slavickp@yahoo.com> wrote in message
news:e4AI9czVHHA.3332@TK2MSFTNGP04.phx.gbl...
> You cannot really prevent null-connection attempts... So the question is -
> how system responds? The GPO that you need is "Named Pipes that can be
> accessed anonymously", and it must e set to Disable. I don't quite
remember
> what the default value is, think it's now secure.

It's not a disable and enable setting. Rather, the states are no checkbox
(which I take to be a third state of "not set") and a checkbox, which when
selected lets you specify specific null named pipes including IPC$.

I could specify the checkbox and then empty out the list. Is this what I
should be doing?

And for my education, when I do not select the checkbox, what is the default
behavior?

And, also, when I do or do not select the checkbox, does either setting have
any effect on a Windows 2000 DC?

--
Will

"S. Pidgorny <MVP>" <slavickp@yahoo.com> wrote in message
news:e4AI9czVHHA.3332@TK2MSFTNGP04.phx.gbl...
> You cannot really prevent null-connection attempts... So the question is -
> how system responds? The GPO that you need is "Named Pipes that can be
> accessed anonymously", and it must e set to Disable. I don't quite
remember
> what the default value is, think it's now secure.
>
> And most recently (W2K3 SP1) there are no named pipes you can possibly
> connect to anonymously:
>
> https://blogs.msdn.com/spatdsg/archi...15/598260.aspx

The behavior of the four GPOs that allow you to specify anonymous access to
named pipes, shares, and registry paths are very misleading. You select a
checkbox to make an explicit selection. You then delete the contents and
apply or save. Now when you open it again, Windows has AUTOMATICALLY
populated it for you!!

So by doing the above action, you incorrectly believe you are explicitly
setting these to null values, when in fact your action has 180 degrees the
opposite effect and blanking the list implicitly enables every anonymous
access! It's a very bad UI design.

I guess the absence of any setting means a null list? That's also not
clear.

--
Will

"Will" <westes-usc@noemail.nospam> wrote in message
news:KsOdnaN_FcYzdELYnZ2dnUVZ_gydnZ2d@giganews.com...
> "S. Pidgorny <MVP>" <slavickp@yahoo.com> wrote in message
> news:e4AI9czVHHA.3332@TK2MSFTNGP04.phx.gbl...
>> You cannot really prevent null-connection attempts... So the question
>> is -
>> how system responds? The GPO that you need is "Named Pipes that can be
>> accessed anonymously", and it must e set to Disable. I don't quite
> remember
>> what the default value is, think it's now secure.
>>
>> And most recently (W2K3 SP1) there are no named pipes you can possibly
>> connect to anonymously:
>>
>> https://blogs.msdn.com/spatdsg/archi...15/598260.aspx
>
> The behavior of the four GPOs that allow you to specify anonymous access
> to
> named pipes, shares, and registry paths are very misleading. You select
> a
> checkbox to make an explicit selection. You then delete the contents and
> apply or save. Now when you open it again, Windows has AUTOMATICALLY
> populated it for you!!
>
> So by doing the above action, you incorrectly believe you are explicitly
> setting these to null values, when in fact your action has 180 degrees the
> opposite effect and blanking the list implicitly enables every anonymous
> access! It's a very bad UI design.
>
> I guess the absence of any setting means a null list? That's also not
> clear.
>

I believe that is a known bug - at what OS rev do you experience as such?
Not sure, but I thought I saw a KB related some time back.

Roger

"Will" <westes-usc@noemail.nospam> wrote in message
news:ufydnWWse9xq9ELYnZ2dnUVZ_vmqnZ2d@giganews.com...
> "S. Pidgorny <MVP>" <slavickp@yahoo.com> wrote in message
> news:e4AI9czVHHA.3332@TK2MSFTNGP04.phx.gbl...
>> You cannot really prevent null-connection attempts... So the question
>> is -
>> how system responds? The GPO that you need is "Named Pipes that can be
>> accessed anonymously", and it must e set to Disable. I don't quite
> remember
>> what the default value is, think it's now secure.
>
> It's not a disable and enable setting. Rather, the states are no
> checkbox
> (which I take to be a third state of "not set") and a checkbox, which when
> selected lets you specify specific null named pipes including IPC$.
>
> I could specify the checkbox and then empty out the list. Is this what I
> should be doing?
>

This is what one should be doing provided one does want to not
have any available to null sessions / anonymous user
and this is what the hardening guide recommends on to do, again,
provided that there should be no such shares or named pipes available,
ie. check it for only these and use an empty list

> And for my education, when I do not select the checkbox, what is the
> default
> behavior?

There is none. When not checked there is no change to what is
already in existence. While Windows installs with default values
in the corresponding reg values, there is no guarantee that those
are still as at install, and it is whatever is in them that will be
effective if there is no policy (not checked) impacting them.

>
> And, also, when I do or do not select the checkbox, does either setting
> have
> any effect on a Windows 2000 DC?
>
Sorry, cannot answer, as now W2k DC free.
However, IIRC these settings, as policies, came about later, but
they may be making use of reg vals that W2k already had in which
case they would have effect.


In your inital post you covered the resultant view in your question 4
<quote>
4) When you deselect the checkbox on this group policy, and simply
fail to define any entities, then what are the defaults that will be in
effect?
When I ran RSOP.MSC on one Windows 2003 DC, it had none of
these defined even through its local policy and GPO did not select
checkboxes for any ofthese.

If the lack of any settings in RSOP.MSC means that nothing is being
allowed for anonymous access, then would I get the same result by
enabling the checkbox, and simply forcing the list of each GPO
setting above to be empty?
</quote>

Hopefully you are now clear on "defaults" when policy is unused to
effect a change from the current (on box) settings - they are whatever
is otherwise current settings.

You say rsop on a W2k3 DC showed none checked "even though"
local policy and GPO had none checked.
Isn't that what one would expect ?? (also, there is no local policy
for a DC except for use in a DS restore mode boot)

The lack of any settings in the rsop means either the rsop in not
accurate, or that there is no policy effecting what is set for those,
and so they are at whatever they are otherwise (outside of policy)
set. Remember there is a "op" at the end of rsop - it only shows
the result of all relevant policies - not all policies plus machine
state (ie. if no policy effective on something it is not showing
the machine state that is being left unchanged).

Now Will, notice that I hung back not replying initially to your
post. That is because there tends to be a behavior that posts with
replies get less attention, and I really want to see MS respond to
you on this issue of getting rid of all null sessions - per our exchange
in some other thread(s).
Anyway, I notice you have not mentioned the policy
Network access: Restrict anonymous access to named pipes and shares
which for W2k3 exists and controls whether the two separate lists
of anonymously available named pipes and of shares are even used.
If this value is not defined to be used the lists are not used and there
is no restriction being imposed.
I mention that as the docs seem to speak as if this set of three policies
exist and work this way in Wk23 and in XP, but in XP the policy that
toggles the two lists does not seem to exist as a settable policy when
using the default sceregvl.inf file.

As you know, no one in these newsgroups has been providing a
definitive list of the necessary named pipes that must be available
from a DC for anonymous access if the DC is going to support the
default set of authentication protocols; of when such as samr can
be removed (i.e. what one looses - precisely what), etc..
Earlier we when through the ones that obviously are present only
for the sake of supporting layered products (IBM mainframe interop,
etc.) but the info dries up after going very far down the road. As Joe
initially commented in prior thread, this may in part be evidence that
no one in MS really knows any longer what some of these are/were
for - precisely that is. I tend to think of this area as on that has been
getting incremental refinement attention from MS over the past few
years, but which still needs further such attention / documentation.

Roger

"Roger Abell [MVP]" <mvpNoSpam@asu.edu> wrote in message
news:%23jzxPUCWHHA.1360@TK2MSFTNGP02.phx.gbl...
> > The behavior of the four GPOs that allow you to specify anonymous access
> > to
> > named pipes, shares, and registry paths are very misleading. You
select
> > a
> > checkbox to make an explicit selection. You then delete the contents
and
> > apply or save. Now when you open it again, Windows has AUTOMATICALLY
> > populated it for you!!
> >
> > So by doing the above action, you incorrectly believe you are explicitly
> > setting these to null values, when in fact your action has 180 degrees
the
> > opposite effect and blanking the list implicitly enables every anonymous
> > access! It's a very bad UI design.
> >
> > I guess the absence of any setting means a null list? That's also not
> > clear.
>
> I believe that is a known bug - at what OS rev do you experience as such?
> Not sure, but I thought I saw a KB related some time back.

I saw this behavior on Windows 2003 with SP1 and all Windows Update patches
through last Friday applied.

So at this point I am pretty much baffled. The only way to null out the
lists of anonymous entities through GPO is to select the checkboxes and
explicitly empty the contents of the lists (of anonymous pipe, shares,
registry paths and subpaths). But doing that has precisely the opposite
effect and the entities are silently repopulated and in fact you end up
forcing the exposure of anonymous entities by virtue of the checkbox. I
can't imagine a more serious bug, short of one that stops the OS from
booting.

It almost feels safer to run with nothing selected since GPO has a bug
(apparently) and empty out the registry entries manually. Does anyone
know which four registry entries contain the lists that correspond to those
GPOs? I'll go look for those in Windows 2000 as well and post the result
of what happens when I empty those on a Windows 2000 DC. Probably
something there will break. Fortunately, we do not have multi-domain
forests and I could even live without trusts if push came to shove.

--
Will

"Will" <westes-usc@noemail.nospam> wrote in message
news:FdydnQHbRujLMn3YnZ2dnUVZ_vGinZ2d@giganews.com...
> "Roger Abell [MVP]" <mvpNoSpam@asu.edu> wrote in message
> news:%23jzxPUCWHHA.1360@TK2MSFTNGP02.phx.gbl...
>> > The behavior of the four GPOs that allow you to specify anonymous
>> > access
>> > to
>> > named pipes, shares, and registry paths are very misleading. You
> select
>> > a
>> > checkbox to make an explicit selection. You then delete the contents
> and
>> > apply or save. Now when you open it again, Windows has AUTOMATICALLY
>> > populated it for you!!
>> >
>> > So by doing the above action, you incorrectly believe you are
>> > explicitly
>> > setting these to null values, when in fact your action has 180 degrees
> the
>> > opposite effect and blanking the list implicitly enables every
>> > anonymous
>> > access! It's a very bad UI design.
>> >
>> > I guess the absence of any setting means a null list? That's also not
>> > clear.
>>
>> I believe that is a known bug - at what OS rev do you experience as such?
>> Not sure, but I thought I saw a KB related some time back.
>
> I saw this behavior on Windows 2003 with SP1 and all Windows Update
> patches
> through last Friday applied.
>
> So at this point I am pretty much baffled. The only way to null out the
> lists of anonymous entities through GPO is to select the checkboxes and
> explicitly empty the contents of the lists (of anonymous pipe, shares,
> registry paths and subpaths). But doing that has precisely the opposite
> effect and the entities are silently repopulated and in fact you end up
> forcing the exposure of anonymous entities by virtue of the checkbox. I
> can't imagine a more serious bug, short of one that stops the OS from
> booting.
>
> It almost feels safer to run with nothing selected since GPO has a bug
> (apparently) and empty out the registry entries manually. Does anyone
> know which four registry entries contain the lists that correspond to
> those
> GPOs? I'll go look for those in Windows 2000 as well and post the
> result
> of what happens when I empty those on a Windows 2000 DC. Probably
> something there will break. Fortunately, we do not have multi-domain
> forests and I could even live without trusts if push came to shove.
>
I am not sure but that the repopulation is just happening when the
policy is edited but that the edit emptying it saves correctly.

Remember, these are saved into sce's persisted structures, and will
only show in registry after policy is applied.

The keys for almost anything in the Security Settings section of
policy can be located by use on notepad with sceregvl.inf file.
Worse come to worse, search on the display string used in UI,
then on its %substitution string% in strings section then search
on that

MACHINE\System\CurrentControlSet\Control\Lsa\RestrictAnonymous,4,%RestrictAnonymous%,0
MACHINE\System\CurrentControlSet\Control\Lsa\RestrictAnonymousSAM,4,%RestrictAnonymousSAM%,0
MACHINE\System\CurrentControlSet\Control\SecurePipeServers\Winreg\AllowedPaths\Machine,7,%AllowedPat hs%,4
MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters\NullSessionPipes,7,%NullPipes%,4
MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters\NullSessionShares,7,%NullShares%,4

"Roger Abell [MVP]" <mvpNoSpam@asu.edu> wrote in message
news:eXqkc9GWHHA.5060@TK2MSFTNGP06.phx.gbl...
> "Will" <westes-usc@noemail.nospam> wrote in message
> news:FdydnQHbRujLMn3YnZ2dnUVZ_vGinZ2d@giganews.com...
>> "Roger Abell [MVP]" <mvpNoSpam@asu.edu> wrote in message
>> news:%23jzxPUCWHHA.1360@TK2MSFTNGP02.phx.gbl...
>>> > The behavior of the four GPOs that allow you to specify anonymous
>>> > access
>>> > to
>>> > named pipes, shares, and registry paths are very misleading. You
>> select
>>> > a
>>> > checkbox to make an explicit selection. You then delete the contents
>> and
>>> > apply or save. Now when you open it again, Windows has AUTOMATICALLY
>>> > populated it for you!!
>>> >
>>> > So by doing the above action, you incorrectly believe you are
>>> > explicitly
>>> > setting these to null values, when in fact your action has 180 degrees
>> the
>>> > opposite effect and blanking the list implicitly enables every
>>> > anonymous
>>> > access! It's a very bad UI design.
>>> >
>>> > I guess the absence of any setting means a null list? That's also
>>> > not
>>> > clear.
>>>
>>> I believe that is a known bug - at what OS rev do you experience as
>>> such?
>>> Not sure, but I thought I saw a KB related some time back.
>>
>> I saw this behavior on Windows 2003 with SP1 and all Windows Update
>> patches
>> through last Friday applied.
>>
>> So at this point I am pretty much baffled. The only way to null out the
>> lists of anonymous entities through GPO is to select the checkboxes and
>> explicitly empty the contents of the lists (of anonymous pipe, shares,
>> registry paths and subpaths). But doing that has precisely the opposite
>> effect and the entities are silently repopulated and in fact you end up
>> forcing the exposure of anonymous entities by virtue of the checkbox.
>> I
>> can't imagine a more serious bug, short of one that stops the OS from
>> booting.
>>
>> It almost feels safer to run with nothing selected since GPO has a bug
>> (apparently) and empty out the registry entries manually. Does anyone
>> know which four registry entries contain the lists that correspond to
>> those
>> GPOs? I'll go look for those in Windows 2000 as well and post the
>> result
>> of what happens when I empty those on a Windows 2000 DC. Probably
>> something there will break. Fortunately, we do not have multi-domain
>> forests and I could even live without trusts if push came to shove.
>>
> I am not sure but that the repopulation is just happening when the
> policy is edited but that the edit emptying it saves correctly.
>
> Remember, these are saved into sce's persisted structures, and will
> only show in registry after policy is applied.
>
> The keys for almost anything in the Security Settings section of
> policy can be located by use on notepad with sceregvl.inf file.
> Worse come to worse, search on the display string used in UI,
> then on its %substitution string% in strings section then search
> on that
>
> MACHINE\System\CurrentControlSet\Control\Lsa\RestrictAnonymous,4,%RestrictAnonymous%,0
> MACHINE\System\CurrentControlSet\Control\Lsa\RestrictAnonymousSAM,4,%RestrictAnonymousSAM%,0
> MACHINE\System\CurrentControlSet\Control\SecurePipeServers\Winreg\AllowedPaths\Machine,7,%AllowedPat hs%,4
> MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters\NullSessionPipes,7,%NullPipes%,4
> MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters\NullSessionShares,7,%NullShares%,4
>
>
Here is the other, which is curiously not present in the XP sceregvl.inf
and hence not available for use in an editing governed by it
MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters\RestrictNullSessAccess,4,%Restrict NullSessAccess%,0
I find that omission troubling as it is the enabling setting for the
ones that are present.

Notice the comment in the Threats and Countermeasures Guide about it
<quote>
When enabled, this policy setting restricts anonymous access to only those
shares and pipes that are named in the Network access: Named pipes that
can be accessed anonymously and Network access: Shares that can be a
ccessed anonymously settings. This policy setting controls null session
access to shares on your computers by adding RestrictNullSessAccess
with the value 1 in the registry key
HKLM\System\CurrentControlSet\Services\LanManServer\Parameters.
This registry value toggles null session shares on or off to control whether
the server service restricts unauthenticated clients' access to named
resources.
</quote>
http://www.microsoft.com/technet/sec.../tcgch05n.mspx

You might want to read comment on some of the others, as for a couple
the W2k equivalents are mentioned. Also, the list of named pipes the
Guide shows (incomplete) is termed the "Default Named Pipes",
whatever that is actually intended to mean (populate policy setting
whenever edited in a GPO despite it having previously been edited
and set to empty by intent).

The comment on the default setting being same as recommended setting
for anonymously accessible shares is also wrong, if you notice.

Needless to say, next time there is a call for review of the Guide, getting
more clarity on these types of questions is on my list of things to push for
(most of last time did result in some changes so perhaps it will improve).

Roger a brief summary:

1) You were completely correct that if I select the checkbox for the lists
of anonymous shares, pipes, and registry entries and then empty them, the
null setting does take effect on next application of the GPO. The bug
where these repopulate is simply within the GPO editor. It's still nasty,
but less serious than it looked at first.

2) Even after you take out ALL anonymous shares, pipes, and registry
settings, and set the authentication level to refuse LM and NTLM, you will
still get eventid 540 and NTLMSSP anonymous connections from every member
server that is seeking to renew a Kerberos ticket. This is at least true
with a Windows 2003 DC and W2K member servers. Not sure if this changes
with Windows 2003 member servers (I would like to know).

I would sure like to understand what the NTLMSSP anonymous logon is used
for. Perhaps that eventID 540 Anonymous Logon is a pre-Kerberos
authentication just to ask the domain controller what authentication methods
it supports using NTLM 2? If anyone has specifics on what it is used for
I would appreciate details.

3) I looked at all of this with a sniffer, and what is quite strange to me
is during the prenegotiation period before the member server attempts to do
any SMB to the DC, the member server is listing the protocols it would like
to work with. It lists very unsecure protocols including Windows for
Workgroups 3.1, early LANMAN protocols, etc. It is the server that comes
back and lists only two acceptable protocols as Kerberos and NTLMSSP. Why
is the W2K member server asking for unsecure protocols when the
authentication level is set to the highest. Strange.

Obviously I don't understand it too well yet, but would like to change that.
Is there a newsgroup that specializes in programmers using Windows
authentication APIs?

--
Will

"Will" <westes-usc@noemail.nospam> wrote in message
news:9KmdnVPoRYDfoHjYnZ2dnUVZ_rKvnZ2d@giganews.com...
> Roger a brief summary:
>
> 1) You were completely correct that if I select the checkbox for the lists
> of anonymous shares, pipes, and registry entries and then empty them, the
> null setting does take effect on next application of the GPO. The bug
> where these repopulate is simply within the GPO editor. It's still
> nasty,
> but less serious than it looked at first.
>

Yes, it is very pernicious.
I think I did see a KB warning about this though,
but I certainly cannot locate it currently.


> 2) Even after you take out ALL anonymous shares, pipes, and registry
> settings, and set the authentication level to refuse LM and NTLM, you will
> still get eventid 540 and NTLMSSP anonymous connections from every member
> server that is seeking to renew a Kerberos ticket. This is at least true
> with a Windows 2003 DC and W2K member servers. Not sure if this changes
> with Windows 2003 member servers (I would like to know).
>

I think it remains so with members also.
I only see those go away for example on my IIS w2k3 r2 members when
the IPsec cloak leaves only tpc 80, 443 open to the authentication attemps,
hence blocking this (what?) residual successful anonymous login.

> I would sure like to understand what the NTLMSSP anonymous logon is used
> for. Perhaps that eventID 540 Anonymous Logon is a pre-Kerberos
> authentication just to ask the domain controller what authentication
> methods
> it supports using NTLM 2? If anyone has specifics on what it is used
> for
> I would appreciate details.
>

I have not seen details, and would similarly appreciate MS providing
more clarity on this entire topic for their customer base.

As I stated in a different thread with yourself, my present working
assumption is that the event recorded is the initial SSPI negotiation,
which of course by definition must be prior to any authenticated
access. It is of course only my current hypothesis, but I do recognize
what you are reporting, that one cannot remove all successful logon
events for anonymous.
PS.
my weak point on the hypotheis is why we see SPNEGO events
that are separate from the NT Authority\Anonymous Logon
success events

> 3) I looked at all of this with a sniffer, and what is quite strange to me
> is during the prenegotiation period before the member server attempts to
> do
> any SMB to the DC, the member server is listing the protocols it would
> like
> to work with. It lists very unsecure protocols including Windows for
> Workgroups 3.1, early LANMAN protocols, etc. It is the server that comes
> back and lists only two acceptable protocols as Kerberos and NTLMSSP.
> Why
> is the W2K member server asking for unsecure protocols when the
> authentication level is set to the highest. Strange.
>

IIRC the SSPI negotiation starts with the requestor listing
the protocols it is capable of using (you said ones it would
like to use). Sever responds with its preference. It is after
all a negotiation, so requestor may not support servers first
choice, etc..

> Obviously I don't understand it too well yet, but would like to change
> that.
> Is there a newsgroup that specializes in programmers using Windows
> authentication APIs?

http://msdn2.microsoft.com
specifically digging in at
http://msdn2.microsoft.com/en-us/library/default.aspx
(and do not overlook the DDK - driver dev kit)

When I was first charged with exploring MS Windows for its
fit/misfit in our environment, the SDK (via MSDN) was THE
(as in only) location for any realistic, meaningful, and not
outdated, info about Windows operation (and hence rigorous
administration/management).
Things have improved greatly, but there is still gap.

Roger

> "Will" <westes-usc@noemail.nospam> wrote in message
> news:9KmdnVPoRYDfoHjYnZ2dnUVZ_rKvnZ2d@giganews.com...
>> Obviously I don't understand it too well yet, but would like to change
>> that.
>> Is there a newsgroup that specializes in programmers using Windows
>> authentication APIs?
>

Sorry Will, I misread, missing that you were asking about forums,
not API docs. MSDN has its own forums,
http://forums.microsoft.com/msdn
and there are some other resources like lists of Developmentor
(http://discuss.develop.com/) which are now-a-days more shifted
toward web services.
I am sure you can google out others.