Break-Glass Credential Rotation ​

The manual procedure for four Security Posture findings that have no automated fix, because the fix needs a step GraphnAI can't safely take on its own.

Requires role: Operator or Admin to see the findings on Security Posture. The procedures run in your directory, with your own administrative rights there.

Related: Account Security & Credential Hygiene Checks | Cross-Tier Credential Exposure | Remediation Action Catalog | Remediation Reversibility and Undo

Overview ​

Many failing checks on Exposure > Security Posture come with a fix you can run: open Select Fire from the check, review the change, and apply it. Four checks are different. Their flyout shows No automated fix with the reason, in the place the Select Fire button would be.

Each of their fixes needs a step GraphnAI doesn't take on its own: a timed wait between two resets, a safe place to deliver a new secret, or a change in how people work. This guide is the manual procedure for each of the four. Where the flyout also reads "An automated fix is planned.", a direct action for that check is planned.

Prerequisites ​

  • Administrative rights in the directory where the check failed.
  • A secure way to hand a new secret to whatever depends on it: a password manager, a sealed ticket, or your existing break-glass process.
  • For the KRBTGT rotation, a maintenance window that holds the full wait described below. Don't shorten it.

Check 1: The KRBTGT Password Is Old ​

This is the check KRBTGT password older than 180 days. The flyout reads "Every ticket in the domain depends on this key, so the two rotations run as a planned procedure."

Why it isn't automated ​

Every Kerberos ticket in the domain is signed with the KRBTGT account's key. One password reset doesn't replace that key cleanly. The safe procedure is two resets at least 10 hours apart, so the tickets signed before the first reset expire in between. Getting the timing wrong can break sign-in across the domain, so the rotation runs with a person watching it.

Manual procedure ​

  1. Schedule a window that allows at least 10 hours between the two resets.
  2. Reset the KRBTGT password once, to a strong random value.
  3. Wait at least 10 hours. Sign-ins and existing tickets keep working during the wait.
  4. Reset the password a second time, to a new random value.
  5. Confirm tickets are being issued normally (see below).

Don't reset twice in quick succession. The wait between the resets makes the rotation safe.

How to confirm it worked ​

  • Both resets appear in the domain's security event log, at least 10 hours apart.
  • After the second reset, sign in with a test account and confirm it gets a ticket without error.
  • The check passes after the next successful sync reads the new password date.

The check reads only the password date. It passes after the first reset, so it can't tell you whether the second reset ran. Complete both.

Check 2: The Built-in Administrator Password Is Old ​

This is the check Built-in Administrator password older than 180 days. The flyout reads "Rotating the break-glass password needs a safe place to keep the new one, so it runs as a guided procedure."

Why it isn't automated ​

The reset is one write. The problem is where the new password goes: a person has to be able to retrieve it in an emergency. GraphnAI doesn't hold a vault or a delivery path for that secret. A new password with nowhere to go would trade an old-password finding for a lockout.

Manual procedure ​

  1. Generate a strong random password with your organization's approved method.
  2. Reset the built-in Administrator password to the new value.
  3. Store the new password in your break-glass credential vault, following your existing break-glass process.
  4. Record the rotation date where your team can find it.

How to confirm it worked ​

  • Have a second person retrieve the new password through your break-glass process before you close the change.
  • The check passes after the next successful sync reads the new password date.

Check 3: The Built-in Administrator Was Used Recently ​

This is the check Built-in Administrator used in the last 14 days. The flyout reads "The built-in Administrator is on GraphnAI's safety list, so no automated action changes it."

Why it isn't automated ​

This check records who signed in. It isn't a directory setting to change. No write stops a person from choosing to use this account, so the fix is a change in practice: give every administrator a named account, and keep the built-in account for emergencies.

Manual procedure ​

  1. Find out who used the built-in Administrator account, and whether it was a planned emergency or routine use.
  2. Give every administrator who needs regular elevated access a named account, with only the access they need.
  3. Move any scheduled task, service or script that runs as the built-in Administrator onto a named service account.
  4. Tell your administrators the built-in account is for break-glass use only, and document when it may be used.

How to confirm it worked ​

  • Watch for sign-ins on the built-in Administrator account over the following weeks. Once named accounts replace routine use, the check stops failing.
  • Confirm the tasks and scripts you moved in step 3 run successfully under their new account.

Check 4: A Credential Is Exposed Across Tiers ​

This is the check Cross-tier credential exposure. A Tier 0 credential was seen on a computer where a lower-tier account holds rights that can steal it. The flyout reads "The holder's rights on this computer come from group policy or local user rights, which GraphnAI doesn't change."

Why it isn't automated ​

Two parts of the fix aren't directory writes. The lower-tier account's rights on the computer come from Group Policy or the computer's local security policy. The exposed credential also needs rotating, with the new value delivered to everything that uses it. That needs a secret delivery path GraphnAI doesn't have.

Manual procedure ​

  1. List every place the exposed credential is used: services, scheduled tasks, applications and interactive sign-ins.
  2. Remove the lower-tier account's right on the computer. If a GPO grants it, keep the user rights setting and remove the account from it. If local security policy grants it, remove it there.
  3. If the Tier 0 account shouldn't sign in to that computer, stop it signing in there. If it has to, make it connect with Remote Desktop in Restricted Admin Mode.
  4. Rotate the exposed credential to a new strong password or secret.
  5. Deliver the new secret to every system you listed in step 1 before you move on.
  6. Confirm no service or scheduled task still uses the old credential.

How to confirm it worked ​

  • Every system from step 1 runs successfully with the new credential.
  • The finding closes when GraphnAI sees evidence the right is gone. A GPO change shows after the next full sync. A local policy change shows within seconds, when the computer logs event 4705. Signing the Tier 0 account out, or letting time pass, doesn't close it. See How an exposure clears.

Troubleshooting ​

A check still fails after the rotation ​

Checks 1 to 3 update when a sync runs. Confirm a sync has completed for the domain after your change, then look at Security Posture again. If the check still fails, confirm the new password is in place. A rotation that stopped partway, for example a skipped KRBTGT reset, looks the same to GraphnAI as no rotation.

For check 4, see A finding stays open after the fix.

The maintenance window is shorter than 10 hours ​

Don't shorten the wait to fit the window. A shorter wait can invalidate tickets that are still in use, which is a wider outage than the finding. Move the second reset to a window that allows the full 10 hours.

The cross-tier finding names an unfamiliar host ​

Confirm the host is still part of your environment before you rotate anything. A decommissioned host whose record was never removed can appear here. If so, remove the stale record instead of rotating a credential for a host that no longer exists.