Fix Kerberos Delegation Findings
Understand the delegation and Kerberos checks on the Security Posture page, and fix the ones GraphnAI can fix with Select Fire.
Requires role: Operator (run a finding's fix from Security Posture); Admin (also set up remediation credentials). Viewers see the finding and its evidence, with no Select Fire button. Related: Select Fire, Remediation Action Catalog, Semi-Auto Execution, Remediation Reversibility and Undo, Delegation Risk, AD Permission Revocation, Account Security & Credential Hygiene Checks
Overview
Three Security Posture findings on Kerberos delegation now offer Select Fire. Select Fire previews the change, simulates it, and runs it for you with your approval.
| Finding | What Select Fire can do |
|---|---|
| Other accounts can act on this object's behalf (resource-based constrained delegation) | Remove the accounts you select, or clear the whole setting |
| Unconstrained delegation on an account that is not a domain controller | Clear the setting |
| Delegation with protocol transition enabled | Clear the setting |
Every delegation change runs in Semi-Auto only. You authorize each action. Full-Auto is unavailable and reads "Delegation changes always need a person to approve them."
Domain controllers and read-only domain controllers are refused. They need these settings to issue Kerberos tickets.
The Delegation and Kerberos category on Security Posture has eleven more checks, on directory permissions, Kerberos settings and managed service accounts. Five offer Select Fire. The rest give manual steps with the reason. See The permission and Kerberos checks.
Prerequisites
- An Operator or Admin role.
- The Identity Bridge for the domain is connected.
- An Admin has saved and validated remediation credentials for the domain. The account needs the rights in Required account rights.
Step-by-step
Remove accounts from a resource-based delegation setting
Requires role: Operator or Admin
Select Exposure > Security Posture, then open the finding "Other accounts can act on this object's behalf (resource-based constrained delegation)".
In the flyout, select Select Fire.
In Preview, read the list. It has one row per account the object lists. Nothing starts selected.
Select the accounts to remove. Or select the step that clears the whole setting instead.
Select Simulate, then continue to Decision.
Check the coverage line. It shows how many of the object's accounts the plan removes, such as "2 of 3 accounts". It also says "This plan closes this finding." or "This finding stays until the remaining account is removed."
Choose Semi-Auto, then select Authorize on each action.
An account with no collected object gets a badge:
| Badge | What it means |
|---|---|
| Everyone in the domain | Any signed-in account, or any computer account, can use this entry. |
| Built-in account | A well-known account that has no object in the collected data. |
| Not in collected data | The account may be deleted, or in a part of the directory the last collection didn't read. |
| Another forest | The account belongs to a forest GraphnAI hasn't collected. |
Each of these rows says the account's reach can't be measured. GraphnAI scores it as the highest, so removing it counts as a large reduction.
Clear unconstrained delegation or protocol transition
Requires role: Operator or Admin
- On Security Posture, open "Unconstrained delegation on an account that is not a domain controller" or "Delegation with protocol transition enabled".
- Select Select Fire. The step that clears the setting starts selected.
- Select Simulate, then continue to Decision.
- Choose Semi-Auto and select Authorize.
Read the disruption note before you authorize. Clearing unconstrained delegation stops services on the host from forwarding users' credentials. Clearing protocol transition stops applications that sign users in without Kerberos from reaching back-end services as those users.
Undo a delegation change
Requires role: Operator or Admin
Open Remediation history, find the action, and select Undo. Undo restores the setting. For resource-based delegation, it puts back the accounts the change removed, or the whole setting if you cleared it.
The restore directions can't be started on their own. If you try, you see "This change only runs as the Undo of an earlier fix, so it can't be started on its own." See Remediation Reversibility and Undo.
| Change | Undo class |
|---|---|
| Clear unconstrained delegation, Clear protocol transition | Reversible |
| Remove an account allowed to act on this object, Clear resource-based delegation | Reversible from saved state |
Work from the Delegation Risk page
Requires role: Operator or Admin
On the Delegation Risk page, a trustee with observed usage (Validated) shows Select Fire first on its row. Other trustees lead with their usage evidence. When two sources have equal scores, the one with poorer conformance sorts first.
The permission and Kerberos checks
Each check below appears under the Delegation and Kerberos category card on Exposure > Security Posture. Open a finding to see its evidence in the drawer, the reason it matters under Why this matters, and the fix under How to fix it.
"Tier 0" means the accounts and systems that control the whole directory. A "lower-tier" account is any account outside Tier 0. If the tier of an account hasn't been worked out yet, the evidence shows Tier not known and the check reports the account anyway.
Permissions on the domain
These three checks look at who holds powerful permissions on the domain object itself.
Non-default account can replicate directory secrets (Critical)
- Looks for: an account other than a domain controller or built-in administrator group that holds the DCSync right, or full control, or the right to change permissions or ownership on the domain.
- Why it matters: the account can copy every password hash in the domain, or give itself that right.
- Drawer: Permissions on the domain shows the domain with the rights this account holds. A line reads "This may be a product permission. Confirm it before removing it." where the account matches a known product default.
- Fix: Select Fire removes the account's replication and permission-changing entries. Review the Preview first, because other software may rely on them.
Directory synchronization account can replicate directory secrets (Critical)
- Looks for: an account whose name starts with
MSOL_orprovAgentgMSA, the names Microsoft Entra Connect and Cloud Sync use, with replication rights on the domain. - Why it matters: the account can read every password in the domain. Whoever controls it, or its server, controls the domain.
- Drawer: Permissions on the domain, with the badge Looks like a directory synchronization account. The badge is a name match, not proof. Someone can copy a name, so confirm the account is yours.
- Fix: manual. Keep the rights if the account is yours, and protect it and its server like a domain controller. If you don't recognize it, remove its replication rights. Removing them from a real synchronization account stops password hash synchronization, so GraphnAI doesn't offer a fix.
Exchange permissions group can change the domain's permissions (High)
- Looks for: the group Exchange creates, found by its name and location, holding the right to change the domain's permissions.
- Why it matters: anyone who controls an Exchange server or this group can give themselves the right to read every password in the domain.
- Drawer: Permissions on the domain, with the badge Looks like the Exchange permissions group.
- Fix: manual. Install a current Exchange cumulative update and run its Active Directory preparation step. That reduces the group's rights. Removing the right by hand can break Exchange, so GraphnAI doesn't offer a fix.
Permissions on accounts and Tier 0 objects
These checks look at who can change a particular account or Tier 0 object. Their drawer lists Accounts with this permission. Each row shows the account, its rights, and the badge Lower tier. A row with Any account means everyone who signs in holds the right.
Lower-tier account can set up delegation on a Tier 0 object (Critical)
- Looks for: an account outside Tier 0 that can change delegation settings on a Tier 0 object.
- Why it matters: it can let an account it controls sign in to that object as anyone.
- Fix: Select Fire removes the permission to change delegation settings. Software that sets delegation through that account stops working. You can undo the change.
Account can add a service name to an account that has none (Medium)
- Looks for: an enabled user or service account with no service principal name (SPN), where an account outside Tier 0 can add one.
- Why it matters: once a service name is added, the account's password can be cracked offline from a Kerberos ticket.
- Fix: Select Fire removes the permission to change service names. A tool that registers service names through that account stops working. You can undo the change.
Lower-tier account can change another account's service or sign-in name (High)
- Looks for: an account outside Tier 0 that can change another account's service names or sign-in name (the user principal name, UPN).
- Why it matters: changing a sign-in name can let the account obtain a certificate that signs in as someone else.
- Fix: Select Fire removes the permission to change service and sign-in names. A tool that renames accounts through that account stops working. You can undo the change.
Key credentials on, or writable to, a Tier 0 object (High)
- Looks for: a Tier 0 object that carries key credentials, or that an account outside Tier 0 can add them to.
- Why it matters: a key credential lets its holder sign in as the object without the password.
- Drawer: Key credentials shows a count and one row per key: Windows Hello or device key, Security key or Other key, with Registered device and the creation date where known. Windows Hello keys look the same as an attacker's key, so every key is listed. If a key can't be read, the drawer says "Some key credentials on this object could not be read, so they are counted as present." Accounts with this permission covers the write permission.
- Fix: Select Fire removes the permission to add key credentials. It doesn't remove the keys. Check each key, and remove the ones you don't recognize by hand.
Kerberos settings and managed accounts
These five checks have no automatic fix. Each says why in the drawer, and gives manual steps.
Managed service account password readable too broadly (High, Critical when the account is Tier 0)
- Looks for: a group managed service account (gMSA) whose password can be read by accounts of a lower tier than the managed account.
- Why it matters: anyone who takes over one of those accounts can sign in as the service.
- Drawer: Accounts that can read this password.
- Why no fix: GraphnAI doesn't change who can read a managed account's password, because the wrong change stops the service. Limit the readers to the servers that run it.
Service account allows the weak RC4 cipher for Kerberos (Medium, High when RC4 is set without AES)
- Looks for: an enabled service account with a service name that allows RC4 encryption.
- Why it matters: any signed-in user can request a ticket for the account and try to crack its password offline.
- Drawer: Kerberos encryption reads "Allowed encryption: RC4" or "Allowed encryption: RC4, AES".
- Why no fix: GraphnAI doesn't change an account's allowed encryption, because a service that only supports RC4 stops working. Set the account to AES only, confirm the service still works, and reset its password.
Computer or trust account password may be guessable offline (Low, Medium for the first and third cases)
- Looks for: a computer or trust account with a password that may not be random. The drawer's Why the password may be guessable gives one of three reasons: "Created in advance and never signed in", "Signs in, but its password has not changed in over 60 days", or "Trust account password unchanged in over 90 days".
- Why it matters: any signed-in user can ask a domain controller for a time reply signed with the account's password, then try to guess it offline.
- Why no fix: GraphnAI doesn't reset computer or trust passwords, because a reset out of step with the other side breaks sign-in. Reset the password (for a trust, from both sides), or remove the account if it's unused.
Delegated managed service account can take over another account's keys (High, Critical when the target is Tier 0)
- Looks for: a delegated managed service account (dMSA) linked to another account as its replacement, where accounts outside its owners can read its keys or control it.
- Why it matters: through that link, they receive the other account's keys.
- Drawer: Account takeover pairing shows the two accounts, the state ("Migration in progress" or "Migration completed"), and the lists Can read the keys and Can control the managed account.
- Why no fix: GraphnAI doesn't change managed account migrations, because the wrong change breaks the service being migrated. If you didn't start the migration, remove the link from both accounts. If you did, limit who can read the keys and who can change the account to the service's owners.
- Requires: Windows Server 2025 domain controllers. Without them, the domain has no delegated managed service accounts to check.
Service names nobody registers
Constrained delegation to a sensitive service now lists delegation entries that no account registers. The drawer adds Service names nobody registers, with each name. It reads "An account that can add service names can claim this one and receive the delegated tickets."
This section appears on a finding that already fails because of a sensitive entry. It tells you which other entries are open to takeover. Select Fire removes the sensitive entries. Remove the unregistered names from the account's delegation list by hand.
Fix permission entries with Select Fire
Requires role: Operator or Admin
Five checks offer Select Fire on permission entries:
| Check | What Select Fire removes |
|---|---|
| Non-default account can replicate directory secrets | Replication and permission-changing entries on the domain |
| Lower-tier account can set up delegation on a Tier 0 object | The permission to change delegation settings |
| Account can add a service name to an account that has none | The permission to change service names |
| Lower-tier account can change another account's service or sign-in name | The permissions to change service and sign-in names |
| Key credentials on, or writable to, a Tier 0 object | The permission to add key credentials |
- Open the finding and select Select Fire.
- In Preview, read the list of permission entries the finding names. Nothing starts selected.
- Select the specific entries to remove.
- Select Simulate, then continue to Decision.
- Choose Semi-Auto and select Authorize on each action. Semi-Auto is the most these fixes allow.
The fix reduces the finding without always closing it. Another account may still hold the right. The finding clears at the next collection that shows no qualifying permission.
Some entries are refused, each with a reason in the Preview:
| Entry | Why it's refused |
|---|---|
| Inherited from a parent container | "Inherited from a parent container. Removing it at the source isn't supported yet." |
| On an account protected by AdminSDHolder | "This object's permissions are reset from the protected-accounts template every hour. Change the template instead." |
| A built-in holder of replication rights | "This is one of the built-in accounts or groups that hold these permissions for directory replication by design. Removing them could stop domain controllers from staying in sync." |
If the permission is already gone, the Preview says "This permission is no longer on the object. The finding clears at the next collection." To undo a removal, see Undo a delegation change. The removal needs the same remediation account as other permission removals. See AD Permission Revocation.
The Entra Connect account
The directory synchronization account is reported once, under Directory synchronization account can replicate directory secrets. It doesn't appear in the checks on service names, sign-in names or key credentials, where it holds rights by design.
What "Not assessed" means here
A check reads Not assessed when it couldn't look at the data. It never counts as a pass. For these checks there are two causes:
- An attribute isn't collected yet. The line names it, for example "the msDS-KeyCredentialLink attribute isn't in the sync profile". Several of these checks read attributes that older syncs didn't collect. The check resolves after the next full sync.
- The domain has too many permission entries. The line reads "This domain has more permission entries than one pass can assess."
Select the "not assessed" line on the category card to see each check and what it's missing.
Notes
- An unset Kerberos encryption value is AES-only. On patched domain controllers, an account with no encryption value gets AES. The RC4 check flags only accounts where RC4 is set explicitly. It assumes your domain controllers have the July 2026 or later update, and it can't see a registry override on them.
- Name matches are hints. The directory synchronization and Exchange badges come from account names and locations. Confirm the account before you act.
- dMSA findings need Windows Server 2025 domain controllers.
Required account rights
The remediation credential is a dedicated Active Directory account. See Configuring Remediation Credentials. Delegation changes need these rights.
| Change | What the account needs |
|---|---|
| Resource-based delegation (remove an account, clear, restore) | Write access to the User-Account-Restrictions property set, or to the msDS-AllowedToActOnBehalfOfOtherIdentity property, on the target objects |
| Unconstrained delegation or protocol transition (clear, restore) | The same write access, and the user right "Enable computer and user accounts to be trusted for delegation" |
Grant the user right through the Default Domain Controllers Policy. Without it, changes to the two delegation settings fail with the message under Troubleshooting. Resource-based delegation changes still work.
Don't grant the right to change permissions (WriteDacl) for these changes. Write access to the property is enough.
Scope the grant to the organizational units that hold delegation findings. Don't grant it at the domain root. Write access to this property lets its holder set up resource-based delegation on any object it covers. It's a known takeover path. Cover the Domain Controllers OU only as a deliberate, separate choice. Domain controllers are refused anyway.
Troubleshooting
"The directory refused the change because the remediation account doesn't hold the right to enable accounts for delegation"
The account lacks the user right. Grant it through the Default Domain Controllers Policy, or make the change by hand. Nothing was changed.
"The directory refused the change. The remediation account needs write access to this delegation setting"
The account can sign in but can't write the setting. Grant write access on the User-Account-Restrictions property set for the object's OU. Some settings also need the user right above.
"No directory write account is set up for this domain"
An Admin must add credentials under Admin > Remediation Credentials. You can still preview and simulate.
"This is a domain controller" or "This is a read-only domain controller"
The change is refused for everyone, Admins included. Controllers need the setting.
"This entry isn't a valid account identifier, so it can't be removed here"
Remove the entry by hand in the object's properties.
"This account couldn't be looked up. Try again shortly."
The lookup failed. Try the action again in a minute.
"No accounts are listed on this object any more"
Another change already removed them. The finding clears at the next collection.
A permission entry shows as refused in the Preview
The reason is in the row. Inherited entries are removed at the container they come from. Protected accounts take their permissions from the protected-accounts template, so change the template. Built-in replication holders are never offered.
A permission check reads "Not assessed"
Run a full sync if the line names an attribute. If it says the domain has more permission entries than one pass can assess, the check can't run on that domain yet. Neither case counts as a pass.