Integrating Windows 2000 and Windows NT 4.0 RAS

Incorporate NT 4.0 RAS servers into your Win2K environment

If you've already started working with Windows 2000 (Win2K), you might have noticed that Windows NT 4.0 RAS systems pose interoperability concerns in a mixed Win2K and NT network. When you promote a Windows 2000 Server (Win2K Server) system to domain controller status and use the Active Directory Installation Wizard (i.e., dcpromo.exe) to create the system's Active Directory (AD), the wizard presents you with default permissions options for AD user and group object access for server applications such as RAS. The Active Directory Installation Wizard Permissions dialog box informs you that to run server programs on pre-Win2K systems in your Win2K network, you must weaken Win2K's security by relaxing AD's default permissions. The dialog box options present security and logistical implications that you need to understand.

The wizard poses this RAS-centric question during AD creation because of the way NT 4.0 RAS servers (and Win2K RAS servers in trusted NT 4.0 domains) authenticate users. NT 4.0's SAM-based NT LAN Manager (NTLM) authentication method poses interoperability problems with NT 4.0 RAS servers that interact with Win2K domain controllers.

Before I dive into the specifics of the problem, let's review a few basic premises about how this mixed environment works. NT domains use SAM-based NTLM authentication, so NT 4.0 RAS servers in mixed Win2K and NT 4.0 domains use legacy, NT 4.0-style authentication requests to try to authenticate user logon attempts from RAS clients. If the Win2K domain is in native mode (i.e., you've upgraded all NT 4.0 domain controllers to Win2K), the domain's PDC emulator will authenticate the RAS clients. However, if the domain is in mixed mode (i.e., NT 4.0 domain controllers are still present in the Win2K domain), the Win2K domain controller that is acting as the PDC emulator or a downlevel NT 4.0 BDC will authenticate RAS clients. The NT 4.0 RAS and RRAS services run in the security context of the special LocalSystem (aka System) account. Running in this context means that to validate RAS clients, RAS and RRAS use anonymous or null session credentials to query domain controllers. The problem occurs when the user account that RAS is validating is part of a Win2K domain. By default, Win2K domains and domain controllers don't permit anonymous access to AD objects such as user objects, so the authentication of RAS clients will fail unless you change this default behavior.

The first way to accommodate legacy RAS servers is to select the Permissions compatible with pre-Windows 2000 servers option in the Active Directory Installation Wizard Permissions dialog box. This option instructs Win2K to relax permissions so that null and anonymous sessions can access AD objects. To set up this relaxed configuration, Win2K creates a special local group (called Pre-Windows 2000 Compatible Access) in the AD domain for Win2K user groups or accounts that are referenced by NT 4.0 RAS or other legacy server applications that use null session credentials during user authentication attempts. If you select the Permissions compatible with pre-Windows 2000 servers option, remember to add to this special domain local group any users that use an NT 4.0 RAS server to log on.

What if you didn't select this option when you created AD, but now you need to permit this type of access? Fortunately, you can still set up this type of access because the AD schema internally references the Pre-Windows 2000 Compatible Access group. You simply need to create the group on any Win2K domain controller, then add the appropriate members (i.e., user accounts that will use NTLM authentication to dial in to RAS servers). At a command prompt, type

net localgroup "Pre-Windows 2000   Compatible Access" everyone /add

You create the group on a domain controller, so the group will automatically become available on all domain controllers after AD replication occurs. Finally, all NT 4.0 RAS servers involved in this type of a mixed environment need to be running Service Pack 4 (SP4) or later, or authentication won't work.