Skip to content Skip to site navigation Skip to service navigation

Kerberos Endpoints and Availability

Introduction

When a Kerberos client authenticates it connects to a Kerberos KDC server (key distribution center server) sending the user's principal name and password and, if the authentication is successful, receives authentication credentials. This page describes how Stanford's KDCs are arranged and accessed.

How does KDC failover work?

A Kerberos client will have a list of KDCs that it can contact. The client starts with the first KDC (the primary) and, if that KDC is inaccessible for some reason, it tries the second KDC (the secondary). If the secondary KDC is not accessible, it tries the third, and so on, until it has exhausted the list. Thus, in almost every case, all Kerberos authentications are made against a single KDC: the primary.

Why might a KDC be inaccessible?

A KDC might be inaccessible because the KDC is on hardware that is faulty, or is undergoing maintenance. It also might be inaccessible because there is some firewall rule that prevents the client from reaching the KDC. Note that none of Stanford's KDCs have inbound firewall rules preventing access to Stanford Kerberos clients.

Where does a client get its list of KDCs?

There are two common methods a Kerberos clients uses to generate its list of the KDCs: DNS and file configuration.

DNS

Most Kerberos clients will use DNS discovery to get a list of the KDCs for a domain. To see the list for yourself you run this command:

dig _kerberos._udp.stanford.edu srv +noall +answer

The /etc/krb5.conf file configuration

On most servers, the /etc/krb5.conf file file will override DNS. This has the advantage of making testing easier since it is simpler to change a local file than changing DNS. The portion of the /etc/krb5.conf file relevant to the list of KDCs to try is the following:

[realms]
    stanford.edu = {
        kdc            = krb5auth1.stanford.edu:88
        kdc            = krb5auth2.stanford.edu:88
        kdc            = krb5auth3.stanford.edu:88
        master_kdc     = kdc-master.stanford.edu:88
        admin_server   = krb5-admin.stanford.edu
        kpasswd_server = krb5-admin.stanford.edu
        default_domain = stanford.edu
        kadmind_port   = 749
    }

The first three entries with key "kdc" form the list. The order the KDCs are tried is the order they appear, so in the above krb5auth1.stanford.edu is the primary. See also Stanford's recommended /etc/krb5.conf.

Where are the KDCs?

Currently, we have two KDCs on campus and one (load-balanced) KDC in a third-party cloud provider. The primary KDC (krb5auth1.stanford.edu) is on campus, while the secondary KDC (krb5auth2.stanford.edu) is hosted by the cloud provider.

If your service cannot reach off-campus networks, you should use these endpoints in your /etc/krb5.conf (in this order):

kdc            = krb5auth1-campus.stanford.edu:88
kdc            = krb5auth2-campus.stanford.edu:88
kdc            = krb5auth3-campus.stanford.edu:88

My service is not allowed off-campus. How does that affect its Kerberos access?

If you are running any machines or services on campus, and those machines or services are restricted from reaching off-campus networks, they will be affected if the KDC primary becomes inaccessible.  The result would be that your Kerberos authentications would fail at the primary, fail at the secondary, and then finally work at the tertiary. Note that each fail-through takes some time and could have a significant  impact on your service if the service performs many Kerberos authentications.

You can address this in a few ways:

  1. Change your firewall rules to allow port 88 UDP and TCP traffic out to the Internet.
  2. Send your port 88 UDP and TCP traffic to a network proxy that does have access to the Internet.
  3. Change your /etc/krb5.conf file to point only to on-campus KDCs (see the "Where are the KDCs?" section above for a list).

Be aware that in the future we might change the primary from being on-campus to being in the cloud.

Where to get more help

Please file a ServiceNow ticket.

 

Last modified January 21, 2020