Kerberos authentication in RHEL: Easing Windows-Linux integration

For a long time, Linux has been able to provide file services for Windows using the Samba server. One of the challenges has been the way Samba integrates with client authentication in typical Windows environments. By combining

Requires Free Membership to View

Samba and Kerberos, Linux now offers better integration between Linux and Windows. In this article you'll learn how Kerberos authentication works in Red Hat Enterprise Linux (RHEL) 5.4 or later.

The purpose of Kerberos is to provide secure authentication over insecure networks. A key factor is that in Kerberos authentication, no passwords are ever sent over the wire. To understand how this works, let's first have a look at how Kerberos provides authentication services.

First and foremost, Kerberos provides authentication services and nothing more. It was developed by MIT in the 1980s and the big breakthrough came when Microsoft implemented it as the basis of authentication in Windows 2000. The key element in Kerberos is the Key Distribution Center (KDC). The KDC makes sure that keys are available for all Kerberos principals. In Kerberos, everything is a principal -- users as well as services -- and all of these can mutually authenticate.

The procedure in Kerberos authentication can be summarized as follows:

  1. The client gets a ticket-granting ticket (TGT). This is a request to obtain a ticket that can be used for authentication. The KDC hands out this TGT.
  2. After getting the TGT, the client uses it to get a service ticket.
  3. This service ticket is used to establish a secure session with the service.

Kerberos authentication layers
In Kerberos, three layers of authentication are closely integrated. First, there is KRB5. This is the Kerberos core layer. To implement Kerberos in particular network protocols, additional protocols are used. First, there is Generic Security Services Application Programming Interface (GSSAPI). This is a standard API that applications can use to authenticate on any security service. The last part of the solution is a simple protected negotiation mechanism (SPNEGO) that is used by GSSAPI. Clients and servers use this protocol to find out how they should communicate. These components are all used when using Kerberos to protect CIFS communication. Represented in a simplified manner, the following steps are accomplished while negotiating authentication:

  1. Client sends NegProt request, which starts the negotiation about the protocol that is going to be used for authentication.
  2. The server replies on this request with a list of supported methods using SPNEGO.
  3. Client uses SPNEGO to send a session setup request that contains a KRB5 ticket wrapped in GSSAPI.

Setting up CIFS to use Kerberos authentication
Kerberos authentication for CIFS is available as a fully supported solution for RHEL 5.4 and later. It consists of several parts. First, there is the client configuration for KRB5, which is in the file /etc/krb5.conf. Next, there is the /sbin/request-key program that is used to request Kerberos keys. The last part is the /usr/sbin/cifs.upcall program. This is in the Samba-client package (cifs-utils in later versions) and makes sure that CIFS can talk to Kerberos.

The easiest way to set up the Kerberos configuration is by using system-config-authentication. As a result, the krb5.conf configuration file is created, which contains all the Kerberos information that is required to authenticate. Below is an example of what this file could look like.

            EXAMPLE.COM = {
                        kdc = ad.example.com:88
                       admin_server = ad.exampe.com:749
            example.com = EXAMPLE.COM
            example.com = EXAMPLE.COM

In addition to that, the /etc/request-key.conf is used. This file tells the request-key program what program it should run and how.

After setting it all up, you can perform the CIFS mount using Kerberos. To do this, you must accomplish two steps. First, you have to get a krb5 ticket. After obtaining the ticket, you can make the mount. You can perform these steps using the kinit command, followed by the mount command:

kinit testuser@EXAMPLE.COM
mount -t cifs -o sec=krb5 //server.example.com/export /mnt/cifs

In these, first kinit is used to get the Kerberos tickets. In this example the ticket is requested for the user testuser@EXAMPLE.COM, where EXAMPLE.COM is the name of the Kerberos realm that is used for authentication. Note that the realm name is always uppercase and normally follows the DNS naming scheme. Once the ticket has been obtained, the user who has the ticket can make a CIFS mount. To do this, he can use the mount -t cifs command, used with the -o sec=krb5 option. The latter indicates that Kerberos is used as the authentication protocol. This establishes the CIFS mount based on Kerberos.

This was first published in September 2010

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.