active directory authentication instructor guide

Fireware TrainingInstructor Guide

Active Directory AuthenticationRestrict Access with Active Directory Users or Groups

Introduction

What You Will LearnAuthentication is an effective way to limit access to resources. This training course shows you how authentication works, and how Fireware can use your Active Direc-tory users and groups to authorize users to access network resources.

ExercisesSample Instructor Note. These appear only in the Instructor Guide. Look for the vertical bar in the right margin of a page to quickly identify instructor notes. For the Student Guide, the instructor notes are removed. The side notes (in italics) are in both the Instructor Guide and the Student Guide.

This course demonstrates two examples of Active Directory authentication. Each step-by-step exercise illustrates a use case that might apply in your network. The titles of the exercises are:

• Allow authenticated users on the external network to manage the Firebox• Use Active Directory to authenticate MUVPN clients

Before you do the exercises, be sure to read “Before You Begin,” on page 27. This section has a list of the equipment and software you need to do the exercises, and gives you basic information about how to prepare the Firebox and the Active Direc-tory server.

What Active Directory Authentication Can Do For YouSample side note. Side notes are extra information that is not necessary to understand the training. They might be configuration or troubleshooting tips, or extra technical information.

Active Directory authentication provides these benefits:

• Restricts access to network resources by user name or group name. With today’s highly mobile workforce you can no longer rely only on IP addresses to control access. A method that forces users to authenticate before they access resources gives you better control in your firewall policies when you don’t know the users’ IP addresses.

• Enforces user accountability based on user name.• Centralizes maintenance of user accounts.

This training is for:

Appliance Firebox X Core / Firebox X Core e-Series / Firebox X Peak / Firebox X Peak e-Series

Appliance Software versions Fireware Pro 9.0

Management Software versions WatchGuard System Manager 9.0

Category Authentication / Active Directory

2 WatchGuard® Fireware® Training

Related InformationThese additional resources can help expand your knowledge of Active Directory and LDAP.

Additional Resources• “How Active Directory Searches Work” from Microsoft:

http://technet2.microsoft.com/WindowsServer/en/library/8196d68e-776a-4bbc-99a6-d8c19f36ded41033.mspx

• LDAP RFCs: - RFC 1777 defines what is now called version 2 of the Lightweight

Directory Access Protocol (or LDAP v2): ftp://ftp.rfc-editor.org/in-notes/rfc1777.txt

- The core specifications of LDAP v3 are defined in RFC 2251: ftp://ftp.rfc-editor.org/in-notes/rfc2251.txt

http://technet2.microsoft.com/WindowsServer/en/library/8196d68e-776a-4bbc-99a6-d8c19f36ded41033.mspx

ftp://ftp.rfc-editor.org/in-notes/rfc1777.txt

ftp://ftp.rfc-editor.org/in-notes/rfc2251.txt

What You Should Know

3


When you want to restrict access to resources by user name or group name, con-sider two distinct concepts: Authentication and Authorization.

• Authentication proves the identity of the user. The Firebox can authenticate users against your Active Directory server for Firewall Authentication and for MUVPN connections.

• Authorization grants the user permission to do something. You give access to networks by putting user names or group names in the source field (the From field) of a policy in Policy Manager.

How Authentication Works in FirewareThe Firebox can authenticate a user with your Active Directory server in two ways:

Firewall Authentication The session between the user’s computer and the Firebox is protected by SSL encryption.

A user with an Active Directory account must establish an HTTPS connection to the Firebox on TCP port 4100 using a web browser. To do this, the user enters the DNS name or IP address of the Firebox interface that protects network resources in the URL field like this: https://my.firebox.net:4100 Or this: https://10.0.1.1:4100

After the user is authenticated, the Firebox knows the user name and the groups the user is a member of. Traffic from that user is allowed through a firewall policy if the policy's source field has a user name or group name that matches the user's identity or group membership.

A firewall policy must exist to allow traf-fic to pass to the Firebox over port 4100. Policy Manager automatically adds the WatchGuard Authentication policy for this, but it allows port 4100 connections to the Firebox from only trusted and optional networks. If you want users to authenticate from external networks, you must edit this pol-icy (or add another policy) to allow port 4100 connections to the Firebox from external networks. We cover this in the Exercises.

To service these requests, a web server in the Firebox listens on only port 4100. The user types a user name and a password in the boxes on the page.

Figure 1: The Firewall Authentication web page


When we get into the “Detailed steps in the authentication process” on page 20, these side notes will give different FAILURE MESSAGES the user can see if the authenti-cation process fails. These messages are different depending on where in the authentication process the failure occurs. The Firewall Authentication web page refreshes every 15 seconds to give the user current status. When the session timeout or idle timeout limit is reached, a message appears in the browser telling the user of the timeout event, and the page gives the login prompt again.

If the authentication is successful, the user sees the success message in the browser.

Figure 2: Firewall Authentication success message

MUVPN Authentication The Extended Authentication session happens after the Phase 1 IKE negotia-tions are complete. This session between the MUVPN user’s computer and the Firebox is protected by the IKE Phase 1 encryption.

The user activates the security policy on the MUVPN client software and issues the command to connect. During the Extended Authentication phase of the VPN negotiations, a popup prompts the user to enter a user name and password.

Figure 3: The Mobile User VPN prompt

The MUVPN user also sees a success mes-sage in the MUVPN software’s Log Viewer: My Connections\50.50.50.1-10.0.1.0 - IKE Extended

Authentication successful

If the authentication is successful, the user sees the success message as a popup.

Figure 4: MUVPN success message

Information the Firebox gets from the authentication processThe Firebox gets all the information it needs to match traffic flows to users when it authenticates the user. After a user authenticates, the Firebox puts these items in memory to track the authenticated user’s session:


5

• Type of authentication server that authenticated the user. For this training, we assume this is Active Directory.

• User name the user typed when authenticating.• IP address that the Firebox sees as the source of the authentication (the user’s

IP address).Group information must come from the authentication server. If group informa-tion is not in the server’s authentication response message, you can restrict the user’s access in a firewall policy only by user name.

• Groups to which the user belongs. This normally comes from the memberOf attribute Fireware gets from the Active Directory search response.

• Session timeout and idle timeout values for this user or group. • Virtual IP address assigned to the MUVPN user (applies only to MUVPN

connections).

How Authorization Works in FirewareTo authorize users to access resources, you add their user names, or the names of groups to which they belong, to a policy in Policy Manager. A user is authorized to pass traffic through a policy if the user’s user name appears in the policy’s From field, or if the user is a member of a group that appears in the policy’s From field.

To prevent your policies from allowing traffic that you did not intend, avoid using aliases that include a wide range of addresses. These can include Any, Any-Trusted, Any-Optional, Any-External, or an alias that is the name of a Firebox interface. Before you use one of them in a policy, carefully consider what the policy is for. Aliases like this can allow access to users that do not authenticate.

Make a list of authorized users and groupsPolicy Manager keeps a list of user and group objects so that you can easily access them when you work with firewall policies. Use the Authorized Users and Groups dialog box to add the Active Directory users and groups you plan to use in Policy Manager before you add them to policies.

1. To add user or groups to this list, select Setup > Authentication > Authorized Users/Groups.

Figure 5: Accessing the Authorized Users and Groups dialog box


The Authorized Users and Groups dialog box appears.

Figure 6: Authorized Users and Groups dialog box

2. Click the Add button in Figure 6 to add a user or group. The Define New Authorized User or Group dialog box appears.

Figure 7: Define a new user or group

t

- Type the name the user will enter when the user authenticates, or type the name of an Active Directory group. You can also enter an optional description.

- Select the Group or User radio button. - From the Auth Server drop-down list, select Active Directory.


7

The new user or group appears in the Authorized Users and Groups dialog box.

Figure 8: New Active Directory user account in Authorized Users and Groups

Use firewall policies to restrict access by user or group

To limit access to firewall policies, you use a policy on the Firewall tab of Policy Manager. Users perform Firewall Authentication to get access.

Figure 9: Firewall tab of Policy Manager

Note the difference in user and group icons: A user is indicated by this icon, with one person:

A group is indicated by this icon, with two people:

Here is a policy that allows a user and a group.

Figure 10: A policy that allows access only for a user and a group


