Segmented OT Vaulting and Distributed Engines
Northline Manufacturing runs Delinea Secret Server 11.x on-premises in its corporate data center with a SQL Server database. It has 1,200 Windows service accounts and 80 Linux service accounts used by production-line applications across three OT segments. The OT network allows almost no inbound traffic from corporate; each segment has a firewall and a local Windows administration server. A pilot vaulted 40 accounts, but heartbeat fails for 28 and two applications broke after an RPC password change. The security team will not open broad SMB/RPC from corporate to OT. Operations wants automatic rotation every 30 days, but application owners insist on a rollback plan. The company also wants to avoid giving the Secret Server service account domain-wide rights. Distributed Engines are not yet deployed.
1. Where should Distributed Engines be placed, and what connectivity should be requested? Explain why this design is safer than opening corporate-to-OT SMB/RPC.
Read the worked answer
Place one Distributed Engine in each OT segment, preferably on the local Windows administration server, and assign that segment's secrets to the matching Site. The engine should initiate outbound HTTPS to the Secret Server application server; the target-side rules should allow only the engine to reach the specific servers on the ports required for heartbeat and password changing, such as SMB/RPC for Windows and SSH for Linux. Do not allow inbound connections from corporate to OT. This limits the blast radius: if the corporate network is compromised, an attacker cannot directly reach OT targets. It also lets each engine use a site-scoped RPC account with local rights only in that segment, rather than a domain-wide service account. The firewall rule should be destination-scoped to the server subnets, not 'any'. Test one engine and a small secret group before expanding.
2. Two applications broke after RPC. What Secret Server controls and rollout steps should be in place before enabling automatic rotation for the rest?
Read the worked answer
The failure shows that changing the password is not the same as updating everything that depends on it. Use dependency management: attach the service, scheduled task, application pool, or script that consumes each credential to the secret, and configure a dependency changer so the new password is propagated after the change. Before enabling a 30-day schedule, run heartbeat to confirm the credential is valid, test RPC on a pilot secret, and verify the application still authenticates. Roll out by application owner and secret group, not globally. Keep a documented rollback: the old password should not be retained in plaintext, but the application owner should have a tested procedure to restore service if propagation fails. Set RPC and heartbeat schedules to avoid a thundering herd, and alert on heartbeat or RPC failure rather than silently retrying. Automatic rotation should start only after a successful pilot and dependency validation.
3. What template and permission choices would you recommend for these service accounts, and why?
Read the worked answer
Use a service-account-oriented template that captures the account name, password, target host or service, service name, and dependency information, rather than a generic password template. Enable heartbeat and RPC on the template only where the changer is supported. Put OT secrets in Site-scoped folders, grant application owners View on their own secrets, and grant Edit or RPC administration only to the platform team. Avoid giving broad View at the OT root, because folder inheritance would expose all segments. For highly privileged accounts, require checkout or approval and consider DoubleLock. The RPC account itself should be a separate secret with restricted access and site-scoped rights, not the domain-wide account the company wants to avoid. These choices reduce standing access and make rotation auditable.