Configure Smart Card Kerberos Authentication

  • Tutorial
Continuing the long-standing topic about using two-factor authentication in GNU / Linux, let me tell you about the scheme of work and setting up authentication using Kerberos. In this article, we will look at the process of configuring MIT Kerberos to authenticate users with certificates and key pairs located on a USB token. Also, the materials presented in the article can be used to configure authentication in a Windows domain.

Brief introduction

To begin with, we will carry out a small educational program in Kerberos terminology and consider the available implementations of this protocol in GNU / Linux-based OS. I must say right away that I could not find an unambiguous translation of the terms used in Kerberos, so I will duplicate the main terms in English to avoid confusion.
So, let's begin. If you quote Wikipedia, then
Kerberos is a network authentication protocol that allows data to be transmitted over insecure networks for secure authentication. It is focused primarily on the client-server model and provides mutual authentication - both users through the server confirm each other's identities.
It is worth noting that Kerberos is primarily a protocol, not a specific authentication system. Its implementations are used in various operating systems, including Windows, as a method of authenticating users in a domain. There are several open source implementations of the Kerberos protocol, for example, the original MIT Kerberos and Heimdal. Such a zoo arose due to US restrictions on the export of cryptographic means of information protection, today this situation around MIT Kerberos has already subsided. In this article, we will look at the configuration process for MIT Kerberos V5.


Kerberos terminology

  • Ticket (ticket) - temporary data issued to the client for authentication on the server on which the necessary service is located.
  • Client is a certain entity in the network (user, host or service) that can receive a ticket from Kerberos.
  • Key distribution center (KDC) - a service issuing tickets Kerberos.
  • A realm is a network used by Kerberos, consisting of KDC servers and multiple clients. The name realm is case sensitive, usually spelled in upper case and matches the domain name.
  • Principal is a unique name for a client for which Kerberos authentication is allowed. It is written as root [/ instance] @REALM.

Kerberos Settings Files

On server:
  • /etc/krb5kdc/kdc.conf - KDC settings
On the client and server:
  • /etc/kbr5.conf - authentication server settings (description of realms, domain names and other settings)

Setting up the work environment

First you need to deploy the environment in which authentication will be performed. The easiest way to do this is by taking two virtual machines on the same subnet. It is enough to install some Ubuntu on one virtual machine (this will be our server), and then clone it and get the client. When writing the article, I used the fresh Ubuntu 12.10 (x86) and the VMWare virtual machine. To make it easier for virtual machines to see each other over the network, it is worth switching the network cards to Bridged mode.
Important! Make sure that the time on the client and server is synchronized, this is necessary for Kerberos to work correctly.

Network configuration

Kerberos clients look for their servers by domain name, so you need to configure DNS and make sure that server names are resolved successfully. In our example, it is enough to enter the server domain name in / etc / hosts, which I did. The network diagram is shown below.


Install the required packages

On the server we need:
  • krb5-kdc - KDC service
  • krb5-admin-server - Kerberos administrative server (it monitors user accounts)
  • krb5-pkinit - Kerberos extension module for certificate authentication

The following packages must be installed on the client:
  • krb5-user - basic set of utilities for client authentication
  • krb5-config - Kerberos configuration files
  • krb5-pkinit
  • libpam-krb5 - PAM module for using Kerberos authentication
  • pcscd, opensc, libengine-pkcs11-openssl - packages necessary for working with tokens

When installing packages, we will be asked for default settings, we will use the following:
  • Default realm: AKTIV-TEST.RU
  • Server names (admin server and KDC): aktiv-test.ru (it is also registered in / etc / hosts on the client)
  • User: testuser@AKTIV-TEST.RU

Configure Kerberos

Basic settings

After installing the packages on the server, you need to initialize realm with the command
$ sudo krb5_newrealm

And on the client - update the configuration files:
$ sudo dpkg-reconfigure krb5-config

Also on the client and server, add the following lines to /etc/krb5.conf:
[domain_realm]
.aktiv-test.ru = AKTIV-TEST.RU
aktiv-test.ru = AKTIV-TEST.RU

Now create a new user on the server named testuser
$ sudo kadmin.local
# username = testuser
# password = test
# добавляем нового пользователя и устанавливаем его пароль
kadmin.local:$ addprinc testuser
# ...
kadmin.local:$ quit

On the client, you can now check whether we have configured the network and Kerberos correctly:
$ kinit testuser@AKTIV-TEST.RU
# вводим пароль пользователя
$ klist
# и видим выданный ticket, после чего его можно удалить следующей командой
$ kdestroy

Configure Public Key Authentication

For the pkinit module to work, we will have to use openssl as a mini-CA to create key pairs and client and server certificates.
On server:
We will create a key pair and a certificate of our "CA". Here we will generate the CA key and create a self-signed certificate using openssl. In the real world, the key naturally needs to be reliably protected from falling into the wrong hands.
$ openssl genrsa -out cakey.pem 2048 
# ...
$ openssl req -key cakey.pem -new -x509 -out cacert.pem
# ...

We will create a key pair for KDC, an application for a certificate and write it for ourselves.
Here we need a special OpenSSL file extension ( pkinit_extensions ), which will indicate additional fields of certificates used in Kerberos. In particular, we will set:
  • Extended Key Usage (EKU) - an identifier (OID) that tells how you plan to use the certificate
  • otherName - field specifying our principal for whom the certificate is issued

$ openssl genrsa -out kdckey.pem 2048 
# создание запроса
$ openssl req -new -out kdc.req -key kdckey.pem
# подпись запроса
$ REALM=AKTIV-TEST.RU; export REALM
$ CLIENT=aktiv-test.ru; export CLIENT
# содержимое файла pkinit_extensions см. по ссылке выше
$ openssl x509 -req -in kdc.req -CAkey cakey.pem -CA cacert.pem -out kdc.pem -extfile pkinit_extensions -extensions kdc_cert –CAcreateserial

