Kerberos Authentication

The Kerberos Authentication Service is offered by Northwestern IT for the use of NU departments and schools for authenticating access to applications, workstations and services. The service is intended to be lightweight, both administratively and technically, and does not require prior approval to use.

Northwestern IT will work with you to understand and deploy the service. We can direct you to some example code. We are not, however, able to offer extensive programming or debugging support. For assistance with the Kerberos authentication service, please contact the IT Support Center at consultant@northwestern.edu.

This service differs from the LDAP Registry service in a few ways:

  • Kerberos provides authentication only; no demographic attributes are available. If you need data such as email address, phone number, etc., you need to use the LDAP Registry.
  • The Kerberos service is designed to be lighter weight (both administratively and technically), and requires no prior approval.
  • Other than being restricted to certain NU IP addresses, Kerberos authentication can be used from anywhere.

There are two main ways you can use Kerberos authentication:

  • Kerberized client/server applications. Kerberized applications make use of Kerberos tickets to authenticate clients to servers. No passwords are ever transmitted over the network. This is the most secure way to use Kerberos. Several Kerberized applications (telnet, ftp, rsh) are included with MIT's distribution. It is also possible to authenticate individual Windows workstations against a Kerberos realm; the user does not need to know his/her Windows password, just his/her Kerberos (netid) password.
  • Kerberos-based password checking. Kerberos can also be used as an external password-checker. Apache modules and PAMs for Linux and Unix are two examples of this technique. Plaintext usernames and passwords are typically given by clients to application servers (protected in an SSL or SSH tunnel), and the application servers then verify the username/password pair by attempting to obtain a Kerberos ticket for the user. If it works, authentication is successful.

 

Guidelines

  • No prior approval is required to use the Kerberos Authentication Service.
  • The Kerberos servers will only be available to the 129.105.0.0 and 165.124.0.0 IP networks. This excludes the student residence halls and some Research Park and other building. Residence halls will not be enabled, but other networks may be enabled if the need arises.
  • Notices of down time, system upgrades, outages and so forth will be posted to the nwu-comp-announce listserv.
  • Northwestern IT will monitor the Kerberos logs closely in an attempt to detect and prevent password guessing attacks or other abuse. Registering your application will help prevent us from mistaking legitimate activity from your application as an attack.
  • Users are expected to maintain reasonably current versions of Kerberos on clients and application servers. We will generally keep the Kerberos servers at the most current release of MIT's distribution.
  • Applications which use Kerberos as an external password-checker should cache some form of token for a defined period of time to avoid excessive round-trips to the Kerberos server for authentication. However, applications should not cache the actual plaintext password.
  • Application owners should take reasonable steps to ensure that their systems are secured against intrusion, and cannot be used as a platform to launch denial-of-service or other attacks.

 

Authentication for Other Operating Systems

There are Kerberos PAM distributions for several flavors of Unix. There are also Kerberized versions of telnet, ftp and rsh included with MIT's Kerberos distribution (see below). OpenSSH also includes support for Kerberos authentication. 

Password Checking

Password checking applications will generally need to perform the following steps:

  • Determine the user's Kerberos principal name: netid@ADS.NORTHWESTERN.EDU
  • Use the principal name and password to obtain a ticket-granting ticket (TGT)
  • Use the TGT to obtain a service ticket, verifying the authenticity of the KDC
  • Cache a timestamp/token that can be used on subsequent requests, avoiding unnecessary round trips to the KDC (optional but recommended)

Configuration

  • The name of the Kerberos realm is ADS.NORTHWESTERN.EDU (all caps).
  • The Kerberos servers (KDC) is kerberos.northwestern.edu. This is a load-balanced virtual IP address (VIP) that points to Active Directory Domain Controllers on each campus.
  • Pre-authentication is required for all applications. We use the simple timestamp-based preauth, which is supported by most versions of Kerberos.

Below is a sample configuration file (/etc/krb5.conf in most Unix systems).

[libdefaults]

Was this helpful?
0 reviews

Details

Article ID: 1915
Created
Fri 7/29/22 7:31 AM
Modified
Thu 9/21/23 10:56 AM

Related Services / Offerings (1)

Northwestern offers many ways to help your IT system authenticate or authorize users. This includes Active Directory, LDAP, Single Sign-On (SSO), Multi-Factor Authentication (MFA), Shibboleth, SAML, and others.