pam_apparmor
An open network provides no means of ensuring that a workstation can identify its users properly, except through the usual password mechanisms. In common installations, the user must enter the password each time a service inside the network is accessed. Kerberos provides an authentication method with which a user registers only once and is trusted in the complete network for the rest of the session. To have a secure network, the following requirements must be met:
Have all users prove their identity for each desired service and make sure that no one can take the identity of someone else.
Make sure that each network server also proves its identity. Otherwise an attacker might be able to impersonate the server and obtain sensitive information transmitted to the server. This concept is called mutual authentication, because the client authenticates to the server and vice versa.
Kerberos helps you meet these requirements by providing strongly encrypted authentication. Only the basic principles of Kerberos are discussed here. For detailed technical instruction, refer to the Kerberos documentation.
The following glossary defines some Kerberos terminology.
Users or clients need to present some kind of credentials that authorize them to request services. Kerberos knows two kinds of credentials—tickets and authenticators.
A ticket is a per-server credential used by a client to authenticate at a server from which it is requesting a service. It contains the name of the server, the client's name, the client's Internet address, a time stamp, a lifetime, and a random session key. All this data is encrypted using the server's key.
Combined with the ticket, an authenticator is used to prove that the client presenting a ticket is really the one it claims to be. An authenticator is built using the client's name, the workstation's IP address, and the current workstation's time, all encrypted with the session key known only to the client and the relevant server. An authenticator can only be used once, unlike a ticket. A client can build an authenticator itself.
A Kerberos principal is a unique entity (a user or service) to which it can assign a ticket. A principal consists of the following components:
Primary—the first part of the principal, which can be the same as your user name in the case of a user.
Instance—some optional
information characterizing the primary. This string is separated
from the primary by a /
.
Realm—this specifies your Kerberos realm. Normally, your realm is your domain name in uppercase letters.
Kerberos ensures that both client and server can be sure of each other's identity. They share a session key, which they can use to communicate securely.
Session keys are temporary private keys generated by Kerberos. They are known to the client and used to encrypt the communication between the client and the server for which it requested and received a ticket.
Almost all messages sent in a network can be eavesdropped, stolen, and resent. In the Kerberos context, this would be most dangerous if an attacker manages to obtain your request for a service containing your ticket and authenticator. The attacker could then try to resend it (replay) to impersonate you. However, Kerberos implements several mechanisms to deal with this problem.
Service is used to refer to a specific action to perform. The process behind this action is called a server.
Kerberos is often called a third-party trusted authentication service, which means all its clients trust Kerberos's judgment of another client's identity. Kerberos keeps a database of all its users and their private keys.
To ensure Kerberos is working correctly, run both the authentication and
ticket-granting server on a dedicated machine. Make sure that only the
administrator can access this machine physically and over the network.
Reduce the (networking) services running on it to the absolute
minimum—do not even run
sshd
.
Your first contact with Kerberos is quite similar to any login procedure at a normal networking system. Enter your user name. This piece of information and the name of the ticket-granting service are sent to the authentication server (Kerberos). If the authentication server knows you, it generates a random session key for further use between your client and the ticket-granting server. Now the authentication server prepares a ticket for the ticket-granting server. The ticket contains the following information—all encrypted with a session key only the authentication server and the ticket-granting server know:
The names of both, the client and the ticket-granting server
The current time
A lifetime assigned to this ticket
The client's IP address
The newly-generated session key
This ticket is then sent back to the client together with the session key, again in encrypted form, but this time the private key of the client is used. This private key is only known to Kerberos and the client, because it is derived from your user password. Now that the client has received this response, you are prompted for your password. This password is converted into the key that can decrypt the package sent by the authentication server. The package is “unwrapped” and password and key are erased from the workstation's memory. As long as the lifetime given to the ticket used to obtain other tickets does not expire, your workstation can prove your identity.
To request a service from any server in the network, the client application needs to prove its identity to the server. Therefore, the application generates an authenticator. An authenticator consists of the following components:
The client's principal
The client's IP address
The current time
A checksum (chosen by the client)
All this information is encrypted using the session key that the client has already received for this special server. The authenticator and the ticket for the server are sent to the server. The server uses its copy of the session key to decrypt the authenticator, which gives it all the information needed about the client requesting its service, to compare it to that contained in the ticket. The server checks if the ticket and the authenticator originate from the same client.
Without any security measures implemented on the server side, this stage of the process would be an ideal target for replay attacks. Someone could try to resend a request stolen off the net some time before. To prevent this, the server does not accept any request with a time stamp and ticket received previously. In addition to that, a request with a time stamp differing too much from the time the request is received is ignored.
Kerberos authentication can be used in both directions. It is not only a question of the client being the one it claims to be. The server should also be able to authenticate itself to the client requesting its service. Therefore, it sends an authenticator itself. It adds one to the checksum it received in the client's authenticator and encrypts it with the session key, which is shared between it and the client. The client takes this response as a proof of the server's authenticity and they both start cooperating.
Tickets are designed to be used for one server at a time. Therefore, you need to get a new ticket each time you request another service. Kerberos implements a mechanism to obtain tickets for individual servers. This service is called the “ticket-granting service”. The ticket-granting service is a service (like any other service mentioned before) and uses the same access protocols that have already been outlined. Any time an application needs a ticket that has not already been requested, it contacts the ticket-granting server. This request consists of the following components:
The requested principal
The ticket-granting ticket
An authenticator
Like any other server, the ticket-granting server now checks the ticket-granting ticket and the authenticator. If they are considered valid, the ticket-granting server builds a new session key to be used between the original client and the new server. Then the ticket for the new server is built, containing the following information:
The client's principal
The server's principal
The current time
The client's IP address
The newly-generated session key
The new ticket has a lifetime, which is either the remaining lifetime of the ticket-granting ticket or the default for the service. The lesser of both values is assigned. The client receives this ticket and the session key, which are sent by the ticket-granting service, but this time the answer is encrypted with the session key that came with the original ticket-granting ticket. The client can decrypt the response without requiring the user's password when a new service is contacted. Kerberos can thus acquire ticket after ticket for the client without bothering the user.
Windows 2000 contains a Microsoft implementation of Kerberos 5. openSUSE® Leap uses the MIT implementation of Kerberos 5, find useful information and guidance in the MIT documentation at Section 7.5, “For More Information”.
Ideally, a user's one and only contact with Kerberos happens during login at the workstation. The login process includes obtaining a ticket-granting ticket. At logout, a user's Kerberos tickets are automatically destroyed, which makes it difficult for anyone else to impersonate this user.
The automatic expiration of tickets can lead to a somewhat awkward
situation when a user's login session lasts longer than the maximum
lifespan given to the ticket-granting ticket (a reasonable setting is 10
hours). However, the user can get a new ticket-granting ticket by running
kinit
. Enter the password again and Kerberos obtains
access to desired services without additional authentication. To get a
list of all the tickets silently acquired for you by Kerberos, run
klist
.
Here is a short list of applications that use Kerberos authentication.
These applications can be found under
/usr/lib/mit/bin
or
/usr/lib/mit/sbin
after installing the package
krb5-apps-clients
. They all have the full
functionality of their common Unix and Linux brothers plus the additional
bonus of transparent authentication managed by Kerberos:
telnet
,
telnetd
rlogin
rsh
, rcp
,
rshd
ftp
, ftpd
ksu
You no longer need to enter your password for using these applications
because Kerberos has already proven your identity.
ssh
, if compiled with Kerberos support, can even
forward all the tickets acquired for one workstation to another one. If
you use ssh
to log in to another workstation,
ssh
makes sure that the encrypted contents of the
tickets are adjusted to the new situation. Simply copying tickets between
workstations is not sufficient because the ticket contains
workstation-specific information (the IP address). XDM and GDM offer
Kerberos support, too. Read more about the Kerberos network applications
in Kerberos V5 UNIX User's Guide at
http://web.mit.edu/kerberos.
A Kerberos environment consists of several different components. A key distribution center (KDC) holds the central database with all Kerberos-relevant data. All clients rely on the KDC for proper authentication across the network. Both the KDC and the clients need to be configured to match your setup:
Check your network setup and make sure it meets the minimum requirements outlined in Section 7.4.1, “Kerberos Network Topology”. Choose an appropriate realm for your Kerberos setup, see Section 7.4.2, “Choosing the Kerberos Realms”. Carefully set up the machine that is to serve as the KDC and apply tight security, see Section 7.4.3, “Setting Up the KDC Hardware”. Set up a reliable time source in your network to make sure all tickets contain valid time stamps, see Section 7.4.4, “Configuring Time Synchronization”.
Configure the KDC and the clients, see Section 7.4.5, “Configuring the KDC” and Section 7.4.6, “Configuring Kerberos Clients”. Enable remote administration for your Kerberos service, so you do not need physical access to your KDC machine, see Section 7.4.7, “Configuring Remote Kerberos Administration”. Create service principals for every service in your realm, see Section 7.4.8, “Creating Kerberos Service Principals”.
Various services in your network can use Kerberos. To add Kerberos password-checking to applications using PAM, proceed as outlined in Section 7.4.9, “Enabling PAM Support for Kerberos”. To configure SSH or LDAP with Kerberos authentication, proceed as outlined in Section 7.4.10, “Configuring SSH for Kerberos Authentication” and Section 7.4.11, “Using LDAP and Kerberos”.
Any Kerberos environment must meet the following requirements to be fully functional:
Provide a DNS server for name resolution across your network, so clients and servers can locate each other. Refer to Book “Reference”, Chapter 19 “The Domain Name System” for information on DNS setup.
Provide a time server in your network. Using exact time stamps is crucial to a Kerberos setup, because valid Kerberos tickets must contain correct time stamps. Refer to Book “Reference”, Chapter 18 “Time Synchronization with NTP” for information on NTP setup.
Provide a key distribution center (KDC) as the center piece of the Kerberos architecture. It holds the Kerberos database. Use the tightest possible security policy on this machine to prevent any attacks on this machine compromising your entire infrastructure.
Configure the client machines to use Kerberos authentication.
The following figure depicts a simple example network with only the minimum components needed to build a Kerberos infrastructure. Depending on the size and topology of your deployment, your setup may vary.
For a setup similar to the one in Figure 7.1, “Kerberos Network Topology”, configure routing between the two subnets (192.168.1.0/24 and 192.168.2.0/24). Refer to Book “Reference”, Chapter 13 “Basic Networking”, Section 13.4.1.5 “Configuring Routing” for more information on configuring routing with YaST.
The domain of a Kerberos installation is called a realm and is
identified by a name, such as EXAMPLE.COM
or simply
ACCOUNTING
. Kerberos is case-sensitive, so
example.com
is actually a different realm than
EXAMPLE.COM
. Use the case you prefer. It is common
practice, however, to use uppercase realm names.
It is also a good idea to use your DNS domain name (or a subdomain, such
as ACCOUNTING.EXAMPLE.COM
). As shown below, your life
as an administrator can be much easier if you configure your Kerberos
clients to locate the KDC and other Kerberos services via DNS. To do so,
it is helpful if your realm name is a subdomain of your DNS domain name.
Unlike the DNS name space, Kerberos is not hierarchical. You
cannot set up a realm named EXAMPLE.COM
, have
two “subrealms” named
DEVELOPMENT
and
ACCOUNTING
underneath it, and expect the
two subordinate realms to somehow inherit principals from
EXAMPLE.COM
. Instead, you would have three
separate realms for which you would need to configure
cross-realm authentication for users from one realm to interact
with servers or other users from another realm.
For the sake of simplicity, let us assume you are setting up just one
realm for your entire organization. For the remainder of this section,
the realm name EXAMPLE.COM
is used in all examples.
The first thing required to use Kerberos is a machine that acts as the key distribution center, or KDC for short. This machine holds the entire Kerberos user database with passwords and all information.
The KDC is the most important part of your security infrastructure—if someone breaks into it, all user accounts and all of your infrastructure protected by Kerberos is compromised. An attacker with access to the Kerberos database can impersonate any principal in the database. Tighten security for this machine as much as possible:
Put the server machine into a physically secured location, such as a locked server room to which only a very few people have access.
Do not run any network applications on it except the KDC. This includes servers and clients—for example, the KDC should not import any file systems via NFS or use DHCP to retrieve its network configuration.
Install a minimal system first then check the list of installed
packages and remove any unneeded packages. This includes servers, such
as inetd
,
portmap
, and CUPS, plus
anything X-based. Even installing an SSH server should be considered a
potential security risk.
No graphical login is provided on this machine as an X server is a potential security risk. Kerberos provides its own administration interface.
Configure /etc/nsswitch.conf
to use only local
files for user and group lookup. Change the lines for
passwd
and group
to look like
this:
passwd: files group: files
Edit the passwd
, group
, and
shadow
files in /etc
and
remove the lines that start with a +
character
(these are for NIS lookups).
Disable all user accounts except root
's account by editing
/etc/shadow
and replacing the hashed passwords
with *
or !
characters.
To use Kerberos successfully, make sure that all system clocks within your organization are synchronized within a certain range. This is important because Kerberos protects against replayed credentials. An attacker might be able to observe Kerberos credentials on the network and reuse them to attack the server. Kerberos employs several defenses to prevent this. One of them is that it puts time stamps into its tickets. A server receiving a ticket with a time stamp that differs from the current time rejects the ticket.
Kerberos allows a certain leeway when comparing time stamps. However, computer clocks can be very inaccurate in keeping time—it is not unheard of for PC clocks to lose or gain half an hour over the course of a week. For this reason, configure all hosts on the network to synchronize their clocks with a central time source.
A simple way to do so is by installing an NTP time server on one machine
and having all clients synchronize their clocks with this server. Do
this either by running an NTP daemon in client mode on all these
machines or by running ntpdate
once a day from all
clients (this solution probably works for a small number of clients
only). The KDC itself needs to be synchronized to the common time source
as well. Because running an NTP daemon on this machine would be a
security risk, it is probably a good idea to do this by running ntpdate
via a cron entry. To configure your machine as an NTP client, proceed as
outlined in Book “Reference”, Chapter 18 “Time Synchronization with NTP”, Section 18.1 “Configuring an NTP Client with YaST”.
A different way to secure the time service and still use the NTP daemon is to attach a hardware reference clock to a dedicated NTP server as well as an additional hardware reference clock to the KDC.
It is also possible to adjust the maximum deviation Kerberos allows when
checking time stamps. This value (called clock
skew) can be set in the krb5.conf
file
as described in
Section 7.4.6.1.3, “Adjusting the Clock Skew”.
This section covers the initial configuration and installation of the KDC, including the creation of an administrative principal. This procedure consists of several steps:
Install the RPMs.
On a machine designated as the KDC, install the following software
packages: krb5
,
krb5-server
and
krb5-client
packages.
Adjust the Configuration Files.
The /etc/krb5.conf
and
/var/lib/kerberos/krb5kdc/kdc.conf
configuration
files must be adjusted for your scenario. These files contain all
information on the KDC.
Create the Kerberos Database. Kerberos keeps a database of all principal identifiers and the secret keys of all principals that need to be authenticated. Refer to Section 7.4.5.1, “Setting Up the Database” for details.
Adjust the ACL Files: Add Administrators.
The Kerberos database on the KDC can be managed remotely. To prevent
unauthorized principals from tampering with the database, Kerberos
uses access control lists. You must explicitly enable remote access
for the administrator principal to enable him to manage the database.
The Kerberos ACL file is located under
/var/lib/kerberos/krb5kdc/kadm5.acl
. Refer to
Section 7.4.7, “Configuring Remote Kerberos Administration” for details.
Adjust the Kerberos Database: Add Administrators. You need at least one administrative principal to run and administer Kerberos. This principal must be added before starting the KDC. Refer to Section 7.4.5.2, “Creating a Principal” for details.
Start the Kerberos Daemon. After the KDC software is installed and properly configured, start the Kerberos daemon to provide Kerberos service for your realm. Refer to Section 7.4.5.3, “Starting the KDC” for details.
Create a Principal for Yourself. You need a principal for yourself. Refer to Section 7.4.5.2, “Creating a Principal” for details.
Your next step is to initialize the database where Kerberos keeps all information about principals. Set up the database master key, which is used to protect the database from accidental disclosure (in particular if it is backed up to tape). The master key is derived from a pass phrase and is stored in a file called the stash file. This is so you do not need to enter the password every time the KDC is restarted. Make sure that you choose a good pass phrase, such as a sentence from a book opened to a random page.
When you make tape backups of the Kerberos database
(/var/lib/kerberos/krb5kdc/principal
), do not back
up the stash file (which is in
/var/lib/kerberos/krb5kdc/.k5.EXAMPLE.COM
).
Otherwise, everyone able to read the tape could also decrypt the
database. Therefore, keep a copy of the pass phrase in a safe or some
other secure location, because you will need it to restore your
database from backup tape after a crash.
To create the stash file and the database, run:
kdb5_util create -r EXAMPLE.COM -s
You will see the following output:
Initializing database '/var/lib/kerberos/krb5kdc/principal' for realm 'EXAMPLE.COM', master key name 'K/M@EXAMPLE.COM' You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter KDC database master key: 1 Re-enter KDC database master key to verify: 2
To verify, use the list command:
kadmin.local kadmin> listprincs
You will see several principals in the database, which are for internal use by Kerberos:
K/M@EXAMPLE.COM kadmin/admin@EXAMPLE.COM kadmin/changepw@EXAMPLE.COM krbtgt/EXAMPLE.COM@EXAMPLE.COM
Create two Kerberos principals for yourself: one normal principal for
everyday work and one for administrative tasks relating to Kerberos.
Assuming your login name is geeko
,
proceed as follows:
kadmin.local kadmin> ank geeko
You will see the following output:
geeko@EXAMPLE.COM's Password: 1 Verifying password: 2
Next, create another principal named
geeko/admin
by typing
ank
geeko/admin
at
the kadmin
prompt. The admin
suffixed to your user name is a role. Later, use
this role when administering the Kerberos database. A user can have
several roles for different purposes. Roles act like completely
different accounts that have similar names.
Start the KDC daemon and the kadmin daemon. To start the daemons manually, enter:
sudo systemctl start krb5kdc sudo systemctl start kadmind
Also make sure that the services KDC (krb5kdc
) and
kadmind (kadmind
) are started by
default when the server machine is rebooted. Enable them by entering:
sudo systemctl enable krb5kdc kadmind
or by using the YaST
.When the supporting infrastructure is in place (DNS, NTP) and the KDC has been properly configured and started, configure the client machines. To configure a Kerberos client, use one of the two manual approaches described below.
When configuring Kerberos, there are two approaches you can
take—static configuration in the
/etc/krb5.conf
file or dynamic configuration with
DNS. With DNS configuration, Kerberos applications try to locate the
KDC services using DNS records. With static configuration, add the host
names of your KDC server to krb5.conf
(and update
the file whenever you move the KDC or reconfigure your realm in other
ways).
DNS-based configuration is generally a lot more flexible and the amount
of configuration work per machine is a lot less. However, it requires
that your realm name is either the same as your DNS domain or a
subdomain of it. Configuring Kerberos via DNS also creates a minor
security issue—an attacker can seriously disrupt your
infrastructure through your DNS (by shooting down the name server,
spoofing DNS records, etc.). However, this amounts to a denial of
service at worst. A similar scenario applies to the static
configuration case unless you enter IP addresses in
krb5.conf
instead of host names.
One way to configure Kerberos is to edit
/etc/krb5.conf
. The file installed by default
contains various sample entries. Erase all of these entries before
starting. krb5.conf
is made up of several
sections (stanzas), each introduced by the section name in brackets
like [this]
.
To configure your Kerberos clients, add the following stanza to
krb5.conf
(where
kdc.example.com
is the
host name of the KDC):
[libdefaults] default_realm = EXAMPLE.COM [realms] EXAMPLE.COM = { kdc = kdc.example.com admin_server = kdc.example.com }
The default_realm
line sets the default realm for
Kerberos applications. If you have several realms, add additional
statements to the [realms]
section.
Also add a statement to this file that tells applications how to map
host names to a realm. For example, when connecting to a remote host,
the Kerberos library needs to know in which realm this host is
located. This must be configured in the
[domain_realms]
section:
[domain_realm] .example.com = EXAMPLE.COM www.example.org = EXAMPLE.COM
This tells the library that all hosts in the
example.com
DNS domains are in the
EXAMPLE.COM
Kerberos realm. In addition, one
external host named www.example.org
should also
be considered a member of the EXAMPLE.COM
realm.
DNS-based Kerberos configuration makes heavy use of SRV records. See (RFC2052) A DNS RR for specifying the location of services at http://www.ietf.org.
The name of an SRV record, as far as Kerberos is concerned, is always
in the format _service._proto.realm
, where realm is
the Kerberos realm. Domain names in DNS are case-insensitive, so
case-sensitive Kerberos realms would break when using this
configuration method. _service
is a service name
(different names are used when trying to contact the KDC or the
password service, for example). _proto
can be
either _udp
or _tcp
, but not all
services support both protocols.
The data portion of SRV resource records consists of a priority value, a weight, a port number, and a host name. The priority defines the order in which hosts should be tried (lower values indicate a higher priority). The weight value is there to support some sort of load balancing among servers of equal priority. You probably do not need any of this, so it is okay to set these to zero.
MIT Kerberos currently looks up the following names when looking for services:
This defines the location of the KDC daemon (the authentication and ticket granting server). Typical records look like this:
_kerberos._udp.EXAMPLE.COM. IN SRV 0 0 88 kdc.example.com. _kerberos._tcp.EXAMPLE.COM. IN SRV 0 0 88 kdc.example.com.
This describes the location of the remote administration service. Typical records look like this:
_kerberos-adm._tcp.EXAMPLE.COM. IN SRV 0 0 749 kdc.example.com.
Because kadmind does not support UDP, there should be no
_udp
record.
As with the static configuration file, there is a mechanism to inform
clients that a specific host is in the EXAMPLE.COM
realm, even if it is not part of the example.com
DNS domain. This can be done by attaching a TXT record to
_kerberos.host_name
, as shown here:
_kerberos.www.example.org. IN TXT "EXAMPLE.COM"
The clock skew is the tolerance for accepting tickets with time stamps that do not exactly match the host's system clock. Usually, the clock skew is set to 300 seconds (five minutes). This means a ticket can have a time stamp somewhere between five minutes behind and five minutes ahead of the server's clock.
When using NTP to synchronize all hosts, you can reduce this value to
about one minute. The clock skew value can be set in
/etc/krb5.conf
like this:
[libdefaults] clockskew = 60
To be able to add and remove principals from the Kerberos database
without accessing the KDC's console directly, tell the Kerberos
administration server which principals are allowed to do what by editing
/var/lib/kerberos/krb5kdc/kadm5.acl
. The ACL
(access control list) file allows you to specify privileges with a
precise degree of control. For details, refer to the manual page with
man
8 kadmind
.
For now, grant yourself the privilege to administer the database by putting the following line into the file:
geeko/admin *
Replace the user name geeko
with your
own. Restart kadmind
for the change to take
effect.
You should now be able to perform Kerberos administration tasks remotely using the kadmin tool. First, obtain a ticket for your admin role and use that ticket when connecting to the kadmin server:
kadmin -p geeko/admin Authenticating as principal geeko/admin@EXAMPLE.COM with password. Password for geeko/admin@EXAMPLE.COM: kadmin: getprivs current privileges: GET ADD MODIFY DELETE kadmin:
Using the getprivs
command, verify which privileges
you have. The list shown above is the full set of privileges.
As an example, modify the principal
geeko
:
kadmin -p geeko/admin Authenticating as principal geeko/admin@EXAMPLE.COM with password. Password for geeko/admin@EXAMPLE.COM: kadmin: getprinc geeko Principal: geeko@EXAMPLE.COM Expiration date: [never] Last password change: Wed Jan 12 17:28:46 CET 2005 Password expiration date: [none] Maximum ticket life: 0 days 10:00:00 Maximum renewable life: 7 days 00:00:00 Last modified: Wed Jan 12 17:47:17 CET 2005 (admin/admin@EXAMPLE.COM) Last successful authentication: [never] Last failed authentication: [never] Failed password attempts: 0 Number of keys: 2 Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt Key: vno 1, DES cbc mode with CRC-32, no salt Attributes: Policy: [none] kadmin: modify_principal -maxlife "8 hours" geeko Principal "geeko@EXAMPLE.COM" modified. kadmin: getprinc tux Principal: geeko@EXAMPLE.COM Expiration date: [never] Last password change: Wed Jan 12 17:28:46 CET 2005 Password expiration date: [none] Maximum ticket life: 0 days 08:00:00 Maximum renewable life: 7 days 00:00:00 Last modified: Wed Jan 12 17:59:49 CET 2005 (geeko/admin@EXAMPLE.COM) Last successful authentication: [never] Last failed authentication: [never] Failed password attempts: 0 Number of keys: 2 Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt Key: vno 1, DES cbc mode with CRC-32, no salt Attributes: Policy: [none] kadmin:
This changes the maximum ticket life time to eight hours. For more
information about the kadmin
command and the options
available, see the krb5-doc
package or refer to
the man
8 kadmin
manual page.
So far, only user credentials have been discussed. However,
Kerberos-compatible services usually need to authenticate themselves to
the client user, too. Therefore, special service principals must be
present in the Kerberos database for each service offered in the realm.
For example, if ldap.example.com offers an LDAP service, you need a service
principal, ldap/ldap.example.com@EXAMPLE.COM
, to
authenticate this service to all clients.
The naming convention for service principals is
service/host_name@REALM
,
where host_name is the host's fully qualified
host name.
Valid service descriptors are:
Service Descriptor |
Service |
---|---|
|
Telnet, RSH, SSH |
|
NFSv4 (with Kerberos support) |
|
HTTP (with Kerberos authentication) |
|
IMAP |
|
POP3 |
|
LDAP |
Service principals are similar to user principals, but have significant differences. The main difference between a user principal and a service principal is that the key of the former is protected by a password—when a user obtains a ticket-granting ticket from the KDC, he needs to type his password so Kerberos can decrypt the ticket. It would be inconvenient for system administrators to obtain new tickets for the SSH daemon every eight hours or so.
Instead, the key required to decrypt the initial ticket for the service
principal is extracted by the administrator from the KDC only once and
stored in a local file called the keytab. Services
such as the SSH daemon read this key and use it to obtain new tickets
automatically, when needed. The default keytab file resides in
/etc/krb5.keytab
.
To create a host service principal for jupiter.example.com
enter the following commands during your kadmin session:
kadmin -p geeko/admin Authenticating as principal geeko/admin@EXAMPLE.COM with password. Password for geeko/admin@EXAMPLE.COM: kadmin: addprinc -randkey host/jupiter.example.com WARNING: no policy specified for host/jupiter.example.com@EXAMPLE.COM; defaulting to no policy Principal "host/jupiter.example.com@EXAMPLE.COM" created.
Instead of setting a password for the new principal, the
-randkey
flag tells kadmin
to
generate a random key. This is used here because no user interaction is
wanted for this principal. It is a server account for the machine.
Finally, extract the key and store it in the local keytab file
/etc/krb5.keytab
. This file is owned by the
superuser, so you must be root
to execute the next command in the kadmin shell:
kadmin: ktadd host/jupiter.example.com Entry for principal host/jupiter.example.com with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/jupiter.example.com with kvno 3, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/etc/krb5.keytab. kadmin:
When completed, make sure that you destroy the admin ticket obtained
with kinit above with kdestroy
.
openSUSE® Leap comes with a PAM module named
pam_krb5
, which supports Kerberos login and
password update. This module can be used by applications such as console
login, su
, and graphical login applications like GDM.
That is, it can be used in all cases where the user enters a password
and expects the authenticating application to obtain an initial Kerberos
ticket on his behalf. To configure PAM support for Kerberos, use the
following command:
pam-config --add --krb5
The above command adds the pam_krb5
module to the
existing PAM configuration files and makes sure it is called in the
right order. To make precise adjustments to the way in which
pam_krb5
is used, edit the file
/etc/krb5.conf
and add default applications to
pam
. For details, refer to the manual page with
man
5 pam_krb5
.
The pam_krb5
module was specifically not designed
for network services that accept Kerberos tickets as part of user
authentication. This is an entirely different matter, and is discussed
below.
OpenSSH supports Kerberos authentication in both protocol version 1 and 2. In version 1, there are special protocol messages to transmit Kerberos tickets. Version 2 does not use Kerberos directly anymore, but relies on GSSAPI, the General Security Services API. This is a programming interface that is not specific to Kerberos—it was designed to hide the peculiarities of the underlying authentication system, be it Kerberos, a public-key authentication system like SPKM, or others. However, the included GSSAPI library only supports Kerberos.
To use sshd with Kerberos authentication, edit
/etc/ssh/sshd_config
and set the following options:
# These are for protocol version 1 # # KerberosAuthentication yes # KerberosTicketCleanup yes # These are for version 2 - better to use this GSSAPIAuthentication yes GSSAPICleanupCredentials yes
Then restart your SSH daemon using sudo systemctl restart
sshd
.
To use Kerberos authentication with protocol version 2, enable it on the
client side as well. Do this either in the systemwide configuration file
/etc/ssh/ssh_config
or on a per-user level by
editing ~/.ssh/config
. In both cases, add the
option GSSAPIAuthentication yes
.
You should now be able to connect using Kerberos authentication. Use
klist
to verify that you have a valid ticket, then
connect to the SSH server. To force SSH protocol version 1, specify the
-1
option on the command line.
The file
/usr/share/doc/packages/openssh/README.kerberos
discusses the interaction of OpenSSH and Kerberos in more detail.
The GSSAPIKeyExchange
mechanism (RFC 4462) is
supported. This directive specifies how host keys are exchanged. For
more information, see the sshd_config manual page (man
sshd_config
).
When using Kerberos, one way to distribute the user information (such as user ID, groups, and home directory) in your local network is to use LDAP. This requires a strong authentication mechanism that prevents packet spoofing and other attacks. One solution is to use Kerberos for LDAP communication, too.
OpenLDAP implements most authentication flavors through SASL, the simple
authentication session layer. SASL is a network protocol designed for
authentication. The SASL implementation is cyrus-sasl, which supports a
number of different authentication flavors. Kerberos authentication is
performed through GSSAPI (General Security Services API). By default,
the SASL plug-in for GSSAPI is not installed. Install the
cyrus-sasl-gssapi
with YaST.
To enable Kerberos to bind to the OpenLDAP server, create a principal
ldap/ldap.example.com
and add that to the keytab.
By default, the LDAP server slapd runs as user and group
ldap
, while the keytab file is
readable by root
only.
Therefore, either change the LDAP configuration so the server runs as
root
or make the keytab file
readable by the group ldap
.
The latter is done automatically by the OpenLDAP start script
(/usr/lib/openldap/start
) if the keytab file has
been specified in the OPENLDAP_KRB5_KEYTAB
variable in
/etc/sysconfig/openldap
and the
OPENLDAP_CHOWN_DIRS
variable is set to
yes
, which is the default setting. If
OPENLDAP_KRB5_KEYTAB
is left empty, the default keytab
under /etc/krb5.keytab
is used and you must adjust
the privileges yourself as described below.
To run slapd as root
, edit
/etc/sysconfig/openldap
. Disable the
OPENLDAP_USER
and
OPENLDAP_GROUP
variables by putting a comment
character in front of them.
To make the keytab file readable by group LDAP, execute
chgrp ldap /etc/krb5.keytab chmod 640 /etc/krb5.keytab
A third (and maybe the best) solution is to tell OpenLDAP to use a special keytab file. To do this, start kadmin, and enter the following command after you have added the principal ldap/ldap.example.com:
ktadd -k /etc/openldap/ldap.keytab ldap/ldap.example.com@EXAMPLE.COM
Then in the shell run:
chown ldap.ldap /etc/openldap/ldap.keytab chmod 600 /etc/openldap/ldap.keytab
To tell OpenLDAP to use a different keytab file, change the following
variable in /etc/sysconfig/openldap
:
OPENLDAP_KRB5_KEYTAB="/etc/openldap/ldap.keytab"
Finally, restart the LDAP server using sudo systemctl
restart slapd
.
You are now able to automatically use tools such as ldapsearch with Kerberos authentication.
ldapsearch -b ou=people,dc=example,dc=com '(uid=geeko)' SASL/GSSAPI authentication started SASL SSF: 56 SASL installing layers [...] # geeko, people, example.com dn: uid=geeko,ou=people,dc=example,dc=com uid: geeko cn: Suzanne Geeko [...]
As you can see, ldapsearch
prints a message that it
started GSSAPI authentication. The next message is very cryptic, but it
shows that the security strength factor (SSF for
short) is 56 (The value 56 is somewhat arbitrary. Most likely it was
chosen because this is the number of bits in a DES encryption key).
This means that GSSAPI authentication was successful and that
encryption is being used to protect integrity and provide
confidentiality for the LDAP connection.
In Kerberos, authentication is always mutual. This means that not only have you authenticated yourself to the LDAP server, but also the LDAP server has authenticated itself to you. In particular, this means communication is with the desired LDAP server, rather than some bogus service set up by an attacker.
There is one minor piece of the puzzle missing—how the LDAP
server can find out that the Kerberos user
tux@EXAMPLE.COM
corresponds to the LDAP
distinguished name
uid=tux,ou=people,dc=example,dc=com
.
This sort of mapping must be configured manually using the
saslExpr
directive. In this example, the
"authz-regexp" change in LDIF would look as follows:
dn: cn=config add: olcAuthzRegexp olcAuthzRegexp: uid=(.*),cn=GSSAPI,cn=auth uid=$1,ou=people,dc=example,dc=com
All these changes can be applied via ldapmodify
on
the command line.
To understand how this works, you need to know that when SASL
authenticates a user, OpenLDAP forms a distinguished name from the name
given to it by SASL (such as tux
) and
the name of the SASL flavor (GSSAPI
). The result
would be uid=tux,cn=GSSAPI,cn=auth
.
If a authz-regexp
has been configured, it checks the
DN formed from the SASL information using the first argument as a
regular expression. If this regular expression matches, the name is
replaced with the second argument of the
authz-regexp
statement. The placeholder
$1
is replaced with the substring matched by the
(.*)
expression.
More complicated match expressions are possible. If you have a more complicated directory structure or a schema in which the user name is not part of the DN, you can even use search expressions to map the SASL DN to the user DN.
For more information, see the slapd-config
man page.
The official site of the MIT Kerberos is http://web.mit.edu/kerberos. There, find links to any other relevant resource concerning Kerberos, including Kerberos installation, user, and administration guides.
The paper at ftp://athena-dist.mit.edu/pub/kerberos/doc/usenix.PS gives quite an extensive insight to the basic principles of Kerberos, without being too difficult to read. It also provides a lot of opportunities for further investigation and reading about Kerberos.
The book Kerberos—A Network Authentication System by Brian Tung (ISBN 0-201-37924-4) offers extensive information.