Centralized Authentication with Kerberos 5, Part I
creates an initial Kerberos database for the new realm. It asks you for the database master password for the new realm and stores it in a file (/usr/local/var/krb5kdc/.k5.EXAMPLE.COM). This command also creates a first set of principals in your Kerberos 5 account database. You can list them by using:
% sudo /usr/local/sbin/kadmin.local
and then typing listprincs at the kadmin.local: prompt. This prints the list:
K/M@EXAMPLE.COM kadmin/admin@EXAMPLE.COM kadmin/changepw@EXAMPLE.COM kadmin/history@EXAMPLE.COM krbtgt/EXAMPLE.COM@EXAMPLE.COM
At this time, we are not ready to use the remote version of the kadmin tool.
Before you start creating any principals in your new realm, you should define a policy that determines how passwords are handled:
kadmin.local: add_policy -maxlife 180days -minlife ↪2days -minlength 8 -minclasses 3 ↪-history 10 default
This input defines a default policy used for every principal we create from now on. It determines that the maximum lifetime for passwords is 180 days. The minimum lifetime is two days. The minimum password length is eight characters, and these characters have to come from three different classes out of these five available ones: lowercase, uppercase, numbers, punctuation and others. A history of the last ten passwords is kept to prevent reuse. If you want to have passwords checked against a dictionary, add a dict_file definition such as:
[realms]
EXAMPLE.COM = {
dict_file = /usr/share/dict/words
}
to your kdc.conf file.
You now are ready to create an administration principal for yourself:
kadmin.local: addprinc john/admin
Adjust the name to your account name but keep the /admin. It then asks twice for a new password for this principal. You can look at the new account with:
kadmin.local: getprinc john/admin
which prints something like:
Principal: john/admin@EXAMPLE.COM Expiration date: [never] Last password change: Wed Dec 24 09:55:17 PST 2003 Password expiration date: Mon Jun 21 10:55:17 PDT 2004 Maximum ticket life: 1 day 00:00:00 Maximum renewable life: 0 days 00:00:00 Last modified: Wed Dec 24 09:55:17 PST 2003 (root/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: default
Exit the kadmin.local program by typing quit and start the KDC dæmon with:
% sudo /usr/local/sbin/krb5kdc
Get a Kerberos 5 TGT by typing:
% /usr/local/bin/kinit john/admin@EXAMPLE.COM
and look at your TGT with:
% /usr/local/bin/klist Ticket cache: FILE:/tmp/krb5cc_5828 Default principal: john/admin@EXAMPLE.COM Valid starting Expires Service principal 12/23/03 14:15:39 12/24/03 14:15:39 krbtgt/EXAMPLE.COM@EXAMPLE.COM
Congratulations! You just completed your first successful Kerberos authentication.
You now need to specify which privileges this administration account should have, which is determined by entries in the file /usr/local/var/krb5kdc/kadm5.acl. You can give john/admin permissions to administer all principals, indicated by the wildcard character *, by adding the line:
john/admin@EXAMPLE.COM *
to this file.
Before you can start using the administration dæmon (kadmind) over the network, you have to create a keytab file containing the key for one of the kadmin principals created when we initialized our realm:
kadmin.local: ktadd -k /usr/local/var/krb5kdc/ ↪kadm5.keytab kadmin/changepw
Now everything is ready for the Kerberos administration dæmon. Start it with:
% sudo /usr/local/sbin/kadmind
This dæmon allows you to administer your Kerberos principals remotely, without logging in to your KDC, using the kadmin client tool. If you want your Kerberos dæmons to start up automatically at boot time, add them to your KDC's /etc/rc files.
With the Kerberos TGT obtained above, start the remote administration tool:
% /usr/local/sbin/kadmin Authenticating as principal john/admin@EXAMPLE.COM with password. Password for john/admin@EXAMPLE.COM:
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Designing Electronics with Linux | May 22, 2013 |
| Dynamic DNS—an Object Lesson in Problem Solving | May 21, 2013 |
| Using Salt Stack and Vagrant for Drupal Development | May 20, 2013 |
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
- Designing Electronics with Linux
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Dynamic DNS—an Object Lesson in Problem Solving
- New Products
- Using Salt Stack and Vagrant for Drupal Development
- Validate an E-Mail Address with PHP, the Right Way
- Build a Skype Server for Your Home Phone System
- Why Python?
- Tech Tip: Really Simple HTTP Server with Python
- A Topic for Discussion - Open Source Feature-Richness?
- Not free anymore
41 min 21 sec ago - Great
4 hours 28 min ago - Reply to comment | Linux Journal
4 hours 36 min ago - Understanding the Linux Kernel
6 hours 51 min ago - General
9 hours 21 min ago - Kernel Problem
19 hours 23 min ago - BASH script to log IPs on public web server
23 hours 50 min ago - DynDNS
1 day 3 hours ago - Reply to comment | Linux Journal
1 day 3 hours ago - All the articles you talked
1 day 6 hours ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?




Comments
SSO not working
I have read document and implement it but my SSH not working for SSO like one time auth its asking me passwd again and again any solution ?
/etc/hosts file
Excellent guide.
Here's a tip that might save knuckleheads like me a few hours of stumbling around: None of this works if you don't have /etc/hosts set up properly. I kept getting this error:
kadmin: Cannot contact any KDC for requested realm while initializing kadmin interface
/etc/hosts MUST contain a line associating the KDC server not with a loopback address (WRONG: "127.0.0.1 kdc.example.com") but with a real IP address available over the network (RIGHT: "128.231.35.98 kdc.example.com"). Ports 88 and 749 must be unfirewalled.
(Since I'm currently out of town and can't fiddle with my router, I'm temporarily assigning KDC to the local address assigned by the router (192.168.2.3), although of course this means I can't access Kerberos over the Internet).
/etc/passwd & /etc/shadow account syncronisation
The second requirement is harder to meet. All account names, UIDs and GIDs have to be the same on all your
computers. This is necessary because each of these accounts becomes a new and independent Kerberos account,
called a principal. You have to go through all your local /etc/passwd files and check whether this requirement is
met. If not, you need to consolidate your accounts. If you want to add Windows or Mac OS X clients to your
Kerberos installation, you need to look at all the accounts on those machines as well.
I assume this only applies to user accounts (ie uid > 1k), it would be an utter pain to have to synchronise system accounts across multiple machines.
Format or /etc/krb5.conf
Running "kdb5_util create -s" gave me the error "Improper format of Kerberos configuration file while initializing Kerberos code" with the example krb5.conf in the article.
Removing all leading whitespace from krb5.conf did the trick.
Thank you btw
Hi,
Hi,
I have read this article. I was wondering is there any second part(s) / continuation of this tutorial? if yes can you provide those tutorial links?
please note my eramil id : massoo@gmail.com , massoo@30gigs.com
regards
shann
pam-krb5 and gksudo
I've been following the directions in this article and the the subsequent articles about centralized authentication and I was delighted to get my kerberos implementation working. But upon further investigation, I realized that although login and sudo works, applications that use gksudo, such as synaptic don't is there a solution for this. I found a few others with this promlem on the internet, but I couldn't find any solutions. Many thanks for your help on this issue, and all of your very informative articles.
gksudo
I have since moved away from sudo and started using .k5user and .k5login in /root/ directory
.k5login allow users in that file access to become root
.k5user allow specified commands to be executed as root or as another user.
enjoy