Applies To:

Show Versions Show Versions

Manual Chapter: How-To Examples
Manual Chapter
Table of Contents   |   << Previous Chapter

The how-to scenarios covered in this appendix 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 either the appropriate sections in this 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.
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.
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 log on. You can read more about sequences and inspectors in Creating pre-logon sequences to protect resources.
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.
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.
In the New Sequence section in the Create new sequence box, type Google Desktop Check.
4.
From the Based on list, select template: Empty.
The screen should look similar to Figure A.2.
5.
Click Create.
6.
Under Select Sequence to Use, click the edit link for Google Desktop Check.
The visual policy editor opens, as shown in Figure A.3.
Now that the pre-logon sequence exists, it needs an action to check for and act on Google Desktop Search. Before you can add an action, you must make the Add Action button visible. To make the Add Action button visible, you position the cursor along the connecting line of the sequence elements. Figure A.4 shows the cursor positioned so that the Add Action button is visible.
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.
The Add Action button appears, as shown in Figure A.4.
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.
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.
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 Inspector Details button 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.
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.
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.
Into the Message for failed logons box, type the following text for the message:
The FirePass controller cannot log you on because you have Google Desktop Search running. Halt the software and try logging on again.
3.
Click the Update button.
4.
In the upper right corner, click the Back to console link to return to the Pre-Logon Sequence Page.
5.
Under Select Sequence to Use, select Google Desktop Check and click the Apply button, as shown in Figure A.9.
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.
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.
Allows connection only from Windows XP, Linux, Pocket PC, and Macintosh systems that have a valid client certificate.
For the purpose of this how-to scenario, we create a pre-logon sequence that tests for the clients 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.
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.
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.
Under the New Sequence section, in the Create new sequence box, type Corporate Access Check.
4.
From the Based on list, select template : Empty.
5.
Click Create.
6.
Under Select Sequence to Use, click the edit link for Corporate Access Check.
The visual policy editor opens, as shown in Figure A.11.
Now that the pre-logon sequence exists, it needs an action to check for the operating systems of clients logging on. Before you can add an action, you must make the Add Action button visible. To make the Add Action button visible, you position the cursor along the connecting line of the sequence elements. Figure A.12 shows the cursor positioned so that the Add Action button is visible.
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.
The Add Action button appears, as shown in Figure A.12.
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.
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.
In this step, we create a message to present to Windows 95, Windows 98, and Windows Me users who are denied logon access.
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:
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.
3.
Click the Update button.
The visual policy editor should now appear similar to the screen shown in Figure A.14.
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.
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.
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.
Delete the session.os.platform == "WinXP" OR condition.
3.
In Name, type Windows NT and 2000.
4.
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.
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.
The Add Action button appears, as shown in Figure A.16.
4.
Under Predefined actions, select Show Virtual Keyboard.
5.
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.
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.
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.
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.
In the box under Add new subsequence in the SUBSEQUENCES panel, type Certificate Check to name the subsequence.
3.
Click the Add subsequence button.
The Subsequence:certificate check appears in the visual policy editor, as shown in Figure A.19.
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.
1.
On the certificate check subsequence you created, position the cursor on the connecting line between Subsequence:certificate check and Logon Denied Page.
The Add Action button appears, as shown in Figure A.20.
4.
Under Predefined actions select Check client certificate.
5.
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.
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.
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.
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.
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.
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.
Click the Update button:
The visual policy editor should now appear similar to the screen shown in Figure A.23.
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. Before you can add a rule, you must make the Add Rule button visible. To make the Add Rule button visible, you position the cursor along the connecting line of the sequence elements. Figure A.12 shows the cursor positioned so that the Add Action button is visible.
1.
On the sequence, position the cursor on the connecting line between Windows 9x family and Linux.
The Add Rule button appears, as shown in Figure A.24.
4.
In Name, type Windows XP.
5.
In the box under Name, type session.os.platform == "WinXP".
6.
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.
1.
On the sequence, position the cursor on the connecting line between Windows XP and Logon Denied Page.
The Add Action button appears, as shown in Figure A.26.
4.
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.
5.
In Subsequences, select Subsequence: certificate check.
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.27.
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.
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

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)