You can't lock down anonymous access any more than that for a Windows 2003
Server. You might want to check Local Security Policy on your Windows 2003
domain controller via secpol.msc to make sure that those security option
settings are being applied. I know that Windows 2000 had a security option
for additional restrictions for anonymous access that could be set to no
access without explicit anonymous permissions. That setting definitely did
block anonymous access so much so that domain networking did not sometimes
work correctly when configured on domain controllers depending on domain
makeup. That option was removed from Windows 2003 probably due to the
experience with Windows 2000. Supposedly do not allow anonymous enumeration
of SAM accounts/Shares was supposed to be as restrictive but I have not
found that to be the case as I can create a null session to Windows 2003
when that security option is enabled via [ net use \\dc1\ipc$ "" /user:"" ].
In my opinion as long as your perimeter firewall is correctly configured
which will prevent users from untrusted networks from using null sessions,
the risk is very low if you enforce complex passwords, etc. The whole null
session vulnerability used to be a big deal a few years back when users had
their computers and networks exposed to the internet without a firewall and
did not enforce strong passwords or did not use passwords at all. Firewalls,
complex password enforcement, and the use of technologies such as ipsec on
the network can effectively mitigate the risk of null sessions. --- Steve
"greg" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) om...
> "Steven L Umbach" <(E-Mail Removed)> wrote in message
> news:<#(E-Mail Removed)>...
>> By default Windows 2003 will only restrict access allow anonymous
>> enumeration of sam accounts. You might also want to enable the security
>> option for do not allow anonymous enumeration of sam accounts and shares
>> in
>> Domain Controller Security Policy. Also make sure that you are indeed
>> using
>> a null session. You could verify that by going to the domain controller
>> and
>> using Computer Management looking at shared folders/sessions to see how
>> the
>> IPC$ connection is being authenticated.
>>
> Hello Steve,
>
> Thanks,
>
> I already have the following in both domain controller policy and
> doamin policy.
> Allow Anonymous SID/Name translation: DISABLED
> Do not allow anonymous enumeration of SAM accounts: ENABLED
> Do not allow anonymous enumeration of SAM accounts/Shares : ENABLED
> Let everyone permissions apply to anonymous users: DISABLED
>
> Which is why I cant understand what is happening here.
>
>> While restricting access for anonymous access to sam/shares makes sense
>> when
>> it can be done it is part of security through obscurity. A properly
>> configured firewall will not allow users from untrusted networks to use
>> null
>> sessions to enumerate user accounts/shares. Ultimately you need to rely
>> on
>> enforcing strong password policy in the network, share/ntfs permissions,
>> group membership, user rights, the use of auditing, etc. to protect your
>> recourses.
>
> I could not agree more, Group policy protects all the workstations,
> but the DC is a potential source of failure here. Teh firewall can be
> tightened to prevent this happening. SP1 for 2003 is supposed to
> implement the WinXP SP/2 firewall so we already have a rule set that
> we can apply to the DC's then,
>
> Thanks for your comments,
> Dave.
|
Similar Threads
Linear Mode
