> For the complete documentation index, see [llms.txt](https://docs.keeper.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.keeper.io/keeperpam/privileged-access-manager/connections/session-protocols/rdp-connections/kerberos-and-protected-users.md). # Kerberos and Protected Users Launching an RDP session with Kerberos and users under the Protected Users group ## RDP with Kerberos (Protected Users) Instructions for connecting to Windows machines over RDP with accounts that must use Kerberos, such as members of the Active Directory **Protected Users** group or accounts in domains where NTLM is disabled. ### Overview Members of the Protected Users group cannot authenticate with NTLM. When the Keeper Gateway connects to a Windows machine over RDP with Network Level Authentication (NLA), it uses Kerberos if it can and falls back to NTLM if it cannot. For a Protected Users account the fallback is rejected, and the session ends with: > Access denied by server (account locked/disabled?) To use Kerberos: 1. The PAM Machine record must identify the target by its **fully qualified host name**. This applies to every Gateway platform and is the most common cause of failure. 2. The Keeper Gateway must be able to locate a domain controller (KDC) for the user's domain. * **Windows Gateway:** Windows locates the domain controller itself. No configuration is needed. * **Linux and Docker Gateway:** the Gateway locates the domain controller through DNS, as described below. {% hint style="info" %} No setting in the Keeper Vault turns Kerberos on. The Gateway uses it automatically whenever the requirements on this page are met. {% endhint %} ### Prerequisites * Keeper Gateway **1.9.0 or later**. * The Gateway can reach your domain controllers on **TCP and UDP port 88** (Kerberos). * The target Windows machine is joined to the Active Directory domain. * On a Windows Gateway, the Gateway host can locate your domain controllers, which is the case when it is joined to the domain or uses your Active Directory DNS servers. ### Configure the PAM Machine and PAM User records | Field | Requirement | Example | | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------- | | PAM Machine: Hostname or IP Address | The machine's **fully qualified host name**: its computer name followed by the Active Directory DNS domain. An IP address (`10.0.1.20`) or the domain name alone (`corp.example.com`) cannot be used with Kerberos. | `server01.corp.example.com` | | PAM User: Login | The user principal name (UPN), **or** the user name with the AD **DNS** domain in the Domain field. A NetBIOS domain name (for example `CORP`) cannot be used. | `jsmith@corp.example.com` | | PAM Machine: Security Mode | `Any` or `NLA`. | `Any` | #### Finding the machine's fully qualified host name On the target machine, open Windows PowerShell and run: ```powershell [System.Net.Dns]::GetHostEntry($env:COMPUTERNAME).HostName ``` The output, for example `EC2AMAZ-A0GBNDM.corp.example.com`, is the value for the **Hostname or IP Address** field. From a command prompt, `hostname` returns the computer name without the domain. Confirm that the Gateway host resolves the name to the machine: ```powershell nslookup EC2AMAZ-A0GBNDM.corp.example.com ``` ### Windows Gateway A Keeper Gateway installed as a Windows service uses Windows' own Kerberos support. It does not need a Kerberos configuration file or any DNS changes beyond what the Gateway host already uses to find your domain controllers. Set the PAM Machine and PAM User records as described above, and connect. ### Linux and Docker Gateway: how the Gateway locates the domain controller The Gateway finds a domain controller by looking up the domain's Kerberos DNS records (`_kerberos._tcp.`). Only DNS servers that serve your Active Directory zone can answer this lookup. The Docker container uses the same DNS servers as the host it runs on. Check the host first: ```bash dig +short SRV _kerberos._tcp.corp.example.com ``` * **The lookup returns one or more domain controllers:** no change is needed. This is typical when the host's DNS servers are your Active Directory DNS servers. * **The lookup returns nothing:** the host uses DNS servers that do not serve your Active Directory zone, for example a cloud VPC resolver or public DNS. Use one of the options below. {% tabs %} {% tab title="Forward the AD domain in your DNS (recommended)" %} Configure your existing DNS to forward queries for your Active Directory domain to your domain controllers, for example with a conditional forwarder on your DNS servers or an Amazon Route 53 Resolver forwarding rule. The Gateway needs no changes, and every other system on the network can resolve the domain as well. {% endtab %} {% tab title="Docker Compose: set the container's DNS servers" %} Point the Gateway container at your Active Directory DNS servers, usually your domain controllers: ```yaml services: keeper-gateway: # ...existing settings... dns: - 10.0.1.10 # domain controller 1 - 10.0.1.11 # domain controller 2 ``` Apply the change by recreating the container. `docker restart` does not apply changes to the compose file. ```bash docker compose up -d ``` With `docker run`, use `--dns 10.0.1.10 --dns 10.0.1.11`. {% hint style="warning" %} The container sends every DNS lookup to these servers, including lookups for Keeper's services. Make sure your Active Directory DNS servers forward external names, which they do by default. If the Gateway shows as offline after the change, they do not. {% endhint %} {% endtab %} {% tab title="Mount a Kerberos configuration file" %} If you cannot change the container's DNS servers, tell Kerberos where your domain controllers are with a configuration snippet. Create `krb5-realm.conf`: ```ini [realms] CORP.EXAMPLE.COM = { kdc = dc01.corp.example.com kdc = dc02.corp.example.com } [domain_realm] corp.example.com = CORP.EXAMPLE.COM .corp.example.com = CORP.EXAMPLE.COM ``` The realm is your Active Directory DNS domain in upper case. You can list domain controllers by IP address. Mount the file into `/etc/krb5.conf.d/`. Do not replace `/etc/krb5.conf`. ```yaml services: keeper-gateway: volumes: - ./krb5-realm.conf:/etc/krb5.conf.d/realm.conf:ro ``` {% endtab %} {% endtabs %} #### Finding your domain controllers On any machine joined to the domain, run: ```powershell nltest /dsgetdc:corp.example.com ``` The `Address:` line shows a domain controller. `ipconfig /all` on a domain-joined machine lists your Active Directory DNS servers under **DNS Servers**. #### Verify from the Gateway container ```bash docker exec -it -u keeper-gw env KRB5CCNAME=MEMORY: kinit jsmith@CORP.EXAMPLE.COM ``` Enter the user's password when prompted. No output means the Gateway reached a domain controller and obtained a Kerberos ticket. `Cannot find KDC for realm` means the DNS step above is not complete. ### Troubleshooting | Symptom | Cause | Fix | | ---------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | | `Access denied by server (account locked/disabled?)` for a Protected Users account, while other accounts connect | Kerberos could not be used and NTLM was rejected | Check that the PAM Machine uses the fully qualified host name, then work through the checks below | | The connection fails when the PAM Machine uses an IP address or the domain name as its host | Kerberos needs the machine's own fully qualified host name | Use the value from *Finding the machine's fully qualified host name* | | Windows Security log on the target shows **Event 4625**, Authentication Package **NTLM**, Status **0xC000006E** | The Gateway fell back to NTLM | Kerberos requirements are not met; see below | | Gateway debug log: `Cannot find KDC for realm "CORP.EXAMPLE.COM"` | The Gateway cannot locate a domain controller | Complete the DNS section | | Gateway debug log: `Cannot find KDC for realm "CORP"` | The domain is a NetBIOS name | Use the UPN or the DNS domain in the PAM User record | | Gateway debug log: `does not specify default realm` | The login has no domain | Use the UPN or set the Domain field | | Connection fails with `No route to host` after changing DNS | Active Directory DNS returns an outdated address for the target | Correct the target's DNS record in Active Directory | To see the detailed Kerberos messages on a Docker Gateway, set `LOG_LEVEL: "debug"` in the Gateway container's environment, recreate the container, and reproduce the connection. On the target machine, a successful Kerberos logon appears in the Windows Security log as **Event 4624** with Authentication Package **Kerberos**. {% hint style="info" %} Sign out of RDP sessions instead of closing the window. A disconnected session stays open on the server, and a new connection as the same user takes it over, which can look like an unexpected disconnect. {% endhint %} {% hint style="info" %} Keeper Gateway versions earlier than 1.9.0 do not support Kerberos for RDP. Upgrade to 1.9.0 or later. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.keeper.io/keeperpam/privileged-access-manager/connections/session-protocols/rdp-connections/kerberos-and-protected-users.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.