Import rules

Use target system import rules to determine which discovered systems should be managed and have corresponding target systems created for them.

One of the main reasons for using target system import rules is to define how the system will be connected. An important decision to make for target system import rules is choosing the source systems whose computers will be subject to the import rule.

Local service mode target systems are not connected to source systems. They still require the local service mode client to contact the server. You can also use import rules to delete target systems.

If a target system is a managed system, then deleting it removes all managed passwords from Bravura Privilege . Only systems which were discovered and managed using import rules can be deleted using import rules.

Manually defined target systems cannot be deleted using import rules.

To add a target systems import rule:

Import rules are disabled by default, and must be enabled to be applied during auto discovery . You can enable or disable an import rule on the Import rule s page and on each rule’s specific page.

Use managed systems import rules to determine policy membership; for example:

When defining managed systems import rule policies, consider the following:

Managed systems with checked-out passwords cannot be unbound.

Systems can be unbound without losing managed password histories.

You must link managed systems rules to managed systems policies .

Use managed accounts import rules to determine what accounts to manage. It is recommended that you set these rules only after setting up managed system policies and managed system import rules. That way, defining managed account import rules is simply a matter of setting the account ID to look for managed accounts.

Windows service accounts must be listed by Bravura Privilege before they can be managed.

Managed systems must be a member of at least one managed system policy for their accounts to be managed using import rules.

Consider:

You must link managed accounts rules to managed system policies .

To add a managed systems import rule:

Import rules are disabled by default, and must be enabled to be applied during auto discovery . You can enable or disable an import rule on the Import rules page and on each rule’s specific page.

To add a managed accounts import rule:

Import rules are disabled by default, and must be enabled to be applied during auto discovery . You can enable or disable an import rule on the Import rules page and on each rule’s specific page.

Each managed systems and managed accounts import rule must be associated with at least one managed system policy. To link import rules to managed system policies:

You can also link rules to policies on the Managed system policy information page (Manage the system > Privileged access > Managed system policies > <policy> ).

To unlink an import rule from a managed system policy, all objects that were added by the import rule must first be removed from the policy.

To add an import rule condition based on attributes:

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:

For example, the following values are extracted while discovering systems during auto discovery :

 computer "" = { 
      cn = <cn>; 
      name = <name>; 
      operatingSystem = "<operatingSystem>"; 
      ADsPath = "<ADsPath>"; 
   } 

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:

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.

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.

Condition examples using expressions

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:

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;
     }
} 

 "" "" = {
  "<system/account attribute>" = "<value>" # one or more
         } 

"" "" = {
    "retval" = "1"
    "errmsg" = "Defining requirements has failed."
} 

function <name>() {
         for (var $i = 0; $i < size(<multi-value-attribute>); $i++) {
                  if (condition on <multi-value-attribute>[$i]) {
                  return 1;
                  }
         }
         return 0;
}
<name>(); 

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(); 

 function firstIP() {
                  if ($comp["ip"][0] == "10.0.1.199") {
                  return 1;
         }
         return 0;
}
firstIP() 

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(); 

For local service mode systems, Bravura Privilege does not require credentials to be specified.

To configure Bravura Privilege to use pre-existing administrator credentials on a managed discovered system using a plugin, type the name of the plugin in the Plugin to get credentials field.

Alternatively, you can define a default plugin in IMPORT ADMIN CRED DEFAULTPLUGIN in Manage the system > Resources > Options . This pre-populates the Plugin to get credentials field when creating target system import rules.

"" "" = { 
    "ead_computer_attributes" "" = { 
        "sv_attributes" "" = { 
            #...single-valued attributes go here... 
        } 
        "mv_attributes" "" = { 
            #...multi-valued attributes go here... 
        } 
    } 
    "sessionid" = "< session id>" # The session ID 
} 

 "" "" = { 
       "admin" = "<account name>"; 
       "adminPW" = "<unencrypted password>"; 
       "isSysPWD" = "[true | false]"; //optional 
       "isConnPWD" = "[true | false]"; //optional 
       "isUpdByPAM" = "[true | false]"; //optional 
       "retval" = "0" 
   } 

 "" "" = { 
       "admin" = "<managed account ID>"; 
       "adminPW" = ""; 
       "resourceid" = "<managed system ID>"; 
       "accountID" = "<managed account ID>"; 
       "isSysPWD" = "[true | false]"; //optional 
       "isConnPWD" = "[true | false]"; //optional 
       "isUpdByPAM" = "[true | false]"; //optional 
       "retval" = "0" 
   } 

 "" "" = { 
      "version" = "2" 
      "resultgroup" "" = { 
         "credential" "" = { 
            "admin" = "<account name>"; 
            "adminPW" = "<unencrypted password>"; 
            "isConnPWD" = "[true | false]"; //optional 
            "isUpdByPAM" = "[true | false]"; //optional 
         } 
         "credential" "" = { 
            "admin" = "<account name>"; 
            "adminPW" = "<unencrypted password>"; 
            "isConnPWD" = "[true | false]"; //optional 
            "isUpdByPAM" = "[true | false]"; //optional 
            //To create a system credential add the following kvg group to 
            //a credential 
            "sys" "" = { 
               "admin" = "<sys account name>"; 
               "adminPW" = "<unencrypted password>"; 
               "isConnPWD" = "[true | false]"; //optional 
               "isUpdByPAM" = "[true | false]"; //optional 
            } 
         } 
      } 
      "retval" = "0" 
   } 

Configure Bravura Privilege to create new credentials on a managed discovered system by setting the options defined in Table 1, “Options for creating new credentials on discovered systems”.

