The System Policy typically contains one or more rules. Place the rules in the order you want them applied. If you have one general rule and also an exception to that rule, place the exception before the general rule; otherwise, the specific rule is never applied.
It is critical that you order rules appropriately to ensure they behave as expected. The following example shows what might happen if the rules are not in the correct order.
Suppose you have created a destination workgroup for the finance managers at your company. You need to send sensitive information to the managers, so you have created a rule with high security settings. You decide that if one of the finance managers does not meet the security action settings, you do not want to transmit information. You also have the Default Rule with security settings to use when communicating with everyone on the LAN. However, if the settings fail to be negotiated, you will still allow the communication to take place without security. The rules you have created appear in the table below.
|
Rule Name |
Destination Workgroup |
Security Action |
If rule fails |
|---|---|---|---|
|
To Finance Management |
Finance Managers |
3DES+SHA1+None |
Deny Communication |
|
Default Rule |
Everybody |
Default Action |
Allow Communication without Security |
The rule ordering above requires the Finance Managers workgroup to have a rule listing your system and the 3DES+SHA1+None security action in order to negotiate secure communication. If the Finance Managers workgroup does not have a matching rule, communication will be denied.
Notice the importance of rule order. If the Default Rule was ordered before the To Finance Management rule, communication with Finance Manager's workstations would be allowed "in the clear" (with no security) even if the Finance Managers workgroup does not have a matching rule for communication with R&D using the 3DES+SHA1+None algorithms. In this case, the general rule would be applied first, and the specific rule would never be applied.
For information about security algorithms and about their notation, see About algorithm notation.
Copyright © 2000, Intel Corporation. All rights reserved.
Intel Corporation assumes no responsibility for errors or omissions in this document. Nor does Intel make any commitment to update the information contained herein.
* Other product and corporate names may be trademarks of other companies and are used only for explanation and to the owners' benefit, without intent to infringe.