STATUS_NOT_ALL_ASSIGNED 0X00000106 - Quick Fix

1. Missing SeTcbPrivilege (Act as part of the operating system)

This is the most common cause. A service or scheduled task needs the SeTcbPrivilege but the account assigned to it doesn't have it. You'll see this error when a service tries to log on with a low-privileged account (like Local Service) but the service code requests privileges that require Act as part of the operating system.

Fix:

1. Open Local Security Policy → Local Policies → User Rights Assignment.
2. Find Act as part of the operating system.
3. Add the account that's running the service (e.g., NT AUTHORITY\LOCAL SERVICE).
4. Run gpupdate /force from an admin command prompt.
5. Restart the service.

Don't bother adding the account to Log on as a service — that's a different privilege. The error here is specifically about privilege assignment, not logon type.

2. Incorrect Logon Type for the Service Account

Sometimes the service is set to log on with Logon type 5 (Service) but the account lacks the Log on as a service user right. This is less common than #1, but happens when a domain account is misconfigured in Group Policy.

How to check:

• Open Event Viewer → Windows Logs → Security.
• Filter for Event ID 4625 (logon failure). Look for Status: 0x00000106 and Logon Type: 5.

Fix:

1. Go to Local Security Policy → User Rights Assignment → Log on as a service.
2. Add the service account if it's missing.
3. If the service uses NT AUTHORITY\SYSTEM, this isn't needed — SYSTEM always has this right.
4. Check if the service is using a Managed Service Account (MSA) — those need explicit assignment in some environments.

3. Group Policy Override Blocking the Privilege

You might have added the right locally, but a Group Policy from the domain is removing it on the next refresh. This is a sneaky one. I've seen it happen when someone removes Everyone or Authenticated Users from a privilege, not realizing a service depends on them.

Diagnose:

• Run rsop.msc (Resultant Set of Policy) and check User Rights Assignment.
• Compare what's listed there vs what you set locally. If local changes are grayed out, GPO wins.

Fix:

1. Work with your domain admin to modify the GPO that's applying the privilege settings.
2. If you can't change the GPO, use a Group Policy loopback processing to apply a custom GPO that adds the privilege back.
3. Or switch the service to use NT AUTHORITY\SYSTEM — it bypasses most privilege issues.

Quick-Reference Summary Table

If none of these work, check if the service itself is buggy — some third-party services incorrectly request privileges they don't need. In that case, contact the vendor.