Windows 2000 – Page 2 – 2000Trainers.com

Internet Authentication Service (IAS)

Windows 2000 implements a powerful centralized authentication, authorizations and accounting service (often referred to as AAA) in the form of IAS, its implementation of the Remote Access Dial-in Authentication Service (RADIUS). Used for both dial-in and VPN connections, IAS allows you to control in a more centralized manner the authentication of users, accounting of their connection start and stop times, as well as a way to centralize the application of remote access policies (authorization).

Not installed by default, IAS must be added via Add/Remove programs in Control Panel. Once installed, IAS is accessed using the associated Internet Authentication Services administrative tool.

Many people get confused about the purpose and configuration of IAS, so lets consider the basics. First of all, a big reason for using IAS is to centralize the authentication requests sent to remote access servers. For example, consider an environment that consists of a variety of remote access solutions (these are sometimes referred to as a NAS, or Network Access Server), such as Windows NT RAS, Windows 2000 RRAS, Cisco routers, various VPN and dial-in hardware solutions, and so forth. Maintaining accounts on those various platforms could be difficult, if not impossible. What RADIUS allows you to do is have all requests from the various remote access servers forwarded to the RADIUS server for authentication instead. As such, it is important to remember that a RADIUS client is actually a remote access server. The remote access server has client connections as well, but these are not RADIUS clients. I repeat, a RADIUS client is a remote access server. The remote access server does not authenticate client requests when RADIUS is used; instead it forwards them to the RADIUS server for processing.

This centralization provides a number of other benefits as well, including the ability to centralize the distribution of remote access policies. Remember that by default, remote access policies are local to the server on which they are created. In instances where you choose to set up a remote access server as a RADIUS client, all remote access policies on the server are ignored in favor of those configured on the RADIUS server. This presents a powerful way to control the application of remote access policy settings, especially in large distributed environments.

The actual configuration of IAS is quite simple, but there are a few things that you will need to be aware of. For starters, if you want a remote access server to act as a RADIUS client, it must be capable of authenticating to RADIUS. Most vendors add this functionality to their remote access servers, since RADIUS is an industry standard. Windows 2000 RRAS can act as a RADIUS client if correctly configured both in the RRAS settings and IAS setting. In RRAS, the setting are configured from the Security tab in the properties of the RRAS server.

By default, an RRAS-based server will authenticate to the Windows provide, either Active Directory or the local SAM database, depending on your setup. If RADIUS is chosen, further configuration is required, including the address of the server and a shared secret, which will be used between the RADIUS client and server for authentication purposes.

Simply configuring the RADIUS client is not enough. The settings for the RADIUS server must be configured via IAS.

Note the three sections that exist – Clients, Remote Access Logging, and Remote Access Policies. The Clients sections will allow you to add remote access server addresses and the corresponding shared secret that you originally set up. You will need to do this for each and every remote access server that you wish to act as a RADIUS client. The remote access logging pages allows you to configure what type information you wish log (and the associated format). Note that by default, nothing is logged, but recommendations are provided.

The last section allows you to configure the centralized remote access policies that I discussed earlier. These policies are configured and work in exactly the same manner as explained in the earlier remote access article.

You should understand that if you want IAS to be able to access a user’s dial-in properties in Active Directory, you must configure it to do so. This is accomplished choosing ‘Register Service in Active Directory’ from the Action menu of the snap-in (if the server is not a member of an AD domain, this option will be grayed out). Note that IAS will authenticate users against Active Directory or the local SAM database, as applicable. Note also that if you want redundant IAS servers, you should configure them similarly, being sure to copy the remote access policies to the second server, while configuring the RADIUS clients appropriately to account for the second server as well.

Network Address Translation (NAT)

Windows 2000 Server also includes another solution similar to ICS but more robust, in the form of the Network Address Translation protocol in Routing and Remote Access. While it basically consists of the same functional elements as ICS (and works in a very similar manner), NAT has some additional features that may make it a better fit than ICS in some environments.

