Setting up SOLR authentication kerebos plugin

Question

Im tasked with setting up Apache SOLR to run under Authentication, while not modifying the existing c# calls to SOLR.

The options available are a basic authentication plugin, and a kerebos plugin

When I try the basic authentication plugin I find that I need to change the calls to SOLR to include the login

Im trying to learn about kerebos, but I cant quite get my mind around it.

My understanding is that I need to set up something called a keytab file that has a list of who the principals are that can access the application and then you update something called the KDC have give those same principals

So I basically have a web api on one box, and apache solr on a separate box.

1. I dont need to login with kerebos, right? so as long as the KDC has the web api box and the solr box, and a windows user account (I'm thinking of using the web api's service account), the back and forth between the servers happen automatically (asking for a ticket, granting a ticket, etc)

2. I dont need to change my http calls, right?

3. i dont need to have a security certificate, right?

Answer 1

If Active Directory will be used as KDC, each domain controller will have KDC service. Your application URL FQDN part should be registered in Active Directory SPN. This is the URL that client will access application using Kerberos authentication, also the hosts that will participate in Kerberos should be registered in Active Directory.

Keytab file will contain the service account credentials and using a utility like ktpass or your application's specific utility this file should be built and securely transferred to the related application directory. This is a service credential in AD with necessary permissions on the related SPN objects.

Your application should require TGT and TGS tickets from KDC using its keytab file. Then the tickets may be used in your application.

Kerberos alone will not require certificates, but if your application uses LDAPS (port 636) connection to AD, then DCs should have certificates. If your application does not require certificates then probably DC certificates will be sufficient.

This scenario alone does not allow every application user to request tickets. The service account builds the secure authentication channel and the remaining user authentication and authorization should be handled by the application.

Answer 2

My understanding is that I need to set up something called a keytab file that has a list of who the principals are that can access the application

No, the keytab holds a key (password) for the application's own principal. It's a bit like certificates in TLS/mTLS; it is not a "list of who can access".

If you've worked with Active Directory, then "service account passwords" in AD are literally what goes into a keytab. Software that uses Windows native Kerberos API generally works with passwords while Java software works with keytabs.

For service-to-service auth, both the 'client' (webapp) and the 'server' (Solr) will need a keytab.

and then you update something called the KDC have give those same principals

The KDC is the server that issues Kerberos tickets. In Active Directory environments, every AD DC is automatically a Kerberos KDC (and every AD user is a Kerberos principal).

Generally you create the (service) accounts on the KDC first, then store their keys in keytabs as needed.

I dont need to login with kerebos, right? so as long as the KDC has the web api box and the solr box, and a windows user account (I'm thinking of using the web api's service account), the back and forth between the servers happen automatically (asking for a ticket, granting a ticket, etc)

Your app users won't; only the web app itself (the Solr client) needs to "log in" to Kerberos.

If the web app uses Windows APIs then it might "log in" automatically using its service account, but if it's a Java app then it'll generally need a keytab.

I dont need to change my http calls, right?

Technically, you do. Kerberos is not magic, it still requires you to send an Authorization: header within every request, just like Basic. The only difference is that Kerberos client software often does that automatically, by retrieving tickets from "the OS".

Whether that will be automatic depends on which HTTP client APIs you use. Some will use Kerberos by default when available; some will use it only when explicitly enabled; and some will require you to provide a whole custom "authenticator class" or something.

i dont need to have a security certificate, right?

If you mean TLS – Kerberos won't care, although you probably should have TLS certs in general.

Kerberos doesn't need certificates for authentication because it has the service principal keys for that. However, when used with HTTP it doesn't provide encryption or even integrity verification, so you'd generally still want TLS in addition.

(Kerberos technically can provide encryption but very few protocols integrate that capability; e.g. LDAP does – which is why secure LDAP on AD doesn't require certificates – but HTTP doesn't.)