Overview
LucidLink supports Kerberos in Windows when connecting through corporate HTTP proxies that require user-attributable authentication. This lets users sign in to their LucidLink filespace through your proxy using their existing Active Directory session, without you embedding any credentials into the LucidLink configuration. It is intended for organizations that mandate per-user accountability for network access and cannot rely on IP whitelisting or proxies that embed passwords in URLs.
Frequently Asked Questions (read before configuring)
Which platforms support Kerberos proxy authentication?
This release supports the LucidLink Windows desktop client only. MacOS and Linux are not supported.
Do I need to enter my Windows password in LucidLink?
No. The LucidLink client uses your existing Windows login session to obtain a Kerberos ticket. Passwords are never transmitted, embedded in URLs, or stored by LucidLink.
Does this work with any proxy?
Your proxy must be reachable by its Fully Qualified Domain Name (FQDN). Кerberos relies on the FQDN to derive the Service Principal Name (SPN) that the proxy registers in Active Directory.
Will end users notice anything different?
No. After the proxy is configured correctly and the user is signed in to Windows with their AD account, LucidLink authenticates to the proxy in the background.
Does this affect SSO sign-in to LucidLink itself?
No. Kerberos here authenticates the network connection to your corporate proxy. Signing in to your LucidLink workspace (via password or SSO) is a separate step and is unchanged.
Can I still use a username and password embedded in the proxy URL?
Yes. The existing [protocol://][user:password@]proxyhost[:port] format remains supported. Use Kerberos when your security policy requires per-user accountability or disallows credential storage.
How Kerberos Proxy Authentication Works
When your Windows client reaches a corporate proxy that requires authentication, the proxy returns an HTTP 407 challenge with a Negotiate header. LucidLink responds with a Kerberos ticket obtained from your Active Directory session, the proxy validates it against your domain controller, and the connection proceeds. The handshake happens automatically.
Prerequisites
Before users can authenticate to your proxy with Kerberos, confirm the following.
Windows client version: The LucidLink Windows client must be on 3.7.8468 or newer.
Proxy reachable by FQDN: Your proxy configuration must use the proxy's Fully Qualified Domain Name.
SPN registered for the proxy: Your proxy must have a Service Principal Name registered in Active Directory matching its FQDN (typically
HTTP/proxy.example.com). Work with your AD administrator if this is not already in place.Workstations joined to the domain: End users must be signed in to Windows with their Active Directory account on a domain-joined machine. Kerberos uses the ticket issued at Windows sign-in.
Network reachability to the KDC: Client machines must be able to reach your Active Directory Key Distribution Center (KDC) to acquire and renew Kerberos tickets.
Setting Up Kerberos Proxy Authentication
Once the prerequisites are in place, no additional credential configuration is required inside LucidLink.
Configure the proxy using its FQDN: Set the proxy via your usual method (operating-system proxy settings, Proxy Auto-Configuration / WPAD file, or the LucidLink configuration), using the proxy's FQDN.
See the HTTP proxy support article for the available configuration options.Sign in to Windows with your AD account: End users must be logged in to Windows with a domain account. This is what supplies the Kerberos ticket LucidLink will present to the proxy.
Launch LucidLink and link your filespace as usual: The first time the client makes a request that traverses the proxy, the proxy returns the 407 Negotiate challenge and LucidLink completes the handshake automatically.
Verify in the LucidLink logs (optional): If a connection problem is suspected, please contact the support team.
System Requirements & Compatibility
Operating system: Windows only. macOS and Linux clients do not support Kerberos proxy authentication.
Kerberos KDC: Required. Active Directory is the typical implementation on Windows environments and is what LucidLink has validated against, but any correctly configured Kerberos KDC should work.
Client version: 3.7.8468