Use this procedure to limit access to a Firewall policy by user or group:

1. Double-click a policy on the Firewall tab to edit it.

2. Remove the Any-Trusted and Any-Optional aliases from the From field, along with any other addresses or aliases that could allow access to a user that is not authenticated yet. Highlight an address or alias and click Remove to remove it.

3. From the Properties tab, click the Add button.

Figure 11: Add to the From field of a policy

4. The Add Address dialog box appears. Click Add User.

Figure 12: Add Address dialog box


9

The Add Authorized Users or Groups dialog box appears. The users and groups you added to the Authorized Users and Groups list appear in this box.

Figure 13: Select a user or group to add to the policy

Select PPTP from the Type drop-down list only for PPTP users that authenticate to the Firebox for PPTP. You cannot use Active Directory to authenticate PPTP users.

5. From the Type drop-down list, select Firewall. 6. From the drop-down list to the right, select Group to see the groups you

added to Authorized Users and Groups, or select User to see the users you added.

7. If the user or group you want to use does not appear in this list, click Add to see the Authorized Users and Groups area of Policy Manager. Do the previous set of steps to add to the list.

8. Highlight the user or group you want to add to the policy and click Select. The object appears in the Selected Members and Addresses area of the Add Address dialog box.

Figure 14: Object appears in Selected Members and Addresses


9. Click OK. The user or group appears in the From field of the policy.

Figure 15: This policy allows traffic from only authenticated members of the group

Custom addresses and tunnel addresses You can put extra restrictions on whether traffic is allowed from an authenticated user with a custom address or a tunnel address. These address types let you spec-ify the user or group, and in addition they let you put two other conditions that traffic must meet in order to match the address.

Custom addresses and tunnel addresses apply only to firewall policies. They do not apply to MUVPN policies.

A custom address lets you put these conditions on traffic:

• User or member of a group.• IP address. This can be a host IP address, a network IP address, or an IP address

range.• Interface where the Firebox sees the traffic.

- If the custom address is in a policy’s From field, this is the interface where the traffic enters the Firebox.

- If the custom address is in a policy’s To field, this is the interface where the traffic exits the Firebox.

A tunnel address lets you put these conditions on traffic:

• User or member of a group.• IP address. This can be a host IP address, a network IP address, or an IP address

range.• Branch Office VPN tunnel that the traffic goes through.

If you use one of these address types in a firewall policy, traffic must match all three conditions of either address type.

For example, suppose you want to grant FTP access to an Active Directory user. You want the user to authenticate first, but you do not want the user to get access to FTP when authenticated from the optional or external network, only from the trusted network. Furthermore, you want the user to have access only if the user’s traffic comes from a small segment of the trusted network, the 10.0.1.64/28 subnet.

Add a custom address to achieve this:

1. Double-click the policy to edit it and go to the Properties tab.


11

2. Remove the Any-Trusted and Any-Optional aliases from the From field, along with any other addresses or aliases that could match this user’s IP address. Highlight an address or alias and click Remove to remove it.

3. In the From field, click Add, then click Add Other. You cannot add users or groups to the Authorized Users and Groups list from the Add Member dialog box. You must add objects to the Authorized Users and Groups list before you can use them in a custom address or a tunnel address. Note that you cannot use an MUVPN Group name in a custom address or tun-nel address. Custom addresses and tun-nel addresses do not apply to MUVPN traffic.

4. The Add Member dialog box appears. From the Choose Type drop-down list, select Custom Address.

Figure 16: The Custom Address dialog box

- From the User/Group drop-down list, select a user or group object you already added to the Authorized Users and Groups list.

The 10.0.1.64/28 subnet includes host addresses from 10.0.1.65 through 10.0.1.78. You could use an address range for this instead of a network IP address.

- From the Address drop-down list, select Specify. A new field appears for you to type the address 10.0.1.64/26.

- From the Interface drop-down list, select Trusted.

5. Click OK. The custom address appears in the Selected Members and Addresses area at the bottom.

Figure 17: Custom address in the Add Address dialog box


Note that you can get the details of this address when you place your cursor over it. A tool tip appears for a few moments.

Figure 18: Tool tip gives details of the custom address

The automatically generated MUVPN policy allows traffic only from users that are members of an Active Directory group that has the same name as the MUVPN group. Create a group in your domain with the same name as the MUVPN group name, or give the MUVPN group the same name as an existing Active Directory group. Put the users allowed to connect via MUVPN into that Active Directory group.

Use MUVPN policies to restrict access by user or groupFor MUVPN users, you control access with policies on the Mobile User VPN tab of Policy Manager. The WSM software automatically makes a policy when you create the MUVPN group. This policy allows access over any port or protocol to the resources you specify when you create the MUVPN group.

Figure 19: The Mobile User VPN tab of Policy Manager


13

A policy on the MUVPN tab of Policy Manager is always tied to a specific MUVPN group; it allows access to the resources you specified when you cre-ated the MUVPN group. You cannot spec-ify a set of resources that is different from the allowed resources defined for that MUVPN group.

The MUVPN group allowed to use the policy appears near the top of the Policy tab:.

Figure 20: The MUVPN group allowed to use the MUVPN policy is circled

The Allowed Resources area of an MUVPN policy shows the host IP addresses or network IP addresses the MUVPN user can access through the VPN.

Add a policy to the MUVPN tabYou can delete the automatically generated Any policy and replace it with a policy that allows access to a more limited range of ports. You must add the policy to the MUVPN tab of Policy Manager, not to the Firewall tab.

1. Select the MUVPN tab of Policy Manager and then select Edit > Add Policy.

2. The Select MUVPN Group dialog box appears. Select the group this policy applies to and click OK.

Figure 21: Select the MUVPN group the new policy applies to


3. The Add Policies dialog box appears. Find the policy you want to add by expanding the appropriate folder, or click New to add a custom policy.

Figure 22: The Add Policies dialog box

Limit access by user instead of the entire MUVPN groupTo limit access to only certain users instead of all members of the group, double-click an MUVPN policy to edit it.

1. Click the Specify Users button on the Policy tab of an MUVPN policy.

Figure 23: Specify users for an MUVPN policy


15

2. The MUVPN Users/Group dialog box appears. It shows the MUVPN group you created. Click Add to specify individual members of the group.

Figure 24: The MUVPN group allowed to use the policy

If the user you want to add is not in this list, click Add to access the Authorized Users and Groups list to add more users.

The Add MUVPN Users - Active Directory dialog box appears. This dialog box shows only the users you added to Authorized Users and Groups that use the same authentication server as the MUVPN group.

Figure 25: Active Directory users you added to Authorized Users and Groups

3. Click the user and then click Select. You can press the Ctrl key on your keyboard while you select multiple users in the list before you click Select. The users you select appear in the MUVPN Users/Group dialog box. Click OK to finish specifying users.

Figure 26: Users allowed to use the MUVPN policy


Details of the Active Directory Authentication Process

Terms and DefinitionsUse this list as a reference for the rest of the training course.

Active DirectoryMicrosoft’s directory service. It stores information about objects on a network and makes this information available to users through an LDAP interface.

AttributeA characteristic of an object in the directory. The schema defines whether the attribute can have only one value (single-valued) or multiple values (multi-valued).

Base DNThe start of the directory tree. The Base DN holds all objects in the domain.

Organizational Units are container objects. Active Directory provides other containers in the default installation, such as the Users container, the Builtin container, and the Computers container.

ContainerAn object in the directory that can contain other objects; similar to a folder on your computer that can contain other folders or files.

DirectoryA store of information, like an address book that stores names and phone numbers.

Directory ObjectAn entry in the directory. An object has a list of attributes that describes it.

Directory ServerA computer, such as a domain controller, that provides access to an LDAP-based directory.

Directory ServiceA service that runs on a directory server to give access to the directory.

Directory TreeHierarchical organization of information that starts from a single point (the root, or Base DN) and branches out; analogous to a tree and similar in structure to a computer file system. The structure of the tree is determined by the schema.

Distinguished Name (DN)The DN starts with the friendly name for the object, followed by the name of the container that holds the object, and con-tinues with the name of the container that holds that container, and so on, all the way to the Base DN. In this way, the DN shows the object’s location in the directory tree.

