Planning for infrastructure auto discovery
Consider the following before configuring import rules and discovery:
Managed system policies
The configuration of infrastructure auto discovery depends firstly on the organization of managed system policies. Consider:
Policy organization
Determine whether policies are organized by:
Systems to which you give access
Accounts on the member systems
Disclosure methods
Permissions; for example, only allow help desk users to access specific computers
Usage; for example:
A default policy for storing all systems at first
Tombstone policy for all systems that have known issues
Disabled policy for systems not to have passwords changed
Load balancing; for example, policies may run specific replication nodes to handle randomizing passwords for one group of systems (possibly separated via geographical location)
Other factors, such as:
Password policies
Randomization schedules
Managed system types
Managed accounts
Will the accounts be domain administrators?
In this scenario, you would only need to manage the domain credentials on the domain controller. This should only require one policy, unless there are different usages, permissions or disclosure methods to separate user access. Discovering computers and probing them is still required to detect which services are using the domain accounts.
Will the accounts be local administrators?
Will the accounts have unique IDs?
Will the accounts need to be discovered and managed?
Managed services
For scenarios where replication node locations are separated geographically, it is recommended that the node closest to the managed systems at each location be responsible for load balancing work, including password randomizations, or requests for users in the area. Thus, having policies dedicated to systems at different locations will be beneficial.
Source systems (push mode)
When implementing push mode privileged access management, an infrastructure auto discovery plan can incorporate multiple sources for computers, or may purposely target only sections of the domain to list computers.
The following use cases illustrate some ways of using sources to discover and manage systems in push mode:
Targetable source systems such as OUs, or groups.
In cases like this, it may be useful to target each section as a unique source, then apply import rules for each source system. This will improve evaluation speeds on certain scenarios where each source will have its own set of import rules to use.
This should be avoided if you want to manage accounts on the actual domain controller, since targeting a single system twice has been known to cause issues.
Multiple source systems that get added periodically.
Similar to the case above, import rules can be applied to discovered systems from each source.
Manually-built list of computers
This method is particularly useful for infrastructure auto discovery since Bravura Security Fabric can filter out computers from a manually-built list, and writing import rules will be easier because the computers listed will have already been passed through a set of filters.
The disadvantage of this method is that the list file provided must be managed by an external source. If the source management is unreliable, then this will cause issues with infrastructure auto discovery.
Credentials for discovered systems
Determine how discovered systems will be managed:
Do the accounts that you plan to use to administer the discovered systems all have a common password?
Do you intend to use domain credentials to manage the system?
Are the domain credentials found on the source system?
Are the domain credentials found on a separate system?
Do you intend to have Bravura Security Fabric create local admin credentials for each of the discovered systems?
Answering these questions will help you define connection methods for discovered systems .
Discovery templates
Once you have decided on policy responsibilities, source systems and how Bravura Security Fabric will connect, you can plan discovery templates to determine specific settings for connecting to managed systems.
Discovery template settings can be unique in certain scenarios such as:
Systems require access through unique proxy servers
In order to configure systems to use a specific set of proxies, you need to use templates to define which computers connect to which proxies.
There are some performance gains from using proxy servers, specifically when dealing with multi-geographical location deployments.
Systems include different target system types; such as ActiveDirectory or Unix.
The templates can be used to distinguish the type of discovered system.
Import rules with subsequent connections determined by the template setting
If discovered systems have unique naming patterns for administrator accounts with the same password, multiple templates can help make management of the systems easier. By generating a template for each type of administrator pattern and/or password, you can specify what credentials each discovered system should attempt to connect with.
Domain service accounts
When loading systems in batches, ensure that you do not manage a domain account until Bravura Security Fabric has discovered all systems that may be using the account; randomizing the password prematurely will cause services to fail to start. It is recommended to that you let auto discovery run first and detect all service accounts before you start randomizing passwords.
When Bravura Security Fabric randomizes domain accounts that are used to manage services, it only updates services that it knows of that are using the domain credentials. Bravura Security Fabric probes the systems to discover the services running on them and which accounts are managing them.
Import rules
The previous planning steps will help in deciding how to create the import rules, particularly with the relationship they have with the managed system policies and discovery templates; for example:
For each local service mode source system, you can set a unique target system import rule for it to evaluate attributes only available from this specific source.
You can configure import rules for each type of system (push mode or local service mode).
Each unique discovery template type requires a new target system import rule.
For each managed system policy with unique settings, a managed system import rule may be required to attach members.
Another factor to consider in the planning stages for import rules is performance. Import rules can be applied to all discovered systems from all sources of computers. Alternatively, import rules can be configured to only run on a set of systems, and avoid doing unnecessary calculations against discovered systems from other sources; for example, an import rule created for Windows servers would not need to be evaluated against Unix systems.
User access
Determine who should be able to access what accounts, and how they will access them (using disclosure plugins ).