Defining conditions
Discovered objects are compared against import rule conditions to determine which systems or accounts satisfy the import rule.
These comparisons use:
Simple attribute matching that return either true or false
PSLang expressions that return either true or false
Discovered computer attributes and account attributes can be used in the expressions.
A plugin copied into the plugin directory
On the Import rules page, you determine whether discovered objects:
Must Match all conditions to satisfy the import rule.
Or,
Can Match any condition to satisfy the import rule.
Setting the order of conditions
If an import rule has more than one conditions defined, then you can configure the order in which conditions are compared against objects. The conditions are compared in descending order.
To move a condition up or down the list, use the arrows
in the Order column.
Using threshold attributes
"PastThreshold" attributes should be used for import rule comparisons over the similar "Days" counterparts for performance purposes; for example CompNotDiscoveredPastThreshold (0/1 comparison) should be used instead of CompNotDiscoveredDays (a regularly changing number) to avoid the import rule re-checks.
Defining conditions based on attributes
To add an import rule condition based on attributes:
Navigate to the Import rules page for a managed system or managed account.
Select the Conditions tab.
Click Add new…
Enter an ID and optionally a Description.
Enable the condition for this import rule by checking the box, or leave it unchecked to exclude the condition.
Set the condition Type to ”Attribute”.
Select the attribute that the condition will evaluate.
The attribute must be discovered by Bravura Security Fabric before it can be used in an evaluation.
Choose an Attribute type :
Computer: the attribute comes from discovered systems.
Account: the attribute comes from discovered accounts.
Account attributes are only available for managed account import rules.
Choose a Comparison method that will be used to compare the value with the system attributes.
When comparing against all items in a multi-valued attribute, using 'does not' comparison methods behaves differently from negating the comparison. For example, if using the ’does not contain’ comparison method, this would only check if any of the items lack the value. If using the ’contains’ method with the condition negated, this would check if no items contain the value.
Select the Value type.
Select Case sensitive comparison if needed.
Select Negate condition to negate the comparison if needed.
Specify the Value used to compare with the system attributes.
Click Add.
Defining conditions using PSLang expressions
You can write PSLang expressions to define import rule conditions, based on the attributes of discovered objects. You can use any of the listed attributes as variables for comparison.
To add an import rule condition based on a PSLang expression:
Navigate to the Import rules page for a managed system or managed account.
Select the Conditions tab.
Click Add new…
Enter an ID and optionally a Description.
Enable the condition for this import rule by checking the box, or leave it unchecked to exclude the condition.
Set the condition Type to "PSLang Expression".
Enter expressions you want evaluated.
Click Add.
For example, the following values are extracted while discovering systems during auto discovery :
computer "" = { cn = <cn>; name = <name>; operatingSystem = "<operatingSystem>"; ADsPath = "<ADsPath>"; }
To access attributes discovered from computer objects, you need to define variables like this:
comp["<attribute name>;"][n]
where n may be either 0 or a number, depending on whether the attribute has single or multiple values.To access attributes discovered for accounts, you need to define variables like this:
acct["<attribute name>"][n]
where n may be either 0 or a number, depending on whether the attribute has single or multiple values.
The PSLang expression must be 256 characters or less. For larger expressions, you must use a plugin instead.
Viewing system and account attributes
You can view discovered system and account attributes and values via the Manage the system > Resources > Discovered objects menu. Click on the object ID to view attributes.

