Applies To:

Show Versions Show Versions

Manual Chapter: FirePass® Controller version 5.5 Administrator Guide: How-To Examples
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>


A

How-To Examples


Introducing how-to scenarios

The how-to scenarios covered in this chapter are based on real-world use. You can find a description of the how-to scenario at the beginning of each section.

Each scenario covers one step-by-step operation, and each one can stand on its own (that is, the scenarios do not build on each other), so you can start anywhere.

Note

Although each section can stand alone, the more complex scenarios might require existing knowledge. In that case, the content points you to appropriate sections in the FirePass Controller Administration Guide or pages in the FirePass controller online help.

You can check your progress against screenshots provided at a number of steps. The intention is to keep you on track without overburdening you with screenshots.

When you complete the steps, you will have a working version of the functionality the scenario covers. All information you need to deploy the working model is provided, including any hints, best practices, requirements, or warnings.

Denying access to users running Google Desktop Search

This how-to scenario describes, step-by-step, creating a pre-logon sequence to manage inbound access to the FirePass controller. This is a relatively simple pre-logon sequence. For steps on creating a more complex pre-logon sequence, see Denying and allowing logons from specific operating systems and requiring certificates.

Google Desktop Search lets users search documents, spreadsheets, email, instant messages, and web pages that have been visited by that PC. To enable this, the software creates cached versions of the content. Depending on the rights of the user accessing the information, this can include corporate information stored on servers accessed using a web browser.

Although Google Desktop Search is not intended to be used in a shared-computer environment, the software may be running on publicly available computers. This scenario describes how to create a pre-logon sequence that blocks logons from computers running the Google Desktop Search engine.

Creating the Google Desktop Check pre-logon sequence

A sequence is a set of actions and rules that act in concert to collect information about the end-user's system before granting or denying access to the FirePass controller. Inspectors activated in the sequence perform the functionality of gathering the information when a user attempts to logon. You can read more about sequences and inspectors in Creating a pre-logon sequence, on page 3-10.

In this example, we create a pre-logon sequence called Google Desktop Check that tests for the presence of the Google Desktop Search software prevents logon from any computer running Google Desktop Search.

To create a new sequence

  1. Log on to the FirePass controller using an administrative account.
  2. In the navigation pane, click Users, expand Endpoint Security, and then click Pre-Logon Sequence.
    The Pre-Logon Sequence screen opens, as shown in Figure A.1 .


  3. Figure A.1 FirePass controller Pre-Logon Sequence screen
  4. In the New Sequence section in the Create new sequence box, type Google Desktop Check.
  5. From the box titled Based on, choose template: Empty.
    The screen should look similar to Figure A.2.


  6. Figure A.2 Creating the Google Desktop Search sequence
  7. Click Create.
  8. Under Select Sequence to Use, click the edit link for Google Desktop Check.
    The visual policy editor opens, as shown in Figure A.3.


Figure A.3 The visual policy editor, for creating pre-logon sequences

Adding the Google Desktop Check action to the pre-logon sequence

Now that the pre-logon sequence exists, it needs an action to check for and act on Google Desktop Search.

Figure A.4 Cursor positioned on the connecting line, with add action icon active

To check for the presence of Google Desktop Search

  1. On the screen containing the Google Desktop Check sequence you created, position the cursor on the connecting line between Sequence Start and Logon Allowed Page.
    A small plus icon appears, as shown in Figure A.4.
  2. Click the add action icon .
  3. The CHANGE SEQUENCE panel opens in the visual policy editor.
  4. Under Predefined actions, select Check for Google Desktop.
  5. Click the Apply changes button at the bottom of the panel.
    The visual policy editor adds Check for Google Desktop to the sequence, as shown in Figure A.5.


Figure A.5 The visual policy editor after adding the Check for Google Desktop action.

The Check for Google Desktop action contains a predefined rule that, by default, prevents access to users running Google Desktop Search. The rule uses the value returned from the check operation to determine access. To open the rule, click the link named Click here to show rules. The Edit rules area opens, as shown in Figure A.6.

Figure A.6 The visual policy editor with the Edit rules section open

In this case, the rule uses the value in session.google_desktop_check.result != 1 to prevent access to users running Google Desktop Search.

Tip


You can force Google Desktop Search to close but still allow logon by changing the end page to Logon Allowed Page.

You can click the I icon next to Checks for presence of Google Desktop Search product under Inspectors in the Edit Action panel to open the details page, as shown in Figure A.7.

Figure A.7 The Google Desktop Search inspector details page

Informing users of the reason that they are prevented from logging on helps them correct the condition and try logging on again. The next step guides you through the process of creating a logon-denied message.

