debian-kerberos 2006-2010 Davor Ocelic Davor Ocelic docelic@spinlocksolutions.com SPINLOCK— advanced GNU/Linux and Unix solutions for commercial and education sectors. Last update: Mar 22, 2010. — Maintain everything up to date (Kerberos 1.6, 1.7 and 1.8), add links to other documentation This documentation is free; you can redistribute it and/or modify it under the terms of the &GNU; General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. It is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. The purpose of this article is to give you a straight-forward, Debian-friendly way of installing and configuring MIT Kerberos 5. By the end of this guide, you will have a functional Kerberos environment and one Kerberized service — the ability to login remotely to other machines in the network in a secure, encrypted and transparent way, without the need for typing in any passwords. This article is part of &SL;'s practical 5-piece introductory series to infrastructure-based Unix networks, containing &DKLAR_DEB;, &DKLAR_KRB;, &DKLAR_LDA;, &DKLAR_AFS; and &DKLAR_RAD;.

Kerberos is a service that has been traditionally captivating system administrators' and advanced users' interest, but its (seemingly or not) high entry barrier and infrastructure requirements have been preventing many from using it. Kerberos has already been the topic of numerous publications. Here, we will present only the necessary summary; enough information to establish the context and to achieve practical results. You do not need to follow any external links; however, the links have been provided both throughout the article and listed all together at the end, to serve as pointers to more precise technical treatment of individual topics.

Kerberos is intended to centrally authenticate users, hosts and services on the network by verifying them against entries in the &KERBEROS_DATABASE;. These entries (called "&PRINCIPAL;s") consist of principal names, &SECRET_KEY;s, key aging information and &KERBEROS-SPECIFIC; data. They're created or modified using a Kerberos-specific administrative tool. When users type in their principal name and password anywhere on the network (within a Kerberos &REALM;), their input is authenticated against the Kerberos database. In case of a successful authentication, the &KDC; ("Key Distribution Center") will issue users a "confirmation", called the &TGT; ("Ticket-Granting Ticket"). From that point on, and until their ticket expires, users will be transparently granted access to all network services they'll wish to use. (Here, the TGT will not grant access by itself — instead, it will be used in place of a password to automatically create further, service-specific tickets. Hence its name, the "Ticket-granting Ticket"). While the idea of a centralized network authentication is not unique, let's quickly identify Kerberos-specific elements in the authentication process: Kerberos is not in any way related to traditional system usernames or other data; Kerberos identity (or tickets) are obtained using a separate, Kerberos-specific mechanism. Arbitrary system user can obtain arbitrary Kerberos identity (provided they know the correct password). Often times, however, the Kerberos identity is obtained during log-in to the system and, for convenience, an assumption is made that the person's system login name matches the Kerberos principal name. The &KERBEROS_DATABASE; only contains the information necessary for Kerberos authentication; it does not (and can not) contain any other information, such as people's real names, Unix user and group IDs etc. This makes Kerberos well-defined and easy to fit in a network infrastructure. When a central directory is required for users' real names, IDs, meta information and other network information, &LDA; is often used in combination and installed after Kerberos as explained in another article from the series, the &DKLAR_LDA;. Thanks to the design of the protocol, users' passwords never travel the wire in any form; Kerberos thus allows for secure authentication in and over untrusted networks. Kerberos requires mutual authentication of users and services, preventing stealing of information. To achieve this, Kerberos uses its database to store host and service principals alongside the "real", person-owned principals. This is normal behavior and indeed, the host and service principals will account for the majority of output when you list database entries for the first time. As users are only required to type in their password once (after which the TGT is used in place of the password to create further tickets), Kerberos offers a true SSO ("Single Sign-On") network solution. You can find the complete Kerberos documentation at the &KRB; website. Their on-line documentation is, however, only generated in multi-page HTML format — other more convenient formats (such as PostScript) are available within &KERBEROS_RELEASE; tarballs.

