Conditions
It is possible to define if/then/else logic in the Windows policy to only launch a check if preconditions are valid or to group multiple tests in one.
The syntax to perform conditions is the following:
<if>
<condition type: "or">
<Insert your audit here>
</condition>
<then>
<Insert your audit here>
</then>
<else>
<Insert your audit here>
</else>
</if>
Conditions can be of type “and” or “or”.
The audit for the conditions above uses “then” and “else” statements, which can be a list of items (or custom items), or an “if” statement. The “else” and “then” statements can optionally make use of the “report” type to report a success or a failure depending on the condition return value:
<report type:"PASSED|FAILED">
description: "the test passed (or failed)"
(optional) severity: INFO|MEDIUM|HIGH
</report>
An “if” value returns SUCCESS or FAILURE and this value is used when the “if” statement is inside another “if” structure. For example, if the <then> structure is executed, the return value will be one of the following:
- audit contains only items: return SUCCESS if all items passed else return FAILURE
- audit contains only
<report>: return the report type - audit contains both items and
<report>: return the report type
If the <report> statement is used and the type is “FAILED” then the reason why it failed will be displayed in the report along with a severity level if defined.
Following is an example that audits the password policy. Since the “and” type is used, for this policy to pass the audit both custom items would need to pass. This example tests for a very odd combination of valid password history policies to illustrate how sophisticated test logic can be implemented:
<if>
<condition type:"and">
<custom_item>
type: PASSWORD_POLICY
description: "2.2.2.5 Password History: 24 passwords remembered"
value_type: POLICY_DWORD
value_data: [22..MAX] || 20
password_policy: ENFORCE_PASSWORD_HISTORY
</custom_item>
<custom_item>
type: PASSWORD_POLICY
description: "2.2.2.5 Password History: 24 passwords remembered"
value_type: POLICY_DWORD
value_data: 18 || [4..24]
password_policy: ENFORCE_PASSWORD_HISTORY
</custom_item>
</condition>
<then>
<report type:"PASSED">
description: "Password policy passed"
</report>
</then>
<else>
<report type:"FAILED">
description: "Password policy failed"
</report>
</else>
</if>
In the above example, only the new “report” type was shown, but the if/then/else structure supports performing additional audits within the “else” clauses. Within a condition, nested if/then/else clauses can also be used. A more complex example is shown below:
<if>
<condition type:"and">
<custom_item>
type: CHECK_ACCOUNT
description: "Accounts: Rename Administrator account"
value_type: POLICY_TEXT
value_data: "Administrator"
account_type: ADMINISTRATOR_ACCOUNT
check_type: CHECK_NOT_EQUAL
</custom_item>
</condition>
<then>
<report type:"PASSED">
description: "Administrator account policy passed"
</report>
</then>
<else>
<if>
<condition type:"or">
<item>
name: "Minimum password age"
value: [1..30]
</item>
<custom_item>
type: PASSWORD_POLICY
description: "Password Policy setting"
value_type: POLICY_SET
value_data: "Enabled"
password_policy: COMPLEXITY_REQUIREMENTS
</custom_item>
</condition>
<then>
<report type:"PASSED">
description: "Administrator account policy passed"
</report>
</then>
<else>
<report type:"FAILED">
description: "Administrator account policy failed"
</report>
</else>
</if>
</else>
</if>
In this example, if the Administrator account has not been renamed, then audit that the minimum password age is 30 days or less. This audit policy would pass if the administrator account has been renamed regardless of the password policy and would only test the password age policy if the administrator account had not been renamed.