The globally-unique name of an object in the directory. It defines the object’s location in the directory.

Firewall AuthenticationAuthentication a user does using a web browser. The user makes an HTTPS connection to the Firebox over port 4100, and the web page gives prompts for user name and password.

LDAPLightweight Directory Access Protocol. A protocol for accessing an information directory.

LeafAn object in the directory that cannot contain other objects. Similar to a file on your computer, a leaf represents the end of the branch for that object in the directory tree. User objects and group objects are leaf objects.

MUVPN Authentication Authentication a user does with WatchGuard’s Mobile User IPSec VPN software. The software makes a popup dialog box for the user to do the authentication.


17

SchemaThe set of rules that controls all aspects of what can be stored in the directory.

User Principal Name (UPN)A naming convention used by Active Directory to identify a user and the domain to which the user belongs. The UPN is almost always identical to the user’s email address: it includes the user’s logon name, followed by @ and the name of the domain. For example, the user bsmith in the training.net domain has UPN [email protected].

Understanding the LDAP framework of Active DirectoryActive Directory includes Microsoft’s implementation of the Lightweight Directory Access Protocol (LDAP). When you understand the LDAP framework of Active Directory, you can confidently configure Active Directory authentication in Policy Manager and more easily diagnose Active Directory search and authentication fail-ures.

What Active Directory has in common with LDAP LDAP is a protocol. It defines methods to access information in a directory. A direc-tory is simply a store of information, like an address book that stores names and phone numbers. A directory server runs a directory service to provide the access for clients. In your Active Directory domain, a domain controller runs the directory service.

Active Directory uses an LDAP-compliant directory for storing information about every object and resource in your domain: users, computers, file shares, applica-tions, organizational units, groups, security policies, and so on. Because Active Directory implements LDAP, you can use standard LDAP operations to get informa-tion about the directory’s objects.

Microsoft provides an interface into the directory with a tool called ADSIEdit. This GUI tool is a Microsoft Management Console (MMC) snap-in that acts as a low-level editor for Active Directory and illustrates the tree structure of the direc-tory. It is included when you install Win-dows Server 2000 or 2003 Support Tools from the product CD. Here is a screen shot of ADSIEdit connected to the training.net domain. The two user objects at the top of Figure 27 are circled.

Structure of the directory Information in an LDAP directory is stored in a tree-like hierarchy. It begins with one container that holds everything, and branches out in a way that is similar to how files and folders are organized on your computer. The start of the tree, the con-tainer that holds everything, is called the Base DN. It represents your Active Direc-tory domain.

The Base DN can hold container objects, leaf objects, or both. Container objects can hold other container objects, leaf objects, or both. You can have many contain-ers within containers. Leaf objects can exist anywhere in the tree but they cannot contain other objects. The diagram in Figure 27 shows a simple representation of a directory tree.

OU=Accounts

OU=Sales

CN=Bob Smith

DC=training,DC=net

CN=Alice Jones

CN=Builtin

CN=Administrators CN=Guests

Leaf object

Organizational Unit or other container

Base DN

dn: CN=Bob Smith,OU=Sales,OU=Accounts,DC=training,DC=net objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user cn: Bob Smith sn: Smith givenName: Bob distinguishedName: CN=Bob Smith,OU=Sales,OU=Accounts,DC=training,DC=net displayName: Bob SmithmemberOf: CN=Some Universal Group,DC=training,DC=net memberOf: CN=Some Local Group,CN=Users,DC=training,DC=net memberOf: CN=Firebox Restricted,OU=Accounts,DC=training,DC=net name: Bob Smith objectGUID: bGh5jCbsmUS9a5PDKjw1NQ== sAMAccountName: bsmith sAMAccountType: 805306368 userPrincipalName: [email protected] objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=trainng,DC=net msNPAllowDialin: TRUE


Figure 27: Simple view of LDAP structure

Objects and AttributesThis is a good opportunity for you to show the students Microsoft’s ADSI Edit interface or some other LDAP browsing tool such as LDAP Browser from Soft-erra. You can show the tree-like struc-ture of the directory with these tools, and you can show all the attributes for an object.

Every object in an LDAP directory is described by a list of attributes. Some attributes, such as sAMAccountName, must be assigned a value while others can be null. These requirements are defined in the schema. An attribute can be either sin-gle-valued (there can be only one value assigned to the attribute) or multi-valued (the attribute can have more than one value).

Figure 28 shows a sample list of some of the attributes for the Bob Smith user object:

Figure 28: Some of the attributes for the Bob Smith user object

When you add a user to a group, Active Directory automatically adds another value to the user object’s memberOf attribute to indicate the user’s membership in the group. Because Fireware’s LDAP query finds the user object and all of its attributes,


19

Fireware can tell what groups the user belongs to by reading the user object’s memberOf attribute.

Identifying Objects in the DirectoryBase DN The name of the Base DN uses the DNS components of your domain name, called Domain Components (DC). Active Directory domains must have at least two DNS domain components: a friendly name such as mycompany, and a top-level domain suffix such as .net or .com. In our examples, we use the domain name training.net. The DNS domain components of this name are training and net. (The domain name can also have a local component, as in classroom.training.net.)

If the training.net domain had a child domain called “classroom”, the DN would be: DC=classroom,DC=training,DC=net

To construct the Base DN name, you write DC=<domain component>,DC=<domain component> with one such entry for each domain component. You start with the first part of your domain name and end with the top-level domain suffix. Separate each part with a comma and no space. There are no dots between each part or at the end. Thus, the name of the Base DN for the training.net domain is: DC=training,DC=net

Object’s Friendly NameThe technical term for the object’s friendly name is the Relative Distin-guished Name or RDN. Two objects can have the same RDN only if no container other than the Base DN contains both objects. In other words, an objects’ RDN must be unique within the branch of the tree where the object is; no other object in that branch, all the way to the root, can use that RDN. This ensures that the DN for any object is globally unique even if two objects have the same RDN. The DNS for objects with identical RDNs remain globally unique because an object’s Distinguished Name specifies not only the object’s RDN, but also its location in the directory.

Every object in the directory has a simple name or friendly name. It starts with an abbreviation for the type of attribute used for the friendly name, followed by =, fol-lowed by the object’s name. The objects you most often work with use well-defined attributes for the friendly name:

• For a user object or group object, the friendly name starts with CN=• For an organizational unit, the friendly name starts with OU=

Here are some examples:

• A user object’s friendly name is usually the user’s first and last name, and possibly a middle initial. For example: CN=Alice Jones or CN=Bob Smith.

• A group object’s friendly name is the name of the group. For example: CN=Firebox Restricted or CN=MUVPN Group.

• An organizational unit’s friendly name is the name you give the OU. For example: OU=Sales or OU=Accounting

Object’s Distinguished NameEvery object in the directory is uniquely identified by its Distinguished Name (DN). The DN for an object starts with its friendly name, followed a list of each con-tainer above the object. Each part of the DN is separated by only a comma. Thus the DN shows how the object relates to its parent objects, all the way to the Base DN.

CN stands for Common Name. Some common misconceptions are that it stands for “container” or “canonical name”.

The friendly name for the Bob Smith object in Figure 27 is CN=Bob Smith, so the DN is: CN=Bob Smith,OU=Sales,OU=Accounts,DC=training,DC=net

The DN for the OU called Accounts, just within the root of the tree, is: OU=Accounts,DC=training,DC=net

The DN for the Administrators group in the Builtin container is: CN=Administrators,CN=Builtin,DC=training,DC=net


Active Directory Groups and LDAP Those familiar with directories will recog-nize that memberOf is only an attribute. A Firebox administrator can use any attribute to define group membership, even a custom attribute added by extending the schema. The value of the attribute is what the Firebox considers to be the group the user belongs to. Use the attribute's name in the Group String field when you configure Active Directory authentication in Policy Manager. Use the attribute's value as the group name in Firebox policies.

Some people confuse the idea of a group with the idea of a container. This is natu-ral, because we often think of groups containing things. However it is important to keep these two concepts separate. The confusion can be an obstacle to under-standing how groups fit into the LDAP structure of Active Directory.

A user’s group membership in Active Directory is not determined by the container the user is in. Instead, group membership is based on the values of an object's group membership attribute, memberOf.

