During the past year, we upgraded our entire domain to Windows 2000. We recently analyzed network traffic and noticed that we were capturing NetBIOS packets. Didn't Microsoft eliminate NetBIOS from pure Win2K environments because it's not a secure transport protocol?
NetBIOS isn't a transport protocol; it's a high-level interprocess communications (IPC) protocol that a transport protocol such as IP, IPX, or NetBEUI must carry. IP carries NetBIOS traffic on UDP ports 137 and 138 and TCP port 139, which is called NetBIOS over TCP/IP (NetBT). To handle file and printer sharing, Microsoft uses the Server Message Block (SMB) protocol, an even higher-level protocol. Windows NT 4.0 and Windows 9x use NetBIOS to carry SMB, and of course NetBIOS rides inside IP, IPX, or NetBEUI.
NetBIOS includes name-resolution and resource-publishing features, but be-cause these features don't scale well to large networks, Microsoft developed WINS, which has had its share of problems. With Win2K, Microsoft broke from naming limitations inherent to NetBIOS and enabled the OS to rely solely on proven Internet technologies such as DNS. Win2K can directly host SMB on IP by using TCP and UDP port 445, which is known as the Common Internet File System (CIFS).
By default, Win2K servers support clients that use NetBT or CIFS to connect, so these servers have no problem supporting NT 4.0 or Win9x clients. But how does a Win2K client know whether to use NetBT or CIFS when it tries to connect to another computer? Win2K doesn't contact the server first to determine which OS the server is running; instead, the Win2K client sends connection requests to ports 139 and 445 at the same time. The server answers on one port, and the client communicates on that port and resets the other. If a Win2K client attempts to connect to an NT 4.0 server, the NT server ignores the port 445 connection request and responds on port 139. If the Win2K client attempts to connect to a Win2K server, the server chooses to respond on port 445. These dual connection attempts are causing the "NetBIOS" packets that you continue to see.
As for security, NetBT isn't really the risk*leaving file sharing active on a server is. The risk of intruders accessing the security service is the same whether they use port 445 or 139 to gain entry to your machine. The advantages of eliminating NetBIOS are enhanced network performance and better name resolution, both of which enable greater scalability. Mark Minasi does a great job of describing how to disable NetBIOS and the effects of doing so in "Life Without NetBIOS," August 2001, http://www.winnetmag.com, InstantDoc ID 21537.
We migrated our entire domain to Windows 2000 and moved the domain from mixed mode to native mode. Recently, I ran a Windows LAN Manager (NTLM) sniffer and discovered that I can still detect NTLM packets when users connect to a particular server on my network. The server is a Win2K machine and is a member of my Active Directory (AD) domain. I thought that a Win2K domain in native mode eliminated NTLM, which I know is much weaker than Kerberos and relatively easy to sniff and crack. What's the deal?>
Native mode and mixed mode have nothing to do with whether computers in the domain use NTLM or Kerberos for authentication. Native mode requires that all domain controllers (DCs)*not all computers*in a domain be Win2K machines. Mixed mode is a temporary mode that a domain starts out in that lets AD support legacy NT BDCs. In mixed mode, AD disables certain features that an NT BDC's SAM can't reflect, including the nesting of global and local security groups and the creation of universal security groups. After you decommission or upgrade all your BDCs to Win2K, you can bring the domain to native mode and regain the functionality you lost while in mixed mode.
As a client, Win2K tries to use Kerberos to authenticate, and if the server or DC doesn't answer, the client falls back to NTLM. Regardless of the domain mode, Win2K DCs and servers support clients that use NTLM. However, because you've upgraded all your computers to Win2K and made them part of an AD domain, the fact that you continue to see NTLM packets when clients connect to your server is interesting. Are the clients all Windows XP or Win2K and part of the overall forest? If not*if, for example, the clients are NT 4.0 machines in a trusted NT domain*they can authenticate to the server only by using NTLM. Another possibility is that although your server and clients are Win2K computers in the same forest, the clients connect to the server by using local user accounts on the server's SAM (which you created in the Computer Management\Local Users and Groups snap-in) instead of with AD domain user accounts. Win2K doesn't support Kerberos for local user accounts, so whenever you connect to a computer by using a local account, you authenticate by using the weaker NTLM protocol.
Win2K gives you no option to completely disable NTLM, so you're left to configure your network to avoid using NTLM (i.e., keep all your computers in the same forest, don't set up trusts with NT domains, and don't use local accounts) and strengthen NTLM where you do use it. NTLM supports two hash and response types: LM and NT. NTLM is weak because of the LM response. Microsoft addressed these weaknesses with NTLMv2. Go to any Group Policy Object (GPO) and implement the LAN Manager Authentication Level policy under Computer Configuration, Windows Settings, Security Settings, Local Polices, Security Options to use NTLMv2 and configure your computers to refrain from sending or accepting the LM response and to use the much stronger NTLMv2 response. However, be aware that this transition isn't always a smooth one. You must make sure that NT and Win9x are properly updated and configured to use NTLMv2 before you configure your DCs to refuse weaker credentials. For more information about NTLMv2 and how to configure your clients to use it, see "Inside SP4 NTLMv2 Security Enhancements," September 1999, http://www.winnetmag.com, InstantDoc ID 7072, and the Microsoft articles "LMCompatibilityLevel and Its Effects" (Q175641, http://support.microsoft.com) and "How to Enable NTLM 2 Authentication for Windows 95/98/2000 and NT" (Q239869, http://support.microsoft.com).
The Security Options for a Group Policy Object (GPO) include a policy called Audit the access of global system objects. What does this policy do? Should I enable it?
This policy corresponds to the AuditBaseObjects value in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa registry subkey. If you open Computer Configuration, Windows Settings, Security Settings, Local Policies and enable this policy, Windows 2000 audits low-level system objects (e.g., mutexes, events, semaphores), so you can track objects that programs access. However, this auditing can result in an overwhelming accumulation of events in your Security log. These events are useful to Win32 programmers for debugging but offer little practical value to administrators.
We've found some events in the Security log that we don't recognize. Recently, we enabled Audit account management on our domain controllers (DCs). Now, whenever we change, add, or remove members from certain groups, we receive unexpected event IDs. For example, when we add a member to a global group, we expect to see event ID 632 (Security Enabled Global Group Member Added) but instead see event ID 655 (Security Disabled Global Group Member Added.) What do security enabled and security disabled mean?
Active Directory (AD) groups can be one of two types (security or distribution) and one of three scopes (local, global, or universal). You can use security groups in ACLs, assigned rights, and any other security-related setting. You can also use security groups as a distribution list (DL) in a Microsoft Exchange Server environment. However, you can use distribution groups only in Exchange and Microsoft Outlook—not for any security-related setting. Local, global, and universal scopes control where in the forest you can grant a group permission and why scopes of groups can be nested inside of one another. In the Security log, Windows 2000 refers to security groups as security-enabled groups and distribution groups as security-disabled groups and lists a full set of group maintenance event IDs for each operation on each scope of group. Evidently, your HRReportDistribution group is a distribution group, hence the unexpected event IDs. Because distribution groups are irrelevant to security, you can probably ignore event IDs 648 through 657. For a complete list of these events, see http://www.counterpane.com/log-windows.html.