The idea behind NAT is pretty straightforward. The system requires at least one external public IP address, from which all requests for external resources by clients on the internal network are made. This single IP address appears to be the one originating all requests to other servers on the Internet. In reality, the NAT server is making the requests for internal clients and keeping track of things by holding a table in memory that maps the internal request to an external request. The NAT server maps the port number that the external request was made on to the internal system that made the request (both the internal IP and port number used by the internal client). When the NAT server receives the appropriate response to its request, it looks at the table, sees which port number the reply is coming in on, and forwards the reply to the correct internal client. This setup allows many many computers to easily access the Internet off of only a single external IP address.

Obviously you will need to configure your Windows 2000 Server’s Routing and Remote Access tool to support NAT. This is accomplished by choosing to add a new routing protocol from within the tool.

Once added, NAT is configured by accessing its properties. One of the main benefits of NAT is that you can choose whether or not you wish for the services to act as a DHCP server for internal clients. This would allow you to continue using an already established DHCP server to hand out addresses, or use the functionality of NAT to do so. It will also allow NAT to be used as a standard address translation service, perhaps translating between internal public and external public ranges if such an addressing scheme is already in use, or simply to connect two different networks together while gradually moving towards an entirely new addressing scheme. For example, if two companies merged, they might be using incompatible ranges of addresses, with immediate connectivity being a priority. The screenshot below outlines the DHCP functionality that can be configured if required, including exclusions if necessary. Note that by default the private 192.168.0.0 range will be used, unless otherwise specified.

NAT would allow this as an interim solution prior to the reconfiguration of the entire network. Another feature within NAT is the ability to continue to handles DNS resolution requests if required via a DNS proxy function (where the internal clients again forward DNS resolution requests to the NAT server). Note that this ability is turned off by default (as is the address assignment function), but can be configured as required, even for demand-dial connections.

Much like ICS, NAT can also be configured to allow external requests to a certain port to be mapped to an internal server, such that a web server or otherwise could be hosted behind the NAT server, on the internal network.

Internet Connection Sharing

A service first provided by Microsoft in its Windows 98 operating system, Internet Connection sharing is meant to allow a single Internet connection to be shared amongst multiple computers on a small network with minimal configuration. In Windows 2000, ICS is implemented via the actual sharing of a network interface, which has a ‘real’ IP address, either via a dial-up or fixed network connection. It is important to remember that ICS (which is available in both Windows 2000 Professional and Server) is mainly meant as a solution for small and home offices, and not larger enterprise environments.

How ICS actually works is quite simple. The machine on which ICS is configured is actually acting as a Network Address Translation (NAT) server. In a nutshell, Network Address Translation is usually used to translate between two connected ranges of IP addresses, usually one that is using a public IP address, and the other which is using a private address range. The ‘external’ interface has a real IP address, and the internal interface is given the private address 192.168.0.1. The system also acts as a sort of mini DHCP server, handing out IP addresses in the 192.168.0.0/24 range to clients on the internal network. To that end, clients use the addresses received, pointing to the 192.168.0.1 interface as their default gateway. The ICS system also does a DNS proxy function, meaning that all client hostname resolution requests will be forwarded to the ICS system for resolution via the configured external DNS parameters.

The actual configuration of ICS couldn’t possibly be simpler. The key is to remember that you will require at least two interfaces on the ICS box. This might be accomplished using two network cards, or perhaps a network card and a dial-up connection such as one made via an ISDN adapter or analog modem. Remember the connection that you wish to ‘share’ is the one that will have the external IP address. If this is your modem, go into the properties of the connection object that you have created to connect to your ISP and share it as I have outlined below. If it were a second network card, you would access the Sharing tab of the appropriate Local Area Connection, and configure that instead.

Note the properties in the screen above. Enabling ICS is as simple as checking a checkbox, but you also have to decide whether or not you wish to enable on-demand dialing, which basically would enable the connection should a client on the external network make a request to an Internet-based resource. What you choose here would depend on the level of control that you wish to have over the Internet connection.