An Active Directory group can have members, but membership in a group is not the same thing as being contained in a parent object of the directory tree. A user object can be contained only in an Organizational Unit or other container. Do not confuse membership in a group with the container that holds the user.

Remember that Fireware tells what groups a user is a member of by looking at the user object’s attributes, not by where in the directory the user is located.

How Fireware Authenticates Users with Active DirectoryTo successfully authenticate a user, the Firebox must do these things:

To identify itself to a directory, the entity that requests a Bind operation normally sends its full Distinguished Name (DN). Active Directory also allows a different form of identification for a Bind: the User Principal Name (UPN).

• Authenticate to the Active Directory server. Fireware does this using the LDAP Bind operation. The Firebox sends credentials to the directory server to establish permissions to search the directory. These can be the credentials of the user trying to authenticate, or credentials that you specify.

• Search for the user object to verify it exists in the directory. Fireware does this using the LDAP Search operation. To do a search, the only permission required is read access. Active Directory domains grant this permission to all domain user accounts by default.

• Get the user’s information from the search results.The Search operation finds the user object in the directory and gets all the object’s attributes. The object’s attributes tell Fireware the user’s distinguished name, the groups of which the user is a member, and possibly other optional information.

• Authenticate the user. Fireware does one final Bind operation with the user’s credentials to verify the user’s password.

Detailed steps in the authentication processThese are the events that make up the Active Directory authentication process.

FAILURE MESSAGE: If Fireware fails to com-plete a TCP session with the server, the user attempting Firewall Authentication sees this error in the browser: Authentication Failed: 'LDAP initial binding failed, please try again later'

1. User attempts to authenticateThis can be an attempt to use Firewall Authentication or an attempt to make an MUVPN connection. The following steps are the same for either type of authentica-tion.

When the Firebox gets the user credentials, it starts a TCP session with the directory server to start the process.


21

2. Fireware attempts to bind to Active Directory FAILURE MESSAGE: If this first Bind request in Step 2 fails, the user attempting Firewall Authentication sees this error in the browser: Authentication Failed: 'LDAP binding failed, credentials are not correct, please try again'

This first Bind request tells the directory server which account Fireware wants to use for the Search operation. For this Bind request, Fireware uses one of two differ-ent accounts:

• The credentials of the user attempting to authenticate.• An account that you specify.

Fireware versions prior to 9.0 do not give the option to specify the Login Attribute. In prior versions, this first Bind is always done using the user’s UPN. If you keep the Login Attribute set to default value sAMAccountName and do not provide a Searching User account as shown in Figure 29, Active Directory authentica-tion in Fireware 9.0 works the same way as in versions prior to Fireware 9.0.

The account the Firebox uses for this Bind is determined by whether you specify a Searching User.

Figure 29: The items that determine the credentials used for the first Bind

The simplest way to complete the highlighted area in Figure 29 is exactly as shown:

• DN of Searching User and Password of Searching User are empty• Login Attribute is set to the default value sAMAccountName

It is not necessary to provide a Searching User if you keep the Login Attribute box at the default value sAMAccount-name. However, you must specify a Searching User if you use any other value for Login Attribute. The Login Attribute is used as a search fil-ter to find the user in the directory.

When you configure the highlighted area like this, Fireware constructs the User Principal Name (UPN) from the user name that the user typed into the authentica-tion dialog box, the @ character, and the domain components in DNS form. Fireware sends this as identification for this first Bind request.

When you use these default settings, the user attempting to authenticate enters the Windows logon name (without domain information) for the Username field. Thus, if a user with logon name bsmith attempts to authenticate, the user types bsmith in the Username field when prompted. The Firebox sends [email protected] as identification for this Bind. (In our examples, the domain components are DC=training,DC=net.)


Active Directory does not require that the User logon name (pre-Windows 2000) value match the User logon name at the top of the Account tab in Figure 30. In most cases the network administrator keeps them the same, but you should make sure you do not confuse the two. Active Directory uses only the User logon name (pre-Windows 2000) value for the sAMAccountName attribute. It uses the User logon name value only for the userPrincipalName attribute.

Figure 30 shows the Bob Smith user account in Active Directory Users and Comput-ers. The circled area shows what Active Directory uses for the sAMAccountName attribute.

Figure 30: User logon name (pre-Windows 2000) for the Bob Smith account in Active Directory Users and Computers is circled

How to use a different Login Attribute

If you want the user to type something else in the authentication dialog box instead of the standard Windows logon name, select (or manually type) a different value for the Login Attribute field in Figure 29.

For example, if you want users to type their Common Name for the Username field when they authenticate, select cn for the Login Attribute in Figure 29. In this case Bob Smith types Bob Smith or bob smith in the Username field when he authenti-cates (Windows user names are not case-sensitive).

If you select an attribute that is not sAMAccountName, you must specify a Searching User in Figure 29. This is because Fireware cannot construct the user’s UPN if the user types something other than the simple logon name into the Username field.

Type the full Distinguished Name for an account that has permission to read the directory in the DN of Searching User field. Type the account’s password in the Password of Searching User field.

3. Fireware searches the directory for the Login AttributeWhen the Bind is successful, Fireware sends a Search request. An LDAP search request can include many different parameters and filters. Fireware’s search request includes the following parameters and search filter:

Use ADSI Edit or LDAP Browser here to illustrate the search base. Ask the stu-dents to identify the correct search base for different users in various branches of the directory tree.

• Search Base A Search request must indicate where in the database hierarchy the directory service should start the search. The Search Base you specify tells Active Directory:

- Start looking in this container (the Search Base). Do not look in any container that is a parent of this container.

• Scope The scope of the search tells the directory service whether to look only in the Search Base but not inside any containers in the Search Base; to look only one container deep inside this container (one level lower in the search base); or to look in all containers within containers (in all containers to the end of the tree). Fireware uses the scope: subtree parameter to tell Active Directory:


23

- Look in the Search Base container, every container within it, inside containers within those containers, and so on, to the end of this branch of the directory tree.

To see all the attributes in Traffic Monitor, increase the Diagnostic Logging level for the Authentication module. From Policy Manager, select Setup > Logging and click the Advanced Diagnostics button. Select the box Display diagnostic mes-sages in Traffic Monitor. Set the Authentication category to at least Advanced, Level 1, to see all the attributes. It is not necessary to turn on advanced diagnostics to see only the user’s group membership in Traffic Monitor. When a user authenticates, you should see mes-sages like this: ADM auth get user group FBusers

• Attributes Only This parameter tells the directory server whether it should return only the names of attributes tied to the object, or if it should send the attribute names and the value of each attribute. The search parameter takes a boolean value of true or false. Fireware uses false for the parameter to tell Active Directory:

- Give me all the attributes for the object you find, and the value of each attribute.

• Search Filter The search filter tells the directory server to return only objects that match certain conditions. (With no filter, the search would return every object and attribute in the database!) Fireware uses an equality match filter that tells the server:

- Look only for objects that have the attribute I specify (this is the attribute you type in the Login Attribute field in Figure 29).

- Return an object as a match only if the value for that attribute matches what the user typed in the Username field in the authentication prompt.

For example, if you use the default settings in the Active Directory setup area of Policy Manager (Figure 29), and Bob Smith tries to authenticate, the filter reads: sAMAccountName=bsmithFor the search result, the server looks only for an object that has an attribute sAMAccountName AND has bsmith as the attribute’s value.

4. The server sends the Search Result to the FireboxFAILURE MESSAGE: If the search result is null, the user attempting Firewall Authentica-tion sees this error in the browser: Authentication Failed: 'Speci-fied username or password is not correct, please try again'

The server searches its database using the parameters and filter described above. If no such object exists with an attribute that matches the filter, Active Directory still returns a search result but the result is <null>, meaning that the search found no matches. The authentication fails if this happens because the server cannot find the user.

If the server finds an object that matches the filter, it sends Fireware all the attributes and their values for that object.

5. Fireware extracts the information it needs from the search resultAfter the Firebox gets the search result, it sends an Unbind command to the server so that it can do one final Bind with the user’s Distinguished Name (see the last step, Step 6).

