Understanding the Default Policy

Let's take a few minutes to look over the default policy that is set in Routing and Remote Access when you install. By default, both Windows Server 2003 and Windows 2000 RAS ship with a default RAS policy. You find this policy in the RRAS snap-in under the remote access server by selecting the Remote Access Policies object and looking in the details pane on the right, as shown in Figure 6.17.

Figure 6.17 Default RAS Policy Properties

2 Routing and Remote Access

-Idlxl

Ele ûctlan ïlew yelp

■5= BU I Ml 1 g

Routing aid P.; m rte Access ■[^Server Status 3--©ARES (local)

Natwork interferes H IP Routing Q Genera) ö Static Rout« ^ NA T/Basic Frewel

P.emrte Access Patdes

Name ] Order |

.^Oonneúticns tú HuuwíI Routing and Remote ... 1 ^CcnneOöcns to o the' access servers z

Et

f^ Remote Access Potties

O Remote Access Logghq 3>crts

Remote Access Clents (0)

As you can see, two policies are listed. The first is called Connections to Microsoft Routing and Remote Access Server. Double-click this policy and open the Settings dialog box, shown in Figure 6.18.

Figure 6.18 Default Remote Access Policy Properties

Figure 6.18 Default Remote Access Policy Properties

As you can see in Figure 6.18, one condition is shown in the policy conditions window. The policy shown says MS-RAS-Vendor matches ^311$. Lower in the figure you can see that it says that if a connection request matches the specified conditions, the RAS is to deny the remote access permission. What this all means is that if the version of the RADIUS client is ^311$, the connection will be denied. Any other RADIUS client not meeting that version number will not be subject to this policy and will therefore move on to the next policy shown in Figure 6.17.

The second policy shown in Figure 6.17 is Connections to other Access Servers. It is the first policy, however, that is the default RRAS policy for the server and therefore the one that you need to modify to match your organization's needs.

Warning_

Keep in mind that many people confuse the terms permission and policy and use them as if they were interchangeable. Permissions are set on a user account and are denied by default. The dial-in permission set on the user account overrides the permission option in the Properties dialog box except in the case of the native-mode administration model, where all user accounts are set to Control Access Through Remote Access Policy.

An essential part of planning for remote access involves making a decision as to the model for administering remote access permissions and connection settings that you will use. There are three basic models:

■ Access by policy in a Windows 2000 mixed or Windows Server 2003 interim domain

■ Access by policy in a Windows 2000 native or Windows Server 2003 domain

There's enough variation in these models that, should you attempt to mix them, you can pretty much count on confusing everyone, including yourself. No matter what, plan to fully test your access policies so that you know that you're getting the results you planned to get.

In the next two sections, we look at setting up policies on two levels: user and machine. Keep in mind that this discussion is superficial and seeks only to demonstrate some of the best practices involved in choosing your administration model.

User Policies

As we discussed earlier, there are three models for remote access policies: access by user, access by policy in a Windows 2000 mixed or Windows Server 2003 interim domain, and access by policy in a Windows 2000 native or Windows Server 2003 domain. Let's examine each of these briefly.

Looking first at the access by user administrative model, we notice that remote access permissions are determined by the remote access permissions in the Dial-In tab of the Properties dialog box for the user account, as shown in Figure 6.19.

Note_

Notice that the third option in Figure 6.19, Control Access through Remote Access Policy, is grayed out and not available to choose. You will see this condition when you deal with user accounts in Windows Server 2003 and Windows 2000 mixed domains.

To enable or disable an individual user's remote access permissions, all you need to do is set the Remote Access Permission to either Allow Access or Deny Access.This is probably the simplest of all three of the Administration models. It works fine when the number of users is small and the time of access is uncomplicated.

The setting here of either allow or deny effectively overrides any remote access permission setting on the remote access policy. As we said earlier, you could use multiple administration methods, but you're asking for trouble if you do. Connections must match the conditions of the policy, but if multiple policies or profile settings don't match, connection attempts could be rejected, as shown in Figure 6.20.

Figure 6.19 User Account Remote Access Permissions

Gena'cJ | Àddesî I Accouil ] PrcfJe ] Telsphores | Organization [ Member Oí Dial-h L^ | Environment | Sessions |

f Contrd access tfirauah Rerijta Accss* .Baity f* £et bjfCaltet(Rouiira and Remote Access Seivce wily)

Delire louhts lo ensbte ioi this Dalri - la;r -RpUjey j

Figure 6.20 Administering Access by User

In the access-by-user model, access is controlled in one of the following three ways:

■ Explicit Allow Here, the remote access permission for the user is set to Allow Access. No conflicts exist among a policy, the settings for the profile, or the dial-in properties for the user account.

■ Explicit Deny The remote access permission for the user is set to Deny Access. End of story.

■ Implicit Deny In this case, the connection attempt doesn't match the conditions set in any remote access policy.

