Fix ERROR_IPSEC_IKE_NOTCBPRIV (0X0000361B) TCB Privilege Issue

When This Error Shows Up

You're setting up a VPN connection or an IPsec policy on a Windows Server 2019 or Windows 10/11 machine. Maybe it's a site-to-site tunnel using IKEv2. The connection fails, and you dig into the event log — there it is: ERROR_IPSEC_IKE_NOTCBPRIV (0X0000361B). The exact message reads: Failed to enabled trusted Win32 error codes Description computer base (TCB) privilege.

I've seen this most often when a third-party VPN client or a custom service tries to interact with the Windows IPsec stack. One client had it after installing a legacy L2TP VPN client on a domain-joined machine that had aggressive security policies. Another time it was a scheduled task running a script that manipulated IPsec rules — the task account didn't have the right juice.

Root Cause in Plain English

The error means whatever process is trying to use IPsec IKE (Internet Key Exchange) doesn't have the SeTcbPrivilege — the Trusted Computer Base (TCB) privilege. This is a heavy-duty permission. It's the kind of privilege the SYSTEM account has by default, and it lets a process act as part of the trusted computing base, basically the core of the OS security model. Without it, IPsec IKE refuses to initialize.

Why does this happen? Either:

• The process (like a service or app) runs under a user account that isn't granted SeTcbPrivilege.
• A Group Policy or Local Security Policy removed SeTcbPrivilege from the account that needs it.
• The account is in a restricted group that explicitly denies this privilege.

A common trigger: using a domain service account to run a VPN-related service, and the domain policy strips out SeTcbPrivilege from non-system accounts. Another scenario: an antivirus or security hardening script nukes the TCB privilege from all user accounts thinking it's a security risk. It is, but only if you don't trust the account holder.

The Fix: Grant SeTcbPrivilege

You have two paths: Local Security Policy UI or command line. I prefer the command line because it's faster and you can script it across machines. But I'll give you both.

Step 1: Identify the Account That's Failing

Check the event log again. Look under Windows Logs > System or Applications and Services Logs > Microsoft > Windows > IPsec. Find the error 0X0000361B. Note the user or service name in the details. Usually it's a specific service account, like NT SERVICE\YourVPNService or a domain account.

Step 2: Grant the Privilege via Local Security Policy (GUI)

1. Press Win + R, type secpol.msc, hit Enter.
2. Go to Security Settings > Local Policies > User Rights Assignment.
3. Find Act as part of the operating system (that's the human-readable name for SeTcbPrivilege).
4. Double-click it, click Add User or Group, type the account name (e.g., NT SERVICE\YourService or DOMAIN\ServiceAccount). Click OK.
5. Run gpupdate /force in command prompt to apply.
6. Reboot the service or the machine.

Step 3: Grant It via Command Line (Faster)

Open an elevated command prompt (Run as Administrator). Use secedit to export current policy, edit it, then import. Or just use ntrights (from the Windows Server Resource Kit) — it's simpler.

ntrights +r SeTcbPrivilege -u "NT SERVICE\YourVPNService"

Replace YourVPNService with the actual service name. If ntrights isn't available, download it from Microsoft or use PowerShell instead:

$sid = (Get-WmiObject Win32_Service -Filter "Name='YourVPNService'").StartName
$sid = $sid -replace '^.*\\(.+)$', '$1'
$principal = New-Object System.Security.Principal.NTAccount($sid)
$sidString = $principal.Translate([System.Security.Principal.SecurityIdentifier]).Value
# Then use secedit to add this SID to SeTcbPrivilege

But honestly, the GUI is less error-prone for one-off fixes.

Step 4: Check Group Policy Overrides

If the system is domain-joined, Group Policy might override your local change. Run rsop.msc and check under Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment. If Act as part of the operating system is defined by GPO, you need to either:

• Ask your domain admin to add the service account to that GPO.
• Or move the service to run as Local System (which already has the privilege).

I had a client where a group policy explicitly removed TCB from all non-admin accounts. We had to create a separate GPO that added the service account back, placed it at a lower precedence so it still applied. Took longer than it should have.

If It Still Fails

Check these:

• Is the service account correct? If the service runs as NT SERVICE\Something, that's a virtual account. Grant the privilege to that exact name, including the NT SERVICE\ prefix.
• Did you reboot? Some privileges only take effect after the service or the OS restarts. I've seen people change the policy and wonder why it didn't work — restart the service, at least.
• Is the service actually running under the account you think? Run services.msc, check the Log On tab of the service. It might be set to Local System, which already has TCB. Then the error might be from a different process — like a scheduled task or a COM object. Recheck the event log for the exact process ID.
• Third-party software conflict? Some VPN clients install their own TCB-aware drivers. If you uninstalled and reinstalled, the old driver might linger. Use sc query to look for orphaned IPsec-related services. Wipe them with sc delete if they're dead.

One last thing: don't go around granting SeTcbPrivilege to every account. It's powerful. A malicious process with it can impersonate any user or service. Only grant it to the specific service that needs it. I've seen people throw it on Network Service and cause chaos. Be specific.

That's it. You should be able to get that IPsec tunnel up now.