Customizing the Google Desktop Check logon-denied message

In this step, we create a message to present to users who are denied access because they have Google Desktop Search running.

To create a logon-denied message

  1. Click the Logon Denied Page box.
    The END PAGE PROPERTIES panel opens in the visual policy editor, as shown in Figure A.8.
  2. Figure A.8 The End Page Properties panel open in the visual policy editor
  3. Into the Message for failed logons box, type the following text for the message:
  4. The FirePass controller cannot log you on because you have Google Desktop Search running. Halt the software and try logging on again.
  5. Click the Update button.
  6. In the upper right corner, click the Back to console link to return to the Pre-Logon Sequence Page.
  7. Under Select Sequence to Use, select Google Desktop Check and click the Apply button, as shown in Figure A.9.
Figure A.9 Pre-Logon Sequence screen with Google Desktop Check selected and applied

You have created a pre-logon sequence that checks for and prevents logon by users running Google Desktop Search. As long as you keep the Google Desktop Check pre-logon sequence selected, users who are running Google Desktop Search cannot log on to the associated FirePass controller.

Note

You can modify any pre-logon sequence to contain different functionality. If you do, you should also change the sequence name to reflect any changes you make. You can change the name by selecting the sequence from the Rename sequence box, typing the new name, and clicking the Rename button.

Denying and allowing logons from specific operating systems and requiring certificates

This how-to scenario describes, step-by-step, creating a pre-logon sequence to manage inbound access to the FirePass controller. This is a relatively complex pre-logon sequence, For steps on creating a simpler pre-logon sequence, see Denying access to users running Google Desktop Search.

The pre-logon sequence created meets the following requirements:

  • Denies logon from Windows 95, Windows 98, and Windows Me connections.
  • Requires Windows NT and Windows 2000 users to log on using the virtual keyboard.
  • Allows connection only from Windows XP, Linux, Pocket PC, and Macintosh systems that have a valid client certificate.

Rule 1 - Deny Windows 95, Windows 98, and Windows Me connections

For the purpose of this how-to scenario, we create a pre-logon sequence that tests for the client's operating system and prevents logon from computers running Windows 95, Windows 98, and Windows Me. We also create a logon-denied message to inform users of the cause of the denial of logon.

Creating the Corporate Access Check pre-logon sequence

In this example we create a pre-logon sequence called Corporate Access Check that prevents logon from any computer running Windows 95, Windows 98, or Windows Me.

To create a new sequence

  1. Log on to the FirePass controller using an administrative account.
  2. In the left navigation pane, click Users, expand Endpoint Security, and then click Pre-Logon Sequence.
    The Pre-Logon Sequence screen opens, as shown in Figure A.10.
  3. Figure A.10 FirePass controller Pre-Logon Sequence screen
  4. Under the New Sequence section, in the Create new sequence box, type Corporate Access Check.
  5. From the box titled Based on, choose template : Empty.
  6. Click Create.
  7. Under Select Sequence to Use, click the edit link for Corporate Access Check.
    The visual policy editor opens, as shown in Figure A.11.
Figure A.11 The visual policy editor, for creating pre-logon sequences

Adding the Check OS action to the pre-logon sequence

Now that the pre-logon sequence exists, it needs an action to check for the operating systems of clients logging on.

Figure A.12 Cursor positioned on the connecting line, with add action icon active

To check the client operating system

  1. On the screen containing the Corporate Access Check sequence you created, position the cursor on the connecting line between Sequence Start and Logon Allowed Page.
    A small plus icon appears, as shown in Figure A.12.
  2. Click the add action icon .
  3. The CHANGE SEQUENCE panel opens in the visual policy editor.
  4. Under Predefined actions, select Check OS.
  5. Click the Apply changes button at the bottom of the panel.
    The visual policy editor adds Check OS to the sequence, as shown in Figure A.13.
Figure A.13 The visual policy editor after adding the Check OS action

The default Check OS action denies access to users logging on using the associated operating systems.

Informing users of the reason that they are prevented logon helps them correct the condition and try logging on again. The next step guides you through the process of creating a logon-denied message.

Customizing the Windows 9.x logon-denied message

In this step, we create a message to present to Windows 95, Windows 98, and Windows Me users who are denied logon access.

To create a logon-denied message

  1. Click the Logon Denied Page box to the right of Windows 9x family.
    The END PAGE PROPERTIES panel opens in the visual policy editor.
  2. Into the Message for failed logons box, type the following text for the message:
  3. This FirePass controller does not support client computers running Windows 98, Windows 95, or Windows Me. Supported client operating systems include Windows 2000, Windows NT, Windows XP, and Windows 2003. Contact the help desk for more information.
  4. Click the Update button.
    The visual policy editor should now appear similar to the screen shown in Figure A.14.