Fireware reads all of the attributes in the user object. It looks for the attributes it needs to tie the user to groups (the memberOf attributes), and possibly other optional attributes. It stores this information in memory so that it can authorize traffic from the user based on the policies in Policy Manager.

Most importantly, Fireware gets the user’s Distinguished Name to use for the last step.


6. Fireware attempts a Bind with the user’s Distinguished NameFAILURE MESSAGE: If the password the user typed is incorrect, the user attempting Firewall Authentication sees this error in the browser: Authentication Failed: 'Speci-fied username or password is not correct, please try again' FAILURE MESSAGE: For all MUVPN authen-tication failures, the remote client sees this in the client-side Log Viewer: My Connections\50.50.50.1-10.0.1.0 - User Authentication failed

Finally, the Firebox can authenticate the user. To verify that the user is who he or she claims to be, Fireware sends a Bind request with the user’s credentials. It uses the Distinguished Name it got from the previous step for the Bind name, and it sends the password that the user typed into the authentication dialog box. If this succeeds, the user is authenticated.

Optional data that Active Directory can give Fireware Fireware can get additional information from Active Directory when it reads the list of attributes in the server’s search response. This lets you use Active Directory to assign extra parameters to the authenticated user’s session, such as timeouts and MUVPN address assignments. Because the data comes from LDAP attributes tied to individual user objects, you can set these parameters for each individual user instead of being limited to global settings in Policy Manager.

However, Microsoft does not provide ready-made attributes you can use for these items, and you cannot assign values to these attributes using Active Directory Users and Computers.

You must do several steps to use these optional settings:

• Extend the Active Directory schema to add new attributes for these items.• Make the new attributes available to the user object class. • Give values to the attributes for the user objects that should use them.

You should thoroughly test and plan before you extend your Active Directory schema. Additions to the schema are generally permanent and cannot be undone. Use the Microsoft web site to get resources to help you plan, test, and implement changes to the schema.

Microsoft provides two main methods to extend the schema. Both of these tools let you add attributes to the schema and make them available to an object class:

• The Active Directory Schema MMC snap-inThis is a graphical interface you can add as a snap-in to the Microsoft Management Console. It lets you access the schema and make changes to it.

• A command-line tool called ldifde (LDIF Data Exchange)This is a scriptable command-line interface to import or export LDIF files. LDIF is the LDAP Data Interchange Format. It specifies the format used to represent LDAP entries in a text file, to import and export directory data between directory servers.

After you add attributes to the schema, you must give them values. You cannot do this with Active Directory Users and Computers. Microsoft provides several differ-ent tools to assign values to the new attributes. Two commonly used tools are:

• The ldifde tool. Use this to import an LDIF file that specifies a value for the new attributes for each user object that should use them.

• The ADSI Edit snap-in to Microsoft Management Console. Use this tool very carefully to edit raw LDAP attributes. It lets you access individual directory objects and edit the value of each attribute tied to an object.


25

Optional attributesTo specify additional attributes for Fireware to look for in Active Directory’s search response, click the Optional Settings in Figure 29. The Active Directory Server Optional Settings dialog box appears.

Figure 31: Optional settings for Active Directory authentication

Each field in Figure 31 lets you type the name of an LDAP attribute. Fireware looks for the attribute in the list of attributes it gets from the search result, and uses the attribute’s value as follows:

If the Firebox does not see the IP attribute in the search response, or if you do not specify an attribute in Policy Manager, it assigns the MUVPN client a virtual IP address from the virtual IP address pool you create when you make the MUVPN Group.

• IP Attribute String Type the name of the attribute Fireware should use to assign the MUVPN client a virtual IP address. This should be a single-valued attribute. The attribute’s value should be a normal dotted-decimal IP address. The IP address must be within the pool of virtual IP addresses you specify when you create the MUVPN group.This applies only to MUVPN clients.

The MUVPN software automatically assigns a netmask if the Firebox does not see the netmask attribute in the search response, or if you do not specify one in Policy Manager.

• Netmask Attribute String Type the name of the attribute Fireware should use to assign a subnet mask to the MUVPN client’s virtual IP address. This should be a single-valued attribute. The attribute’s value should be a normal dotted-decimal subnet mask.This applies only to MUVPN clients.

If the Firebox does not see the DNS attribute in the search response, or if you do not specify an attribute in Policy Man-ager, it uses the DNS addresses you enter at Network > Configuration > WINS/DNS tab in Policy Manager.

• DNS Attribute String Type the name of the attribute Fireware should use to assign the MUVPN client one or more DNS addresses for the duration of the MUVPN session. This can be a multi-valued attribute. Each value for the attribute should be a normal dotted-decimal IP address.This applies only to MUVPN clients.

If the Firebox does not see the WINS attribute in the search response or if you do not specify an attribute in Policy Man-ager, it uses the WINS addresses you enter at Network > Configuration > WINS/DNS tab in Policy Manager.

• WINS Attribute String Type the name of the attribute Fireware should use to assign the MUVPN client one or more WINS addresses for the duration of the MUVPN session. This can be a multi-valued attribute. Each value for the attribute should be a normal dotted-decimal IP address.This applies only to MUVPN clients.


If the Firebox does not see session time-out or idle timeout attributes in the search response, or if you do not specify attributes for them in Policy Manager, it uses these values: – For MUVPN clients, edit the MUVPN group at VPN > Remote Users. Select an MUVPN group to edit. You set session and idle timeout values on the General tab when you edit the MUVPN group. – For Firewall Authentication, set session and idle timeouts in Policy Manager at Setup > Global Settings.

• Lease Time Attribute String Type the name of the attribute Fireware should use to control the absolute amount of time a user can stay authenticated (session timeout). After this amount of time, Fireware removes the user from its list of authenticated users. This should be a single-valued attribute. Fireware interprets the attribute’s value as a decimal number of seconds. It interprets zero as “never time out.”This can apply to MUVPN clients and to clients that use Firewall Authentication.

- For MUVPN clients, when the timeout is reached Fireware sends an “SA Delete” message to tell the client to delete its IKE and IPSec security associations.

- For Firewall Authenticated users, the web authentication page shows a message when the session timeout is reached: Authentication Failed: ‘Session timed out by session limit’

• Idle Timeout Attribute String Type the name of the attribute Fireware should use to control the amount of time a user can stay authenticated with no traffic passing to the Firebox from the user. If no traffic passes to the Firebox for this amount of time, Fireware removes the user from its list of authenticated users. This should be a single-valued attribute. Fireware interprets the attribute’s value as a decimal number of seconds. It interprets zero as “never time out”.This applies to MUVPN clients and to clients that use Firewall Authentication.

- For MUVPN clients, when the timeout is reached Fireware sends an “SA Delete” message to tell the client to delete its IKE and IPSec security associations.

- For Firewall Authenticated users, the web authentication page shows a message when the idle timeout is reached: Authentication Failed: ‘Session timed out by idle limit’

Before You Begin

27

Before You Begin

Optional: Extending the Active Direc-tory Schema The zip file that you downloaded con-tains two LDIF files. You can use these files to extend your Active Directory schema and give values to the new attributes. This lets you illustrate how to use the “Optional Attributes” discussed previously. We leave it up to the instructor whether to do this; it is not necessary to use the optional attributes to complete the exer-cises. Additional instructor notes are pro-vided to help you illustrate these advanced concepts if you choose to use them. To use the LDIF files: (1) Use the file “wg-optional-AD-attributes.ldf” first to extend your Active Directory schema. The file has usage notes at the beginning. (2) Next, use the file “edit-sample-account.ldf” to give values to the new attributes for a user object in your Active Directory. This file also has usage notes at the beginning. This part of the exercises is optional. You should carefully consider whether you want to discuss extending the schema in more detail than we give in the training guide. Consider whether your Active Directory skills allow you to support your students when they have questions about it. It is beyond the scope of this training to explain how LDIF works, or to explain in any detail how to extend the Active Directory schema.

Necessary Equipment and ServicesYou need these things to do the exercises:

• Windows 2000 or 2003 Server This must be a domain controller for an Active Directory domain. The instructor should provide an Active Directory domain controller for the classroom domain. This server does the authentication for all students. The domain for the exercises is training.net.

• Management station computer (see the section below for configuration)• WSM version 9.0 software / Fireware Pro version 9.0 software