Keep in mind that, in the access-by-user model, access is determined solely by the settings in the Properties dialog box for the individual user account. Take a look again at Figure 6.18 and notice that it is set to deny access. If the Allow Access is set in Figure 6.19, that deny setting doesn't mean anything. Again, in the access-by-user model, access is determined solely by the settings in the Properties dialog box for the individual user account.

In the administer-access-by-policy model in a Windows 2000 mixed or Windows Server 2003 interim domain, the remote access permissions on every user account are set to allow access. Here, the default remote access polices are deleted or demoted, and separate remote access policies are created for the various types of connections that will be allowed. In this model, access is controlled in one of the following three ways:

■ Explicit Allow In this case, the attempted connection matches all the conditions of the policy, subject to the profile settings and the user account dial-in properties.

■ Explicit Deny Here, the attempted connection matches the conditions of a policy but not the profile settings.

■ Implicit Deny The attempted connection doesn't match the conditions of any remote access policy.

Finally, in the administer-access-by-policy model in a Windows 2000 native or Windows Server 2003 domain, you have two alternatives for controlling access:

■ Set the remote access permissions on every user account to Control Access Through Remote Access Policy.

■ Determine your remote access permissions by the Remote Access Permission setting on the remote access policy.

In using either of these methods, you control access through:

■ Explicit Allow On the remote access policy, the remote access permission is set to Grant Remote Access Permission. The attempted connection matches the conditions of the policy, subject to the profile settings and the user account dial-in properties.

■ Explicit Deny On the remote access policy, the remote access permission is set to Deny Remote Access Permission. The attempted connection matches the conditions of the policy.

■ Implicit Deny The attempted connection doesn't match the conditions of any remote access policy.

Remember that if the access-by-policy administrative model for Windows Server 2003 or Windows 2000 native domain is being used and you're not using groups to specify which users get access, you need to make sure that the Guest account is disabled and the remote access permission for this account is set to deny access. Otherwise, the default permissions for the Guest account will allow access when it shouldn't be allowed.

Machine Policies

One of the first policies you will probably want to set up regards what servers in your network can actually run RAS.You can create a security policy that designates the servers that can actually run the Remote Access Service by first creating two new GPOs, as follows:

■ The first GPO you'll create should be named Disable RAS.This GPO will disable the RAS service. The policy will be assigned at the domain node so that it affects every computer in the domain.

■ The second GPO you'll create should be named Enable RAS.This GPO autostarts RAS and sets security on the service so that only the Administrators group (and local system) will have access to the service. This policy is assigned to the RAS server's OU, allowing it to override the Disable RAS GPO defined at the domain level.This means that only those computers in the RAS server's OU will be able to, and actually must, run RAS.

To create the RAS server OU, first load the Active Directory Users and Computers snap-in.

1. Click Start | Programs | Administrative Tools | Active Directory Users and Computers.

2. Right-click the domain name, choose New, and click Organizational Unit, as shown in Figure 6.21.

3. In the Name text box, type RAS Servers and then click the OK button, as shown in Figure 6.22.

Figure 6.21 Choose Organizational Units

Figure 6.21 Choose Organizational Units

Figure 6.22 Enter the Name of Your Organizational Unit

4. Close the Active Directory Users and Computers snap-in.

Next you need to create a new domain-level GPO to disable the RAS. To do this, you must first load the Group Policy snap-in.There are two ways you can accomplish this.The simplest method is to use the Active Directory User and Computer snap-in that you just closed, right-click the domain name, choose Properties, and then choose the Group Policy tab. Another way is to follow the these steps:

1. Click Start | Run. In the Open text box, type mmc /s.

2. On the Console menu, choose Add/Remove Snap-in, as shown in Figure 6.23.

Figure 6.23 Click Add/Remove Snap-in

Figure 6.23 Click Add/Remove Snap-in

3. Click Add, as shown in Figure 6.24.

Figure 6.24 Click Add

4. Choose Group Policy Object Editor from the list, and click Add, as shown in Figure 6.25.The Select Group Policy Object dialog box is displayed, as shown in Figure 6.26.

Remote Access and Address Management • Chapter 6 359 Figure 6.25 Add Group Policy Object Editor

Add Standalone Snap-in

Avalabte Standalone Snap-ins:

Snap-in

Vendor I

^Device Manager

Microscit Corporaticn

^ D isk D ¿fragmenter

Microscit Corp, ExecutL.

Disk Management

Microsoft and VER IT AS... .

¿jé Distributed File System

Microscit Corporation

«&DNS

Microscit Corporation

SÍI Ever* Viewer

Microscit Corporation

1 Foidet

Microsoft Corporation

F_JUioup Policy Object Editor

Microsoft Corporation

¡^Indexing Service

Microsoft Corporation, 1...

^Internet Authentication Service (IAS)

Microsoft Corporation

This snap-in allows you to edit Group Policy Objects which can be inked to a Site, Donari, or Organizational Unit in the Active Directoiy or stored on a computer.

add M

Close

Figure 6.26 The Select Group Policy Object Window

Figure 6.26 The Select Group Policy Object Window

