Elyse KCD CONFIGURATION

OVERVIEW

What is KCD? Kerberos Constrained Delegation (KCD) is a Windows security feature that allows one service to act on behalf of a user when talking to another service. In the context of Elyse, it allows the backend web server to “pass along” the identity of the person using the application when it connects to the database. This means the database knows which user is making each request, not just that “the backend application” is making a request.

This is essential for the security model: every database connection is made under the Windows identity of the actual user, not the application service account. Without KCD, the backend cannot pass the user's identity through to SQL Server (the “double-hop” problem), and all database connections would appear as the service account, breaking user-level access control.

This document covers:

Prerequisites from previous steps:

PREREQUISITES

Replace YOURDOMAIN, hostnames, and FQDNs with your actual values throughout this document.

BACKGROUND: THE DOUBLE-HOP PROBLEM

Why is this section important? Understanding the double-hop problem helps you understand why all the steps in this document are necessary. If you just want to get things working, you can skip ahead to Step 1, but reading this section will help you troubleshoot if something goes wrong.

In a standard Windows Authentication scenario, there are two “hops” (network connections):

User's PC --> Backend Server (Hop 1) --> SQL Server (Hop 2)

Hop 1: When a user opens the Elyse application in their web browser, their PC authenticates to the backend server. Windows handles this automatically — the user does not need to type a password because they are already logged in to the domain.

Hop 2: The backend server then needs to connect to SQL Server to fetch data. Ideally, it should connect as the user so that SQL Server knows who is actually requesting the data.

The problem: By default, Windows does not allow the backend to forward the user's credentials to SQL Server. The backend knows who the user is (from Hop 1), but it cannot prove that identity to SQL Server (Hop 2). This is the “double-hop” problem.

KCD solves this by doing two things (which are the two main steps in this document):

  1. Registering SPNs (Step 1 below) — this tells Windows “the svc_sql account runs SQL Server on this machine” and “the svc_elyse_be account runs the HTTP backend on that machine.” Think of SPNs as name tags that link a service to the account that runs it.
  2. Configuring Constrained Delegation (Step 2 below) — this tells Windows “the svc_elyse_be account is allowed to request Kerberos tickets on behalf of users, but only for the SQL Server service.” This is the “constrained” part — it cannot impersonate users to any other service.

The result is that SQL Server sees the actual user's Windows identity on every connection, enabling user-level access control in the database.

STEP 1: REGISTER SERVICE PRINCIPAL NAMES (SPNs)

SPNs link a service (e.g., SQL Server, HTTP) to the domain account that runs it. Kerberos uses SPNs to locate the correct account when issuing tickets. Without SPNs, Kerberos cannot determine which account is responsible for a service, and authentication will fail.

Perform these commands on the Domain Controller (e.g., DC01) while logged in as a Domain Administrator.

How to open a Command Prompt as Administrator:

  1. Click the Start button (the Windows icon in the bottom-left corner of the taskbar, or press the Windows key on your keyboard).
  2. Type cmd (you do not need to click anywhere first — just start typing and the search will appear).
  3. In the search results, you will see Command Prompt. Right-click on it.
  4. Select Run as administrator from the context menu.
  5. If a “User Account Control” (UAC) prompt appears asking “Do you want to allow this app to make changes to your device?”, click Yes.
  6. A black window with white text will open. The title bar should say Administrator: Command Prompt (the word “Administrator” confirms you have elevated privileges).
Important: In the commands below, replace ELYSE-SQL01, ELYSE-BE01, yourdomain.com, and YOURDOMAIN with your actual server hostnames, FQDN, and domain name. The hostnames must exactly match the server names as they appear in Active Directory.

In the Command Prompt window, type or paste each of the following commands and press Enter after each one:

SQL Server SPNs (link SQL Server to svc_sql)

These two commands tell Windows: “The svc_sql account is responsible for running SQL Server on the machine named ELYSE-SQL01.” Two commands are needed — one using the full domain name (FQDN) and one using just the short hostname — because clients may connect using either form.

setspn -S MSSQLSvc/ELYSE-SQL01.yourdomain.com:1433 YOURDOMAIN\svc_sql
setspn -S MSSQLSvc/ELYSE-SQL01:1433 YOURDOMAIN\svc_sql

Type (or copy and paste) the first command and press Enter. Wait for the response, then type (or paste) the second command and press Enter.

Backend HTTP SPNs (link the backend HTTP service to svc_elyse_be)

These two commands tell Windows: “The svc_elyse_be account is responsible for running the HTTP web service on the machine named ELYSE-BE01.”

