Zone Processor Use Case Scenarios

A deferred processor is deployed with a thick client (Privileged Identity Management Console) whereas a zone processor can be deployed independently. A deferred processor and a zone processor are technically the same thing. However, a deferred processor is only limited by job types, and a zone processor can be limited by both management sets and job types. Because management sets define management zones that are often a segmented network, or a network with clear security boundaries, the deferred processor should be assigned only the job type Reports, or be disabled. You will need to deploy a zone processor to handle all other job types.

The following scenarios show when you should have zone processors and a deferred processor, as well as their configuration.

Scenario 1: All Access Everywhere #1

You have a well-connected network with high-speed, highly reliable links where:

  • There are no well-defined internal security boundaries, or if there are boundaries, they will not be managed by this instance of Privileged Identity.

Recommendation:

One or more deferred processors will suit your needs.

Scenario 2: All Access Everywhere #2

You have a well-connected network with high-speed, highly reliable links where:

  • There are no well-defined internal security boundaries, or if there are boundaries, they will not be managed by this instance of Privileged Identity.
  • You simply want to improve the job processing throughput of the job scheduling system.

Recommendation:

Either multiple zone processors or multiple zone processors and a deferred processor will be sufficient. No special configuration is required.

In Privileged Identity, a single job processor can handle only one job at a time. This can lead to other jobs getting backed up in the job queue until a job processor becomes available. If there are two processors, then two jobs may run simultaneously. This concept will scale linearly. More processors means more jobs at the same time.

Scenario 3: All Access Everywhere #3

You have a well-connected network with high-speed, highly reliable links where:

  • There are no well-defined internal security boundaries, or if there are boundaries, they will not be managed by this instance of Privileged Identity.
  • You want to ensure that password change jobs do not interfere with account elevation jobs.

If you want to ensure that password change jobs do not interfere with account elevation jobs, you can install an additional zone processor to manage any management set, restricting it to account elevation jobs only.

Recommendation:

  • Deploy one or more zone processors to handle all job types and one or more zone processors to handle only account elevation jobs.

Scenario 4: WAN Links with All Access Everywhere #1

Your organization is setup as follows:

  • Is divided into multiple geographical regions separated by WAN links where WAN traffic is NOT a concern.
  • Has no well-defined internal security boundaries, or if there are boundaries, they will not be managed by this instance of Privileged Identity.

Recommendation:

Deploy one or more deferred processors to handle all job types and one or more zone processors to target specific management sets.

Scenario 5: WAN Links with All Access Everywhere #2

Your organization is setup as follows:

  • Is divided into multiple geographical regions separated by WAN links, where WAN traffic IS a concern.

In this scenario, you are concerned about the amount of traffic that Privileged Identity sends over a WAN link from a central point. Hundreds of simultaneous connections from a single source can be problematic over slow or unreliable long distance links, or where there is a need not to send management traffic over the link.

At this point, you must determine the following:

  • The number of regions or offices that require a zone processor
  • If management traffic may be sent over a link

Recommendation:

  • If you require that no management traffic goes over the WAN link, then each segment, or zone, including the zone where Privileged Identity is actually located, will need its own zone processor. Furthermore, you must have the default zone processor not run discovery, refresh, or management jobs. A management set is required for each zone where there is a zone processor.

A zone processor can do management set updates only if you do not include or exlude systems when you configure the management set. You can use the zone processor if its only job is reporting.

  • If you prefer a zone processor to handle a job locally on the segment, but it is all right for management traffic to traverse the WAN links, then configure zone processors in each of the zones and let the default deferred processor continue with its default configuration to manage anything anywhere. Note that this is not a system of preference, but a system of availability. If the default deferred processor is available before a zone processor is available, the default deferred processor will run the job over the WAN links, even if the zone processor is scheduled to run the job later.

Scenario 6: A Network with a DMZ

A DMZ (de-militarized zone) is a section of a network where traffic is explicitly cut off from the rest of the network. You can think in terms of the internal network (where you are), the DMZ (where the secured servers are), and the external network (the internet).