After that, transfer the following files to / var / lib / krb5kdc /:
  • kdc.pem
  • kdckey.pem
  • cacert.pem

On the server, edit the Kerberos settings (file /etc/krb5kdc/kdc.conf) to use the keys and certificates of the server and CA:
[kdcdefaults]
    kdc_tcp_ports = 88
    pkinit_identity = FILE:/var/lib/krb5kdc/kdc.pem,/var/lib/krb5kdc/kdckey.pem
    pkinit_anchors = FILE:/var/lib/krb5kdc/cacert.pem
[realms]
    AKTIV-TEST.RU = {
        database_name = /var/lib/krb5kdc/principal
        admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab
        acl_file = /etc/krb5kdc/kadm5.acl
        key_stash_file = /etc/krb5kdc/stash
        max_life = 10h 0m 0s
        max_renewable_life = 7d 0h 0m 0s
        master_key_type = des3-hmac-sha1
        supported_enctypes = aes256-cts:normal arcfour-hmac:normal des3-hmac-sha1:normal des-cbc-crc:normal des:normal des:v4 des:norealm des:onlyrealm des:afs3
        default_principal_flags = +preauth
    }

Next, on the server, you must enable pre-authentication for our user.
$ kadmin.local
kadmin.local$: modprinc +requires_preauth testuser

We will perform further actions on the client
Format the token
$ pkcs15-init --erase-card -p rutoken_ecp
$ pkcs15-init --create-pkcs15 --so-pin "87654321" --so-puk ""
$ pkcs15-init --store-pin --label "User PIN" --auth-id 02 --pin "12345678" --puk "" --so-pin "87654321" –finalize

We will generate a key pair of RSA 2048 bits on the token and create a certificate application. It is important to note that the paths to the engine_pkcs11.so and opensc-pkcs11.so libraries on your system may differ, so you should first check their location.
# на данном шаге важно запомнить ID ключевой пары, его мы используем позже
$ pkcs15-init -G rsa/2048 --auth-id 02 --id 42 --label "testuser's key" --public-key-label "testuser's public key"
# ...
$ openssl
# на multiarch-системах opensc-pkcs11.so и engine_pkcs11.so могут лежать в других местах
OpenSSL> engine dynamic -pre SO_PATH:/usr/lib/openssl/engines/engine_pkcs11.so -pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre MODULE_PATH:opensc-pkcs11.so
(dynamic) Dynamic engine loading support
[Success]: SO_PATH:/usr/lib/openssl/engines/engine_pkcs11.so
[Success]: ID:pkcs11
[Success]: LIST_ADD:1
[Success]: LOAD
[Success]: MODULE_PATH:opensc-pkcs11.so
Loaded: (pkcs11) pkcs11 engine
OpenSSL> req -engine pkcs11 -new -key 1:42 -keyform engine -out client.req -subj "/C=RU/ST=Moscow/L=Moscow/O=Aktiv/OU=dev/CN=testuser/emailAddress=testuser@mail.com"
engine "pkcs11" set.
PKCS#11 token PIN: 
OpenSSL> quit

After that, we will receive the client.req application file, which must be placed on the server and write out a user certificate based on the CA data:
$ REALM=AKTIV-TEST.RU; export REALM
$ CLIENT=testuser; export CLIENT
$ openssl x509 -CAkey cakey.pem -CA cacert.pem -req -in client.req -extensions client_cert -extfile pkinit_extensions -out client.pem

Then it is worth restarting the server and KDC:
$ /etc/init.d/krb5-admin-server restart
$ /etc/init.d/krb5-kdc restart

At the output of openssl, we get a file with the client.pem client certificate. It must be transferred to the client machine, put in / etc / krb5 / and written to the token:
$ pkcs15-init --store-certificate client.pem --auth-id 02 --id 42 --format pem

Finally, we need to make a setting in the Kerberos configuration file that will indicate what data to use for authentication (in our case, this is a CA certificate and the path to the PKCS # 11 module). The MIT Kerberos documentation contains various parameters that allow you to configure the choice of authentication data on the token, in our case we just specify the PKCS # 11 module, since this is enough in this situation.
[libdefaults]
    default_realm = AKTIV-TEST.RU
# путь к сертификату УЦ
    pkinit_anchors = FILE:/etc/krb5/cacert.pem
# путь к модулю PKCS#11
    pkinit_identities = PKCS11:/usr/lib/opensc-pkcs11.so

Check if we can get a ticket on the client using data from the token:
$ kinit testuser
# на этом этапе у нас должны спросить PIN-код от токена
$ klist	

Configuring PAM Authentication Using Kerberos

Earlier, when setting up the client machine, we installed the libpam-krb5 package. It will help us authenticate with Kerberos when we log in, as well as with applications that use system authentication (for example, login, lightdm, etc.). To connect the PAM module, just run the command
$ sudo pam-auth-update

and select the necessary authentication modules in the dialog. For more fine-tuning, you can look into the /etc/pam.d/common-auth file and edit it as desired. The file structure I described in a previous article .

Conclusion

The use of the Kerberos protocol for centralized authentication in conjunction with the centralized creation of storage and distribution of accounts (for example, through a directory based on OpenLDAP) allows you to create a “UNIX domain”, which consists entirely of machines running free software. This solution can be applied in the corporate sector, and smart card authentication will be a nice bonus for both administrators and users of the company’s network.

useful links


Also popular now: