The maintenance job reads its password from a file

A management server checks services on several member servers every night. Its script imports a credential file exported years ago. Nobody is certain which team owns the account, which other jobs use it, or why it has administrator rights on every target. After a server migration, decryption fails. The quick repair produces another file.

These dependencies survive even when WinRM Basic Authentication has been disabled. Transport, authentication method and secret storage are separate controls. The existing article on disabling Basic Auth addresses the protocol baseline; this article covers identities, password lifecycle and retiring credential copies.

The scope includes administrative workstations, automation servers, scheduled tasks and their actual targets. Review Tier-0 administration separately. Cleaning up credentials must not introduce a new route from a general job server to domain controllers.

Give every connection an accountable identity

For interactive domain administration, start with the signed-in, appropriately authorized identity on a protected management workstation. Give automation a dedicated service identity with only the required rights. If a password is unavoidable, manage it centrally and provide it when needed. It belongs neither in a repository nor in a profile directory as a permanent administrator credential.

Acceptance requires more than a successful job: document the execution account, permitted targets, required operations, downstream resources and responsible team. Demonstrate recovery without a personal credential file. Removing a permission must produce a visible failure, not an automatic retry with a more powerful account.

Encrypted credential files remain usable secrets

On Windows, Export-Clixml protects exported credentials with DPAPI, tying decryption to the user and computer. On Linux and macOS, this export does not provide equivalent encryption. The Windows binding protects the file in certain access scenarios; it does not establish a security boundary against processes running as the authorized user.

Operationally, the script must still recover and use the secret. A SecureString or XML file cannot replace restricted permissions, rotation and protection of the execution system. A separately stored decryption key does not solve the problem if the same job can read both files.

Map dependencies without collecting passwords

Start with approved script locations, job definitions, runbooks and configurations. Look for uses of Import-Clixml, explicit credentials, Credential Manager entries and fixed RunAs accounts. Record location and purpose. Do not decrypt secrets or copy them into tickets or centralized search results.

Six fields are initially sufficient for each workflow: starting system, execution account, target, required rights, additional resources and owner. Include monthly tasks, recovery jobs and manually triggered maintenance. The absence of a password parameter in a script does not prove that the execution platform stores no password.

Assign a replacement pattern to each finding before migration. Deleting all Credential Manager entries or resetting a shared account without mapping its consumers would not be a controlled cleanup. Keep the inventory specific enough that another operator can identify the intended dependency without opening a secret.

Verify Kerberos on the direct remoting path

For direct access from a management workstation to a domain server, Kerberos can use the current identity without passing a separately stored password to the script. DNS, time synchronization, trust and service identity must match the target name. Selecting Negotiate does not prove that Kerberos was used.

This read-only test explicitly requires Kerberos. Replace the example hostname with an approved FQDN and run it in the intended execution context:

$remoteCheck = @{
    ComputerName = 'srv01.ad.example.com'
    Authentication = 'Kerberos'
    ErrorAction = 'Stop'
    ScriptBlock = {
        [pscustomobject]@{
            Computer = $env:COMPUTERNAME
            Identity = [System.Security.Principal.WindowsIdentity]::GetCurrent().Name
        }
    }
}
Invoke-Command @remoteCheck

The test checks authentication and effective identity in the standard endpoint. It does not establish application permissions or access to another server. A scheduled job must also run under its real account; success in an administrator session is insufficient. Investigate naming, SPNs and permissions when it fails, rather than enabling Basic or broad TrustedHosts entries.

Choose gMSAs and restricted endpoints for automation

Where the execution platform supports a group Managed Service Account, Windows manages its password. A gMSA remains an identity that can hold privileges. Limit its use to the intended hosts and grant only necessary target rights. Demonstrate scheduler or product support before moving the job.

Just Enough Administration suits recurring, bounded administration tasks. Shape the allowed commands and parameters around the operation. Virtual accounts avoid a maintained RunAs password for local work; a gMSA can provide the execution identity when network access is required. Session records must connect that shared service identity to the original caller.

JEA virtual-account defaults require special care on domain controllers: without an adjusted group assignment, those accounts receive Domain Admins membership. Constrain commands and deliberately reduce execution privileges. Adding a JEA endpoint does not remove a user's existing full administrator access.

If an application requires a password, consider an operated vault with a restricted access identity, rotation and audited retrieval. Authentication to that vault also needs a workable design. SecretManagement can provide an interface, but it does not guarantee secure storage or automatic rotation. Putting a vault token beside the script would simply create another permanent secret.

Design the second hop as a separate access path

When computer A connects to B through remoting and B needs a resource on C, there is another authentication path to design. Successful Kerberos access to B does not automatically authorize access to C. CredSSP can make credentials available on B, increasing the trust placed in that host; it is not the default replacement for a removed password file.

First assess whether orchestrator A can contact both targets directly and combine their results. Otherwise, B needs a deliberately chosen, restricted execution identity. Kerberos Constrained Delegation and Resource-based Constrained Delegation do not support a second hop over WinRM. For other downstream services, validate their protocol separately.

Migrate, observe and invalidate the old secrets

Include a frequent job, an infrequent maintenance workflow and a workflow with an additional network resource in the pilot. Provision the identity and permissions, switch the job, then verify its result and logging. Failed attempts must identify the affected target and operational error without exposing secrets.

After acceptance, remove old references and active credential copies individually. Retire unused accounts; coordinate all consumers before rotating static passwords that remain necessary. Backups and repository history may contain earlier copies. Deleting current files does not invalidate those copies. Account retirement must also consider previously issued tickets and existing sessions.

Recovery should have a defined procedure, an owner and a time-limited exception if needed. It must not depend on a forgotten copy of the previous Domain Admin password. Record which test confirms recovery and where the responsible operator can find its runbook.

Advantages: fewer copies and clearer ownership

  • Reusable administrator secrets disappear from everyday script and profile directories.
  • Separate service identities limit the effects of an individual misbehaving job.
  • Permissions, targets and owners become reviewable for each workflow.
  • Recovery and account changes become planned operations rather than dependencies on personal exports.

Disadvantages and limits: the execution host remains critical

  • Role design, migration and testing take time; older products do not support every identity pattern.
  • A compromised authorized host can still perform its permitted operations.
  • gMSAs and vaults reduce manual password handling but cannot replace secure host administration.
  • Shared execution identities complicate attribution without adequate session records.
  • Vault outages, permission changes and rarely used jobs require an established operating procedure.

Project checklist for acceptance

  • Identify credential use and infrequent workflows without collecting secrets.
  • Define execution accounts, targets, rights and owners for each job.
  • Separate Tier-0 access from general server automation.
  • Verify direct Kerberos access in the actual execution context.
  • Demonstrate gMSA support or the chosen vault authentication method.
  • Review JEA commands, parameters and effective execution privileges.
  • Document every second hop, its target protocol and identity decision.
  • Pass positive functional tests and negative permission tests.
  • Ensure logs support attribution and troubleshooting without passwords or tokens.
  • Remove old copies, invalidate affected secrets and account for existing sessions.
  • Assign recovery, exception expiry and recurring access review to a team.