Your instructor provides this software, or you can download it from the WatchGuard web site with a valid LiveSecurity login.

• MUVPN Lite version 7.3 software Your instructor provides this software, or you can download it from the WatchGuard web site with a valid LiveSecurity login.

• Firebox X Core or Firebox X Peak• Feature Key

Your instructor will provide a feature key to turn on the features the Firebox needs to have for the exercises. You give the feature key near the end of the Quick Setup Wizard when you configure the Firebox.

• Ethernet Cables At a minimum, to do all the exercises you need:

- One crossover Ethernet cable to connect your computer to the trusted interface on your student Firebox.

- One straight-through Ethernet cable to connect the external interface from your Firebox to a hub or switch that connects all student Fireboxes to the central Firebox or Internet gateway.

Management Station Configuration• If your management station computer does not already have WSM version 9.0

software and Fireware Pro version 9.0 software installed, install this software. • For these exercises you do not need to install the Server Software components

of the WSM software. The Client Software part of WSM is sufficient.• Connect the management station computer directly to the trusted interface #1

on the Firebox with a crossover Ethernet cable. Make sure your management station has an IP address in the same subnet as the trusted interface with the correct subnet mask. Use the Firebox trusted interface IP address as the computer’s default gateway.

Firewall ConfigurationIf your Firebox is not yet configured, run the Quick Setup Wizard. Use the routed mode for the Quick Setup Wizard. Routed mode gives these defaults:• The external interface #0 is configured and enabled with a static IP address.

Your instructor will tell you what IP address to assign to the external interface.• The trusted interface #1 is configured and enabled with IP address 10.0.1.1/24.

Your instructor will tell you what IP address to use for the trusted interface and for your management station.


The exercises are designed so that all students can use the same IP address range for their trusted networks.

• None of the other interfaces are configured (they are all set to Disabled).• Policy Manager contains five policies: FTP, Ping, DNS, WatchGuard, and

Outgoing.

Physically Connecting your DevicesThe exercises are designed for a classroom environment. The external interfaces of all student Fireboxes should be connected to the same network segment that ter-minates at the instructor’s Firebox. Your management station computer should be connected directly to interface 1 on your Firebox.

Exercises

29

Exercises

Exercise 1: Allow authenticated users on the external network to manage the Firebox

1. When to use authentication for access to the Firebox There are many situations where you need to manage the Firebox from external locations. Forcing users to authenticate before they can manage the Firebox lets you track who accesses the Firebox using WSM tools.

You can easily extend this concept to restrict access to any resource protected by the Firebox.

2. Network topologyIn a typical installation, you connect the Active Directory server to a trusted or optional interface so that the Firebox can protect it from the external network. For these exercises, we place the server on the external network so that it is available to every Firebox in the class-room; only one Active Directory server is needed.

This exercise shows how to configure the Firebox to do Active Directory authenti-cation to a Windows server on the external network.

Figure 1 shows how your equipment is connected.

Figure 1: Network topology for Exercise 1


3. Configure the Active Directory serverYour instructor will give you the details of the classroom’s Active Directory domain. For this exercise, we use these details:

• The training.net domain contains an organizational unit called Accounts that is not inside any other container.

• A user account called student exists somewhere inside this organizational unit.

• The user is a member of an Active Directory group called Firebox Admins.

4. Configure the Firebox Specify an Active Directory Authentication Server

You can also select Setup > Authentication > Authentica-tion Servers from the Policy Manager menu.

1. From Policy Manager, click the Authentication Servers icon in the toolbar.

Figure 2: Authentication Servers icon

Note that the Active Directory server is on the external network. In a typical instal-lation the server would be on a trusted or optional network, protected by the Firebox.

2. Select the Active Directory tab and configure as shown.

Figure 3: Active Directory tab; configure as shown

- Select the Enable Active Directory server check box - In the IP Address box, type 50.50.50.2 - In the Search Base field, type OU=accounts,DC=training,DC=net - Keep all other fields set to the defaults

3. Click OK.

Add a group to the Authorized Users and Groups list1. Select Setup > Authentication > Authorized Users/Groups.

Exercises

31

The Authorized Users and Groups dialog box appears. Click Add.

Figure 4: Authorized Users and Groups dialog box

2. The Define New Authorized User or Group dialog box appears. Configure as shown.

Figure 5: Define the Active Directory group Firebox Admins

- In the Name field, type the name of the Active Directory group your instructor gives you. For this exercise we use Firebox Admins.

- Select the Group radio button. - From the Auth Server drop-down list, select Active Directory.

3. Click OK. The new group appears in the Authorized Users and Groups dialog box.

Figure 6: The new Active Directory Group shows in the list

4. Click OK to finish adding the group to the Authorized Users and Groups list.

Edit the WatchGuard policy to allow access by Active Directory group

1. From Policy Manager, double-click the WatchGuard policy to edit it.

Figure 7: Edit the WatchGuard policy


Do not remove the other aliases in this box. The Any-Trusted alias allows you to manage your Firebox from the trusted network.

2. In the From field, click Add.

Figure 8: Add to the From field

3. In the Add Address dialog box, click Add User.

Figure 9: Add User button

4. The Add Authorized Users or Groups dialog box appears. The new group you added is there. Double-click the group to add it.

Figure 10: Add Authorized Users or Groups has the new Active Directory group

Exercises

33

5. The group appears in the Selected Members and Addresses area. Click OK.

Figure 11: The new group is selected

6. The WatchGuard policy now looks like this. Click OK to finish editing the policy.

Figure 12: The finished WatchGuard policy


The automatically generated WatchGuard-Authentication policy allows TCP port 4100 connections to the Firebox only from trusted and optional networks. You must edit the policy to allow users on external networks to authenticate to the Firebox.

Notice that Policy Manager automatically added a new policy, the WatchGuard-Authentication policy. Policy Manager automatically adds this policy when you first add a user or group to a policy.

Figure 13: WatchGuard-Authentication policy is automatically added

7. Double-click the WatchGuard-Authentication policy to edit it. A warning box appears. Click Yes.

8. In the From field, click Add.

9. Double-click the Any-External alias to add it to the Selected Members and Addresses area.

10. Click OK.Note that even though this policy limits port 4100 connections To: Firebox, you can still get to external locations over port 4100 from trusted and optional net-works. The Outgoing policy in Policy Manager allows port 4100 connections to external locations.

The WatchGuard-Authentication policy looks like this now. It allows external users to connect to the Firebox over port 4100 for Firewall Authentication.

Figure 14: Finished editing the WatchGuard-Authentication policy

Exercises

35

11. Save this configuration to the Firebox. Select File > Save > To Firebox, or select the Save to Firebox icon in the toolbar:

Figure 15: Save to Firebox icon in the toolbar

5. Demonstrate it: Authenticate to your partner’s Firebox to manage it

To begin:

You will not make any changes to your partner’s Firebox in this exercise. You need the configuration password because you will make a configuration change to your partner’s Firebox in the next exercise.

• Tell your partner your Firebox external IP address, the status (read-only) password, and the configuration (read-write) password.

• Get the same information about your partner’s Firebox from your partner.

Try to connect to your partner’s Firebox without authenticating first

1. From WatchGuard System Manager, select File > Connect to Device.

2. Type the external IP address and status passphrase for your partner’s Firebox and click Login.You cannot connect because you did not authenticate first. You see an error message.

Figure 16: Unable to connect

Authenticate to your partner’s Firebox and try again to connect1. Use a browser to make an HTTPS connection to your partner’s Firebox over

port 4100. Type this IP address in your browser’s address bar:Replace the 100.100.100.30 address with the IP address of your partner’s Firebox!

https://100.100.100.10:4100 2. Your browser gives you a warning about the site:


Your browser gives this warning because the Fireware web server uses a self-signed certificate.

- Firefox gives you two messages. Click OK on both.

Figure 17: Firefox warnings

- Internet Explorer 6 gives this message. Click Yes.

Figure 18: IE 6 Security Alert

Exercises

37

- Internet Explorer 7 gives this message. Click Continue to this website.

Figure 19: IE 7 warning

3. Enter the user name and password your instructor gives you and click Login. For this exercise we use student.

