|
|
|
|
Posted by Roger Abell [MVP] on February 24, 2007, 10:04 am
Please log in for more thread options
>> 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/archive/2006/05/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
|
|
Posted by Will on February 24, 2007, 4:34 pm
Please log in for more thread options
> > 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
|
|
Posted by Roger Abell [MVP] on February 24, 2007, 6:55 pm
Please log in for more thread options >> > 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,%AllowedPaths%,4
MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters\NullSessionPipes,7,%NullPipes%,4
MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters\NullSessionShares,7,%NullShares%,4
|
|
Posted by Roger Abell [MVP] on February 24, 2007, 7:59 pm
Please log in for more thread options
>>> > 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,%AllowedPaths%,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,%RestrictNullSessAccess%,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/security/guidance/serversecurity/tcg/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).
|
|
Posted by Will on February 28, 2007, 3:28 am
Please log in for more thread options 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
|
| Similar Threads | Posted | | Explanation of Anonymous Named Pipes Security Policy | August 20, 2006, 9:28 pm |
| 64 bit windows server 2003 ent sp2 remote registry security | November 11, 2008, 5:50 am |
| Anonymous folder access | December 13, 2006, 9:14 pm |
| Enterprise Ca authority anonymous access | January 16, 2007, 4:07 pm |
| Anonymous Access to Shared Folder | November 5, 2007, 1:13 pm |
| Outlook Compatibility issue with Disabling Anonymous Access | September 13, 2007, 2:22 pm |
| user cannot access shares | October 21, 2005, 12:30 pm |
| Re: user cannot access shares | October 25, 2005, 10:23 pm |
| How can admin not have access to certain shares? | February 16, 2008, 12:36 pm |
| Trusted NT domain users have full access to 2K3 server shares | January 23, 2007, 6:51 am |
|
|
|
|
XML Sitemap