By default, ICS is configured such that all requests made to the external interface for resources inside your network are denied by default. This helps to protect your network from outside users. However, in many cases companies might be hosting FTP or Website internally, which they wish the outside world to be able to access. For these cases, you can configure options in the Settings area.

These setting can include standard services such as those shown above (FTP, SMTP, etc), or can include custom applications that you can define on the applications tab. Note that these will allow you to specify an external port that will ‘listen’ for requests on the external interface, and then forward them to the appropriate internal address that you specify.

Possibly the single most important thing to remember when running ICS is that all other internal DHCP servers must be removed, since ICS will be handling the DHCP server functionality on the network. Having other DHCP servers present may lead to conflicts.

Multicast Routing with Windows

Windows 2000 Routing and Remote Access also has the ability to act as a multicast router, using the IGMP router and proxy protocol (it supports IGMP version 2, which is backwards compatible with version 1). For those not familiar with multicasts, this is a type of transmission that is sent to a class D address. Multiple hosts listen in on a given class D address, and all hosts that are part of this group receive the transmission. Note that IGMP is not actually a data transmission protocol, but rather the protocol that keeps track of multicast group membership. The beauty of multicasting is that the transmission is sent only once by the sender, and can be received by many many hosts. The key in any multicast implementation is that the routers used should support the ability for hosts to register and unregister as part of the multicast group – this controls where multicasts go, which also ensures that the multicast only goes to network where it is required. Note that in cases where routers do not support multicasts, it is possible to set up IP-to-IP tunnels, while allow multicast traffic to be forwarded between two multicast-enabled routers, even if intermediary routers do not support this type of routing functionality.

Multicast registration is actually a simple idea. When a host on a given subnet wants to receive a multicast, it contacts its local router and asks it to forward traffic for the particular class D address onto this subnet. The router then contacts its upstream router, asking it to send the multicast, and so on and so forth. As other hosts on the original subnet ask to receive the multicast the router simply adds them to the multicast group, a list of who needs the multicast. Understand that this does not mean that the multicast will be sent onto the subnet multiple times. Instead, it will be forwarded once, and all hosts who are participating will grab the transmission. The router keeps track of who wants the multicast with periodic polling, and will cease forwarding it once nobody wants it. The portion of the Internet that supports multicasting is referred to as the MBONE.

While Windows 2000 can act as a simple multicast router as mentioned earlier, it is actually not full-featured because it doesn’t actually use a proper multicast routing protocol (such as DVMRP). Instead, it does something interesting. On the client side of the router, it acts as a multicast router, handling registration requests. However, on the Internet side of the connection is acts as just another multicast client, registering with its upstream router. The leads to the two ‘modes’ in which the interfaces on the system must be configured – Router mode and Proxy mode. For the sake of clarity, just remember that the Internet interface (or side) should always be configured in Proxy mode, while the private network interface should always be configured in Router mode.

In order to configure Windows 2000 as a multicast router, first add IGMP under routing protocols in Routing and Remote Access. Once added, you next need to add interfaces, which is done by right clicking on IGMP and choosing New Interface. In adding the new interfaces, you must choose whether they will be configured in either Router mode or Proxy mode.

Be sure that the interfaces have been configured in the correct manner, or the multicast routing will not function correctly. After both (or more) interfaces have been configured, Windows 2000 will function as a multicast router. Remember from previous articles that Windows 2000 can also be configured with Multicast scopes for automatic multicast address allocation (via MADCAP in DHCP).

Demand-Dial Routing with Windows

While the use of Windows 2000 as a traditional LAN or WAN router is debatable (based on the speed and popularity of hardware-based solutions), for smaller or branch offices the use of Windows 2000 as a demand-dial router can be both cost-effective and deliver decent performance. To configure Windows 2000 as a demand-dial router, you will of course need at least one dial interface, such as a modem or ISDN adapter.

