After attending a CEH security seminar, you make a list of changes you would like to perform on your network
to increase its security. One of the first things you change is to switch the RestrictAnonymous setting from 0 to
1 on your servers. This, as you were told, would prevent anonymous users from establishing a null session on
the server. Using Userinfo tool mentioned at the seminar, you succeed in establishing a null session with one
of the servers. Why is that?
A.
RestrictAnonymous must be set to “10” for complete security
B.
RestrictAnonymous must be set to “3” for complete security
C.
RestrictAnonymous must be set to “2” for complete security
D.
There is no way to always prevent an anonymous null session from establishing
Windows 2000 introduced support for a new value in RestrictAnonymous – ‘2’. This is pretty cool because it prevents all anonymous calls (as far as I can tell) that are not explicitly granted to the null user. When Windows 2000 builds the access token for the Null user, he is specifically not included in the ‘Everyone’ group when RA is set to 2, and that is the key. In reality, the only reason Null can do so much in NT land is not because he is somebody special, but because he is part of the Everyone group. Since Windows 2000 allows us to remove him from this group, we can effectively lock-down what he can do. In fact, this setting prevents him from using the IPC$ share in the first place. I tried going back to an NT box and setting RA to 2 just to see if there was some super-secret undocumented support for this, but no joy.
RestrictAnonymous is a setting in the Domain Controller which defines whether or not an “anonymous” account (such as Local System Account) is permitted to enumerate domain groups for a particular user.
If RestrictAnonymous is set to 1, which is the default, then the LSA account does not have permission to enumerate groups, which certain application requires.