On all GNU/Linux-based platforms, &PAM; is available for service-specific authentication configuration. &PAM; is an implementation of PAM ("Pluggable Authentication Modules") from &SUN;. Network services, instead of having hard-coded authentication interfaces and decision methods, invoke PAM through a standard, pre-defined interface. It is then up to PAM to perform any and all authentication-related work, and report the result back to the application. Exactly how PAM reaches the decision is none of the service's business. In traditional set-ups, that is most often done by asking and verifying usernames and passwords. In advanced networks, that could be retina scans or — Kerberos tickets. PAM will allow for inclusion of Kerberos into the authentication path of all services, regardless of whether they natively support Kerberos or not. You can find the proper introduction (and complete documentation) on the &PAM; website. Pay special attention to the &PSY; page. Also take a look at the Linux-PAM 7 and pam 7 manual pages.

It's quite disappointing when you are not able to follow the instructions found in the documentation. Let's agree on a few points before going down to work: Our platform of choice, where we will demonstrate a practical setup, will be &DEB;. Install sudo. Sudo is a program that will allow you to carry out system administrator tasks from your normal user account. All the examples in this article requiring root privileges use sudo, so you will be able to copy-paste them to your shell. su -c 'apt-get install sudo' (If asked for a password, type in the root user's password.) To configure sudo, add the following line to your /etc/sudoers, replacing $USERNAME with your login name: $USERNAME ALL=(ALL) NOPASSWD: ALL Debian packages installed during the procedure will ask us a series of questions through the so-called debconf interface. To configure debconf to a known state, run: sudo dpkg-reconfigure debconf When asked, answer interface=Dialog and priority=low. Monitoring log files is crucial in detecting problems. The straight-forward, catch-all routine to this is opening a terminal and running: cd /var/log; sudo tail -F daemon.log sulog user.log auth.log debug kern.log syslog dmesg messages kerberos/{krb5kdc,kadmin,krb5lib}.log The command will keep printing log messages to the screen as they arrive. Our test system will be called monarch.spinlock.hr and have an IP address of 192.168.7.12. Both the server and the client will be installed on the same machine. However, to differentiate between client and server roles, the client will be referred to as monarch.spinlock.hr and the server as krb1.spinlock.hr. The following addition will be made to /etc/hosts to completely support this scheme: 192.168.7.12 monarch.spinlock.hr monarch krb1.spinlock.hr krb1 Note that in some Debian installations the system's network hostname is assigned to the localhost address 127.0.0.1. This can and will cause problems for network operations, so make sure that your "localhost" entry in /etc/hosts looks exactly like the following (nothing more, nothing less): 127.0.0.1 localhost localhost.localdomain Finally, test that the network setup is as expected. Pinging the hostnames should report proper FQDNs and IPs as shown: ping -c1 localhost PING localhost (127.0.0.1) 56(84) bytes of data. .... ping -c1 monarch PING monarch.spinlock.hr (192.168.7.12) 56(84) bytes of data. .... ping -c1 krb1 PING krb1.spinlock.hr (192.168.7.12) 56(84) bytes of data. ....

Now when everything has been properly prepared, let's move forward.

Kerberos server installation basically consists of just two packages — the KDC (Key Distribution Center), which takes care of handling authentication requests and issuing Kerberos tickets, and kadmind (Kerberos master server), which allows remote administration access to the Kerberos database and carrying out of administrative tasks. sudo apt-get install krb5-{admin-server,kdc} Here are the Debconf answers for reference. The listing here includes all questions; some were asked in Kerberos 1.6 packages and some are asked only in Kerberos 1.7 and newer, and their order has changed a little as well. In any case, it's no problem — just answer the subset of questions you are asked: Default Kerberos version 5 realm? SPINLOCK.HR # (Your domain name in uppercase - a standard for naming Kerberos realms) Does DNS contain pointers to your realm's Kerberos Servers? No # (No DNS configuration is required for our setup) Add locations of default Kerberos servers to /etc/krb5.conf? Yes # (Adding entries to krb.conf instead of DNS) Create the Kerberos KDC configuration automatically? Yes Kerberos4 compatibility mode to use: none # (No krb4 compatibility needed in our setup) Run a Kerberos V5 to Kerberos V4 ticket conversion daemon? No Should the data be purged as well as the package files? No Run the Kerberos V5 administration daemon (kadmind)? Yes Kerberos servers for your realm: krb1.spinlock.hr # (Make sure your DNS resolves krb1.spinlock.hr to # the NETWORK IP of the server, NOT 127.0.0.1!). Hint is given in # . Administrative server for your Kerberos realm: krb1.spinlock.hr # (Make sure your DNS resolves krb1.spinlock.hr to # the NETWORK IP of the server, NOT 127.0.0.1!). Same hint as above. Create the Kerberos KDC configuration automatically? Yes # New question added in Kerberos 1.7 and newer packages As soon as the installation is done, the Kerberos admin server (kadmind) and the KDC will start. Kadmind will fail as, initially, there are no Kerberos &REALM;s created.

To create the Kerberos realm, invoke Debian-specific command krb5_newrealm. sudo krb5_newrealm The command will first ask for the master password, and then proceed with creating the realm using the name we defined earlier in the Debconf step (SPINLOCK.HR). Make sure to pick a good password, and possibly write it down for later reference as it is hardly ever used, yet very important. After the realm is created, we will need to adjust the Kerberos config file, /etc/krb5.conf. That file also needs to be the same on all Kerberos servers and clients belonging to the same realm. /etc/krb5.conf is split into sections; you should search for section "[domain_realm]" and append your definition: .spinlock.hr = SPINLOCK.HR spinlock.hr = SPINLOCK.HR At the bottom of the file, you should add the logging section: [logging] kdc = FILE:/var/log/kerberos/krb5kdc.log admin_server = FILE:/var/log/kerberos/kadmin.log default = FILE:/var/log/kerberos/krb5lib.log To create the logging directory and set up permissions, run: sudo mkdir /var/log/kerberos sudo touch /var/log/kerberos/{krb5kdc,kadmin,krb5lib}.log sudo chmod -R 750 /var/log/kerberos Don't forget to also restart the log monitoring command you ran earlier (see ) — the tail program needs to pick up the new log files from the kerberos/ directory. It is also a good idea to disallow "weak enctypes" in Kerberos. These are the cryptographic algorithms that are no longer considered secure (or at least robust), and currently include all single-DES enctypes. The option called "allow_weak_crypto" was added in Krb 1.7, defaulting to true. In Kerberos 1.8 and later, weak enctypes are disabled by default and no manual setting is necessary. So, if you are using Kerberos 1.7, search for the section called "[libdefaults]" in /etc/krb5.conf (usually at the top of the file) and append the following definition: allow_weak_crypto = false Finally, to apply all changes, run: sudo invoke-rc.d krb5-admin-server restart sudo invoke-rc.d krb5-kdc restart

It is already the time to test the installation. We assume that both the admin server and the KDC can be restarted with no errors (which should be no problem to determine if you're monitoring the log files as advised). As the first test, we will run command kadmin.local on the server. Start kadmin.local, then type listprincs. That command should print out the list of principals (user, host and service accounts) in the database. The whole session should look like this: sudo kadmin.local Authenticating as principal root/admin@SPINLOCK.HR with password. kadmin.local: listprincs K/M@SPINLOCK.HR kadmin/admin@SPINLOCK.HR kadmin/changepw@SPINLOCK.HR kadmin/history@SPINLOCK.HR kadmin/krb1.SPINLOCK.HR@SPINLOCK.HR krbtgt/SPINLOCK.HR@SPINLOCK.HR kadmin.local: quit The kadmin command ordinarily requires principal name and password before letting anyone access the administrative interface. However, kadmin.local is a variant of the command that must be run locally on the same machine as the KDC, and with administrator privileges. It is then able to open the Kerberos database file directly (taking advantage of Unix file permissions), without requiring extra privileges and without using the kadmind (Kerberos master server) daemon.

In the test step above, you might have noticed &PRINCIPAL; names similar to kadmin/admin@SPINLOCK.HR. The general naming syntax for principals is SPEC@REALM, where SPEC by convention consists of components separated by "/", and the default REALM can be omitted. In the case of user names, the first component identifies the user name, and the second component, if present, identifies user role. For regular users, there will usually be one principal with no special role, named simply USERNAME. But when administrative or other roles are required, there will be no need to condense them all to one "root" prinicpal — each user can simply be given conveniently named additional principals with special privileges, such as USERNAME/admin. In the case of service names, the components will be used to identify service and hostname, such as host/monarch.spinlock.hr or ldap/monarch.spinlock.hr. ("host" is somewhat of a misnomer from today's perspective — it has nothing to do with host per-se, but is actually the service name for all remote shell protocols, such as rsh, rlogin and ssh).

Let's take a look at the /etc/krb5kdc/kadm5.acl file; it defines user access rights for the Kerberos database. For regular users with no special privileges, no action will be required. For admin users, we will want to grant all privileges, as hinted earlier in . To do this, make sure the following line is present in the file and enabled (that is, without the comment '#' character at the beginning): */admin * (While the above syntax might remind you of &SHELL_GLOBBING;, unfortunately it does not work that way at all. The only matching character supported is the asterisk ("*"), it does not match multiple components, and it can only be used in form of "component1/*" or "*/component2".) Make sure to restart the admin server to apply /etc/krb5kdc/kadm5.acl changes: sudo invoke-rc.d krb5-admin-server restart

Kerberos "policies" offer an elegant way to sort principals into a kind of categories and to automatically apply corresponding defaults onto newly created principals. Let's create four basic policies: for admins, hosts, services and users. In this example, each policy will define minimum password strength (measured in number of character classes present in the password, from 1 to 5), but a few other options can be set — run addpol (the supported abbreviation of add_policy) if you're curious. sudo kadmin.local Authenticating as principal root/admin@SPINLOCK.HR with password. kadmin.local: add_policy -minlength 8 -minclasses 3 admin kadmin.local: add_policy -minlength 8 -minclasses 4 host kadmin.local: add_policy -minlength 8 -minclasses 4 service kadmin.local: add_policy -minlength 8 -minclasses 2 user kadmin.local: quit

As you might have noticed, the kadmin.local command identified us as the principal root/admin. Still, that principal does not actually exist in the database so we might as well create it now. Once the principal is actually there, we'll be able to connect to the administrative server using kadmin from any machine within the Kerberos realm, and not just by using kadmin.local on the Kerberos server. Creating a principal based on your regular identity (such as USERNAME/admin) is preferred over creating one called root/admin, so feel free to subsitute "root" in the following transcript (and the rest of the guide) with your username: sudo kadmin.local Authenticating as principal root/admin@SPINLOCK.HR with password. kadmin.local: addprinc -policy admin root/admin Enter password for principal "root/admin@SPINLOCK.HR": PASSWORD Re-enter password for principal "root/admin@SPINLOCK.HR": PASSWORD Principal "root/admin@SPINLOCK.HR" created. kadmin.local: quit

Now that the root/admin principal exists in the Kerberos database, we should be able to use kadmin just as we used kadmin.local. The only exception, of course, is that kadmin will prompt for a password to connect to the Kerberos admin server. Double-check that all the permissions are granted to admin roles in the /etc/krb5kdc/kadm5.acl (as explained in ), and that the admin server has been restarted to read the new configuration; then proceed to test kadmin connection: sudo kadmin -p root/admin Authenticating as principal root/admin@SPINLOCK.HR with password. Password for root/admin@SPINLOCK.HR: PASSWORD kadmin: listprincs K/M@SPINLOCK.HR root/admin@SPINLOCK.HR kadmin/admin@SPINLOCK.HR kadmin/changepw@SPINLOCK.HR kadmin/history@SPINLOCK.HR kadmin/krb1.SPINLOCK.HR@SPINLOCK.HR krbtgt/SPINLOCK.HR@SPINLOCK.HR kadmin: quit

Let's add a principal that will correspond to your regular, unprivileged user account. In our example, the username will be called "mirko". We've essentially performed this procedure for the root/admin principal above, but we'll repeat it here for your regular user account, using a different policy, replacing mirko with your username: sudo kadmin -p root/admin Authenticating as principal root/admin@SPINLOCK.HR with password. Password for root/admin@SPINLOCK.HR: PASSWORD kadmin: addprinc -policy user mirko Enter password for principal "mirko@SPINLOCK.HR": PASSWORD Re-enter password for principal "mirko@SPINLOCK.HR": PASSWORD Principal "mirko@SPINLOCK.HR" created. kadmin: quit

As hinted in the introduction, each user is expected to type in the password once, to obtain the initial TGT (Ticket-granting Ticket). Obtained tickets are saved to a so-called ticket cache, which is most commonly a file named /tmp/krb5cc_*, stored on the user's workstation. Let's run the klist command to inspect our ticket cache (run this command under your regular, non-privileged username). As one might guess, since we did not obtain any tickets yet, the cache will be empty: klist -5f klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_0) Let's use kinit now to obtain the ticket, and then re-inspect the ticket cache. If the command seemingly "hangs" and does nothing, wait a few seconds — DNS misconfiguration may cause a delay. kinit Password for mirko@SPINLOCK.HR: PASSWORD klist -5f Ticket cache: FILE:/tmp/krb5cc_1000 Default principal: mirko@SPINLOCK.HR Valid starting Expires Service principal 11/22/06 22:30:36 11/23/06 08:30:33 krbtgt/SPINLOCK.HR@SPINLOCK.HR renew until 11/23/06 22:30:34, Flags: FPRIA If you remember the story from the beginning, you will recognize the "krbtgt" to be the Ticket-granting Ticket. klist switch -f produced the "renew until..." line. The meanings of each flag letter are not important at this stage, but long-term it is useful to get into the habit of using -f, and the flags descriptions can be looked up in the klist 1 manpage. All great. Let's run kdestroy to terminate the ticket now.

To actually use Kerberos, we need to install kerberized versions of the standard services. Each service may support Kerberos authentication either by having native Kerberos support, or by delegating the authentication work to the PAM subsystem (and since all relevant services support PAM, this means it is possible to Kerberize all network services). In your &DEB; repository, there will be packages like krb-ftpd, krb5-telnetd and krb5-rsh-server. Those are replacement services for ftp, telnet and rsh with native Kerberos (and encryption) support. The mentioned krb-ftpd, krb5-telnetd and krb5-rsh-server are still part of Kerberos for traditional reasons, but they contain known implementation flaws and their removal has been discussed a couple of times. We will use still use krb5-rsh-server here because that is the most straight-forward during learning phase, but removing krb5-rsh-server and setting up ssh is covered in later chapters of this Guide. So let's install the krb5-rsh-server. After installation, ensure that the service runs. It is started from inetd, so inetd must be running and the kshell and eklogin services need to be enabled in /etc/inetd.conf. sudo apt-get install openbsd-inetd sudo apt-get install krb5-rsh-server sudo update-rc.d -f openbsd-inetd remove sudo update-rc.d openbsd-inetd defaults sudo update-inetd --enable kshell sudo update-inetd --enable eklogin sudo invoke-rc.d openbsd-inetd restart To connect to a certain service, the service must have a corresponding principal in the Kerberos database. This is because the Kerberos server acts as a trusted 3rd party and performs mutual authentication of the user and the service as explained in . The generic service name for telnet, rsh, ssh and related protocols is "host", so let's create the necessary principal with a randomly-generated password. Make sure that you export the key to a keytab file as shown (that is, within the same invocation of kadmin) to save yourself from getting an error about the "Key version number" being incorrect: sudo kadmin -p root/admin Authenticating as principal root/admin@SPINLOCK.HR with password. Password for root/admin@SPINLOCK.HR: PASSWORD kadmin: addprinc -policy service -randkey host/monarch.spinlock.hr Principal "host/monarch.spinlock.hr@SPINLOCK.HR" created. kadmin: ktadd -k /etc/krb5.keytab -norandkey host/monarch.spinlock.hr Entry for principal host/monarch.spinlock.hr@SPINLOCK.HR with kvno 3, encryption type AES-256 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/monarch.spinlock.hr@SPINLOCK.HR with kvno 3, encryption type ArcFour cbc mode with HMAC/md5 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/monarch.spinlock.hr@SPINLOCK.HR with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/monarch.spinlock.hr@SPINLOCK.HR with kvno 3, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/etc/krb5.keytab. kadmin: quit With Kerberos 1.7 version 1.7dfsg~beta3-1 (and possibly others), you will see the following error when assigning -randkey passwords to principals with minimum character classes set above 1: kadmin: addprinc -policy service -randkey host/monarch.spinlock.hr add_principal: Password does not contain enough character classes while creating "host/monarch.spinlock.hr" This is due to a bug introduced in -randkey operation during addition of UTF-8 support. Status report on the issue can be tracked under RT Ticket #6568, but your immediate short term solution is to just reduce the corresponding policy's -minclasses to 1 as follows: kadmin: modpol -minclasses 1 host kadmin: modpol -minclasses 1 service Finally, ensure that this keytab file, /etc/krb5.keytab, is moved to the rsh server machine. If the rsh server and the Kerberos server are the same machine, no copying to the remote location is necessary.

Let's install kerberized versions of the basic client programs: sudo apt-get install krb5-clients One of the client programs, krb5-rsh, will allow you connect to the secure rsh server, automatically and without asking for any user names or passwords. The connection will also be encrypted as long as the -x switch is used. As we have taken care of all the pre-requisites, we can try connecting: Obtain Kerberos ticket: kinit Password for USERNAME@SPINLOCK.HR: PASSWORD Connect: krb5-rsh -x -PN krb1.spinlock.hr This rlogin session is encrypting all data transmissions. Last login: Mon Nov 27 16:49:49 from monarch Linux monarch 2.4.27-2-686 #1 Mon May 16 17:03:22 JST 2005 i686 GNU/Linux The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. You have new mail. logout Connection closed. Congratulations! You have a working Kerberos setup. If anything is not working, proceed right to — it contains an extensive list of possible errors and the corresponding solutions! If everything is working, then you can skip that section for now and head directly to .

krb5-rsh -x -PN krb1.spinlock.hr Trying krb4 rlogin... krb_sendauth failed: You have no tickets cached You have no valid Kerberos tickets, which can be verified by running klist -5 (the output will either be empty or show expired tickets). Obtain a new ticket using kinit: kinit PRINCIPAL_NAME

krb5-rsh -PN krb1.spinlock.hr connect to address 192.168.7.12: Connection refused Trying krb4 rlogin... connect to address 192.168.7.12: Connection refused trying normal rlogin (/usr/bin/netkit-rlogin) exec: No such file or directory Let's take a look at this. First of all, you can see that krb5-rsh has some fallbacks built-in. It first tries to connect using the Kerberos 5 protocol, then Kerberos 4, and then using the normal, non-kerberized rsh. We are only interested in the krb5 result. If any of the other two methods succeed (the krb4 or plain rsh), it's still not what we want (and you will probably want to disable them somehow, because no one setting up a new Kerberos realm in the 21st century should be running either krb4 or unprotected rsh). So where's the problem? Assuming that you did everything right (installed krb5-rsh-server and restarted inetd), the problem is very simple. Namely, by default, kerberized servers in Debian do not accept unencrypted connections! So, on next attempt, add -x on the command line. krb5-rsh -PN -x krb1.spinlock.hr

krb5-rsh -PN -x krb1.spinlock.hr error getting credentials: Server not found in Kerberos database As explained in , both the users and the services must have an appropriate principal entry in the Kerberos database. While users are in form of NAME/ROLE, services are in form SERVICE-NAME/HOSTNAME. So we need to add a principal for service "host" (common name for all shell services), on host where the service is provided — monarch.spinlock.hr. (Strictly, the service is provided on the server, on krb1.spinlock.hr, but in a single-machine setup, the hostname's FQDN returns monarch.spinlock.hr so we must use that). Within the same session, you will almost always want to export that principal's key to a keytab file. Exporting will not work as intended if the key was not created in a single kadmin session, so the below solution deletes the existing key (if any), creates it anew and exports it to a file. As to what you need to do with the keytab file after creation — you need to move it from the Kerberos server onto the machine providing the service. If that is the same machine, no moving is necessary. As most of the errors really boil down to this step, we also take care of re-initializing the ticket properly, to minimize the chance of a mistake: rm /etc/krb5.keytab kdestroy sudo kadmin.local Authenticating as principal root/admin@SPINLOCK.HR with password. kadmin.local: delprinc host/monarch.spinlock.hr Are you sure you want to delete the principal "host/monarch.spinlock.hr@SPINLOCK.HR"? (yes/no): yes Principal "host/monarch.spinlock.hr@SPINLOCK.HR" deleted. Make sure that you have removed this principal from all ACLs before reusing. kadmin.local: addprinc -randkey host/monarch.spinlock.hr WARNING: no policy specified for host/monarch.spinlock.hr@SPINLOCK.HR; defaulting to no policy Principal "host/monarch.spinlock.hr@SPINLOCK.HR" created. kadmin.local: ktadd -k /etc/krb5.keytab -norandkey host/monarch.spinlock.hr kadmin.local: quit kinit root/admin

krb5-rsh -PN -x krb1.spinlock.hr Couldn't authenticate to server: Server rejected authentication (during sendauth exchange) Server returned error code 60 (Generic error (see e-text)) Error text sent from server: No such file or directory The above error indicates that we should pay attention to the "e-text" (error text returned to the client). The error text tells us, in kind of a confusing way (since — you see — there is no filename reported), that the /etc/krb5.keytab file on the rsh server is missing altogether. This file needs to exist and contain the service key. The way to obtain the file and the key is to follow the recipe from .

krb5-rsh -PN -x krb1.spinlock.hr Couldn't authenticate to server: Server rejected authentication (during sendauth exchange) Server returned error code 60 (Generic error (see e-text)) Error text sent from server: Key table entry not found The server did accept the connection, but the e-text "Key table entry not found" indicates that the service principal (created earlier, host/monarch.spinlock.hr) is not listed in the keytab file on rsh server. Follow the recipe in .

krb5-rsh -PN -x krb1.spinlock.hr Couldn't authenticate to server: Server rejected authentication (during sendauth exchange) Server returned error code 60 (Generic error (see e-text)) Error text sent from server: Key version number for principal in key table is incorrect The service key has changed on the Kerberos server, and the service did not succeed in proving its identity to the Kerberos server — the file /etc/krb5.keytab on the service did not contain the correct key. Have in mind that the key changes if you run ktadd from within the kadmin shell, and the only way to prevent that from happening is to use kadmin.local interface and use ktadd -norandkey in it. If curious, read up on ktadd behavior in kadmin 8 . Follow the recipe in .

kinit root/admin kinit(v5): Client not found in Kerberos database while getting initial credentials This is Kerberos way of saying "User not found". You either misspelled the principal name ("root/admin" in this case), or you didn't add the principal to the kerberos database in the first place. Adding a principal is performed using the addprinc command as shown in or .

sudo kadmin -p root/admin kadmin: Client not found in Kerberos database while initializing kadmin interface This is Kerberos way of saying "User not found". You either misspelled the principal name ("root/admin" in this case), or you didn't add the principal to the kerberos database in the first place. Adding a principal is performed using the addprinc command as shown in or .

krb5-rsh -PN -x krb1.spinlock.hr Couldn't authenticate to server: Server rejected authentication (during sendauth exchange) Server returned error code 31 (Decrypt integrity check failed) Error text sent from server: Decrypt integrity check failed This is Kerberos way of saying "Password incorrect". In this case, it means that the service key changed on the server, and your your ticket cache no longer contains the ticket with the correct key. Running kdestroy; kinit should obtain a new ticket and solve the problem.

The final step in this article pertains to integrating Kerberos into the system authentication procedure. We want Kerberos tickets to be issued for users as they log in, without the need to run kinit manually after login. On GNU/Linux and derivatives, this is done by simply altering &PAM; configuration in /etc/pam.d/ on all machines where the users are logging in. As we have explained in , Kerberos alone does not help replace the usual password files (/etc/passwd, /etc/shadow or /etc/group). For now, your "kerberized" users will have to be present in both system password files and in Kerberos. This will lead to users having two passwords and two password aging settings — one in /etc/shadow and one in the Kerberos database. Our &PAM; configuration will be defined so that either the usual password authentication or Kerberos authentication will need to succeed for the user to log in. This way, both users that will have no Kerberos entry (the system ones, such as root, daemon, bin, sync, sys, ...) and those that will (regular user accounts), will be able to log in. System password in /etc/shadow will be tried first. If you want Kerberos tickets to be issued, this type of authentication must fail for regular users (otherwise their "system login" would succeed — resulting in the Kerberos part being skipped altogether and no tickets issued). The most common way to make regular users have only one password (and that one being in Kerberos) is to replace their system password in /etc/shadow with a literal "*K*", which is not a valid password and also by spoken convention indicates that the "real" password is stored in Kerberos. This password can be set either by editing /etc/shadow file directly (i.e. with sudo vipw -s) or by invoking sudo usermod -p '*K*' USERNAME. Let's install the necessary Kerberos PAM module: sudo apt-get install libpam-krb5 Let's configure &PAM;. PAM configuration is quite fragile, so use the provided examples that have been verified to work. For any modifications, you will want to look at &PSY; and pay special attention to seemingly insignificant variations — with PAM, they often make a whole world of difference. To minimize the chance of locking yourself out of the system during PAM configuration phase, ensure right now that you have at least one root terminal window open and a copy of the files available before starting on PAM configuration changes. To do so, execute the following in a cleanly started shell and leave the terminal open: sudo su - cd /etc cp -a pam.d pam.d,orig If you break logins with an invalid PAM configuration, the above will allow you to simply revert to a known-good state by using the open root terminal and executing: cp -a pam.d,orig/* pam.d/ The following PAM examples are complete; you should replace your existing configuration with the one shown below:

account sufficient pam_unix.so account sufficient pam_krb5.so account required pam_deny.so

auth sufficient pam_unix.so nullok_secure auth sufficient pam_krb5.so use_first_pass auth required pam_deny.so

password sufficient pam_unix.so nullok obscure md5 password sufficient pam_krb5.so use_first_pass password required pam_deny.so

session required pam_limits.so session optional pam_krb5.so session optional pam_unix.so

After you've edited PAM configuration, restart the services you will be connecting to. This isn't strictly necessary, but it ensures that the services will re-read the PAM configuration and not use any cached information.

DONATE_LINK At this point, you have a functional Kerberos installation! You can rely on either system login or manually running kinit in obtaining Kerberos tickets and accessing Kerberized services. One of those services is the passwordless, Kerberos-secured rsh login that we've demonstrated in this guide. Remember that, as explained in this Guide, your user accounts still need to be created locally on all hosts the users wish to access. To solve that problem and achieve true centralized logins, follow the next article in the series, the &DKLAR_LDA;. If you've followed this &DKLAR_KRB; only as a pre-requisite for installing OpenAFS and do not want to use LDAP in combination, proceed to another article in the series, the &DKLAR_AFS;. With a good foundation we've built, for further information on Kerberos, please refer to other available resources: Official documentation: &DOC; Mailing lists: &MLS; IRC: channel #kerberos at the FreeNode network (irc.freenode.net) For commercial consultation and infrastructure-based networks containing Kerberos, contact &SL;.

Platforms: &GNU; &DEB; Kerberos: &KRB; &HDL; &KRBC; Kerberos specifics: &KERBEROS_RELEASE; &KERBEROS_DATABASE; &REALM; &KDC; &PRINCIPAL; &SECRET_KEY; &TGT; Glue layer: &PAM; &PSY; Related infrastructural technologies: &LDA; &AFS; &RAD; Commercial support: &SL; Misc: &DOCBK;