Introduction (Deploying Windows Server 2003 Internet Authentication Service (IAS) with Virtual Local Area Networks (VLANs))

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

By using VLAN-aware network access servers and Internet Authentication Service (IAS) in Microsoft® Windows Server™ 2003, you can provide groups of users with access only to the network resources that are appropriate for their security permissions. For example, you can provide visitors with wireless access to the Internet without allowing them access to your organization network.

In addition, VLANs allow you to logically group network resources that exist in different physical locations or on different physical subnets. For example, members of your sales department and their network resources, such as client computers, servers, and printers, might be located in several different buildings at your organization, but you can place all of these resources on one VLAN using the same IP address range; the VLAN then functions, from the end-user perspective, as a single subnet.

You can also use VLANs when you want to segregate a network between different groups of users. After you have determined how you want to define your groups, you can create security groups in Active Directory and add members to the groups. You can define groups of users in several ways:

• By role. You can create groups for the sales team, the finance department, and other departments.

• By position. You can create groups for knowledge workers, managers, executives, and other positions.

• By access level. You can create groups for visitors, partners, full-time employees, and other categories with different access levels.

After you have created groups in Active Directory, you can open the IAS Microsoft Management Console (MMC) snap-in and create a remote access policy for each group. Within the remote access policy configuration process, you can define the VLAN to which the group will be assigned.

Configuration of VLAN-aware network hardware, such as VLAN-aware routers, switches, wireless access points, and access controllers, is beyond the scope of this white paper. When you have one or more of these devices configured as a Remote Authentication Dial-In User Service (RADIUS) client to your IAS server, however, you can use IAS to designate which VLAN the connecting user is placed on.

For information about how to configure your VLAN-aware network access server, see your access server documentation.

IAS is included in the following products:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

• Microsoft Windows Server 2003, 64-Bit Enterprise Edition

• Microsoft Windows Server 2003, 64-Bit Datacenter Edition

• Microsoft Windows Small Business Server 2003, Standard Edition

• Microsoft Windows Small Business Server 2003, Premium Edition

Requirements

To deploy IAS with VLANs as described in this white paper, the following components are required:

• A computer running Windows Server 2003 and IAS

• An Active Directory® directory service user accounts database

• RADIUS clients that are VLAN-aware, such as wireless access points, switches, or access controllers

Remote access policy

When you use Active Directory as your user accounts database, IAS performs network access authentication and authorization using Active Directory user account dial-in properties and remote access policies, which are configured in the IAS snap-in.

Authentication is the process of verifying identity, while authorization is the process of verifying that the user or device connecting to the network has permissions to do so.

A remote access policy is an ordered set of rules that define how a connection is either authorized or rejected by IAS. For each rule, there are one or more conditions, a set of profile settings, and a remote access permission setting.

If a connection is authorized, the remote access policy profile settings specify a set of connection restrictions that can include the assignment of the connection to a VLAN.

Authorization by group

It is recommended that you manage authorization by security group rather than by individual user. Managing authorization by group provides the ability to create one remote access policy, or rule, for network connection attempts by all members of the group. For example, if you have a sales department that you want to place on a VLAN, you can create a security group named Sales in the Active Directory Users and Computers snap-in, and then you can add all members of the sales department as members of the group. When a member of the Sales group attempts to connect to the network, the connection attempt is processed by IAS with the remote access policy for the group.

If the user is authenticated and authorized, IAS applies connection restrictions, and can instruct a VLAN-aware access server to place the member of the Sales group onto the VLAN for the sales department.

IAS authorizes connection attempts with both the dial-in properties of the user account, which are configured in the Active Directory Users and Computers snap-in, and remote access policies, which are configured in the IAS snap-in.

User account remote access permission

One of the dial-in properties of user accounts in Active Directory is Remote Access Permission (Dial-in or VPN). You can use this property to set remote access permission to be explicitly allowed, denied, or determined through remote access policies. In all cases, remote access policies are used to authorize the connection attempt.

If access is explicitly allowed, remote access policy conditions, user account properties, or profile properties can still deny the connection attempt. The Control access through Remote Access Policy option is only available on user accounts in a Windows 2000 native domain, a Windows Server 2003 domain, or for local accounts on stand-alone servers running Windows 2000; Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; or Windows Server 2003, Datacenter Edition.

New accounts that are created on a stand-alone server or in a Windows 2000 native domain are set to Control access through Remote Access Policy. New accounts that are created in a Windows 2000 mixed domain are set to Deny access.

When you manage authorization by security group, the remote access permission setting in user account dial-in properties can be set to one of the following:

• Allow access. Only apply this setting for users who are members of groups to whom you want to grant remote access permission. You can use this setting when your domain functional level is Windows 2000 mixed. Windows 2000 mixed supports Windows NT 4.0, Windows 2000, and Windows Server 2003 family domain controllers. With user account remote access permission set to Allow access, authorization is performed by IAS in circumstances where you have created a policy that matches the conditions of the connection.

• Control access through Remote Access Policy. This setting is recommended for domains with a functional level of Windows 2000 native or Windows Server 2003.

Ignoring the user account dial-in properties

You can configure IAS to ignore the dial-in properties of user accounts. This setting is useful for circumstances where you want IAS remote access policy to determine authorization for all connections to your network. For example, you can configure IAS to ignore the dial-in properties of user accounts when:

• Your domain functional level is Windows 2000 mixed.

• Changing the current settings on user accounts is not cost-effective.

For more information about configuring IAS to ignore the dial-in properties of user accounts, see “Dial-in properties of a user account” in Help and Support Center for Windows Server 2003 or on the Web at https://go.microsoft.com/fwlink/?LinkId=30601.

For more information about remote access policies, see “Introduction to remote access policies” in Help and Support Center for Windows Server 2003 or on the Web at https://go.microsoft.com/fwlink/?LinkId=30602.