When Bravura Privilege creates the new credentials, it uses the default global password policy. The description for created accounts notes that the account was created by Bravura Privilege , and states which rule (if any) was used to create it.

If account creation fails on the discovered system, then the system is not managed by Bravura Privilege . If evaluated against an import rule:

If Bravura Privilege fails to add the new account to any of the selected administrator groups, then the system is not managed. However, the account remains in the groups that were joined successfully. If this occurs, either fix or remove the incorrect/missing group ID.

"" "" = { 
    "resource" "" = { 
        #...single-valued attributes go here... 
    } 
    "sessionid" = "<session id>" # The session ID 
} 

 "" "" = { 
       "admin" = "..."; 
       "adminPW" = "<unencrypted password>"; 
       "return" = "0"; 
   } 

Configure Bravura Privilege to test and copy administrator credentials from the target system template if you have groups of systems using the same set of credentials. This way, you can select which administrator credentials to use based on the target system template selected.

This is also useful if the administrator accounts are unique on each system; for example, IDs that use the format Admin_<computer name>. In this case, the passwords must be identical.

If the credentials are invalid, then the system is not imported or managed by Bravura Privilege . Target systems that require a system password only have the administrator credential validated, not the system credential. If the system is imported and managed by Bravura Privilege , then the system password is copied. If multiple system passwords are configured, then the first alphabetically-sorted password is copied.

Copy administrator credentials from the source system if you intend to use a domain administrator account to manage all discovered systems. This setting applies to push mode systems only. It is recommended that the administrator ID on the source system follows the format <adminid>@<domain>. Bravura Security Fabric does not verify whether the source system credentials are valid.

If the credentials change on the source system, then Bravura Privilege automatically propagates the new credentials to the managed systems that are using them. However, if the imported credentials get removed from the managed system, then Bravura Privilege stops propagating source system changes to that system.

You can evaluate one import rule against discovered objects; Target system and Managed system rules are evaluated against computers, and Managed account rules are evaluated against accounts.

To evaluate a single import rule against discovered objects:

The evaluation only runs if there is at least one enabled condition for the rule being evaluated.

You can evaluate multiple import rules and their conditions simultaneously. You can evaluate all import rules to simulate all rules running automatically during auto discovery .

To evaluate multiple import rules:

After an evaluation is complete Bravura Security Fabric displays the results including which objects (systems and accounts) have passed all the conditions, and which objects have failed. If they failed, Bravura Security Fabric indicates which conditions caused them to fail; however, if an import rule’s conditions is set to “Match any expression”, then the results cannot include an explanation of why an object failed the evaluation.

On production systems, or with a large set of test matches, run auto discovery to process discovered objects and make them into managed systems and managed accounts.

Alternatively, on a test system, you can click Apply on the Import rules page to make all objects that passed all conditions into managed systems and managed accounts.

Once an import rule has processed all discovered objects, either by running auto discovery or by evaluating the rule and clicking Apply, then those objects are not re-evaluated against the same import rule again. This includes both passed and failed results.

Discovered systems which pass all conditions for a target systems import rule but fail to obtain valid credentials on subsequent connections are re-evaluated against the import rule, unless they pass and obtain valid credentials from another rule. This process for local service mode discovered systems will occur over a few intervals where the client connects to the server.

Use the TEST IMPORT RULE MAX LENGTH system variable (Manage the system > Resources> Options, or from the Import rules tab in Manage the system > Privileged access > Options) to limit the number of computers or accounts to evaluate a rule against. The default number of objects is 10. You can increase this value to evaluate the import rules on more discovered objects.

On the test section of each import rule you can override the TEST IMPORT RULE MAX LENGTH value by entering a new value in the Maximum number of systems to run test rule against field.

You can execute a trial run to test all objects that have not already been evaluated against a rule. The difference between a test and a trial run is that:

To execute a trial run on an import rule:

To cancel a trial run, click Cancel on the Import rule < rule type > page for the rule. You can only cancel a trial run from the instance on which it was started.

Import rules are only run once on each discovered object. They are not re-run on objects that have already been evaluated.

If the import rule changes, or if the attributes being used in an import rule are changed, then the import rule is re-evaluated against the discovered objects. You can also manually re-evaluate an import rule by clicking Update on the Import rules < rule type > page. This resets the rule and re-evaluates all discovered objects.

Discovered objects can be re-evaluated manually through the import rules test page or when changes are detected during an auto discovery . Local service mode discovered objects can also be re-evaluated when they connect to the Bravura Security Fabric server after it has detected a change in an attribute used by an import rule.

The behavior when re-evaluating import rules is different for each rule type:

Target systems import rules

Discovered systems that satisfy Target systems import rules and become managed systems are not re-evaluated by any import rules, regardless of changes to the managed systems or import rules.

To modify the settings for a managed system, you can:

Managed systems import rules

Managed system import rules are re-evaluated against managed systems whenever a change is detected in the managed system during auto discovery , or when the import rules have changed.

If a change is made to a managed system that causes the system to fail the import rule, depending on the configuration of the managed system import rule, it may archive the system. If there are managed accounts on this system, the password changes no longer occur, but regular users can still request access to these accounts, and product administrators can still access them.

Managed accounts import rules

Managed accounts import rules are re-evaluated against discovered accounts whenever a change is detected:

All accounts managed by a managed system policy are evaluated, including discovered accounts that were manually added to the policy and those added to the policy by an import rule.

If a change is made to a managed account that causes the account to fail the import rule, depending on the configuration of the managed account import rule, it may archive the account. If this account’s password is being managed, the password changes no longer occur, but regular users can still request access to this account, and product administrators can still access it. If the managed system is removed from the policy the system’s managed account passwords are archived.