When creating demand-dial connections, you have the ability to make them either one-way or two-way. In a one-way setup, only one system is allowed to dial the other. In a two-way setup, either system can initiate the connection. Before you can create a new demand dial interface, you must first ensure that the server is configured to allow demand-dial routing (configured in the properties of the server).

Right clicking on Routing Interfaces in Routing and Remote Access gives you the ability to create new demand-dial interfaces, which are configured via a wizard. Note that the naming of the connection is extremely important, since the user account that must later be created must match the name of the connection.

After choosing the device that you will use to connect, providing the phone number to be dialed and so forth, you will be presented with the screen below, which allows you to control which protocols will be routed, automate the creation of a user account, and so forth.

The next screen allows you to configure dial-out account properties for the connection. These will be used by the router when it initiates a connection, and an account much be configured on the receiving computer in order for this to function correctly. Don’t forget that the user account that you create on each remote router must match exactly the name of the demand-dial connection. Note also that the account you create must have permission to dial-in, and is susceptible to any remote access policies that you might have created.

A few remaining things that you should be aware of when using demand-dial routing:

Demand dial filtering (by port number) allows you to control which types of traffic will initiate the connection. For example, you might only allow HTTP traffic to initiate dial-up, while ignoring other traffic.
A demand-dial router should be configured with static routes, using a routing protocol (such as RIP) would cause the connection to be repeatedly initiated because of routing table updates. Another option, called auto-static mode, allows you to configure the router such that static routes are automatically added to the routing table at pre-defined intervals.
Note that you can also add static routes to the routing table upon connection by adding a static route to the dial-in properties of the user account that will be used for the connection.
To troubleshoot demand-dial connections, use the Rasmon.exe utility.

OSPF Routing with Windows

The OSPF routing protocol is the only other traditional routing protocol included with Windows 2000 outside of RIP versions 1 and 2. Traditionally RIP is used in small networks because it is easy to configure. However, certain scalability issues with RIP (such as the limitation that it only allows up to 15 hops) tend to make it a poor choice for larger networks. Whereas RIP is a distance-vector protocol, OSPF is a link-state protocol, meaning that each router has a database of the network routing topology. While this leads to more effective routing decision-making, it also increased the complexity of setting up an OSPF-based topology. Note that both RIP and OSPF can be run on routers at the same time.

In order to better understand how OSPF works, you need to be familiar with some key concepts. These include the idea of an Autonomous System (AS), areas, backbone areas, and the different types of OSPF routers (these differ in their responsibilities and how they function). The section below outlines these key concepts.

Autonomous System – an AS basically refers to a collection of areas that fall under the same administrative control, and has a backbone area between which different areas communicate directly.

Area – An OSPF area is a portion of an AS that includes contiguous subnet ranges. One of the main purposes of an OSPF area is route aggregation, which allows routing within an area to be confined to that area and not travel over the backbone. This is also sometimes referred to as route summarization, where routers within an area know only about their area, and a default route to the backbone. This makes OSPF a more efficient routing protocol, since every router does not need to necessarily know the details of other network available. As a general rule, follow the idea that an OSPF area should be comprised of the same systems that make up an Active Directory site. Areas are usually numbed in the format 0.0.0.x, where x usually designates a subnet range (although this is convention, not any requirement).

