0XC00002F5

STATUS_MUST_BE_KDC (0xC00002F5): Why Your App Wants a Domain Controller

EP
Erropedia Team
📅 September 17, 2026 📅 Updated Sep 17, 2026 👁 3 views Windows Errors Intermediate
You're trying to run a service that needs Kerberos, but your machine isn't a domain controller. Here's why it happens and how to fix it.

You're probably seeing this after installing a service like SQL Server, IIS with Windows Authentication, or some third-party app that relies on Kerberos. The moment you try to start it, the Service Control Manager spits out STATUS_MUST_BE_KDC (0xC00002F5). Or maybe you're writing a quick script to test Kerberos and it fails with the same code. Either way, Windows is telling you something very specific: the operation you're asking for can only be performed by a Key Distribution Center, and your machine isn't one.

What's Actually Happening

Kerberos is the authentication protocol behind Active Directory. In a Kerberos realm, the KDC is the trusted third party that issues tickets. On Windows, that role is played by a domain controller. When a service or application tries to perform a Kerberos operation that requires KDC functionality — like issuing a ticket-granting ticket (TGT) or validating a service ticket — it calls into the Local Security Authority (LSA). If the LSA detects that the machine isn't a domain controller, it returns STATUS_MUST_BE_KDC.

The error isn't a bug. It's a guardrail. Microsoft doesn't want a random workstation acting as a KDC because that would be a security nightmare. So the check is hardcoded. The real question is: why is your application asking for KDC-level operations in the first place?

Common triggers include:

  • Configuring a service to use Kerberos constrained delegation without a domain controller present.
  • Running a custom app that calls LsaCallAuthenticationPackage with a KDC-only request.
  • Setting up a read-only domain controller (RODC) and then trying to perform a write operation that requires a full DC.
  • Using a third-party tool that assumes it's running on a DC (some backup or monitoring agents do this).
  • Manually creating a service principal name (SPN) on a non-DC machine — that operation must be done on a DC.

In most cases, the fix isn't to turn your workstation into a domain controller. It's to point the application at a real DC or to change how it authenticates.

How to Fix It

  1. Identify the process that's failing. Check Event Viewer under Windows Logs > System or Applications and Services Logs > Microsoft > Windows > LSA. Look for the service name or executable that triggered the error. If it's a service, note its name.
  2. Verify domain membership. Run whoami /fqdn in an elevated command prompt. If it returns a workgroup name (like WORKGROUP\YourPC), the machine isn't domain-joined. Join it to the domain. If it's already joined, skip to step 3.
  3. Check if a domain controller is reachable. Run nltest /dsgetdc:yourdomain.com. If it fails, you have a network or DNS problem. Fix that first. Kerberos won't work without a DC.
  4. Point the application to a domain controller. For services like SQL Server, open the service configuration and specify a domain account (not a local account) for the service logon. Then restart the service. The service will use the domain's KDC automatically.
  5. If the app requires KDC functionality, run it on a DC. Some legacy applications (think old backup software) literally need to run on a domain controller. In that case, install the app on a DC or use a jump server that is a DC. Don't try to hack around it — you'll break Kerberos.
  6. For custom code, adjust the request. If you're writing a program that calls LsaCallAuthenticationPackage, make sure you're not requesting KDC-only operations. Use Kerberos package with KerbQueryTicketCacheMessage instead of KerbRetrieveEncodedTicketMessage if you just need to read tickets.

After making changes, restart the affected service or reboot if you modified domain membership. Then test the operation again.

If It Still Fails

Check these things:

  • Time skew. Kerberos is picky about time. If your machine's clock is more than 5 minutes off from the DC, authentication fails silently. Run w32tm /resync.
  • SPN issues. If you're getting this error while trying to register an SPN, make sure you're running the command on a DC. Use setspn -A on a DC, not on a member server.
  • Firewall. Kerberos uses port 88 (TCP and UDP). Ensure your firewall allows traffic to the DC on that port.
  • DNS. Kerberos relies on DNS SRV records. Run nslookup -type=SRV _kerberos._tcp.yourdomain.com to verify they exist.

If none of that helps, the application might be genuinely misconfigured. Check its documentation for Kerberos requirements. Sometimes the fix is as simple as switching from Kerberos to NTLM authentication in the app's settings — but that's a security downgrade, so only do it if you understand the trade-offs.

Remember: STATUS_MUST_BE_KDC isn't a Windows bug. It's Windows telling you that you're asking the wrong machine to do a job only a domain controller can do. Point the request at a DC, or change what you're asking for.

Related Errors in Windows Errors
0X000020D3 Fixing ERROR_DS_CANT_REMOVE_ATT_CACHE (0x000020D3) 0X0000213F Fix ERROR_DS_INSTALL_NO_SRC_SCH_VERSION (0X0000213F) on DCPROMO 0XC0262583 Fix Error 0xC0262583: I2C Data Receive Failure on GPU 0X80320036 Fix FWP_E_TOO_MANY_SUBLAYERS (0x80320036) – too many WFP sublayers
STATUS_MUST_BE_KDC 0xC00002F5 Kerberos KDC error Windows domain controller required Kerberos authentication error service fails to start LSA error domain controller not found Windows Kerberos fix run service as domain controller KDC not available Windows security error

Was this solution helpful?

EP
Erropedia Team
Tech Support Editors
The Erropedia editorial team researches and documents real-world tech errors from across Windows, Linux, macOS, networking, databases, cloud platforms, and more. Every solution is reviewed for accuracy and updated as software and systems evolve.