Figure A.14 The END PAGE PROPERTIES panel with the logon-denied message for Windows 9.x users

Rule 2 - Require Windows NT and Windows 2000 clients to log on using the virtual keyboard

Next we modify the Windows NT Based action so that it requires Windows NT and Windows 2000 clients to logon using the virtual keyboard.

The virtual keyboard is a floating keyboard that requires mouse clicks to enter a password. After each click, the virtual keyboard repositions itself on the screen. Use of the virtual keyboard aids in preventing unauthorized recording of logon information by key loggers and other software.

Changing the Windows NT based action

Because the rule we are creating should apply only to clients logging on using Windows NT and Windows 2000, the first step is to change the Windows NT Based action to remove the occurrence of Windows XP.

To modify the Windows NT based action

  1. Click Windows NT based link in the Corporate Access Check sequence.
    The UPDATE RULE panel opens in the visual policy editor, as shown in Figure A.15.
  2. Figure A.15 The UPDATE RULE panel for the Windows NT Based action
  3. Delete the session.os.platform == "WinXP" OR condition.
  4. In Name, type Windows NT and 2000.
  5. Click Update.

You can find a complete set of the session variables generated by inspectors for action rule expressions in the online help for Users : Endpoint Security : Pre-Logon Sequence.

Adding the Show Virtual Keyboard action

Now we add the action to require use of the virtual keyboard for Windows NT and 2000 connections.

To add the Show Virtual Keyboard action

  1. On the sequence containing the Corporate Access Check sequence you created, position the cursor on the connecting line between Windows NT Based and Logon Allowed Page.
    A small plus icon appears, as shown in Figure A.16.


  2. Figure A.16 Cursor positioned on the connecting line, with add action icon active.
  3. Click the add action icon .
  4. The CHANGE SEQUENCE panel opens in the visual policy editor.
  5. Under Predefined actions, select Show Virtual Keyboard.
  6. Click the Apply changes button at the bottom of the panel.
    The visual policy editor adds Show Virtual Keyboard to the sequence, as shown in Figure A.17.
Figure A.17 The visual policy editor after adding the Show Virtual Keyboard action

Now, any users who are running Windows NT or Windows 2000 must use the virtual keyboard to enter their password when they log on to the FirePass controller.

Rule 3 - Allow logons only from Windows XP, Linux, Pocket PC, and Macintosh computers that have a valid certificate.

Next, we want to allow logon only when the connecting client operating system is of a certain type and that has a specified client certificate. To accomplish that, we use the subsequence feature in the visual policy editor.

Creating a subsequence for Corporate Access Check

For this rule, we create a subsequence that maps several conditions in the Check OS action. Subsequences are sequences that perform self-contained actions. You can use subsequences to refine what actions occur in response to certain conditions.

To create a subsequence for Corporate Access Check

  1. Click the Open subsequences management link in the Subsequences area of the screen.
    The SUBSEQUENCES panel opens in the visual policy editor, as shown in Figure A.18.
  2. Figure A.18 The visual policy editor with the SUBSEQUENCES panel open
  3. In the box under Add new subsequence in the SUBSEQUENCES panel, type Certificate Check to name the subsequence.
  4. Click the Add subsequence button.
    The Subsequence:certificate check appears in the visual policy editor, as shown in Figure A.19.
Figure A.19 The visual policy editor after adding the certificate check subsequence

Adding the Client certificate check action

Next, we add the Client certificate check action to the certificate check subsequence. The Client certificate check gathers information about certificates on client computers and compares that information with the configuration that you specify in the rule.

Note

You must configure and enable client certificate checking before the FirePass controller can request and check users' client certificates. For more information, see Setting up client-certificate-based authentication, on page 2-42.

To add the Client certificate check action

  1. On the certificate check subsequence you created, position the cursor on the connecting line between Subsequence:certificate check and Logon Denied Page.
    A small plus icon appears, as shown in Figure A.20.
  2. Figure A.20 Cursor positioned on the connecting line, with add action icon active
  3. Click the add action icon .
  4. The CHANGE SEQUENCE panel opens in the visual policy editor.
  5. Under Predefined actions select Check client certificate.
  6. Click the Apply changes button at the bottom of the panel.
    The visual policy editor adds Check client certificate to the subsequence, as shown in Figure A.21.
Figure A.21 The visual policy after adding the Check client certificate action to the subsequence

Changing the end page for the subsequence

