لطفا منتظر باشید ...
PublisherNT4 RAS Servers and Active Directory Domains
There's one more item of business left to cover before starting to deploy Windows Server 2003 remote access servers, and that's how to deal with any classic NT4 RAS servers that might be still be in production. Unless you make special accommodations for these RAS servers, they will not be able to authenticate dial-up users in an Active Directory domain. The reason for this harkens back to the origins of Windows networking in LanMan Server.As we've seen, MS-CHAPv2 requires that the remote access server obtain the user's NT password hash to complete the authentication transaction. The NT4 RAS server makes its call to the domain controller to get the user's credentials, but the domain controller says, "Not so fast, buddy. Let me see some Kerberos credentials, first, before I let you touch Active Directory."Well, NT4 doesn't know diddly about Active Directory and it keeps submitting its tried-and-true connection request until it finally gives up and returns an Access Denied message to the user.
Null Sessions
It's a little mystifying at first to figure out why this happens because a user at an NT4 server is able to access Active Directory without a hitch. The problem lies with the security context of the RAS service, which runs under the aegis of the Local System account. The Local System account on a Windows computer has no SID and therefore it cannot make a normal connection to a domain controller.In an NT4 domain, this lack of security context is not a problem because the RAS service can make a null session connection to the domain controller. A null session is a special type of connection in which a connecting entity that presents no credentials whatsoever is given limited access permissions on a server. The NT4 RAS server uses a null session connection to perform an impersonation of the user to the extent necessary to look up the user's credentials and dial-up permissions in the SAM and LSA databases.Windows Server 2003 and Windows 2000 domain controllers do not permit null session connections to touch Active Directory. This avoids certain notorious exploits that have plagued (and continue to plague) classic NT. A Kerberos-enabled remote access server is able to access Active Directory by using the Kerberos credentials obtained by the underlying computer account. The RAS service on an NT4 server is not that fortunate because the underlying computer has no means of obtaining Kerberos credentials.So we have a stalemate of sorts. The workaround involves a group with the long but appropriate name of Pre-Windows 2000 Compatible Access . This group has Read access to the following User attributes in Active Directory:
- Remote Access Information
- General Information
- Logon Information
- Group Membership
- Account Restrictions
The group also has the following permissions for Group objects:
- Read All Properties
- List Contents
- Read Permissions
What is the net result? These permissions give members of the Pre-Windows 2000 Compatible Access group the ability to obtain a user's logon credentials, account restrictions, and group membership, all the information needed to validate an MS-CHAPv2 authentication.
Anonymous Access
Now comes the ugly part. Because NT4 RAS servers have no Kerberos identity, you cannot simply put their computer objects in the Pre-Windows 2000 Compatible Access group and expect dial-in authentication to work. You must open the door to null session connections across the board by making the Anonymous Logon group a member of the Pre-Windows 2000 Compatible Access group.This is a change from Windows 2000, where it was necessary to add the Everyone group rather than the Anonymous Logon group to the Pre-Windows 2000 Compatible Access group. This is due to a change in the way Windows Server 2003 handles null session connections. In legacy Windows, including Windows 2000, the null session connection was assigned membership in the Everyone group by default. This was accomplished by putting the well-known SID representing Everyone into the access token that was auto-generated for null session connections.In Windows Server 2003, null sessions are not put in the Everyone group. This stymies many of the null session port scanners that circulate around the Internet for use in hacking Windows networks. The Anonymous Logon group is a new well-known RID in Windows Server 2003 that is tied to the domain, as contrasted with the Everyone group SID, which is the same for any domain.During Dcpromo, the utility that promotes a server running Windows Server 2003 to a domain controller, there is an option that asks whether or not to maintain Windows 2000 compatibility. This option controls whether the Anonymous Logon group is added to the Pre-Windows 2000 Compatible Access group. (The Everyone group is also added for backward compatibility with Windows 2000.)Additionally, because the NT4 RAS server must query for specific attributes in user and group objects rather than the entire object itself, as is done in classic NT, the NT4 RAS server must be running Service Pack 4 or later. This service pack contains changes to RLOGON and other functions that permit NT to read specific attributes.
Anonymous Access and Active Directory Security
Leaving a null session connection capable of reading Active Directory, even for the limited number of attributes controlled by the Pre-Windows 2000 Compatible Access group, represents a vulnerability that you should avoid. For this reason, you should upgrade your NT4 RAS servers to Windows Server 2003 or Windows 2000 prior to migrating your domain to Active Directory.If you should choose to retain Windows 2000 compatibility for sake of your NT4 RAS servers then later upgrade those servers to Windows Server 2003, you can eliminate the null session vulnerability by removing the Anonymous Logon and Everyone groups from the Pre-Windows 2000 Compatible Access group.IMPORTANT:
You must restart every domain controller after you've made this change to stop Anonymous Logon from reading Active Directory.
