Choosing an Administrative Model for Remote Access Policies

In Windows 2000, you can choose from among three models for administering remote access permissions and connection settings:

  • Access by user
  • Access by policy in a Windows 2000 mixed-mode domain
  • Access by policy in a Windows 2000 native-mode domain

An essential part of planning for remote access is determining which models you can use and deciding on an appropriate one. There is enough variation among the models that attempting to mix them is a recipe for confusion. No matter which model you choose, plan on thoroughly testing your chosen access policies to make sure that you're getting the results you intend.

Administering Access by User

In the access-by-user administrative model, remote access permissions are determined by the remote access permissions in the Dial-In tab of the Properties dialog box for the user account. To enable or disable remote access permission for individual users, set Remote Access Permission to either Allow Access or Deny Access, as in Windows NT Server. This administrative model is by far the simplest, and it works very well when the number of remote users is small and the access issue is uncomplicated.

If remote access permission for the user account is set to either Allow Access or Deny Access, the remote access permission setting on the remote access policy is effectively overridden. Access by user can be administered with multiple policies, but doing so can be complicated because a connection attempt might be rejected even when the remote access permission on the user account is set to Allow Access. If a connection attempt matches the conditions of a policy but does not match the profile settings or does not match any of the remote access policies, the connection attempt is rejected, as shown in Figure 32-6. In the access-by-user administrative model, you can control access in three ways:

  • Explicit allow The remote access permission for the user account is set to Allow Access, and the connection attempt doesn't conflict with a policy or the settings of the profile and the dial-in properties of the user account.
  • Explicit deny The remote access permission for the user account is set to Deny Access.
  • Implicit deny The connection attempt doesn't match the conditions set in any remote access policies.

The access-by-user administrative model can be used on a stand-alone remote access server, a remote access server on a Windows 2000 native-mode domain, a remote access server on a Windows 2000 mixed-mode domain, or a remote access server on a Windows NT 4 domain.

Granting Access by User

The access-by-user model resembles the administrative model of Windows NT 4. Individual user accounts are set to Allow Access or Deny Access. The default policy in Routing and Remote Access, Allow Access If Dial-In Permission Is Enabled, is in place with the following settings:

  • The single condition of day and time restrictions is set to allow access at all times on all days.
  • The profile is set to the default settings.
  • The Deny Remote Access Permission option is selected.

But wait! If Deny Remote Access Permission is selected, isn't remote access permission denied? No; it means basically nothing in this scenario. Access is determined solely by the settings in the Properties dialog box for the individual user account. Figure 32-6 shows the progression of a connection under the access-by-user administrative model.

Figure 32-6. Progression of a connection attempt when administering access by user.

Administering Access by Policy for a Mixed-Mode Domain

In the access-by-policy administrative model for a Windows 2000 mixed-mode domain, the remote access permission on every user account is set to Allow Access, the default remote access policy is deleted or demoted, and separate remote access policies are created to define the types of connections that are allowed. On a remote access server running Windows 2000 that is a member of a Windows 2000 mixed-mode domain, the Control Access Through Remote Access Policy option is not available for remote access permission on the user account. If a connection attempt corresponds to the conditions of a policy (subject to the profile and user account dial-in settings), the connection is accepted.

The access-by-policy administrative model also applies to a remote access server running Windows 2000 that is a member of a Windows NT 4 domain.

In the access-by-policy administrative model for a Windows 2000 mixed-mode domain, you can control access in three ways:

  • Explicit allow The connection attempt matches the conditions of a policy, subject to the settings of the profile and the dial-in properties of the user account.
  • Explicit deny The connection attempt matches the conditions of a policy but not the settings of the profile. You can do an explicit deny in this model by editing the profile and enabling the Restrict Dial-In To This Number Only option in the Dial-In Constraints tab and typing a number that does not correspond to any dial-in number being used by the remote access server.
  • Implicit deny The connection attempt does not match the conditions of any remote access policies.

If you do not delete the default remote access policy, Allow Access If Dial-In Permission Is Enabled, all users can obtain a remote access connection.

The access-by-policy administrative model for mixed-mode domains can be used with Windows NT servers running Routing and Remote Access if the Windows NT servers are configured as RADIUS clients to a Windows 2000 Internet Authentication Service (IAS) server. A Windows NT server running RAS cannot use access by policy. You must upgrade the server to Windows NT RRAS (or to Windows 2000) to employ the remote access policy authorization.

Granting or Denying Access by Group Membership

To allow connections for users by group membership, all user accounts must have Remote Access Permission in the Dial-In tab set to Allow Access. To set up the access by groups, the administrator makes the following settings:

  • In Routing and Remote Access, delete the default policy, Allow Access If Dial-In Permission Is Enabled.
  • Create a new policy named Accept If Member Of Selected Groups.
  • Add the Windows-Groups attribute to the policy.
  • Select the group or groups to be granted access.
  • On the policy, select the Grant Remote Access Permission option.

In this case, the Grant Remote Access Permission option means what it says. Figure 32-7 shows the progression of a connection attempt when a remote user dials in and access is controlled by group membership.

Figure 32-7. Progression of a connection attempt when administering access by group membership.

Perhaps it would be easier in your situation to specify who isn't allowed access than to specify who is. For example, employees in production might have user accounts on the network but have no need for dial-in access. In this case, you need to make the following settings:

  • Leave the default policy, Allow Access If Dial-In Permission Is Enabled, in place.
  • Create a new policy named Reject Production Group.
  • Add the Windows-Groups attribute to the policy.
  • Select the Production group.
  • On the policy, select the Deny Remote Access Permission option.
  • Click Edit Profile and, in the Dial-In Constraints tab, select Restrict Dial-In To This Number Only and type in a number that is not a dial-in number of the remote access server, as shown in Figure 32-8.
  • In the details pane of the Routing and Remote Access snap-in, right-click the new policy and select Move Up so that it is the first to be evaluated.

