Choosing an Administrative Model for Remote Access Policies

[Previous] [Next]

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 on the Dial-In tab of the Properties window 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 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 31-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 window for the individual user account. Figure 31-6 shows the progression of a connection under the access-by-user administrative model.

click to view at full size.

Figure 31-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.

TIP
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 on 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.

TIP
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 on 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 31-7 shows the progression of a connection attempt when a remote user dials in and access is controlled by group membership.

Figure 31-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 will 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, on 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 31-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 31-8. Configuring the dial-in constraints to deny access to a group.

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

click to view at full size.

Figure 31-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 31-10 shows the progression of a connection attempt in a native-mode domain.

click to view at full size.

Figure 31-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.

NOTE
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.

TIP
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 on the Dial-In tab of the user account's Properties window. 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 31-11 shows the progression of a connection attempt with this policy setting.

Figure 31-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 on the Dial-In tab of the user account's Properties window. 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 31-12 shows the logical progression when a connection attempt is made with these settings in effect.

click to view at full size.

Figure 31-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 in the first case is to upgrade the Windows NT server to a domain controller or to Windows 2000. In the second situation, the best answer is to upgrade the Windows NT domain to Windows 2000.

However, you can 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 will add the special identity Everyone to the pre–Windows 2000 Compatible Access group so that the remote access server can use NTLM (NT LAN Manager) security to read the domain user accounts.



Microsoft Windows 2000 Server Administrator's Companion, Vol. 1
Microsoft Windows 2000 Server Administrators Companion (IT-Administrators Companion)
ISBN: 1572318198
EAN: 2147483647
Year: 2000
Pages: 366

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