setspn -S HTTP/ELYSE-BE01.yourdomain.com YOURDOMAIN\svc_elyse_be
setspn -S HTTP/ELYSE-BE01 YOURDOMAIN\svc_elyse_be

Again, type (or paste) each command one at a time and press Enter after each.

Frontend Proxy SPNs (separate-server deployments)

When the frontend and backend are on different servers, the user’s browser connects to the frontend hostname (e.g., ELYSE-FE01) and requests a Kerberos ticket for HTTP/ELYSE-FE01. The frontend’s ARR reverse proxy forwards this ticket to the backend. For the backend to accept it, svc_elyse_be must also have HTTP SPNs registered for the frontend hostname:

setspn -S HTTP/ELYSE-FE01.yourdomain.com YOURDOMAIN\svc_elyse_be
setspn -S HTTP/ELYSE-FE01 YOURDOMAIN\svc_elyse_be
Note: If the frontend and backend are on the same server, skip these two commands — the backend HTTP SPNs above are sufficient. Only register frontend proxy SPNs when the frontend IIS site is on a different machine from the backend.

What to expect: Each command should respond with text similar to: “Registering ServicePrincipalNames for ...” followed by “Updated object”. This means the SPN was registered successfully.

If you see “Duplicate SPN found”, the SPN is already registered. This is not necessarily an error — it may have been registered previously. Verify it is registered to the correct account using the verification commands in Step 3.

Note on Named Instances: If you installed SQL Server as a Named Instance rather than a Default Instance, the SPN format remains the same as long as you are connecting via the port number (1433). The SPN uses the port, not the instance name.

STEP 2: CONFIGURE CONSTRAINED DELEGATION

This step configures the backend service account (svc_elyse_be) to be trusted for delegation to the SQL Server service only. This is “constrained” delegation because it limits which services the account can impersonate users to. In plain terms: you are telling Windows “the backend is allowed to act on behalf of users, but only when talking to SQL Server — nothing else.”

This step is performed in the Active Directory Users and Computers (ADUC) tool on the Domain Controller.

Step 2a: Enable Advanced Features in ADUC

  1. Open ADUC on the Domain Controller:
    1. Open Server Manager (it usually opens automatically when you log in to a Windows Server; if not, click the Start button and type Server Manager, then click the result).
    2. In Server Manager, click Tools in the top-right menu bar.
    3. From the drop-down menu, click Active Directory Users and Computers.
    4. A new window titled “Active Directory Users and Computers” will open. This is ADUC.
  2. In the ADUC window, click the View menu in the menu bar at the top of the window.
  3. In the drop-down menu, look for Advanced Features. If it has a tick/checkmark next to it, it is already enabled and you can close the menu. If it does not have a tick, click it to enable it. The menu will close and the view will refresh.
Important: If Advanced Features is not enabled, the Delegation tab will not be visible on user account properties. This is the most common reason for the Delegation tab being missing.

Step 2b: Configure Delegation on the Backend Service Account

  1. In the ADUC window (still open from Step 2a), look at the left panel. You will see your domain name (e.g., yourdomain.com). Click the small ▶ arrow (or + icon) next to it to expand it and reveal the folders (called Organizational Units, or OUs) underneath.
  2. Click on the Elyse OU (this is the folder where the svc_elyse_be account was created during Domain Setup). When you click it, the right panel will show the contents of that OU.
  3. In the right panel, locate the svc_elyse_be account. It will appear as a user icon with the name Backend Service Account (this is the Full Name that was set during Domain Setup).
  4. Right-click on Backend Service Account and select Properties from the context menu. A properties dialog window will open with multiple tabs across the top.
  5. Click the Delegation tab (it is one of the tabs along the top of the properties window).
    Note: If the Delegation tab is not visible: verify that Advanced Features is checked (Step 2a); verify that SPNs were successfully registered for this account (Step 1) — the Delegation tab only appears on accounts that have at least one SPN registered; close and reopen ADUC, then try again.
  6. On the Delegation tab, you will see several radio button options. Select (click on): “Trust this user for delegation to specified services only”. This tells Windows that this account is allowed to act on behalf of users, but only for specific services that you will define next.
  7. Below that, two more radio buttons will become available. Select: “Use Kerberos only”
    Why “Use Kerberos only”: This is the tighter security posture. It requires that the user’s initial authentication to the backend is already Kerberos — the backend can only delegate the user’s identity to SQL Server if it received a genuine Kerberos ticket from the user in the first place. This ensures end-to-end Kerberos authentication and prevents delegation of identities that were authenticated via weaker protocols such as NTLM.

    The alternative option, “Use any authentication protocol”, enables Kerberos Protocol Transition, which allows the backend to accept authentication via any method (including NTLM) and then obtain a Kerberos ticket to SQL Server on behalf of the user. NTLM is a weaker protocol (susceptible to relay attacks, no mutual authentication) and allowing it to feed into delegation widens the attack surface. Do not select this option.
  8. Click the Add... button (located below the empty services list in the lower half of the dialog). A new dialog titled “Add Services” will appear.
  9. In the “Add Services” dialog, click the “Users or Computers...” button. Another dialog titled “Select Users or Computers” will appear.
  10. In the text box at the bottom of the “Select Users or Computers” dialog, type: svc_sql. Then click the “Check Names” button. The text should change to show the full account name with an underline (e.g., YOURDOMAIN\svc_sql), confirming Windows found the account. Click OK.
  11. You will be returned to the “Add Services” dialog. It will now show a list of “Available services” — these are the SPNs you registered in Step 1. Select (click on) the MSSQLSvc entry (or entries) that correspond to your SQL Server. If there are multiple MSSQLSvc entries, select all of them by holding Ctrl and clicking each one.
  12. Click OK to close the “Add Services” dialog. You will be returned to the Delegation tab, and the services list should now show the MSSQLSvc entries you selected.
  13. Click Apply (bottom-right of the properties window) to save the changes, then click OK to close the properties window.

