Service accounts on windows
The following sections explain how Bravura Security Fabric can manage service accounts on Windows systems.
Terminology
The following terminology is introduced in this chapter:
Service accounts | A managed account that has at least one subscriber. The service account provides a security context for a subscriber to authenticate against. |
Subscriber | A subscriber is an entity that stores passwords or permissions used to authenticate to a primary security database, such as a local Windows SAM database or Active Directory. It can be a process, program, or file, such as Service Control Manager, IIS, scheduler or DCOM objects. |
Orchestration | Orchestration is the coordinated process involving one service account password change and related subscriber notifications. Subscriber notification can inform subscribers of a new password value for a service account that they use. Notification may require extra steps, in addition to providing the new password value, such as stopping and restarting services. |
Product administrators can manage subscribers and configure subscriber notifications.
How Bravura Privilege manages service accounts
Bravura Privilege can be configured to secure service account passwords. This can be done two ways, depending on the mode of operation:
In local service mode, the Bravura Privilege workstation service periodically scrambles service account passwords locally, in coordination with the central Bravura Privilege server cluster.
In push mode, Bravura Privilege servers periodically connect to Windows servers in order to change the passwords of service accounts.
You can manage accounts on a domain controller by enabling all accounts to be discovered objects. However, subscribers cannot be listed from domain controllers.
Bravura Privilege must notify the program that launches services – the subscriber – of the new password value, so that it can successfully launch the service at the time of the next system restart or when an administrator manually stops and restarts the service in question. The Subscriber notification component provides this functionality.
Bravura Privilege includes several mechanisms for managing subscribers:
Auto-discovery of subscriber/account dependencies for a variety of subscriber types: IIS, Scheduler, SCM, DCOM, at various OS and subscriber versions.
A white-list mechanism (usually table driven, but a plugin is available for more complex scenarios) so customers can control which service accounts should have their passwords randomized and when.
Built-in tools to notify known subscribers of new password values.
A transaction manager that can retry notifications to off-line subscribers.
The above are primarily used when managed systems are integrated with Bravura Privilege in push mode – that is, there is no locally installed software on the target system and Bravura Privilege initiates all connections remotely, over the network, directly or via a co-located Bravura Privilege proxy server.
In case push mode is inappropriate – for example because the relevant services (such as remote registry, WMI) are disabled or firewalled or because the end system is offline or inaccessible due to name resolution or IP routing issues (such as NAT), a Local Workstation Service can be installed on the managed system, which performs essentially the same functions but with much simpler connectivity (call home over HTTPS) and no need for network accessible services on the local system.
Local service mode is normally used on laptops and in some cases desktop PCs, but works on any system running any version of the Windows OS. Any problems encountered in updating a service password can, and should be configured to trigger an exit trap program on the Bravura Privilege server, to notify an administrator of an imminent problem when the service in question is next started.
Requirements
Some organizations configure services on Windows servers to run in the context of a domain-level, rather than local service account. This is mandatory on domain controllers, which have no local security database. This is also common on non-domain controllers, since Microsoft encourages this practice.
In Bravura Security's view, running a service on a member server in the security context of a domain account is not recommended, since the same service account may be used to run many different services on many different servers. This complicates changes to the password of the AD service account, since multiple servers must be notified of the new password. To complicate matters further, some of the servers may be offline or unreachable when the service account password is changed on AD, making it even more complex to notify them of the new password.
In general, Bravura Security recommends that organizations:
Run services on AD DCs as SYSTEM or similar.
Run services on member computers as local, not domain accounts.
The following should also be considered when planning to manage service accounts:
Bravura Security Fabric can only list subscribers on servers that utilize the Windows NT target system type.
A plugin program or script is required to determine which discovered object should be updated when the managed account’s password has been randomized. The program or script is called by the PAMSA SUBSCRIBER NOTIFICATION plugin point and is part of the subscriber notification component.
In order to prepare an account for subscriber orchestration, you need to ensure that the notification is configured for all of the subscribers it runs. This is done by using the SubscriberNotification column of the pam_pwd_randomization_subscriber Manage external data store (DBE) module table.
Subscriber notification
The subscriber notification component, Functional.pam_subscriber_notification_plugin, allows Bravura Security Fabric to notify relevant subscribers, such as services, that an associated password is changing. Primarily this component is used for updating service account passwords on their respective service before or after performing the password change.
Subscribers to an account are automatically determined based on data gathered during auto discovery, and relevant information associated with the subscribers is populated into a table in the SQLite External Data Store. Once the subscriber data has been populated, the record must be reviewed before subscriber orchestration will be enabled for that account. This process can be done by humans, or can be automated depending on the requirements of the Bravura Security Fabric deployment.
Subscriber orchestration will only take place if all servers that house subscribers can be contacted when the randomization takes place. If any of the servers are unreachable then the password will n ot be randomized. This ensures that no services are left in an unusable state by Bravura Security Fabric .
The following plugin points, scripts, and tables control the logic that powers the subscriber notification component, and are automatically configured when the component is installed:
Calculation Logic –
PAMSA SUBSCRIBER NOTIFICATION – calls a plugin to give notifications of imminent service account password randomization to subscribers and receive orchestration information.
PSUPDATE POST – the
psupdate_post.pslscript is called by psupdate at the end of auto discovery after all other tasks are complete.
SQL Table – A table in the SQLite External Data Store called Subscribers contains the data that is used to determine which subscribers to notify of upcoming password randomization.
This component is usually installed with the subscriber scenario component, part of the Bravura Privilege Pattern. See Example: Onboard a Windows server with subscribers for details.
Subscriber notification plugin
You use a plugin or PSLang script to determine which discovered object that is using a managed account’s credential should be updated when the managed account’s password has been randomized. This allows you to control which objects on a discovered managed system should have credentials updated, to prevent un-authorized services, scheduled tasks, dcom objects and IIS objects from obtaining the new password. If the plugin is empty, password randomization will occur without any subscribers being notified.
To control what objects to update after a password randomization:
Click Manage the system > Privileged access > Options > Password randomization .
Type the name of the plugin in the field.
Click Update.
If the Bravura Privilege Pattern is used the plugin_sub scriber_notification.py plugin will be installed with it.
Requirements
See Writing plugins for general requirements.
Execution points
The plugin is run as part of the password change orchestration process, which occurs whenever a managed account password has been randomized by the Bravura Security Fabric instance. This includes product administrators randomizing passwords, the scheduled password randomizations, and password check-ins.
Input - local accounts
The plugin has access to the following KVGroup input for local accounts:
"orchestrationid" "<orchestration id>" = {
"target" "<target id>" ={
"ead_computer_attributes" "" = { # attributes discovered through auto discovery process
"sv_attributes" "" = {
"<attribute key>" = "<attribute value>"
...
}
"mv_attributes" "" = {
"<attribute key 1>" = "<attribute value 1>"
"<attribute key 1>" = "<attribute value 2>"
"<attribute key 2>" = "<attribute value 3>"
...
}
}
"ead_computer_attributes" "" = { # attributes listed
"<attribute key>" = "<attribute value>"
...
}
}
"account" "<account longid>" = {
"account" "" = {
"account" "" = {
"userid" = "<user id>"
"hostid" = "<target system id>" # Target system the account is on
"longid" = "<longid>"
"shortid" = "<shortid>"
"helpdesk" = "<TRUE|FALSE>"
"list" = "TRUE|FALSE"
"user" = "TRUE|FALSE"
"associated" = "TRUE|FALSE"
"invalid" = "TRUE|FALSE"
}
}
}
"subscribers" "" = {
"<target system id>" "" = { # ID of target system where the subscriber is on
"HostID" = "<target system id>"
"accountDomain" = ""
"description" = "<target system description>"
ead_computer_attributes" "" = {
"sv_attributes" "" = {
"<attribute key 1>" = "<attribute value>"
...
}
"mv_attributes" "" = {
"<attribute key 1>" = "<attribute value 1>"
"<attribute key 1>" = "<attribute value 2>"
"<attribute key 2>" = "<attribute value 3>"
...
}
}
"<subscriber 1 address>" "Service|Task|IIS|DCOM" = {
"rawaccount" = "<account id>" # Account ID as it appears on the subscriber
"attribute" "" = {
"<attribute>" = "<value>"
...
}
}
...
"<subscriber N address>" "Service|Task|IIS|DCOM" = {
"rawaccount" = "<account id>" # Account ID as it appears on the subscriber
"attribute" "" = {
"<attribute>" = "<value>"
...
}
}
}
}
"sessionid" = "<session id>"
} Input - Domain accounts
The plugin has access to the following KVGroup input for domain accounts:
"orchestrationid" "<orchestration id>" = {
"target" "<domain target id>" ={
"ead_computer_attributes" "" = { # attributes discovered through auto discovery process
"sv_attributes" "" = {
"<attribute key>" = "<attribute value>"
...
}
"mv_attributes" "" = {
"<attribute key 1>" = "<attribute value 1>"
"<attribute key 1>" = "<attribute value 2>"
"<attribute key 2>" = "<attribute value 3>"
...
}
}
"ead_computer_attributes" "" = { # attributes listed
"<attribute key>" = "<attribute value>"
...
}
}
"account" "<account longid>" = {
"account" "" = {
"account" "" = {
"userid" = "<user id>"
"hostid" = "<target system id>" # Target system the account is on
"longid" = "<longid>"
"shortid" = "<shortid>"
"helpdesk" = "<TRUE|FALSE>"
"list" = "TRUE|FALSE"
"user" = "TRUE|FALSE"
"associated" = "TRUE|FALSE"
"invalid" = "TRUE|FALSE"
}
}
}
"subscribers" "" = {
"<target system 1 id>" "" = { # ID of target system where the subscriber is on
"HostID" = "<target system id>"
"accountDomain" = "<domain of account>" # Format dependent on how it was targeted
"description" = "<target system description>"
ead_computer_attributes" "" = {
"sv_attributes" "" = {
"<attribute key 1>" = "<attribute value>"
...
}
"mv_attributes" "" = {
"<attribute key 1>" = "<attribute value 1>"
"<attribute key 1>" = "<attribute value 2>"
"<attribute key 2>" = "<attribute value 3>"
...
}
}
"<subscriber 1 address>" "Service|Task|IIS|DCOM" = {
"rawaccount" = "<account id>" # Account ID as it appears on the subscriber
"attribute" "" = {
"<attribute>" = "<value>"
...
}
}
...
"<subscriber N address>" "Service|Task|IIS|DCOM" = {
"rawaccount" = "<account id>" # Account ID as it appears on the subscriber
"attribute" "" = {
"<attribute>" = "<value>"
...
}
}
}
... # Repeat for each system that has a subscriber use the domain account
"<target system N id>" "" = { # ID of target system where the subscriber is on
...
}
}
"sessionid" = "<session id>"
} Output
The plugin expects the following return value:
"output" "plugin_subscribernotification" = {
"orchestrationid" "<orchestration id>" = {
"changePassword" = "<true|false>"
"infomsg" = "<message>"
"warnmsg" = "<message>"
"operations" = "<operation id>" = { # Used for dependencies
"operation" "<SERI|UPRS|ACHG>" = {
"attributes" "" = {
"restart" = "<true|false>"
"position" = "<pre|post>"
}
"resourcetype" = "<up_scmpass|up_taskpass|up_iispass|up_compass|up_cuspass>"
"resourceaddress" = "<subscriber addresss>" # Matches subscriber Id on managed system
"rawaccount" = "<raw account id>" # Matches how account is set in subscriber
"accountTarget" = "<target system id>" # Where the account exists on (used for domain accounts)
"accountID" = "<account id>"
}
"depends" "" = {
"dependency" = "<orchestration id>" # Empty KVG signifies no dependency
}
"target" = "<target system id>" # Where the subscriber is
}
...
}
"retval" = "0"
} Decommissioning subscribers
When tasks, services and other already discovered subscribers are removed from their targets, disable subscriber notification in Manage external data store > pam_pwd_randomization_subscriber , so that orchestration can complete successfully for the affected service account randomizations. Do not delete the subscriber, as it will be restored after the next discovery, even if it is not listed.