Backbone Area – the backbone area is the (usually) high-speed area into which all other OSPF areas are connected (these other areas are generally referred to as stub areas. Any traffic moving between different areas should communicate via the backbone area. The backbone area is always designated as area 0.0.0.0 in an OSPF implementation.

Stub Areas – A stub area is an area connected to the backbone area by an Area Boundary Router (ABR). When designing an OSPF-based topology, you should try to connect all stub areas to the backbone instead of connecting them to other stub areas. In a stub area, you can set up a single static route for all traffic destined outside of the area.

Area Border Router – any router in an OSPF system that borders and interconnects two or more areas (such as the backbone and a stub area) is considered an Area Border Router. Each ASB will carry an individual link state database for each area with which it is interconnected.

Autonomous System Boundary Router (ASBR) – a router than interconnects different Autonomous Systems in an OSPF topology.

Backbone Router – Any router that interconnects to the backbone area, including ABRs with a backbone connection.

Internal Router – any router that has all interfaces connected within the same area. These routers only carry a single link state database, containing information about the area in which it exists.

Virtual Link – A logical link between the backbone area and an ABR when a physical link between them does not exist. It is usually recommended that you avoid using virtual links where possible, since they can sometimes cause routing problems that can be difficult to troubleshoot.

While I could dedicate an entire article to OSPF and all of its workings, I’ll spare you the majority of the details. The key things to understand are that an OSPF-enabled router speaks to the other routers in its own area directly, exchanging routing information. This ensures that every router within the area has the same link state database as every other router in the area, and changes are flooded within the area as they occur. If a network has been properly designed into a hierarchical VLSM (variable length subnet mask) scheme, routing will be much more efficient and effective, since OSPF usually exchanges less traffic than RIP. Note that OSPF and RIP version 2 both pass subnet mask information in their routing table updates, while RIP version 1 does not. For companies that use VLSM, this is a critical consideration in choosing a routing protocol.

In order to configure a Windows 2000 Server to act as an OSPF router, you need to add the OSPF protocol.

Once OSPF has been added, you will need to configure an interface to use OSPF. As such, it is possible to have one or more interfaces use OSPF, while another (like a dial-up interface) might not. After an interface is added, you will be presented with the OSPF properties page.

Note that by default, an OSPF interface will be made part of the backbone area. The General tab allows you to configure the network type as well as router priority, cost, and an authentication password. The NBMA Neighbors tab allows you to configure the IP addresses of other OSPF routers on non-broadcast networks (such as Frame Relay, for example). Finally, the Advanced tab allows you to configure OSPF properties such as the Hello interval (how often an OSPF router announces its existence on the network), MTU size and so forth.

Note also that by right clicking on the OSPF heading under IP routing you can easily view neighboring routers, the link state database(s) of the system, and more.

RIP Routing with Windows

Since static routing can become cumbersome in very large internetworks, companies will usually choose to have routing tables built dynamically by a routing protocol. It is via routing protocols that routers ‘talk’ to one another, exchanging information about the networks that they are aware of. Although a wide variety of routing protocols exist, Windows 2000 supports only three, RIP versions 1 and 2, as well as OSPF. In order for routers to exchange information with one another, they must be running a common routing protocol. By far the simplest routing protocol to implement is RIP, the Routing Information Protocol. RIP’s simplicity comes from the fact that it requires very little in terms of configuration outside of simply ‘turning it on’. In an internetwork that uses RIP, routers broadcast their routing tables to their neighbors at configurable intervals. The downside of this is that it has a negative impact on network performance, and changes in the network topology (such as a router going down) can take a long time to propagate through a network, thus compounding network communication problems.

As mentioned earlier, Windows 2000 supports both RIP versions 1 and 2. RIP version 1 is often considered a poor choice in larger environments, mainly because it only supports classful IP addressing, which in part means that subnet mask information is not propagated as part of the RIP v1 broadcasts. This also means that RIP version 1 is not suitable for networks that use either CIDR (classless interdomain routing) or VLSM (variable-length subnet masks). Another downfall of RIP v1 is the fact the security is very limited, since neighboring routers do not authenticate with one another. This would might allow any RIP router to exchange information with neighboring RIP routers, regardless of whether they should be.

On the other hand, RIP version 2 does support VLSM, CIDR, and basic authentication (a string value that must be the same on routers participating in the exchange, via clear text). RIP v2 routers also support the exchange of information via broadcast or multicast, which can be configured. Note that a router running only RIP v1 cannot exchange information with a router running only RIP v2.

RIP is added via the ‘New Routing Protocol’ menu choice off the General tab in the IP Routing section of Routing and Remote Access.

Note that you first add a routing protocol, and then configure that protocol on an interface-by-interface basis. Note also that even though the screen above suggests that only RIP version 2 can be added, this option also allows you to configure interfaces using RIP 1 if desired.

By accessing the properties of RIP via the shortcut menu, you are actually configuring what are sometimes referred to as global parameters. The options here are limited, since an interface hasn’t actually been added yet, as will be discussed in a moment. The general tab controls how long a router will wait before sending a triggered update (meaning that its table has been updated), as well as RIP logging options. The Security tab is actually a little more important, since it allows you to control exactly which RIP routers this router is allowed to interact with. While the router will be able to accept announcements from all other RIP routers (running the same version) by default, you can also specify which routers it can or cannot accept announcements from explicitly by IP address.

Pages: 12

Static Routing with Windows

The most basic routing setup involves configuring a router to use static routing. In this scenario, you tell the router about networks explicitly, including information on the next-hop address (where packets destined for that network should then be sent – the destination host or another router). Note that a router will know about all networks or subnets on which in has a configured interface – as such, you need not usually add these to the routing table using static routes. For any network to which the router does not have directly connected interface, you much configure the information as described. Note that adding many static routes is time consuming, and as such most situations will dictate that a routing protocol be used. However, static routes provide a very quick, simple, and efficient method for setting up routing, especially in small environments.

In Windows 2000 Routing and Remote Access, static routing is configured under the IP Routing section.

When configuring a static route, you need to provide the network address of the interface, destination network, the subnet mask, gateway (or next hop address), as well as a metric. If the static route will be used to initiate a demand-dial connection (to be discussed later in the article), you can also check the box at the bottom of the screen.

Note that the routing table for the system can be viewed either by using the ‘Show IP Routing tab option shown above, or by using the route print command from the command prompt. Note that the default destination network, 0.0.0.0 is used to route packets to networks not found in the table, usually to the configured default gateway.

Routing With Windows

Those familiar with Windows NT 4.0 will remember that by adding more that one network card to a system and enabling IP forwarding, you could use Windows NT as a router. Though the functionality was limited to acting as a static router or one which could only exchange information with other routers using RIP version 1, the ability to have NT act as a router was often used where a hardware-based solution (such as a Cisco router or similar) was impractical or too expensive. Windows 2000 builds on this functionality, with the Routing and Remote Access service (RRAS) providing the ability to integrate with other routers using a variety of popular routing protocols including RIP versions 1 and 2, as well as OSPF. Further to this, RRAS will also allow your server to act as a demand-dial router, initiating dial-up connections (as well as VPN connections) via ISDN and standard phone lines. This demand-dial functionality provides what could potentially be a very cost-effective solution in offices where Internet or related dial-up costs (such as WAN connection) are prohibitively expensive.

Before having a discussion about configuring a router, I think it is first important to understand what a router actually does, especially besides the obvious (routing packets). For the sake of simplicity, lets consider a 2-subnet internet. In order for hosts on one subnet (who have a given address range) to talk to computers on another subnet, they must communicate using a router as an intermediary. Sometimes referred to as a gateway, the router has a connection on both networks, usually with separate network interface cards, one on each subnet. When a host on one subnet needs to talk to a host on another, it forwards the frame it has created to the local router interface. Upon receiving the frame, the router does a number of things. First, it strips off the associated frame addressing (for example the Ethernet MAC addresses), and then looks at the destination IP address. Though the router (usually) won’t know about the whereabouts of a specific host, it will know about the networks to whom it is attached at a minimum, as well as any it has learned about via routing protocols. If the router has the destination network in its routing table, it will note the IP address to where the datagram should be sent next, either the destination host itself, or another router (if applicable). After decrementing the TTL of the datagram by 1 (as happens at every router), the router them frames the datagram for the underlying network technology, including the appropriate MAC addressing, and forwards the frame to that host.

Whenever you talk about routers you should be sure to distinguish between routing protocols and routed protocols. Quite simply, a routed protocol is one whose traffic has an addressing scheme that allows it to be routed, such as IP or IPX. On the other hand, a routing protocol is one that routers use to exchange information with one another, such as RIP or OSPF.

Remote Access Policies

Perhaps the biggest single new feature in Windows 2000 RRAS is the ability to control access in a more granular fashion using Remote Access policies. Unlike group policy settings that are stored in Active Directory, RAS policies are stored on the RAS server on which they are created. Essentially, RAS policies allow you to control who can (or can’t) connect to the server (using groups), the properties of the connection (which can be different for different users), how long they can connect for, the protocols they must use, and so forth. Furthermore, there can be multiple policies per server, such that completely different policies apply to different groups of users. It is important to understand how these policies work, the elements involved, and why you would configure settings in a certain way.

Remote Access Policies are found in the section with the same name in the RRAS tool, as shown below. Note that by default a single policy, called ‘Allow access if dial-in permission is enabled’ exists by default.

This is important to note. If no policies exist in this list, then ALL remote access connection attempts to this RAS server will be denied. The default policy is very simple. Basically, it allows you remote access if your user account settings are set to ‘Allow access’, while all other connection attempts are denied. This very basic policy effectively emulates the way remote access settings worked in Windows NT 4.0 – either you are allowed access, or you’re not.

Windows 2000 Remote Access Policies are really made up of three distinct parts, and each must be considered when designing these policies. The three parts to RAS policy are the evaluation of:

1. Policy Conditions
2. Permissions
3. Profile

This part can be a little confusing, so stay with me. Basically, the first thing that gets evaluated is the policy conditions, which you must meet in order for a policy to apply to you. As an example, I might make it such that a policy I create applies to the group called ‘Sales’. If this were the only policy that existed, and you were not part of Sales, then you would not be able to connect to this RAS server. Policy conditions are the basic parameters that must be met in order to be allowed to make a connection to the server. Double-clicking on a policy will show you the conditions of that policy, and whether meeting those conditions allow or deny you access.

Example of settings that can be used as conditions include Windows group membership, days and times, the phone number dialed by the user, and so forth.

The most important thing to remember is that the conditions of a policy are looked at according to their order in the list of policies. That means that if you don’t meet the conditions of the first policy, then the second policy is looked at, then the third, and so forth. However, as soon as you meet the conditions of a policy, that is the last policy evaluated. So, if 13 policies exist, and you meet the conditions of the 2nd, the remaining policies will not be evaluated, even if they were to give you a higher level of access. Remember that if you do not meet the conditions of any policy, then you are automatically denied access.

Permissions are evaluated once you meet the conditions of a policy. Permissions are the settings with respect to dial-in configured on your user account. Three settings exist: Allow Access, Deny Access, and Control Access through Remote Access Policy. If your account permissions are set to Allow Access, then the Profile settings are applied (as will be discussed in a moment). If your account permissions are set to Deny Access, then you are automatically denied access. If your account is set to Control Access through Remote Access Policy, then whether or not you are allowed to connect is controlled via whether you meet the conditions and profile settings. By default, if your domain is in mixed mode, all users are set to deny access. Once the domain is switched to native mode, all accounts are switched to Control Access through Remote Access Policy. This last setting offers the most flexibility, since multiple users could be granted access at once simply by setting up a policy that gives access to all users in the Sales group, which is obviously easier than setting the properties on many accounts individually

If your permissions allow you access, the final level of evaluation involves the application of profile settings. Profile settings are controlled via the ‘Edit Profile’ button in the properties of a policy. Quite simply, they constitute the settings you are given if you meet the conditions and have the permission use remote access. For example, you might be given a 2-hour connection time, be disconnected if idle for 30 minutes, and be required to use strong encryption. If for any reason you are not able to meet the requirements outlined in the profile, you are also denied access. While you should take the time to go through profile settings yourself (there are too many to describe here), you should be aware that they are categorized according to Dial-in Constraints, IP settings, Multilink properties, Authentication settings, Encryption settings, and Advanced settings (which can vary based on the dial-in equipment).

As you can see, controlling remote access in Windows 2000 is a much more granular task than in Windows NT. However, it is also provides for different levels of access for different groups of users, which makes it much more flexible.