5. Click the Browse button, as shown in Figure 6.26.The Browse for a Group Policy Object dialog box shown in Figure 6.27 will open. Note that the RAS Servers OU is listed as a possible location where you can link the GPO. The Disable RAS GPO, however, belongs with the domain.

6. Click the Create New GPO icon, as shown in Figure 6.27. Modify the default name of the new GPO. Name it Disable RAS, and click OK. Click Finish.

7. Click the Close button in the Add Standalone Snap-in dialog box.

8. Click OK to close the Add/Remove Snap-in dialog box.

Figure 6.27 The Browse for a Group Policy Object Window

Figure 6.27 The Browse for a Group Policy Object Window

9. In the scope pane of the console, expand Disable RAS, and navigate to Computer Configuration, to Windows Settings, and then to Security Settings.

10. Select System Services.

11. In the list of service names, double-click Routing and Remote Access, as shown in Figure 6.28.

Figure 6.28 Double-Click Routing and Remote Access le Ruuü.DñdljIe RAS l<.eiilduri.siil.drï]rït.eiiiQ.MjmmiU]ier

íd.m;lJPufe.if''i.Ci)iii|iuLertonfÍ!jijrd#.iuM'i.W¡inJuvJ,,, | »

"fi «s Actfcf s»" FavgrRes Wilde* Hsip 4= ■+ I £][B , fl ü| iff

~l Ccredf Reo: El I OCal CMpUer Pel Iff'

H ■TJ? DisatfeRAStcBrftauh.KiIfl-ïjnAeinO sumrfttnmniixfe.ret] B-iSfl Ccirçubei cerf cu'at en I Qj Srftnaiifi lilting? WTdmsSBtbnjf ¿J La ct' ;'-ts tuî.t(-u:dc»xi'i gp ícn.rity Suirinfp R -CT ¿toart Paicistí H Lxs P^iaas 0 ¿J FVcnl Lag R Ruilriulwí &uups - 19 Sfsterr Services

H -T VfcdBssNBbworfctlMt9CE.il) Pokes

□ rtfcfc teyPtlrfcs R LJ Software Restriction Pdifcb H jp Security Hd lass m fletr/e ttnertory (solí

: i Q flthJiístíflthe Templaüs E LS« Cef liflii ct'ùii

5srvkoNdnB

1 SUTJJO

f^rt-Bi on

-

Mot Defined

KotDef|-Kd

%NetKOlkDDIC5OT

Mot Defined

Kot Defined

^ItNetKoik Lo:absn A ftaraness (N.A;

Net llefned

KatUcî-^d

^S-Nl LT-1 .«Jt;.1 JXfxr. I-Hmdst

Met ^efned

hatUerj-rad

Loîb arc flJsls

Met íefned

Hot Defined

^jfrP'ug aiJl-tsy

Mot Defined

hot Defined

MsJa swialfcurbe-ienire

¡■Jot Defined

hot Defined

Spi^s-

Mot Defined

fat Defined

%P-ct9:ted;torag»

Mot Defined

fat Defined

^.Pairts Ancsss ftüto Ccrnscbm Mr\ajx

Mot Defined

fatDefinsd

^fe-Rwiwlw tvxi/ii Correction Matiíj*

Mentid

fatDeüwd

^fePjwiul'j DeaKtp rtsil 5ttaon Mi»!:'

Mtt Defiied

fatOefineJ

%Rjemote Procedura Cd 1 (RFC >

Nul Defined

faLDe'i ml

^Remote ^cieCore Cd 1 (SPC) locator

Met Defined

fatDefiml

^Remote Registry

Not Defined

fatDefiml

%Renws6te Storegs

NotDefned

KotDeH-PSd

%R.e¡sJ:¿r 1 Set of Pd»:>' PtovWer

NctDefned

%5Kordary loacn Hí

Not defned

r^r.t rdwi

^Sfc-ii-ty Arrmirís Hwrrr

Mot Drfned

KarnnFiwl

':¿L - '■■■■} r

tint Drfned

r^ntnerlviH

%5tiallH»diuiftir>eaa±ton

tit Dcfncd

Katncfhcd

%5riSít Cad

fût Defined

fat Defined

%îny al nantir Gonadshc^cr

tttDcfned

Hot Defined

■^Sj-ston Event

Defned

lïot Defined

^TaslíSd-cdifer

Me* Defned

Flat Derived

^TCPjlP NÄEDD3 He ter

tJc* Defined

fiat Derivad

-

12. Select the Define this policy setting check box, as shown in Figure 6.29.

Figure 6.29 Select Define This Policy Setting

Figure 6.29 Select Define This Policy Setting

13. Select the Disabled option, as shown in Figure 6.29, and click OK.

14. Close the Group Policy snap-in.

15. When prompted to save the console settings, click No.

The Disable RAS policy has now been established for the domain.You now need to create the Enable RAS policy, as discussed earlier.You can follow the same process we've discussed so far.

Was this article helpful?

0 0

Responses

  • luis feemster
    How to apply default group policy in domain server 2003?
    9 years ago
  • anna-liisa larnia
    How to create RRAS policy in Windows Server 2008?
    9 years ago

Post a comment