by danang.wijanarko@gmail.com
MASTER SLAVE KERBEROS SETTING
Basically there're only 1 packet necessary to set kerberos server. It is krb5-kdc and others just follow, try it you'll feel nice when you stick with debian packaging system.
Step 1: apt-get install krb5-kdc
Then edit the /etc/krb5.conf and you need to really set the realm part, other is opt. see for the compleet doc at distribution for every tag. This need krb5-doc package. If you haven't install it yet, fell free 'bout your decision, :-).
Next step will create database for your realm and the stash.
Step 2: kdb5_util create -r YOUR.REALM -s
Then we need to add some account to the acl list for administering databases purpose. It would take 2 step. First one adding the principal that accepted in the acl and next add the principal to the kerberos database. Tipically sarge would give acl file default to /etc/krb5kdc/kadm5.acl. You can overide it by overiding entry at /etc/krb5kdc/kdc.conf
Step 3: kadmin.local -r YOUR.REALM -q "addprinc admin/admin"
Next just restart the server and you've done your first walk.
Step 4: /etc/init.d/krb5-kdc restart; /etc/init.d/krb5-admin-server restart
Note: See the file that related to kerberos package at /etc/default/ dir.
The following steps is optional for setting slave. If you don't fell ok with slave then skip it. You are now ready to start configuring the slave KDCs.
BIG FAT NOTE: Assuming you are setting the KDCs up so that you can easily switch the master KDC with one of the slaves, you should perform each of these steps on the master KDC as well as the slave KDCs, unless these instructions specify otherwise.
First you need to create host heys for the slave KDCs.
Step 5:
kadmin -p admin/admin -r YOUR.REALM -q "addprinc -randkey host/your.master.host"
kadmin -p admin/admin -r YOUR.REALM -q "addprinc -randkey host/your.slave.host"
It is not actually necessary to have the master KDC server in the Kerberos database, but it can be handy if:
- anyone will be logging into the machine as something other than root.
- you want to be able to swap the master KDC with one of the slaves if necessary.
Next step is to extract host keytabs for the KDCs. Each KDC (including the master) needs a keytab to decrypt tickets. Ideally, you should extract each keytab locally on its own KDC. If this is not feasible, you should use an encrypted session to send them across the network. To extract a keytab on a KDC called your.master.host, you would execute the following command.
Step 6: kadmin -p admin/admin -r YOUR.REALM -q "ktadd host/your.master.host"
Note: The principal must exist in the Kerberos database in order to extract the keytab. Next step is to set up the slave KDCs for database propagation. But before that you must install the klogind on kerberos version.
Step 7: apt-get install krb5-rsh-server
The database is propagated from the master KDC to the slave KDCs via the kpropd daemon. To set up propagation, create a file on each KDC (on the database directory), named /etc/krb5kdc/kpropd.acl, containing the principals for each of the KDCs. For example, if the master KDC were your.master.host, the slave KDCs were your.slave.host, and the realm were YOUR.REALM, then the file's contents would be:
host/your.master.host@YOUR.REALM
host/your.slave.host@YOUR.REALM
Then, add the following lines to /etc/inetd.conf file on each KDC:
krb5_prop stream tcp nowait root /usr/local/sbin/kpropd kpropd
eklogin stream tcp nowait root /usr/local/sbin/klogind klogind -k -c -e
The first line sets up the kpropd database propagation daemon. The second line sets up the eklogin daemon, allowing Kerberos-authenticated, encrypted rlogin to the KDC.
You also need to add the following lines to /etc/services on each KDC:
kerberos 88/udp kdc # Kerberos authentication (udp)
kerberos 88/tcp kdc # Kerberos authentication (tcp)
krb5_prop 754/tcp # Kerberos slave propagation
kerberos-adm 749/tcp # Kerberos 5 admin/changepw (tcp)
kerberos-adm 749/udp # Kerberos 5 admin/changepw (udp)
eklogin 2105/tcp # Kerberos encrypted rlogin
PROPAGATION
On master do the following step.
Dump the database:
Step 1: kdb5_util dump /usr/local/var/krb5kdc/slave_datatrans
Propagate it! :
Step 2: kprop -f /usr/local/var/krb5kdc/slave_datatrans your.slave.host
DAMN IT'S NOTE: ABOUT KEYTAB
Add the keytab only for your specific machine only (add keytab your slave only to ypur slave and master only to master), and this is common problem.
IN MASTER: ktadd host/kerberos.master@MY.REALM
IN SLAVE: ktadd host/kerberos.slave@MY.REALM
DAMN IT'S NOTE: ABOUT ALIAS
And again, add the principal of you all alias name of your master and slave host. So if you have alias name for kerberos.master to begundal.master, just add both in host/...@... principal and also in the keytab, so does for the slave. This also very common wrong setting.
FINISHING
Create Stash Files on the Slave KDCs
Step 1: kdb5_util stash
As mentioned above, the stash file is necessary for your KDCs to be able authenticate to themselves, such as when they reboot. You could run your KDCs without stash files, but you would then need to type in the Kerberos database master key by hand every time you start a KDC daemon.
Start the krb5kdc Daemon on Each KDC
Step 2: /etc/init.d/krb5-kdc restart
FILES
Debian
All configuration is stored in:
/etc/krb5.conf # Global configuration
/etc/krb5kdc/ # All configuration files related to KDC is tored in this directory
Don't bothering where it lies the database is, it's easy to find.
NEXT ... SEE DOC
Reference
- krb5-doc
- Kerberos-Infrastructure-HOWTO
Using as administrator.
Common terminology and explanation:
Client : An entity that can obtain a ticket. This entity is usually either a user or a host.
Host : A computer that can be accessed over a network.
KDC : Key Distribution Center. A machine that issues Kerberos tickets.
Principal : primary/instance@realm
- Primary : In the case of a user, it is the username.
In the case of a service, it is the name of the service.
- Instance : It gives information that qualifies the primary.
The instance may be null.
In the case of a user, the instance is often used to describe the intended use of the corresponding credentials.
In the case of a host, the instance is the fully qualified hostname.
- Realm : The logical network served by a single Kerberos database and a set of Key Distribution Centers.
By convention, realm names are generally all uppercase letters, to differentiate the realm from the internet domain.
Kerberos database server : Maintain a database of user, server, and password information.
Ticket : A temporary set of electronic credentials that verify the identity of a client for a particular service.
TGT :
Ticket-Granting Ticket. A special Kerberos ticket that permits the client to obtain additional Kerberos tickets within the same Kerberos realm.
The kinit command prompts for your password.
If you enter it successfully, you will obtain a ticket-granting ticket and a ticket session key which gives you the right to use the ticket.
This combination of the ticket and its associated key is known as your credentials.
Client programs use your ticket-granting ticket credentials in order to obtain client-specific credentials as needed
Services :
Any program or computer you access over a network.
Examples of services include "host" (a host, e.g., when you use telnet and rsh), "ftp" (FTP), "krbtgt" (authentication; cf. ticket-granting ticket), and "pop" (email).
The master database also contains entries for all network services that require Kerberos authentication.
Suppose that your site has a machine, nermus.its.ac.id, that requires Kerberos authentication from anyone who wants to rlogin to it.
The host's Kerberos realm is ITS.AC.ID.
This service must be registered in the Kerberos database, using the proper service name, which in this case is the principal:
host/nermus.its.ac.id@ITS.AC.ID
Keytab : A key table file containing one or more keys. A host or service uses a keytab file in much the same way as a user uses his/her password.
For each service, there must also be a service key known only by Kerberos and the service.
- On the Kerberos server, the service key is stored in the Kerberos database.
- On the server host, these service keys are stored in key tables, which are files known as keytabs.
For example, the service keys used by services that run as root are usually stored in the keytab file /etc/krb5.keytab.
N.B.: This service key is the equivalent of the service's password, and must be kept secure.
Data which is meant to be read only by the service is encrypted using this key.
Interaction User / Kerberos
When we want to rlogin to nermus.its.ac.id:
- Use the kinit command to get a ticket-granting ticket.
- The kinit command sends your request to the Kerberos master server machine. The server software looks for your principal name's entry in the Kerberos database.
- If this entry exists, the Kerberos server creates and returns a ticket-granting ticket and the key which allows you to use it, encrypted by your password. If kinit can decrypt the Kerberos reply using the password you provide, it stores this ticket in a credentials cache on your local machine for later use. The name of the credentials cache can be specified in the KRB5CCNAME environment variable. If this variable is not set, the name of the file will be /tmp/krb5cc_, where is your UNIX user-id, represented in decimal format.
- Use the rlogin client to access the machine nermus.its.ac.id.
- The rlogin client checks your ticket file to see if you have a ticket for the host service for nermus.its.ac.id. You don't, so rlogin uses the credential cache's ticket-granting ticket to make a request to the master server's ticket-granting service.
- This ticket-granting service receives the request for a ticket for host/nermus.its.ac.id, and looks in the master database for an entry for host/nermus.its.ac.id. If the entry exists, the ticket-granting service issues you a ticket for that service. That ticket is also cached in your credentials cache.
- The rlogin client now sends that ticket to the nermus.its.ac.id klogind service program. The service program checks the ticket by using its own service key. If the ticket is valid, it now knows your identity. If you are allowed to login to nermus.its.ac.id (because your username matches one in /etc/passwd, or your Kerberos principal is in the appropriate .k5login file), klogind will let you login.
/etc/krb5.conf
Some configurations might interesting to look. These are some that make me interested, 'cause these had been screw me up in some moment:
[libdefaults]
default_realm : Identifies the default Kerberos realm for the client.
Set its value to your Kerberos realm.
If this is not specified and the TXT record lookup is enabled (see Using DNS), then that information will be used to determine the default realm.
If this tag is not set in this configuration file and there is no DNS information found, then an error will be returned.
clockskew : Sets the maximum allowable amount of clockskew in seconds that the library will tolerate before assuming that a Kerberos message is invalid.
The default value is 300 seconds, or five minutes.
kdc_timesync : If this is set to 1 (for true), then client machines will compute the difference between their time
and the time returned by the KDC in the timestamps in the tickets and use this value to correct for an inaccurate system clock.
This corrective factor is only used by the Kerberos library.
The default is 1.
dns_lookup_kdc : Indicate whether DNS SRV records should be used to locate the KDCs and other servers for a realm,
if they are not listed in the information for the realm.
(Note that the admin_server entry must be in the file, because the DNS implementation for it is incomplete.)
Enabling this option does open up a type of denial-of-service attack, if someone spoofs the DNS records and redirects you to another server.
However, it's no worse than a denial of service, because that fake KDC will be unable to decode anything you send it
(besides the initial ticket request, which has no encrypted data),
and anything the fake KDC sends will not be trusted without verification using some secret that it won't know.
If this option is not specified but dns_fallback is, that value will be used instead.
If neither option is specified, the behavior depends on configure-time options; if none were given, the default is to enable this option.
If the DNS support is not compiled in, this entry has no effect.
dns_lookup_realm : Indicate whether DNS TXT records should be used to determine the Kerberos realm of a host.
Enabling this option may permit a redirection attack,
where spoofed DNS replies persuade a client to authenticate to the wrong realm,
when talking to the wrong host (either by spoofing yet more DNS records or by intercepting the net traffic).
Depending on how the client software manages hostnames, however, it could already be vulnerable to such attacks.
We are looking at possible ways to minimize or eliminate this exposure.
For now, we encourage more adventurous sites to try using Secure DNS.
If this option is not specified but dns_fallback is, that value will be used instead.
If neither option is specified, the behavior depends on configure-time options; if none were given, the default is to disable this option.
If the DNS support is not compiled in, this entry has no effect.
[appdefaults] : The value of the tag defines the default behaviors for that application.
telnet = {
ITS.AC.ID = {
option1 = false
}
}
telnet = {
option1 = true
option2 = true
}
ITS.AC.ID = {
option2 = false
}
option2 = true : The above four ways of specifying the value of an option are shown in order of decreasing precedence.
In this example, if telnet is running in the realm EXAMPLE.COM, it should, by default, have option1 and option2 set to true.
However, a telnet program in the realm ITS.AC.ID should have option1 set to false and option2 set to true.
Any other programs in ITS.AC.ID should have option2 set to false by default.
Any programs running in other realms should have option2 set to true.
Application Servers
If you need to install the Kerberos V5 programs on an application server, you need to add that host to the Kerberos database, and generate a keytab for that host, that contains the host's key. You also need to make sure the host's clock is within your maximum clock skew of the KDCs.
Again: Keytab
A keytab is a host's copy of its own keylist, which is analogous to a user's password. An application server that needs to authenticate itself to the KDC has to have a keytab that contains its own principal and key. Just as it is important for users to protect their passwords, it is equally important for hosts to protect their keytabs. You should always store keytab files on local disk, and make them readable only by root, and you should never send a keytab file over a network in the clear. Ideally, you should run the kadmin command to extract a keytab on the host on which the keytab is to reside.
PAM
Doing this would track you to the right place. (Remember that i use debian).
apt-cache search pam | grep krb
apt-get install libpam-krb5
Then edit entry at /etc/pam.d/ to provide authentication against Kerberos, add the following:
auth required /lib/security/pam_krb5.so use_first_pass
To force authentication against the kerberos server, add
auth required pam_krb5.so try_first_pass
A complete PAM stack for user authentication might look like the following:
auth required pam_env.so
auth sufficient pam_krb5.so try_first_pass
auth sufficient pam_unix.so likeauth nullok
auth required pam_deny.so
This stack will first check the password for a user against the Case Kerberos server. If it fails, it will check against the local /etc/shadow file.
If you wish to place the Kerberos module as a fallback authentication module, you need to change the try_first_pass parameter to use_first_pass or the user will be prompted a second time for a password.
Optionally, you can plug the kerberos module into PAM for password changing so any time a password is changed on the machine, your Case network ID password will change as well. This is much easier than doing it online!
password sufficient pam_krb5.so use_authtok
A complete PAM password stack might look like the following:
password required pam_cracklib.so retry=3
password sufficient pam_unix.so nullok md5 shadow use_authtok
password sufficient pam_krb5.so use_authtok
password required pam_deny.so
LINKS
I swear that the most elegant and explanatory docs is using "apt-get install kr5-doc". I SWEAR ON IT !!! :-).
- d
