In an effort to prevent attackers and other curious folks from viewing lists of SAM user accounts and share names on my servers and workstations, I opened Local Security Policy on each machine and set Additional restrictions for anonymous connections to Do not allow enumeration of SAM accounts and shares, as you described in "Protecting the Administrator Account," November 2000, InstantDoc ID 16093. I recently did a vulnerability scan and confirmed that my Windows XP workstations aren't giving up SAM account names and shares, but my Windows 2000 computers are. What's going on?
When you setAdditional restrictions for anonymous connections toDo not allow enumeration of SAM accounts and shares, Win2K still lets anonymous connections translate a supplied SID to its username and vice versa, which causes some vulnerability scanners to report that the Win2K machine allows full enumeration of all accounts and shares. Although the vulnerability report isn't fully accurate in this case, it does highlight a risk—namely that attackers can still figure out the name of built-in accounts such as Administrator and Guest because such accounts have predictable SIDs.
The scan didn't flag your XP computers because in XP, Microsoft replaced Additional restrictions for anonymous connections with three new settings: Network access: Allow anonymous SID/name translation; Network access: Do not allow anonymous enumeration of SAM accounts; and Network access: Do not allow anonymous enumeration of SAM accounts and shares. (You'll find all these settings in any Group Policy Object—GPO—under Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options.) The Network access: Allow anonymous SID/name translation setting defaults to disabled, which explains why your scanner didn't flag the XP computers. To learn how to use the same GPO to maintain both XP's and Win2K's settings, see "Using One GPO to Control Both Windows XP and Windows 2000 Settings," InstantDoc ID 42328.
End of Article
Register
