Is the Kerberos SPN FQDN significant to the server, or is the keytab enough?

Question

I spend most of my time as a developer, so I'm not familiar with all the details...

I have a service running on a linux host. I want to use Kerberos to transmit identity information to the service. Some of my clients are on windows clients attached to AD, so they already have a ticket. I understand how to use kinit to get a ticket on my *nix clients, and have verified that I can do so. I have an /etc/krb5.conf file that seems to work on my *nix clients

I understand I need to do the following...

1. Ask the AD admin to generate a keytab for a particular SPN.
2. Place the keytab on my server in a place where the service can find it.
3. the clients to use the ticket and the SPN to get a token from the Kerberos infrastructure.
4. Configure the service to receive the token and decode it using the keytab.

Here is my issue...

The SPN is usually in the form of service_name/FQDN@domain_name. My clients, however, don't construct the SPN using the host name of the service. Instead the SPN is set in a configuration file. It would be easiest for me if I could create a single SPN and use it on each instance of my server.

So I would then do the following...

1. Create an SPN of the form service_name/some_dummy_name@domain_name.
2. Generate the keytab and copy it to svr1.mycompany.mydomain, svr2.mycompany.mydomain, ..., svrX.mycompany.mydomain.
3. Configure my clients with the single SPN.

I seem to think that this will work, in that the same SPN/keytab can be used on several servers with different host names when servers are clustered.

To boil it down - is the FQDN part of an SPN significant to the server, or is it just there so that typical clients can generate the proper SPN? If several servers have the same keytab, can they receive and validate the same tokens, or is something else required?

Just to emphasize, the service is a java app on Linux, the clients are java apps on windows and *nix. AD would provide the Kerberos server infrastructure.

Answer 1

In the case you outline, it should work. You can use a keytab across multiple machines as long as the clients all have some way to figure out what service principal to request a service key for. Kerberos requires that both sides of the connection figure out the service principal via some out of band means. Usually this is a convention based on the DNS name of the server, but there is nothing in kerberos that requires that.

I'd say that's a reasonable solution if the number of servers is "small" and there is no security requirement to rotate the keytab on a regular basis.

Answer 2

The FQDN is important for CLIENT when using default Windows API as the client uses it to determine what SPN they want ie API gets just service and FQDN the client wants to connect to and the system does rest with getting the ticket from dc.

If you are using hardcoded SPN inside your config there will be no need to conform to this for it to work as for technical view but I would be aware that it might cause problems if the automatic API gets involved as you will be going against best practices.