If you extended the Active Directory schema to use a session timeout attribute, you can illustrate it by using a very short timeout. The user’s browser will give a message when the timeout occurs. The Firebox does not drop active connections when the timeout occurs, but new connections are not possible when the user is no longer authenticated.

4. From the Domain drop-down list, select Active Directory.

Figure 20: Firewall Authentication screen

When the authentication is successful you see this message.

Figure 21: Successful authentication


5. Try to connect to your partner’s Firebox again. Now you can connect.

Figure 22: Connected to your partner’s Firebox

If you supply a very short session time-out using the optional attributes, have the user disconnect from the Firebox. Show that the student can no longer connect after the timeout occurs.

Do not click the Logout button in the authentication web page. You must be able to connect to your partner’s Firebox in the next exercise.

Exercises

39

Exercise 2: Use Active Directory to authenticate MUVPN clients

This exercise assumes you completed Exercise 1. Do the previous exercise first.

In this exercise you make an MUVPN con-nect to your partner’s Firebox. This pre-sents a problem for the classroom setup: Because each student’s Firebox uses the same trusted network address range 10.0.1.0/24, the IP address on your com-puter is in the same subnet as your part-ner’s computer. You cannot test the MUVPN connection by attempting to pass traffic to an IP address in your own subnet. Because of basic IP routing, traf-fic that goes to an address in your own subnet stays in your own subnet; it does not route through the MUVPN tunnel. We resolve this problem by enabling Interface 2 on each classroom Firebox. The IP address on this interface is outside your own computer’s subnet. You test by connecting to interface 2 on your part-ner’s Firebox.

You should be connected to your partner’s Firebox with WatchGuard System Man-ager if you finished the previous exercise.

From WatchGuard System Manager, click the Policy Manager icon in the toolbar to bring up Policy Manager for your partner’s Firebox.

1. When to use Active Directory for MUVPN authenticationUse Active Directory to authenticate MUVPN connections when the remote users that you allow to connect with MUVPN are all in your Active Directory domain.

2. Network topologyYour equipment is connected exactly the same as for Exercise 1.

3. Configure the Firebox1. Use Policy Manager from your partner’s Firebox and select Network >

Configuration. The Network Configuration dialog box appears. Only Interfaces 0 and 1are configured (the other interfaces are disabled).

Figure 1: Beginning network configuration

2. Double-click Interface 2 to configure it.


3. From the Interface Type drop-down list, select Optional.

Figure 2: Set the interface type to Optional

It is not necessary to physically connect interface 2 to an Ethernet cable. You enable it so that you and your partner have an IP address outside your own trusted network to connect after you make the MUVPN connection to your partner’s Firebox. The Firebox will respond to pings and management con-nections on this interface when you enable it.

4. By default, this interface is called Optional-1 and the IP address is 10.0.2.1/24 Keep the default settings and click OK.

Figure 3: Interface 2 defaults

5. Click OK to return to the main part of Policy Manager.

You can also click the Remote Users icon in the Policy Manager toolbar.

6. Select VPN > Remote Users. The Remote User VPN Configuration dialog box appears.

Figure 4: Click to add a new MUVPN group

Exercises

41

7. Click Add. The Add Mobile User VPN Wizard appears.

Figure 5: The first page of the MUVPN Wizard

8. Click Next. Configure the next page of the wizard as shown.

Figure 6: Configure authentication server and group name

- From the Authentication Server drop-down list, select Active Directory.

- In the Group Name field, type the name of the Active Directory group that includes members you want to connect with MUVPN. For our example we use Firebox Admins.


Because all students will exchange this passphrase with a partner, we recom-mend everyone use the same simple passphrase, such as password. Note that this is not the password for any Active Directory user account. This pass-phrase serves two purposes: 1. WSM software uses the passphrase as a key to encrypt the client configuration file (the .wgx file). The user must provide this key to unlock and import the .wgx file. 2. IKE uses the passphrase as a key to encrypt Phase 1 negotiations.

9. Click Next. The Use this passphrase radio button is automatically selected. Keep this setting and type a passphrase that has at least eight characters. Type it again to confirm it.

Figure 7: Type a passphrase

10. Click Next. The top radio button No, allow internet traffic to go directly to the mobile user’s ISP is automatically selected. Keep this setting and click Next.

Figure 8: Keep the defaults on this page

On this page of the wizard, you specify the IP addresses of the network resources that the client can access through the MUVPN tunnel.

Exercises

43

11. Click Add. The Add Address dialog box appears. Configure as shown.

Figure 9: Click Add to specify allowed resources

This is the network IP address for both yours and your partner’s optional inter-face.

- From the Choose Type drop-down list, select Network IP. - In the Value field, type 10.0.2.0/24.

The 10.0.2.0/24 network appears in the white box.

Figure 10: The resource that the remote client can reach through the tunnel

12. Click Next. On the next page of the wizard, click Add to create a pool of virtual IP addresses.


13. The Add Address dialog box appears. Configure as shown.

Figure 11: Create the virtual IP address pool

- From the Choose Type drop-down list, select Network IP. - In the Value field, type 10.0.2.100. - In the To field, type 10.0.2.109.

14. Click OK. The address range appears in the box. Click Next.

Figure 12: The new virtual IP address pool

Exercises

45

15. Click Next. The last screen of the wizard congratulates you on your fine technical abilities and shows where to find the MUVPN configuration file (the .wgx file). Click Finish.

Figure 13: The MUVPN Wizard is finished

16. The new MUVPN group appears in the Remote User VPN Configuration dialog box. Click OK.

Figure 14: The new MUVPN group

17. Select the Mobile User VPN tab of Policy Manager to see the new Any policy.

Figure 15: The automatically generated Any policy


18. Double-click this policy to edit it. Select the Properties tab and click the Logging button.

Figure 16: Properties tab of the MUVPN policy

19. In the Logging and Notification dialog box, select the check box Send log message, then click OK.

Figure 17: Turn on logging for the policy

20. Click OK again to return to the main part of Policy Manager.

21. Save this configuration to the Firebox. Select File > Save > To Firebox, or select the Save to Firebox icon in the toolbar.

Figure 18: Save to Firebox icon in the toolbar

Exercises

47

22. You should still be authenticated to your partner’s Firebox. After the save operation is complete, go back to the browser and click the Logout button in the web authentication page to log out.

Figure 19: Log out from your partner’s Firebox

4. Install and configure the Mobile User VPN softwareYour instructor should provide this soft-ware to you.

1. Find the MUVPNLite73.exe software on your computer and double-click it to start the installation.

2. The Mobile User VPN Setup 7.3 dialog box appears. Click Next to start to install. Select the defaults at each step of the installation wizard.


3. Near the end of the install, you get a screen to select the MUVPN profile. Click Browse.

4. Browse to: C:\Documents and Settings\All Users\Shared

WatchGuard\muvpn\50.50.50.10\Firebox Admins\wgx

5. The Firebox Admins.wgx file shows in the wizard. Click Next.

Exercises

49

6. At the next screen, agree to restart your computer and click Finish. Your computer restarts.

7. When your computer is restarted, you see the WatchGuard Policy Import dialog box. Type the passphrase you used in Step 9 on page 42.

8. Once again you receive congratulations on your fine technical skills. Click OK.

5. Demonstrate it: Make an MUVPN connection to your partner’s Firebox

1. Right-click the MUVPN icon next to the clock in your system tray and select Activate Security Policy.

Figure 20: Activate the SafeNet Security Policy


The red slash through the MUVPN icon disappears.

Figure 21: Security Policy activated

The connection name for our example is 50.50.50.10-10.0.20.0 because the client connects to the Firebox at 50.50.50.10. The name of your connection depends on the external IP address of your part-ner’s Firebox. The first part of the connec-tion name is the external IP address of the Firebox to which you connect. . The second part of the connection name, 10.0.2.0, indicates the network you can access through the VPN tunnel.

2. Right-click the MUVPN icon again and select Connect > My Connections\50.50.50.10-10.0.2.0.

Figure 22: Start the VPN connection

3. The MUVPN User Authentication popup appears. Type the user name and password of the Active Directory user account your instructor provides. For this example we use the account called student.

Figure 23: Type the Active Directory user name and password