To complete the certificate check subsequence, we change the final action to allow logons when the client computer has a valid certificate. In this case, we change Logon Denied Page to Logon Allowed Page.

To change the subsequence's final action

  1. Click the top Logon Denied Page box for the certificate check subsequence.
    The END PAGE PROPERTIES panel opens in the visual policy editor.
  2. In the Type box in the END PAGE PROPERTIES panel, select Logon Allowed Page.
  3. Click the Update button.
    The end page changes to Logon Allowed Page, as shown in Figure A.22.
Figure A.22 The subsequence after changing the final action to Logon Allowed Page.

Informing users of the reason that they are prevented from logging on helps them correct the condition and try logging on again. The next step guides you through the process of creating a logon-denied message.

Customizing the logon-denied message for the subsequence

In this step, we create a message to present to Windows XP, Linux, Pocket PC, and Macintosh users who are denied logon access because they lack a client certificate.

To create a logon-denied message

  1. Click the Logon Denied Page box to the right of the fallback rule in the subsequence.
    The UPDATE RULE panel opens in the visual policy editor.
  2. Into the Message for failed logons box, type the following text for the message:
  3. The FirePass controller cannot log you on because you do not have a valid client certificate. Contact the help desk to get a valid client certificate, and try to logon again.
  4. Click the Update button:
    The visual policy editor should now appear similar to the screen shown in Figure A.23.
Figure A.23 The END PAGE PROPERTIES panel with the logon-denied message for users without valid certificates

Adding a Windows XP rule to the sequence

In this step, we create a Windows XP-related rule and map the Windows XP, Pocket PC, and Mac OS rules to the Certificate Check subsequence.

To create the Windows XP-related rule

  1. On the sequence, position the cursor on the connecting line between Windows 9x family and Linux.
    A small plus icon appears, as shown in Figure A.24.
  2. Figure A.24 Cursor positioned on the connecting line, with add rule icon active
  3. Click the add rule icon .
  4. The INSERT RULE panel opens in the visual policy editor.
  5. In Name, type Windows XP.
  6. In the box under Name, type session.os.platform == "WinXP".
  7. Click the Insert Rule button.
    The visual policy editor should now appear similar to the screen shown in Figure A.25.

You can find a complete set of the session variables generated by inspectors for action rule expressions in the online help for Users : Endpoint Security : Pre-Logon Sequence.

Figure A.25 The sequence after adding the Windows XP file.

Next, we map the Windows XP, Pocket PC, and Mac OS rules to the Certificate Check subsequence.

To map the Windows XP rule to the subsequence

  1. On the sequence, position the cursor on the connecting line between Windows XP and Logon Denied Page.
    A small plus icon appears, as shown in Figure A.26.
  2. Figure A.26 Cursor positioned on the connecting line, with add action icon active
  3. Click the add action icon .
  4. The CHANGE SEQUENCE panel opens in the visual policy editor.
  5. In the CHANGE SEQUENCE panel in the Change sequence box, select Replace action (deletes branch after).
    Options in CHANGE SEQUENCE update to include a Subsequences section.
  6. In Subsequences, select Subsequence: certificate check.
  7. Click the Apply changes button at the bottom of the panel.
  8. The visual policy editor adds Check client certificate to the subsequence, as shown in Figure A.27.

    Figure A.27 The sequence after adding Check client certificate.
  9. Repeat the steps in this procedure to map Linux, Pocket PC, and Mac OS to the subsequence.
  10. The final Corporate Access Check pre-logon sequence screen should appear similar to Figure A.28.

Figure A.28 The final visual policy editor for the Corporate Access Check pre-logon sequence

Activating the Corporate Access Check pre-logon sequence

In this step, we activate the pre-logon sequence we just created.

To activate the pre-logon sequence

  1. From the visual policy editor, click the Back to console link in the upper right of the screen.
    The Pre-Logon Sequence screen opens.
  2. Under Select Sequence to Use, select Corporate Access Check and click the Apply button, as shown in Figure A.29.
Figure A.29 The Pre-Logon Sequence screen with Corporate Access Check selected and applied

You have now completed creating a pre-logon sequence that checks for and prevents logon by users running Windows 95, Windows 98, and Windows Me, requires virtual keyboard for logon from Windows NT- and Windows 2000-based clients, and requires a valid certificate for logon from Windows XP, Linux, Pocket PC and Macintosh computers.

Tip


You can modify any pre-logon sequence to contain different functionality. If you do, you should also change the sequence name to reflect any changes you make. You can change the name by selecting the sequence from the Rename sequence box, typing the new name, and clicking the Rename button.



Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)