STEP 3: VERIFICATION

Step 3a: Verify SPNs

Open a Command Prompt as Administrator on the Domain Controller (if you still have the one from Step 1 open, you can use that; otherwise, follow the same steps: click Start, type cmd, right-click Command Prompt, select Run as administrator, click Yes on the UAC prompt).

Type or paste each of the following commands and press Enter. These commands list the SPNs registered to each account (the -L flag means “list”):

setspn -L YOURDOMAIN\svc_sql

Expected output (2 entries):

MSSQLSvc/ELYSE-SQL01.yourdomain.com:1433
MSSQLSvc/ELYSE-SQL01:1433
setspn -L YOURDOMAIN\svc_elyse_be

Expected output (2 entries for same-server, or 4 entries for separate-server deployments):

HTTP/ELYSE-BE01.yourdomain.com
HTTP/ELYSE-BE01
HTTP/ELYSE-FE01.yourdomain.com    <-- separate-server only
HTTP/ELYSE-FE01                    <-- separate-server only

If any entries are missing, re-run the corresponding setspn command from Step 1.

If an SPN is registered to the wrong account, remove it first:

setspn -D MSSQLSvc/ELYSE-SQL01:1433 WRONGDOMAIN\wrong_account

Then re-register it to the correct account.

Step 3b: Verify Delegation Configuration

  1. Switch to the ADUC window (if it is still open from Step 2). If you closed it, reopen it: open Server Manager, click Tools in the top-right menu bar, then click Active Directory Users and Computers.
  2. Ensure Advanced Features is enabled: click the View menu at the top of the ADUC window and verify that Advanced Features has a tick/checkmark next to it.
  3. In the left panel, expand your domain name and click on the Elyse OU. In the right panel, right-click Backend Service Account (svc_elyse_be) and select Properties.
  4. Click the Delegation tab.
  5. Verify the following three things are all correct:
    • “Trust this user for delegation to specified services only” is selected.
    • “Use Kerberos only” is selected.
    • The services list shows the MSSQLSvc entry for svc_sql.

Step 3c: End-to-End Verification (After Application Deployment)