Figure 32-8. Configuring the dial-in constraints to deny access to a group.

Figure 32-9 shows the logic of the connection attempt when access is denied by group membership.

Figure 32-9. Progression of a connection attempt when the policy is to deny access by group membership.

Administering Access by Policy for a Native-Mode Domain

In a Windows 2000 native-mode domain, you can use the access-by-policy administrative model, which has the following settings:

  • The remote access permission on every user account is set to Control Access Through Remote Access Policy.
  • Remote access permissions are determined by the remote access permission setting on the remote access policy.

These settings mean that the Remote Access Permission setting on the remote access policy determines whether remote access permission is allowed or denied. Figure 32-10 shows the progression of a connection attempt in a native-mode domain.

Figure 32-10. Progression of a connection attempt when administering access by policy in a native-mode domain.

In the access-by-policy administrative model for a Windows 2000 native-mode domain, you can control access in three ways:

  • Explicit allow The remote access permission on the remote access policy is set to Grant Remote Access Permission, and the connection attempt matches the conditions of the policy, subject to the settings of the profile and the dial-in properties of the user account.
  • Explicit deny The remote access permission on the remote access policy is set to Deny Remote Access Permission, and the connection attempt matches the conditions of the policy.
  • Implicit deny The connection attempt does not match the conditions of any remote access policies.

If you use the access-by-policy administrative model for a native-mode domain, don't add remote access policies, and don't change the default remote access policy (Allow Access If Dial-In Permission Is Enabled), then no users are allowed remote access. By default, the remote access permission on the default remote access policy is set to Deny Remote Access Permission. If you change the setting to Grant Remote Access Permission, all users are allowed remote access.

The access-by-policy administrative model for a Windows 2000 native-mode domain also applies to stand-alone remote access servers that are not members of a domain. You can't use the access-by-policy administrative model for a Windows 2000 native-mode domain if you have Windows NT 4 RAS or RRAS or IAS servers because a native-mode domain by definition has no Windows NT servers.

If you use the access-by-policy administrative model for a Windows 2000 native-mode domain and you do not use groups to specify which users get access, verify that the Guest account is disabled and that its remote access permission is set to Deny Access.

Granting or Denying Access by Group Membership

In a native-mode domain, setting access by policy requires that all user accounts have the Control Access Through Remote Access Policy option selected in the Dial-In tab of the user account's Properties dialog box. To allow access by specified groups, the administrator must do the following:

  • Delete the default policy, Allow Access If Dial-In Permission Is Enabled.
  • Create a new policy called Accept If Member Of Selected Groups.
  • Add the Windows-Groups attribute to the policy.
  • Select the group or groups to be granted access.
  • On the policy, select the Grant Remote Access Permission option.

Figure 32-11 shows the progression of a connection attempt with this policy setting.

Figure 32-11. Progression of a connection attempt when the policy is to allow access by group membership in a native-mode domain.

In a native-mode domain, you can easily reverse the criteria just described and deny access based on group membership. This policy also requires that all user accounts have the Control Access Through Remote Access Policy option selected in the Dial-In tab of the user account's Properties dialog box. As in the mixed-mode domain, two policies are needed: one to reject members of a specified group and another to allow a connection made by anyone else. Follow this procedure to deny access based on group membership:

  • Leave in place the default policy, Allow Access If Dial-In Permission Is Enabled. Select the Grant Remote Access Permission option on the default policy.
  • Create a new policy named Deny Configured Group.
  • Add the Windows-Groups attribute to the policy.
  • Add the groups that are to be denied remote access.
  • On the new policy, select the Deny Remote Access Permission option.
  • In the details pane of Remote Access Policies, right-click the new policy and select Move Up so that it is the first to be evaluated.

Figure 32-12 shows the logical progression when a connection attempt is made with these settings in effect.

Figure 32-12. Progression of a connection attempt when access is controlled by groups in a native-mode domain.

Real World

Windows NT 4 Remote Access in a Windows 2000 Domain

In a Windows 2000 domain, a server running Windows NT 4 and either RAS or RRAS can't authenticate the credentials of domain accounts unless it (the Windows NT server) is also a domain controller. A Windows NT server that is not a domain controller does not have permission to read Active Directory and therefore can validate only local accounts. This same restriction applies when you have a remote access server (running Windows NT or Windows 2000) in a Windows NT domain that needs to validate user accounts in a trusted Windows 2000 domain.

The recommended solution is to upgrade the Windows NT 4 server to Windows 2000. This provides the best functionality and maintains an acceptable level of security.

However, if security is of less importance, you can upgrade the Windows NT server to a domain controller (which exposes the SAM to external attack) or loosen the normal Active Directory security so that the remote access server can read the user account properties. Open a command prompt window on a domain controller and type:

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

This adds the special identity Everyone to the Pre-Windows 2000 Compatible Access group so that the remote access server can use NT LAN Manager security to read the domain user accounts. Once again, be aware that doing this substantially weakens the security of your network. Upgrading any RRAS servers to Windows 2000 is a far superior solution.



Microsoft Windows 2000 Server Administrator's Companion
Microsoft Windows 2000 Server Administrators Companion
ISBN: 0735617856
EAN: 2147483647
Year: 2003
Pages: 320

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net