well, actually i didn't set the registry value directly... i enabled both of
the followings through group policy.
Network access: Do not allow anonymous enumeration of SAM accounts
Network access: Do not allow anonymous enumeration of SAM accounts and
shares
it's applied to both domain controllers container, and the domain level.
i go to the registry and saw that restrictanonymous=2,
restrictanonymoussam=1 are being set.
since our domain controllers are Win2003... so, i guess you can say those
are Win2003 group policy templates.
anyway, i'm using an old tool by ForixNT null scanner (from a machine not
belonging to our domain)... and surprisingly saw that using null session,
one :
- CAN get a list of user accounts on the domain controllers (Win2003)
- CANNOT get a list of accounts on any Win2000/ Win2003 member servers and
WinXP
i'm not sure where you can download this tool now... 'coz ForixNT.com
website is no longer up for over a year... but i think there are other tools
that can produce the same result.
- corinna
-----Original Message-----
From: Levinson, Karl [mailto:Karl.Levinson (at) dhs (dot) gov [email concealed]]
Sent: Tuesday, May 11, 2004 9:00 AM
To: 'Corinna'; focus-ms (at) securityfocus (dot) com [email concealed]
Subject: RE: Virus is getting domain account listing
On your 2003 servers, have you tried RestrictAnonymous=1 plus
RestrictAnonymousSAM=1 ?
As I said, my understanding is that RestrictAnonymous=2 is only a meaningful
and valid value in Windows 2000. Assuming I'm correct on this, I would
recommend you avoid using this value in XP, 2003 or NT, as it is untested
and I have no idea what the end result might be on various OSes. It could
be that this is the reason for your problem, who knows. I believe
RestrictAnonymous=2 in Windows 2000 is similar or identical to using
RestrictAnonymous=1 plus RestrictAnonymousSAM=1 in XP/2003.
Also, make sure you haven't applied Group Policy templates that were
designed for Windows 2000 onto Windows Server 2003.
For Windows Server 2003, I'd recommend inspecting the available Group Policy
options in the Group Policy MMC snap-in, and reading the various Microsoft
documentation on what those settings do and where they should be set. For
example, see the first link below, particularly the Group Policy settings
that start with "Network access:"
-----Original Message-----
From: Corinna [mailto:corinna (at) turbonet (dot) com [email concealed]]
Sent: Monday, May 10, 2004 6:01 PM
To: focus-ms (at) securityfocus (dot) com [email concealed]
Subject: RE: Virus is getting domain account listing
well, actually... this HKLM\System\CurrentControlSet\Control\LSA
restrictanonymous=2, restrictanonymoussam=1
the setting works only on our winxp, win2000, win2003 member machines...
on our Win2003 AD domain controllers... one can still use null session to
get our entire list of domain accounts.
if anyone knows of any fix... please let me know.
thanks!
- corinna
-----Original Message-----
From: David Carlin [mailto:djc6 (at) cwru (dot) edu [email concealed]]
Sent: Monday, May 10, 2004 10:30 AM
To: focus-ms (at) securityfocus (dot) com [email concealed]
Subject: Re: Virus is getting domain account listing
On May 10, 2004, at 11:42 AM, Levinson, Karl wrote:
> RestrictAnonymous=1 does not disable netbios null sessions or prevent
> enumeration of data. It just tries to reduce the amount of data
> detail that can be enumerated. Read the articles at
> www.securityfriday.com and download
> the free Getacct tool from that site to see what information is still
> available from your system anonymously.
This was very helpful. Getacct does indeed show all my users, and
conveniently marks which ones have Administrative privledges.
> As you may know, for XP, there is a second registry value,
> RestrictAnonymousSam. Search www.google.com for
> "RestrictAnonymousSam" for information on how it works. In Windows
> 2000, as you may know there is also
> a value RestrictAnonymous=2 which does not exist in either NT, XP or
> 2003
> [but which is similar to RestrictAnonymous=1 plus
> RestrictAnonymousSAM=1 in
> XP and 2003]. This gets you closer to protecting your user lists.
> But you
> can't consider using these higher values until you get rid of NT, 9x
> and ME
> from your network, as well as some other legacy software
> considerations.
> The Windows 2000 Group Policy guide at www.nsa.gov/snac/ has some good
> information and links on the things that can break.
So basically, long term, wait for Active Directory - still waiting for
campus network folks to implement this at the university level. We're
not allowed to start our own AD on a per-department basis.
There is not much I can do in the mean time to block whatever method
getacct uses to gain access to the user list?
well, actually i didn't set the registry value directly... i enabled both of
the followings through group policy.
Network access: Do not allow anonymous enumeration of SAM accounts
Network access: Do not allow anonymous enumeration of SAM accounts and
shares
it's applied to both domain controllers container, and the domain level.
i go to the registry and saw that restrictanonymous=2,
restrictanonymoussam=1 are being set.
since our domain controllers are Win2003... so, i guess you can say those
are Win2003 group policy templates.
anyway, i'm using an old tool by ForixNT null scanner (from a machine not
belonging to our domain)... and surprisingly saw that using null session,
one :
- CAN get a list of user accounts on the domain controllers (Win2003)
- CANNOT get a list of accounts on any Win2000/ Win2003 member servers and
WinXP
i'm not sure where you can download this tool now... 'coz ForixNT.com
website is no longer up for over a year... but i think there are other tools
that can produce the same result.
- corinna
-----Original Message-----
From: Levinson, Karl [mailto:Karl.Levinson (at) dhs (dot) gov [email concealed]]
Sent: Tuesday, May 11, 2004 9:00 AM
To: 'Corinna'; focus-ms (at) securityfocus (dot) com [email concealed]
Subject: RE: Virus is getting domain account listing
On your 2003 servers, have you tried RestrictAnonymous=1 plus
RestrictAnonymousSAM=1 ?
As I said, my understanding is that RestrictAnonymous=2 is only a meaningful
and valid value in Windows 2000. Assuming I'm correct on this, I would
recommend you avoid using this value in XP, 2003 or NT, as it is untested
and I have no idea what the end result might be on various OSes. It could
be that this is the reason for your problem, who knows. I believe
RestrictAnonymous=2 in Windows 2000 is similar or identical to using
RestrictAnonymous=1 plus RestrictAnonymousSAM=1 in XP/2003.
Also, make sure you haven't applied Group Policy templates that were
designed for Windows 2000 onto Windows Server 2003.
For Windows Server 2003, I'd recommend inspecting the available Group Policy
options in the Group Policy MMC snap-in, and reading the various Microsoft
documentation on what those settings do and where they should be set. For
example, see the first link below, particularly the Group Policy settings
that start with "Network access:"
www.microsoft.com/resources/documentation/WindowsServ/2003/all/techref/e
n-us
/w2k3tr_sepol_local_set.asp
www.microsoft.com/technet/security
-----Original Message-----
From: Corinna [mailto:corinna (at) turbonet (dot) com [email concealed]]
Sent: Monday, May 10, 2004 6:01 PM
To: focus-ms (at) securityfocus (dot) com [email concealed]
Subject: RE: Virus is getting domain account listing
well, actually... this HKLM\System\CurrentControlSet\Control\LSA
restrictanonymous=2, restrictanonymoussam=1
the setting works only on our winxp, win2000, win2003 member machines...
on our Win2003 AD domain controllers... one can still use null session to
get our entire list of domain accounts.
if anyone knows of any fix... please let me know.
thanks!
- corinna
-----Original Message-----
From: David Carlin [mailto:djc6 (at) cwru (dot) edu [email concealed]]
Sent: Monday, May 10, 2004 10:30 AM
To: focus-ms (at) securityfocus (dot) com [email concealed]
Subject: Re: Virus is getting domain account listing
On May 10, 2004, at 11:42 AM, Levinson, Karl wrote:
> RestrictAnonymous=1 does not disable netbios null sessions or prevent
> enumeration of data. It just tries to reduce the amount of data
> detail that can be enumerated. Read the articles at
> www.securityfriday.com and download
> the free Getacct tool from that site to see what information is still
> available from your system anonymously.
This was very helpful. Getacct does indeed show all my users, and
conveniently marks which ones have Administrative privledges.
> As you may know, for XP, there is a second registry value,
> RestrictAnonymousSam. Search www.google.com for
> "RestrictAnonymousSam" for information on how it works. In Windows
> 2000, as you may know there is also
> a value RestrictAnonymous=2 which does not exist in either NT, XP or
> 2003
> [but which is similar to RestrictAnonymous=1 plus
> RestrictAnonymousSAM=1 in
> XP and 2003]. This gets you closer to protecting your user lists.
> But you
> can't consider using these higher values until you get rid of NT, 9x
> and ME
> from your network, as well as some other legacy software
> considerations.
> The Windows 2000 Group Policy guide at www.nsa.gov/snac/ has some good
> information and links on the things that can break.
So basically, long term, wait for Active Directory - still waiting for
campus network folks to implement this at the university level. We're
not allowed to start our own AD on a per-department basis.
There is not much I can do in the mean time to block whatever method
getacct uses to gain access to the user list?
-David
------------------------------------------------------------------------
---
------------------------------------------------------------------------
---
------------------------------------------------------------------------
---
------------------------------------------------------------------------
---
------------------------------------------------------------------------
---
------------------------------------------------------------------------
---
------------------------------------------------------------------------
---
------------------------------------------------------------------------
---
[ reply ]