When you have a DMZ to manage, you have four choices for Privileged Identity configuration:

  • Not recommended: Completely open the firewall to allow the Privileged Identity host full access into the DMZ from the internal network.
  • Not recommended: Allow the Privileged Identity host to establish a VPN (private, on-demand connection) into the DMZ and have full access from the internal network.
  • Recommended: Stand up a separate instance of Privileged Identity in the DMZ. This is an option, but since it at least doubles the MS Windows and MS SQL licensing requirements, plus the Privileged Identity management requirements, this is not the best choice. Creating a standalone instance of Privileged Identity is not a bad design decision, as it fully separates the infrastructure and exposure if Privileged Identity ever gets compromised internally or externally, but it is an option that rarely gains traction.
  • Preferred: Install a zone processor in the DMZ to handle the DMZ systems. Allow that zone processor (known host) access through the firewall (one direction, one port, known host) to the Privileged Identity central database (known destination, known port). This is often the most accepted scenario when working with a DMZ, as it is familiar, comfortable, easy to manage, easy to understand, and easy to secure.

Building on the fourth option, as this is the recommended zone processor scenario, you should set up zone processors for each zone. In this scenario, there are only two zones: internal and DMZ.

You may allow the deferred processor to run but should turn off its ability to perform password changes or discoveries. It should be relegated to admin activity reports and management set updates only.

 

If the option Attempt remote connection to targets found is enabled in the management set criteria, the management set update of a deferred or zone processor located in a DMZ will fail, unless the option Verify connectivity system as a criteria for inclusion in or exclusion from the set is also checked.

You need one zone processor for the internal network and one for the DMZ.

If neither the deferred processor nor the zone processor is configured as described, the following will occur:

  • The default deferred processor may attempt to manage DMZ systems. This will fail, as the DMZ does not allow incoming connections from the internal network.
  • Failure of the deferred processor to manage a DMZ system will cause the job to fail, causing avoidable alerts to be generated from Privileged Identity, which in turn require human response.

Scenario 7: The Network Has Trust Issues

This scenario applies to managing Windows workstations and servers only.

In the Windows world, there is a concept of trust. Trust is what allows an identity from one domain to access a resource in another domain. If there is a trust in place and going in the correct direction (it is possible for A to trust B but for B not to trust A) and Privileged Identity is in on the correct side of that trust, then things are relatively easy. But if there is no trust or Privileged Identity is on the wrong side of that trust, then things are going to be more complex.

If there are trusts in place and Privileged Identity is on the correct side of the trust, then refer to the previously described scenarios.

If there are no trusts in place or Privileged Identity is on the incorrect side of the trust, you will likely need zone processors if you want to manage the whole network through a single instance of Privileged Identity. This will require further investigation. Specifically determine:

  • Will you solely be dealing with password changes (domain or local), and not propagating those password changes to scheduled tasks, IIS, COM/DCOM or other remote COM related items?
    • If the answer to this question is “yes, the scope will be limited AND no, we will not propagate to any of those items,” zone processors may not be required. Alternate administrators or cached credentials could be used in this scenario so long as your environment falls under scenario 1, 2, or 3. If your environment falls under scenario 4, 5, or 6, a zone processor will likely be required.
    • If the answer to the question indicates that propagation may be required, then a zone processor will likely be required.
  • If zone processors are a requirement, there will be no fewer than two zone processors (assuming only two domains). The actual number of zone processors required will be determined through further discovery of the total number of untrusted domains, DMZs, regions, etc., as defined in the prior scenarios.

Scenario 8: Clustered Services

This scenario applies to managing Windows servers only.

Privileged Identity can propagate passwords. This means that once the password is changed for the account in question, Privileged Identity can also update all the other references for the account, such as those used by Windows services.

Windows allows for clustered services. Clustering is a means of ensuring that even if the service in question (such as email, database, or web) goes down on one server, there is a duplicate service on another machine that will continue to provide service to the customer.

Privileged Identity can propagate password changes to Windows clustered services. However, there are some considerations:

  • The most important consideration is that starting with Windows Server 2008, the management of clustered services is no longer backward or forward compatible.
  • Clustered services running on one version of a Windows Server. For example, Windows Server 2008, cannot be managed by a different Windows Server version, such as Windows Server 2012.
  • This is a limitation imposed by Microsoft.

If you manage clustered services, you must consider whether the clustered services are hosted on a version of Windows that is exactly the same as the Windows OS that is running Privileged Identity.

If the operating systems are not the same, then zone processors will be required. This scenario, to guarantee there are no problems during password propagation, requires that all zones, including the zone where Privileged Identity is hosted, will have a zone processor. The default deferred processor, if left enabled, must be configured NOT to perform password management jobs, in order to guarantee that the correct zone processor with the correct OS requirements manages the services. If the default deferred processor performs password management jobs, it will cause a service outage or possible failover/destruction of the cluster.

The number of zone processor deployments planned impacts the database hardware requirement, as detailed in Sizing Guidelines.