In previous versions, EasyMorph Hub used the Windows HTTP.sys stack for Windows/AD sign-in. In many environments this made Kerberos work implicitly through the server machine account, especially when Hub was accessed by the machine's own domain name.
Starting with Hub v6, Windows/AD sign-in is handled by the new .NET hosting stack. This is more modern and flexible, but it also means Kerberos configuration must be correct for the account that runs the EasyMorph Hub service and for the exact DNS name users open in the browser.
For most installations, no change is required. However, if your Hub uses Windows/AD sign-in and is accessed through a custom DNS name, alias, or domain service account, we recommend checking the Kerberos/SPN configuration before or immediately after updating to Hub v6.
If Kerberos is not configured correctly, Windows may silently fall back to NTLM. NTLM is more fragile over modern HTTP connections, proxies, and browser connection reuse. The typical symptoms are:
- Browser sign-in fails with "An anonymous request was received in between authentication handshake requests".
- EasyMorph Desktop sign-in fails with "Unauthorized".
- The AD "Test connection" in Hub settings is green, but actual Windows sign-in still fails.
The last point is important: the AD Test connection checks whether Hub can connect to Active Directory over LDAP. It does not prove that a browser or Desktop client can authenticate to the Hub URL with Kerberos.
Do I need to do anything?
First of all, if you don't use Windows/AD sign-in in EasyMorph Hub - no action is required.
If users access Hub by the server's own domain name and the Hub service runs under one of the built-in Windows service accounts, Kerberos may already work without any explicit SPN configuration.
If users access Hub by a friendly DNS name, alias, load-balanced name, or public intranet name - for example:
https://hub.company.com
then Kerberos should be checked.
If the EasyMorph Hub service runs under a domain service account, for example:
COMPANY\svc-easymorph-hub
then the HTTP SPN must be registered on that domain service account.
Recommended configuration
The safest configuration is:
- Use an
Arecord for the Hub DNS name - not aCNAME. - Register an HTTP SPN for the exact Hub host name.
- Register that SPN on the account that runs the EasyMorph Hub service.
- Verify Kerberos from a client machine.
For example, if users open Hub at:
https://hub.company.com
and the Hub service runs as:
COMPANY\svc-easymorph-hub
then the SPN should be:
HTTP/hub.company.com
registered on:
COMPANY\svc-easymorph-hub
Why CNAME aliases can be a problem
Kerberos is very sensitive to the server name, and a DNS alias is not always treated as the name typed into the browser.
For example, consider such DNS record:
hub.company.com CNAME server123.company.local
In this case, Windows clients may request a Kerberos ticket for the canonical target name:
HTTP/server123.company.local
instead of the alias:
HTTP/hub.company.com
If the EasyMorph Hub service runs as a domain service account, this can fail even if you registered HTTP/hub.company.com, because the client may not request that SPN at all.
For this reason, we recommend using an A record for the Hub URL where possible:
hub.company.com A 10.20.30.40
Then clients request the SPN for the name users actually type:
HTTP/hub.company.com
and that SPN can be registered on the Hub service account.
Kerberos setup steps
Note: these steps can be performed by your Active Directory administrator only, being local admin is not enough.
1. Identify the Hub URL
Write down the exact host name users use to open EasyMorph Hub.
For example:
https://hub.company.com
The Kerberos SPN uses only the host name, not the protocol, port, or path:
HTTP/hub.company.com
2. Check whether the name is a CNAME
For example, from a client machine, run:
nslookup hub.company.com
If the result shows that hub.company.com is an alias for another name, consider changing it to an A record.
This is not always strictly required, but it avoids Kerberos problem where Windows requests a ticket for the DNS target name instead of the friendly name.
3. Identify the Windows account running the EasyMorph Hub service
On the Hub server, open Windows Services and check the "Log On As" account for the EasyMorph Hub service.
Alternatively, run:
sc qc EasyMorphServer
Look at
SERVICE_START_NAME : .....
If this is a domain account such as COMPANY\svc-easymorph-hub, then the SPN must be registered on that account.
4. Check for an existing SPN
Ask your AD administrator to run:
setspn -Q HTTP/hub.company.com
If the SPN is already registered on another account, do not add a duplicate. Kerberos does not work reliably with duplicate SPNs. You can also check for duplicates with setspn -X.
5. Register the SPN
Register the SPN on the Hub service account:
setspn -S HTTP/hub.company.com COMPANY\svc-easymorph-hub
Use -S, not -A. The -S option checks for duplicates before adding the SPN.
Again, this is an Active Directory write operation, local administrator rights on the Hub server are not enough.
The command must be run by a domain administrator or by an account that has been delegated permission to write SPNs for the service account.
6. Verify from a client machine
On a client machine, run:
klist purge
klist get HTTP/hub.company.com
If Kerberos is configured correctly, the second command should obtain a ticket for HTTP/hub.company.com.
Then open EasyMorph Hub in the browser and try Windows/AD sign-in again.