Note: This verification step can only be performed after the backend and frontend are fully deployed. If you are following the deployment guides in order, come back to this step after completing Backend Installation (Server) and Frontend Installation.

  1. On a domain-joined workstation (not the server), open a web browser (e.g., Microsoft Edge or Google Chrome).
  2. Navigate to the Elyse application URL (e.g., https://elyse-fe01.yourdomain.com).
  3. Log in as a regular domain user (not the administrator).
  4. In the application, navigate to: Connected User > Who is this?
  5. The username displayed should match the Windows login of the person using the browser (e.g., YOURDOMAIN\jsmith), NOT the service account (svc_elyse_be).

If the service account name is displayed instead of the user's name, KCD is not working correctly. Check the following (in order of likelihood):

TROUBLESHOOTING

Problem: Delegation tab is missing on the service account

Cause: This is the most common issue. The Delegation tab only appears when both of these conditions are met: (1) Advanced Features is enabled in ADUC, and (2) the account has at least one SPN registered.

Fix:

  1. In ADUC, click the View menu and ensure Advanced Features has a tick next to it.
  2. Open a Command Prompt as Administrator and run: setspn -L YOURDOMAIN\svc_elyse_be. If no SPNs are listed, re-run the setspn -S commands from Step 1.
  3. After registering SPNs, close and reopen ADUC, then check the account properties again.

Problem: “Duplicate SPN found” error when registering SPNs

Cause: The SPN is already registered to another account.

Fix: Find the existing registration:

setspn -Q MSSQLSvc/ELYSE-SQL01:1433

Remove it from the wrong account:

setspn -D MSSQLSvc/ELYSE-SQL01:1433 WRONGDOMAIN\wrong_account

Re-register to the correct account.

Problem: SPNs registered with placeholder domain name instead of actual domain

Symptom: Running setspn -L shows FQDN entries containing yourdomain.com (the placeholder from the documentation) instead of your actual domain name. For example:

MSSQLSvc/ELYSE-SQL01.yourdomain.com:1433    <-- wrong
MSSQLSvc/ELYSE-SQL01:1433                   <-- correct (short name is fine)

Cause: The setspn commands from Step 1 were run without first replacing the placeholder values (yourdomain.com, YOURDOMAIN) with the actual domain name and NetBIOS name.

Fix: Remove the incorrect FQDN SPNs and re-register them with the correct domain. Replace yourdomain.com and YOURDOMAIN with your actual values in the commands below:

setspn -D MSSQLSvc/ELYSE-SQL01.yourdomain.com:1433 YOURDOMAIN\svc_sql
setspn -D HTTP/ELYSE-BE01.yourdomain.com YOURDOMAIN\svc_elyse_be

setspn -S MSSQLSvc/ELYSE-SQL01.actualdomain.com:1433 YOURDOMAIN\svc_sql
setspn -S HTTP/ELYSE-BE01.actualdomain.com YOURDOMAIN\svc_elyse_be

Then verify with:

setspn -L YOURDOMAIN\svc_sql
setspn -L YOURDOMAIN\svc_elyse_be

All FQDN entries should now show your actual domain suffix. The short hostname entries (without a domain suffix) do not need to be changed.

Problem: KCD works for some users but not others

Cause: The failing users may not be members of the Elyse_Users AD group, or their Kerberos tickets may be stale (expired or cached from before the configuration was completed).

Fix:

  1. Verify the user is a member of the Elyse_Users group in ADUC.
  2. Have the user log out of their workstation completely and log back in. This forces Windows to obtain fresh Kerberos tickets.
  3. If that does not help, on the user's workstation (not the server), open a Command Prompt (click Start, type cmd, press Enter) and run:
klist purge

This clears all cached Kerberos tickets. The user should then close the browser, log out, and log back in.

Problem: Backend returns 401 Unauthorized

Cause: Windows Authentication may not be enabled in IIS, the HTTP SPN may be incorrect, or useAppPoolCredentials is not set.

Fix: Verify IIS Windows Authentication is enabled (see Backend Installation (Server) — Step 7). Verify useAppPoolCredentials is set to true on the backend site. Verify HTTP SPNs match the backend hostname exactly. For separate-server deployments, also verify HTTP SPNs are registered for the frontend hostname.

Problem: Browser prompts for credentials instead of passing through automatically

Cause: Kerberos authentication is not completing transparently. This can happen for several reasons.

Fix: Check the following in order:

  1. Ensure you are accessing the application using a hostname (e.g., http://ELYSE-FE01:8080), not localhost or an IP address. Kerberos requires a hostname to locate the correct SPN.
  2. Verify the URL is in the browser’s Local Intranet zone. On domain-joined Windows machines, single-label hostnames (e.g., ELYSE-FE01) are automatically treated as Intranet. FQDNs (e.g., elyse-fe01.yourdomain.com) may need to be added to the Intranet zone via Group Policy or Internet Options > Security > Local Intranet > Sites > Advanced.
  3. Verify HTTP SPNs are registered for the hostname in the URL (run setspn -L YOURDOMAIN\svc_elyse_be and check the output).
  4. Verify useAppPoolCredentials is set to true on the backend IIS site (see Backend Installation (Server) — Step 7).
  5. Clear cached Kerberos tickets on the workstation: open a Command Prompt and run klist purge, then close and reopen the browser.

Problem: SQL Server connection fails with “Login failed for user”

Cause: The user's identity is not being passed through (KCD failure), or the user is not a member of the Elyse_Users AD group.

Fix: Check the SQL Server error log for the exact login name that was attempted. If it shows the service account name, KCD is not working — review all steps above. If it shows the user's name, verify the user is in the Elyse_Users group and the SQL Server login for that group exists.

NEXT STEPS

  1. Install the backend application layer: Backend Installation (Server)
  2. Install the frontend application layer: Frontend Installation
  3. After both layers are installed, proceed to Bootstrapping to onboard users and configure the system.