Systems pages display all discovered attributes and their values, both single and multi-valued. Accounts pages display certain attributes, discovered services, tasks, IIS and DCOM objects.
Attributes defined with Bravura Privilege may also be displayed here, though some are not displayed until they are set. For example:
The attachedPolicies attribute is blank by default: comp["attachedPolicies"][0]=""
Managed systems and managed accounts import rules which are set to use the attachedPolicies attribute will only work if the managed system is a member of the policy before the import rule is evaluated.
If a member system is placed into a policy by an import rule during auto discovery , this information will not be made available until the next time the import rule is evaluated.
If the discovered system no longer appears on the discovered system list files, the compDiscovered attribute will be set to 0; otherwise it will be set to 1.
The compNotDiscoveredDays attribute will be incremented for every day the discovered computer has not appeared in the system list files.
Use PSW CLEAN DELETED WSTN DELAY and PSW CLEAN NEVER MANAGED LWS DELAY (Manage the system > Modules > Privileged access) to control when the Bravura Security Fabric will permanently remove discovered systems from the database.
The compNotDiscoveredPastThreshold attribute will be set to true if the threshold is reached for the number of days the discovered computer has not been discovered (as defined in attribute compNotDiscoveredDays).
The compNotConnectedPastThreshold attribute will be set to true if the threshold is reached for the number of days since the last successful connection to the discovered computer (as defined in attribute compNotConnectoredIntervals).
The compFailurePastThreshold attribute will be set to true if the threshold is reached for the number of days the discovered computer has uninterrupted failures of a password randomization or list operation.
The compNotConnectedIntervals attribute is incremented by 1 for every 10 day period since the last successful connection to the discovered computer.
When choosing which computer attributes to use, note how often the attributes change. Each time they change, the rule is evaluated during the daily auto discovery (psupdate
) process and several entries are added to several historical tables. Whenever possible, choose threshold attributes, such as compNotDiscoveredPastThreshold for push mode systems and compFailurePastThreshold for local service mode systems, over their non-threshold counterparts.
Push mode system threshold values
You can set the following variables on Import rules tab at Manage the system > Resources > Options , or Manage the system > Privileged access > Options to set thresholds for push mode systems.
PUSH COMP NOT DISCOVERED THRESHOLD sets the threshold value that determines the compNotDiscoveredPastThreshold attribute for push mode discovered systems. The default threshold value is 7 days.
PUSH COMP NOT CONNECTED THRESHOLD sets the threshold value that determines the compNotConnectedPastThreshold attribute for push mode discovered systems. The default number of days is 30.
COMP FAILURE THRESHOLD sets the threshold value that determines the compFailurePastThreshold attribute. The default number of days is 30. For push mode systems, the threshold is the number of days of uninterrupted randomization or listing failures.
Local workstation service mode threshold variables
You can set the following variables on Import rules tab at Manage the system > Resources > Options , or Manage the system > Privileged access > Options to set thresholds for local workstation mode systems.
LWS COMP NOT DISCOVERED THRESHOLD system variable to set the threshold valuethat determines the compNotDiscoveredPastThreshold attribute for local service mode discovered systems. The default threshold value is 7 days for both system variables.
COMP FAILURE THRESHOLD sets the threshold value that determines the compFailurePastThreshold attribute. The default number of days is 30. For Local service mode systems, the threshold is the number of days since the system’s last contact with the server.
Condition examples using expressions
The computer name must match the string “user1-ws”:
$comp["name"][0]=="user1-ws"
The string “OU=Domain control” must exist within the value of the variable $ADsPath:
%strlen(strstr($ADsPath,"OU=Domain Control"))>0 strcontains($comp["ADsPath"][0],"OU=Domain Control")
If the length of the computer name is greater than 5 characters and its operatingSystem is Microsoft Windows Server 2008, then return true, otherwise return false:
iif(((strlen($comp["name"][0])>5)&&($comp["operatingSystem"][0] == "Windows Server 2008")),"true","false")
This expression is useful for moving managed systems that are already known to be a member of another policy:
function MV() {for (var $i=0; $i< size($comp["attachedPolicies"][0]); $i++) {if($comp["attachedPolicies"][$i]=="<managed system ID>") { return 1;}} return 0; } MV();
This rule must be evaluated twice in order for the necessary information to be gathered.
This expression would be useful, for example, in cases where systems must be placed in a default policy, or if a system is a member of a tombstone policy (grouping non-contactable systems) and should not be a member of any other policy.
To detect systems that Bravura Privilege has not been able to contact for the set time period:
Configure the COMP FAILURE THRESHOLD system variable to <N> (where N = number of days)
$comp["compFailurePastThtreshold"][0] == 1
To detect systems that Bravura Privilege has not been able to contact since a specified period (in this example, 2 months) past a certain date based on their last successful connection time:
function dateComparison() { var $certainDate; var $attributeDate; var $period = P2M; toDate($attributeDate, $comp["lastSuccessConnection"][0]); toDate($certainDate, "2012-07-15 13:48:00 (GMT-07:00)"); if($attributeDate > ($certainDate + $period)) { return 1;} return 0; } dateComparison();
To detect previously-discovered systems that Bravura Privilege has not been able to discover from the domain:
$comp["compDiscovered"][0] == 0
To detect the number managed systems that have not been discovered by Bravura Privilege in the last 10 days:
$comp[compNotDiscovered][0] > 10
This expression allows you to create import rules based on Active Directory structures, and place managed systems into dedicated managed system policies for structures like location or department:
strcontains(($comp["ADsPath"][0]|$comp["distinguishedName"][0]), <AD object organization object such as CN values, or OU>)
Or,
strlen(strstr(($comp["ADsPath"][0]|$comp["distinguishedName"][0]), <AD object organization object such as CN values, or OU>))>0
To determine if a discovered account is a domain account or not:
$acct["accountDomain"][0] == "<domain>"
If you are manually providing computer list files, you can also provide custom attributes:
$comp["<custom attribute>"][0] == "<custom value>"
To determine whether an attribute exists on a discovered object:
compAttrExists("<attribute_name>" , "<optional attribute value>" , "<1|0 multi-value or not>");
If the attribute value is empty, the expression simply determines whether the attribute exists or not. If the value is included, the attribute must exists and have the same value.
This expression is particularly useful when providing custom attributes for a set of specific discovered objects.
Conditions may also contain logical statements; for example:
(<condition 1>) && (<condition 2>) && (<condition 3>) && ... (<condition 1>) || (<condition 2>) || (<condition 3>) || ...
These are useful when working with either a smaller set or conditions for specific systems, or if you want to add exceptions to the condition.
Defining conditions using plugins
You can write a plugin to define import rule conditions. All plugins have access to the data stored in the variables for PSLang expressions . Scripts that are not written in PSLang need to be wrapped in a PSLang script to access these variables.
To add an import rule condition using a plugin:
Navigate to the
page for a managed system or managed account.Select the Conditions tab.
Click Add new…
Enter an ID and optionally a Description.
Enable the condition for this import rule by checking the box, or leave it unchecked to exclude the condition.
Set the condition Type to ”Plugin”.
Select Used attributes you want to have passed into the plugin.
Click Add.
Input
There are two options for input:
In-process PSLang with direct variable references for the managed system/object
External process with standard input/ouput
The following is an example of a PSLang plugin script for import rule requirements:
function main() { var $outkvg = kvgCreate( "", "" ); if ($name=="user1-ws") || ($comp["name"][0] == "user1-ws") { kvgAddValue( $outkvg, "retval", "0" ); return $outkvg; # or return 1; } else { kvgAddValue( $outkvg, "retval", "1" ); kvgAddValue( $outkvg, "errmsg", "server name does not match"); return $outkvg; # or return 0; } }
If an external interpreter is used (set in PLUGIN PROGRAM), then the following input is passed into the external call:
"" "" = { "<system/account attribute>" = "<value>" # one or more }
Output
The following is an example of output from a plugin script for import rule requirements:
"" "" = { "retval" = "1" "errmsg" = "Defining requirements has failed." }
Where:
retval is zero on success or non-zero on failure.
errmsg is an optional failure message that can be displayed.
See more information on writing PSLang expressions.
Define requirements for multi-valued attributes using plugins
To define a requirement for multi-valued attributes, you must use functions:
function <name>() { for (var $i = 0; $i < size(<multi-value-attribute>); $i++) { if (condition on <multi-value-attribute>[$i]) { return 1; } } return 0; } <name>();
Examples
If the discovered system is a member of "Domain Computers":
function membership() { for (var $i = 0; $i < size($comp["memberOf"]); $i++) { if ($comp["memberOf"][$i] == "CN=Domain Computers,CN=Users,DC=domain,DC=com") { return 1; } } return 0; } membership();
If the first listed IP address of the discovered system is 10.0.1.199:
function firstIP() { if ($comp["ip"][0] == "10.0.1.199") { return 1; } return 0; } firstIP()
If the discovered system has an IP address within the 10.0.1.0 to 10.0.1.9 range:
function iprange() { var $i = 0; for($i = 0; $i < size($comp["ip"]); $i++) { var $j = 0; for ($j = 0; $j < 10; $j++) { log ("Comparing: 10.0.1."+$j + " with " + $comp["ip][$i]); if ($comp["ip"][$i] == "10.0.1."+$j) { return 1} } } return 0; } iprange();