If you extended the schema for the classroom domain to use the optional attributes, tell the students to use the “ipconfig/all” command to see the MUVPN virtual IP address and DNS/WINS address assignments. Note that when the Firebox assigns vir-tual IP addresses from virtual IP address the pool, it pulls addresses in succes-sion, starting from the lowest number. If you use the optional attributes to have Active Directory assign the address, use an address in the middle of the pool to reinforce the fact that the assignment came from AD attributes and not directly from the Firebox pool of addresses.

4. The Manual Connection Status dialog box appears. After a few seconds the message changes to tell you that you successfully connected to your partner’s Firebox. Click OK.

Figure 24: Connection messages

5. To test the connection, open WatchGuard System Manager and connect to the optional interface of your partner’s Firebox.

Exercises

51

Do not use the external IP address of your partner’s Firebox. Connect to the optional interface IP address 10.0.2.1 so that the traffic goes through the MUVPN tunnel.

Figure 25: Connected to the optional interface of your partner’s Firebox

6. Click the Firebox System Manager (FSM) icon in the WSM toolbar.

7. On the Front Panel tab of FSM, expand Interfaces.

8. Verify that you connected to your partner’s Firebox (not to your own Firebox optional interface) by looking at the external interface IP address. It should be the IP address for your partner’s Firebox.

9. Expand Mobile User VPN Tunnels and see your MUVPN connection statistics.

10. Bring up a command prompt and ping the 10.0.2.1 IP address on the optional interface of your partner’s Firebox.

11. Watch Traffic Monitor for your partner’s Firebox to verify that the ping goes through the VPN tunnel. You should see a message like this:Allow 10.0.2.105 10.0.2.1 icmp-Echo Firebox Admins/IPsec Firebox allowed (decrypted packet, SA info: id 0x086632d8) 60 128 (Firebox Admins-Any.in-00) src_user="student@Active Directory"

For the WSM and FSM traffic you should see messages like this:Allow 10.0.2.105 10.0.2.1 WG-Management/tcp 2321 4117 Firebox Admins/IPsec Firebox allowed (decrypted packet, SA info: id 0x086632d8), mss not exceeding 1376, idle timeout=43205 sec 48 128 (Firebox Admins-Any.in-00) tcpinfo="offset 7 S 2628964518

win 16384" src_user="student@Active Directory"


Frequently Asked Questions

Why can’t I use the Domain Users group in my policies?Microsoft decided not to add the user’s Primary Group as a value to the user’s “memberOf” attribute because of the nature of the group object. A group object has an attribute called “member”. It is a multi-valued attribute that has one value for each user or group that is a member of the group. If one group listed every user in the domain as a member, then replication of that group object’s list of attributes to another directory server in the forest could take a very long time. The limit for the number of values a multi-valued attribute can take is 5,000. In a domain with more than 5,000 users, the list of values for the primary group object’s “member” attribute would be larger than allowed if it listed every user in the domain.

By default, when you add a new user to the domain, Active Directory makes the user a member of the Domain Users group. Active Directory also makes this group the user’s Primary Group. You rarely encounter the Primary Group concept; it is used for POSIX compliance.

By design, Active Directory does not add a value to the user’s memberOf attribute for the user’s Primary Group. Because of this, no LDAP query will find “Domain Users” as a value for the memberOf attribute, unless you change a user’s Primary Group. Microsoft does not recommend changing the user’s Primary Group ID except when you have Macintosh clients or POSIX-compliant applications.

If you find that Active Directory does not return a memberOf attribute for a certain group that you are sure a user is a member of, check to see if the user’s Primary Group has been set to that group. The Primary Group is set on the Member Of tab of a user’s account when you edit it in Active Directory Users and Computers.

Why doesn’t Fireware see the user as a member of a Universal Group X?

When Active Directory replicates objects across the forest, it replicates only partial lists of some objects’ attributes. In a domain that is not the domain where the uni-versal group was created, a user’s universal group membership shows only on a Global Catalog server. However, a user’s universal group membership information is always present in the primary domain controller in the user’s home domain.

To summarize, if these things are true, then the search results for that user will not show universal group membership for that universal group:

• Your domain is part of a multi-domain forest.• The user is a member of a universal group that was created in a domain that is

not the user’s home domain.• You specify an Active Directory server in Policy Manager that is neither the

primary domain controller for the user’s home domain nor a global catalog server.

If you want to use universal groups in this situation, you have two options:

1. If it is possible, when you specify the Active Directory server in Policy Manager, use the primary domain controller in the home domain of all the users that authenticate to your Firebox.

2. If #1 is not possible, then configure Policy Manager to use a Global Catalog (GC) server. Specify the IP address for the GC server in the Active Directory setup area of Policy Manager, and change the port from 389 to 3268, the port used for GC queries.

Is it necessary to allow connections from external locations to the Firebox over TCP port 4100 for MUVPN to work?

IKE is the Internet Key Exchange protocol. No. IPSec VPNs use IKE ports (UDP port 500 and possibly UDP port 4500, if NAT-Tra-versal is used) for tunnel construction. The Firebox automatically allows connec-tions over IKE ports from external locations when you add MUVPN; you do not have to add a service to allow this traffic.

This is different from what happens when users do Firewall Authentication. Firewall authenticated users connect to the Fireware web server over TCP port 4100. Although the Firebox listens for connections on port 4100, the Firebox does not

Frequently Asked Questions

53

allow port 4100 traffic to get to its interfaces unless a policy specifically allows it. Policy Manager automatically adds a policy to allow these connections from trusted and optional networks when you add a user or group to a policy so that users on those networks can authenticate to the Firebox.

However, port 4100 is never exposed by default on the Firebox external interface. You must edit the automatically generated Firebox-Authentication policy to allow connections to the Firebox over port 4100 from external networks.

What happens if the user closes the browser after the user is authenticated?

After a user successfully authenticates using Firewall Authentication, it is not nec-essary to keep the browser open to stay authenticated. However, eventually the session timeout or the idle timeout will cause the Firebox to remove the user from the list of authenticated users. If your Active Directory server does not return the optional attributes discussed in “Optional data that Active Directory can give Fireware” on page 24, select Setup > Global Settings in Policy Manager to set these values.

The user does not have a way to check authentication status when the browser that authenticated the user is closed. The user can visit the Firewall Authentication page again to check the status. If the user is currently authenticated, the page will say “You have been successfully authenticated”. If not, the page will prompt the user for user name and password.

Can I use Active Directory to authenticate PPTP sessions?No. The Firebox can authenticate PPTP sessions only with its internal database of Firebox Users or a RADIUS server.

What account should I use for the Searching User?By default, any user in an Active Directory domain has read access to the directory. You can create a user account with limited privileges for the searching user.

Users in the Administrators group on a directory server get answers to their Active Directory queries faster than normal users, but the difference should not be notice-able except on a directory server with an extremely heavy traffic load. It is not rec-ommended to use an account with administrator-level privileges.

Is the Users object a container or a group?There is one of each:

• The Users folder in Active Directory Users and Computers is a container. • Active Directory also has a group called Users in the Builtin container.A user account you add in the Users container is not automatically a member of the Users group.

Why does a user lose the ability to authenticate to the Firebox when I set “Log On To” machine restrictions for the user account?

When you edit a user account in Active Directory Users and Computers, you can restrict which domain computers the user can log on to locally using the Log On To button on the Account tab. If you set this restriction on the user account, LDAP Bind requests with the user’s credentials no longer succeed, even if the Bind request comes from the listed machine. You can resolve this by adding the Active Directory server’s netBIOS name to the list of computers in the Log On To area of the user account. This does not give local logon privileges to the user on the DC; normal users are not allowed to log on to a domain controller.


TRAINING: www.watchguard.com/[email protected]

COPYRIGHT © 2007 WatchGuard Technologies, Inc. All rights reserved.WatchGuard, the WatchGuard logo, Firebox, and Core are registered trademarks or trademarks of WatchGuard Tech-nologies, Inc. in the United States and/or other countries.

What You Have Learned

• You learned how Fireware authenticates users against an Active Directory server.

• You learned how Fireware authorizes traffic from users.• You learned how Active Directory uses LDAP.• You learned how to set up the Firebox to do Active Directory authentication to

allow users to access Firebox management ports from the external network.• You learned how to configure Active Directory authentication for a Mobile User

VPN group.