this is roughly how it works:
- client (C) request for a web service (S), which is secured by kerberos; the web service (S) respond back with
negotiate
, which modern browser would support - receiving the `negotiate` response, the client (C) would send KDC that it’s requesting access for web service (S)
- there are few rounds between the client (C) and KDC, for exchanging the request (encrypted by C’s key/password); then KDC decrypt using C’s key, and send back a TGT, encrypted by KDC/TS’s key; client (C) then send this request encrypted by TS’s key to TS with TGT; TS then give back a ticket, which is secured by web service (S)’s encryption key
- with the ticket, client (C) send to web service (S), (S) then decrypt the message successfully with its own key, hence verifies/authenticate the client (C)
as for the set up, this is roughly how it looks like
- set up keberos account for client(C) which is likely a user
this is done on KDC (Windows AD).
- set up keberos service account for web service (S) which likely is service account
this is done on KDC (Windows AD).
- register a SPN, map to S’s kerberos
this is done on KDC (Windows AD).
To verify the spn:
setspn -L <service_account>

- set up a keytab for S (service account), and make it accessible by web service
- when C send over the ticket encrypted by S’ key, the web service (S) should be able to decrypt it using the keytab above
this can either be done from windows server with ktpass:
ktpass -out outputfile.keytab -princ HTTP/[fqdn]@[domain] -mapUser [user] -mapOp set -pass [password] -crypto ALL -pType KRB5_NT_PRINCIPAL
or on Unix Server with ktutil
ktuil: addent -password -p <service_account>@DOMAIN -s <salt> -k <version> -e aes256-cts
ktutil: wkt <account>.keytab
to verify the keytab
klist -kt <account>.keytab ---> this shows the entry in the keytab
kinit -kt <account>.keytab <account> --> this verifies the login
klist ---> after kinit, this should return the ticket from KDC
sample:
step 2:
- Log in to the computer as a domain administrator or a user who is a member of the built-in Account Operators domain group.
- Open the Active Directory Users and Computers MMC snap-in.
- Create an ordinary user account with the following properties:
- Use the same identifier in the Full name and User logon name (pre‐Windows 2000) fields.Note: Use only lowercase characters and make sure that there are no spaces in these fields.
- Select the Password never expires check box.
- Clear the User must change password at next logon check box.
- If you want to use the crypto algorithm aes128-sha1 or aes256-sha1 the account option This account supports Kerberos AES 128 bit encryption or This account supports Kerberos AES 256 bit encryption must also be selected.
- \
step 3:
- Log in to the computer as a domain administrator or a user who is a member of the built-in Account Operators domain group.
- From the Microsoft Support Tools package, use the setspn.exe command-line tool to register two SPNs for the Kerberos service account:
- Execute the following two commands, replacing the variables as indicated in the table below the commands:> setspn -S HTTP/<fully qualified hostname>[:<port>] <service account name> > setspn -S HTTP/<hostname>[:<port>] <service account name>If the Spotfire Server is not listening on the default HTTP port 80 or the default HTTPS port 443, you should execute the setspn commands both with and without the port specified:> setspn -S HTTP/<fully qualified hostname>[:<port>] <service account name> > setspn -S HTTP/<hostname>[:<port>] <service account name> > setspn -S HTTP/<fully qualified hostname> <service account name> > setspn -S HTTP/<hostname> <service account name>
it should work with above steps done, and should work with Windows (service running out windows box). However, there is a TRICK of the TRICK, for Unix (service running out of Unix) to work, the SPN should include an entry for the real server
so, when list spn
SETSPN -L <account>
this should return entries not only with the cname, but also with the REAL server

so on windows server/AD side, for the SPN set up, these should be done
setspn -S HTTP/<service_name/CNAME>.DOMAIN <service_account> --> this is enough for windows to work
setspn -S HTTP/<REAL_SERVER_NAME>.DOMAIN <service_account> ----> this is important for unix to work
Seems like the cause for above issue, there could be different setting for the reverse dns setup.
This is the set up in my Unix box, where reverse dns is disabled, this probably however likely is enabled in Windows AD.

https://web.mit.edu/kerberos/krb5-1.12/doc/admin/princ_dns.html


https://www.baeldung.com/spring-security-kerberos
https://www.baeldung.com/spring-security-kerberos-integration