When a group of users has accounts on many computers, though, maintaining those accounts can be tedious. Furthermore, with passwords flying across the network wires, often in an unencrypted form, the chance for a malicious individual to do damage by stealing passwords is substantial. These are the problems that Kerberos is intended to solve. This tool allows you to maintain a centralized user database. Individual computers defer to this centralized database when authenticating users, and use sophisticated encryption techniques to ensure that data transfers aren't subject to hijacking.
Kerberos uses both a client and a server. To do any good, you must be able to configure both.
Kerberos is an extremely complex protocol, and to use it fully you must configure not only a single Kerberos server, but many of your network's servers and clients
Tools like firewalls (discussed in Chapter 25, Configuring iptables) are designed to protect a computer or network from the outside world, or to protect the outside world from miscreants inside a local network. Kerberos, on the other hand, is an internal security tool—it helps both servers and clients be sure that they're communicating with the proper systems and users, and to protect passwords so that they can't be stolen and abused by other local network users. (Kerberos can also improve external security by providing encryption to external users who need access to internal servers.) Simultaneously, Kerberos provides convenience—by centralizing the password database, Kerberos allows a user to log in to any workstation on a network and enter a login password only once, obviating the need to enter passwords for POP mail servers, FTP servers, and other local servers that would otherwise require passwords.
These features make Kerberos a very useful tool on mid-sized and large local networks, such as those operated by many colleges, universities, and corporations. Such networks frequently host mail servers, print servers, and the like internally, and allow users to log in to workstations at many locations. Rather than maintain a centralized computer system with terminals, users at these organizations use more powerful workstations. On such a network, maintaining individualized password databases is tedious at best, so Kerberos is a useful tool.
Kerberos credentials and Kerberos tickets are the same thing.
Kerberos is a cross-platform tool; Kerberos clients and servers can exist on Linux, other UNIX-like OSs, Windows, MacOS, or many other OSs. (Microsoft's own Kerberos implementation, though, is subtly incompatible with the standard version. The MIT Kerberos page includes links to another implementation of Kerberos for Windows that is more compatible with the standard version.) Cross-platform compatibility can be an extremely important characteristic in many environments.
Centralized versus Distributed Computing
In the late 1960s through much of the 1980s, UNIX systems were generally intended to be used by several people simultaneously. These computers sat in machine rooms and were used via text-mode terminals or, later, X terminals that provided GUI access. As processing power became cheaper, a trend developed to place workstations on all users' desks. The modern x86 PC is a manifestation of this trend.
Today, most networks use a largely decentralized computing model, with workstations running Windows, MacOS, or occasionally Linux or some other UNIX variant. These computers may rely on network servers such as mail servers, file servers, print servers, and so on, but they do most of their processing locally. Such a network has a certain advantage in robustness, because if a server goes down, chances are the rest of the network will continue to operate. This distributed approach also means that all users can count on a certain minimum amount of processing power—whatever's available on the local workstation. In simple networks like this, users are often tied to specific computers, because they only have passwords on their own computers. This is one of the problems that Kerberos is intended to solve.
Today's x86 computers are far more powerful than the mainframes of just a couple of decades ago, and it's possible to use them in a centralized computing approach. A single powerful Linux system can run many users' programs. These users can sit at much less powerful systems that function only as terminals, using terminal software like that discussed in Chapters 13 (Maintaining Remote Login Servers) and 14 (Handling GUI Access with X and VNC Servers). Such an approach is vulnerable to problems with the central system, though; if it goes down, the rest of the network becomes useless. The centralized approach can be easier to administer, though, and it may obviate the need for user management software like Kerberos.
In most cases, the applications you use must include explicit Kerberos support to take advantage of the tool. For instance, your POP mail client and server must both support Kerberos authentication, or they'll continue using their own authentication methods.
Effectively using Kerberos on your network requires you to install a Kerberos password server (more commonly called a key distribution center, or KDC) and add both client and server software that uses the KDC for authentication (these are often called Kerberized applications). Understanding the basics of the Kerberos protocols, including the interactions between these elements, is important for effective use of Kerberos on a network
Described in a single sentence, Kerberos is a centralized user authentication protocol that uses encryption to protect against various forms of attack
As already described, a Kerberos network is built around a KDC. This KDC is responsible for authenticating machines in a Kerberos realm. Typically, a realm corresponds to an Internet domain or subdomain. For instance, the threeroomco.com domain might contain a single Kerberos realm, which would probably be called THREEROOMCO.COM.
The convention is to use all-uppercase letters for Kerberos realms simply to distinguish in writing between the functions of a realm and a domain, although the two may consist of the same set of computers
Some protocols encrypt passwords to avoid this problem, but Kerberos uses an unusual approach: Rather than send passwords in an encrypted form, it uses the password as an encryption key for transmitting data required for Kerberos's operation. Thus, the password isn't transmitted, but only a user with the correct password can use the data
Most importantly, the KDC is an extremely sensitive system, from a network security point of view.The KDC should run as few other network servers as possible (normally only those required to administer it—ideally none), it should have no ordinary users except for its administrators, you should pay particular care to keeping its software up to date, and it should be physically secure. Because use of many network services depends upon the KDC, you should be prepared with contingency plans in case it fails. Keep backups of the KDC's data and have backup hardware ready in case of failure. You might even want to maintain a slave or backup KDC, which pulls its configuration from the master KDC, so that the slave can take over KDC functions in case of a failure of the master KDC.
debian -sarge-
edit /etc/krb5.conf
edit /etc//krb5kdc/kdc.conf
/var/lib/krb5kdc/ dizini bo?
/etc/krb5kdc dizini içinde sadece kdc.conf var
Creating a Master Key
Kerberos relies on a master key to control access to itself. This key is essentially a password, and it may be stored locally in a stash file, which is a file that the server reads sto allow itself to start up automatically. Without the stash file, the server requires manual intervention at startup—somebody must type in the master key.Because of its critical nature, the stash file should be stored only on a disk that's local to the KDC, and be readable only by root
If you don't want to use a stash file, you can omit the -s from the kdb5_util command; this will cause the program to not create the stash file. You'll then need to enter the Kerberos master key whenever you start the server.
To create a master key and store it in a stash file, use the kdb5_util command:
# kdb5_util create -r EDAKOM.COM -s
q1w2e3r4*
This command creates or initializes several files in the /var/kerberos/ krb5kdc directory, or some other location a given Kerberos package uses for this purpose.
These files include:
· The stash file, which may be called .k5.REALM.NAME, where REALM.NAME is the realm name; or .k5stash.
· Two Kerberos database files, principal and principal.ok. (The principal file is called principal.db on some systems.)
· Two Kerberos administrative files, principal.kadm5 and principal. kadm5.lock.
bu komuttan sonra
sarge26:~/sil# ls -al /var/lib/krb5kdc/
total 18
drwx------ 2 root root 1024 Jul 26 09:32 .
drwxr-xr-x 28 root root 1024 Jul 26 06:43 ..
-rw------- 1 root root 8192 Jul 26 09:32 principal
-rw------- 1 root root 8192 Jul 26 09:32 principal.kadm5
-rw------- 1 root root 0 Jul 26 09:32 principal.kadm5.lock
-rw------- 1 root root 0 Jul 26 09:33 principal.ok
sarge26:~/sil# ls -al /etc/krb5kdc/
total 6
drwx------ 2 root root 1024 Jul 26 09:32 .
drwxr-xr-x 82 root root 3072 Jul 26 09:21 ..
-rw-r--r-- 1 root root 498 Jul 25 14:50 kdc.conf
-rw------- 1 root root 30 Jul 26 09:32 stash
Administering a Realm
Once you've modified the Kerberos configuration files for your realm and used kdb5_util to create a master key and initialize the Kerberos databases, you can begin administering the realm. This process is essentially one of defining principals, including some that have administrative privileges to add other principals.
Defining Basic ACLs
Kerberos principal information is stored in the form of Access Control Lists (ACLs), which are stored in the file pointed to by the acl_file entry in kdc.conf.
Create an administrator kadm5.acl file following the instructions in the Kerberos manual. Put it in the location specified in the 'acl_file =' section of kdc.conf.
echo "*/admin@EDAKOM.COM *" > /etc/krb5kdc/kadm5.acl
Creating Principals
You use the kadmin or kadmin.local programs to administer your Kerberos user database. The former program uses encrypted Kerberos communications to administer a KDC from a remote system; the latter modifies the local database files directly, without using network tools. You must use kadmin.local to add at least one administrative user. Thereafter, you can theoretically use kadmin from other systems in much the same way, although of course you must have appropriate Kerberos administrative servers running on the KDC, which at this point in the process they are not.
Add your administrator(s) to the KDC database as per the manual
/krb5:738: sbin/kadmin.local
kadmin.local: addprinc admin/admin@EDAKOM.COM
Enter password for principal "admin/admin@EDAKOM.COM": your_password
Re-enter password for principal "admin/admin@EDAKOM.COM": your_password
Principal "admin/admin@EDAKOM.COM" created./krb5/sbin/kadmin.local
zaq1xsw2
Create the keytab file on the server. kadmind uses this to determine what access it should give to administrators. The manual is wrong here. Stay in kadmin.local and give the command:
kadmin.local: ktadd -k /etc/krb5kdc/kadm5.keytab kadmin/admin kadmin/changepw
Entry for principal kadmin/admin with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5kdc/kadm5.keytab.
Entry for principal kadmin/admin with kvno 3, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/etc/krb5kdc/kadm5.keytab.
Entry for principal kadmin/changepw with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5kdc/kadm5.keytab.
Entry for principal kadmin/changepw with kvno 3, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/etc/krb5kdc/kadm5.keytab.
kadmin.local: quit
Getting the kadmin demon to work
kadmin allows you to administer the Kerberos databases remotely (and securely). If you just run kadmin, you will obtain an error message like:
kadmin: Client not found in Kerberos database while initializing kadmin interface
To be able to use the kadmin interface, you need to register yourself as a database administrator.
On the KDC machine, in kadmin.local add an administrator role for yourself:
sarge26:~/sil# kadmin.local
Authenticating as principal root/admin@EDAKOM.COM with password.
kadmin.local: addprinc kurt/admin@EDAKOM.COM
WARNING: no policy specified for kurt/admin@EDAKOM.COM; defaulting to no policy
Enter password for principal "kurt/admin@EDAKOM.COM":
Re-enter password for principal "kurt/admin@EDAKOM.COM":
Principal "kurt/admin@EDAKOM.COM" created.
quit
xsw2cde3
?ifreyi de?i?tirmek için
kadmin.local: cpw -pw 12345678 kurt/admin
After you've created an administrative principal, you must create a keytab for the administrative principal. This is a key that Kerberos uses to decrypt administrative tickets. You don't need to specify this key yourself; Kerberos can generate it. You do need to tell Kerberos to do so, though, using the ktadd command within kadmin.local:
You specify the file in which the keytab is stored by preceding the filename with -k. This file should match the one specified in the kdc.conf file's admin_keytab entry.
sarge26:~/sil# kadmin.local
Authenticating as principal root/admin@EDAKOM.COM with password.
kadmin.local: ktadd -k /etc/krb5kdc/kadm5.keytab kurt/admin
Entry for principal kurt/admin with kvno 2, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5kdc/kadm5.keytab.
Entry for principal kurt/admin with kvno 2, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/etc/krb5kdc/kadm5.keytab.
bu komuttan sonra kadm5.keytab olu?tu
sarge26:~/sil# ls -al /etc/krb5kdc/
total 7
drwx------ 2 root root 1024 Jul 26 09:48 .
drwxr-xr-x 82 root root 3072 Jul 26 09:21 ..
-rw------- 1 root root 122 Jul 26 09:48 kadm5.keytab
-rw-r--r-- 1 root root 498 Jul 25 14:50 kdc.conf
-rw------- 1 root root 30 Jul 26 09:32 stash
Setting up a host server
A host is a machine that offers kerberized services (telnet, ftp, rlogin,?) to users. We want to configure dsrocf as a Kerberized host. To allow this, we need to create a /etc/krb5.keytab file. This is easy now that we can run kadmin remotely on the KDC. You need to be root on the host machine in order to be able to write into /etc. In kadmin, add the host as a principal:
migfer' de kerberized ftpd servisi vermek istiyorum.
migfer:~# kinit kurt/admin
migfer:~# kadmin
Authenticating as principal kurt/admin@EDAKOM.COM with password.
Password for kurt/admin@EDAKOM.COM:
kadmin: add_principal host/migfer.edakom.com
WARNING: no policy specified for host/migfer.edakom.com@EDAKOM.COM; defaulting to no policy
Enter password for principal "host/migfer.edakom.com@EDAKOM.COM":
Re-enter password for principal "host/migfer.edakom.com@EDAKOM.COM":
Principal "host/migfer.edakom.com@EDAKOM.COM" created.
12345678
Then add its keytab entry in the LOCAL (migfer) /etc/krb5.keytab file. This process securely shares a secret key to be used for communication between the Kerberized host and the KDC server.
kadmin: ktadd host/migfer.edakom.com
Entry for principal host/migfer.edakom.com with kvno 2, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/migfer.edakom.com with kvno 2, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/etc/krb5.keytab.
kadmin: quit
bu komutlardan sonra migfer' de /etc/krb5.keytab dosyası oluştu.
Repeat this process for every host in your realm.
Finally, you should add the following lines to the end of the /etc/inetd.conf file on each host so that the Kerberos daemons start up automatically when your host is rebooted:
apt-get install krb5-ftpd (kerberize /usr/sbin/ftpd için)
apt-get install krb5-clients (kerberize /usr/bin/krb5-ftp için)
#
#Kerberos daemons
#
klogin stream tcp nowait root /krb5/sbin/klogind klogind -ki
eklogin stream tcp nowait root /krb5/sbin/klogind klogind -eki
kshell stream tcp nowait root /krb5/sbin/kshd kshd -ki
ktelnet stream tcp nowait root /krb5/sbin/telnetd telnetd -a user
kftp stream tcp nowait root /krb5/sbin/ftpd -a
kullanıcı ekledim bir tane
sarge26:~# kadmin.local
Authenticating as principal root/admin@EDAKOM.COM with password.
kadmin.local: addprinc ayse@EDAKOM.COM
WARNING: no policy specified for ayse@EDAKOM.COM; defaulting to no policy
Enter password for principal "ayse@EDAKOM.COM":
Re-enter password for principal "ayse@EDAKOM.COM":
Principal "ayse@EDAKOM.COM" created.
kadmin.local: quit
yavru
***********
client conf
kinit vs vs için
apt-get install krb5-user krb5-config ******.paket kurulumu realm ve kdc yi soruyor.******
**********
HATA Mesajı 1
uzaktaki bir makinadan
migfer:~# kadmin
Authenticating as principal kurt/admin@EDAKOM.COM with password.
Password for kurt/admin@EDAKOM.COM:
kadmin: Communication failure with server while initializing kadmin interface
yönetim(kdc) makinasında kadmind çalışmıyordu.tcp port 749
**********
http://mailman.mit.edu/pipermail/kerberos/2004-June/005582.html
Adding the user to the local machine database is not about authentication but authorization. Once the machine has identified that I am jaltman at ATHENA.MIT.EDU it needs to know whether or not there is an account into which jaltman at ATHENA.MIT.EDU is allowed to access. Jeffrey Altman
Lara Adianto wrote: > Thanks, that's a very clear explanation ! > But I still can't understand why I should add the user > to the local machine as well. When the server (the > local machine) does AP-REQ processing, it doesn't need > the username right ? The server only needs to compare > the username in the authenticator and the ticket and > see if the two of them match...Correct me if i'm > wrong.
***********
I have a weird problem with authentication to active directory from my linux box using kerberos. I'm using pam_krb5 to do the authentication and looking up the uid/gid through ldap meaning I do not have an entry in the /etc/passwd file.
***********
I am having hard time using Kerberos Authentication method for SSH login on Red Hat Advance Server 3.0. Basically I am trying to authenticate against MS AD, I was able to configure /etc/krb5.conf and create Kerberos ticket w/out any error message and I can telnet and login via console using my MS AD login and password. But the only problem I am having is ssh login, it is not working smoothly for me. If someone has encounter similar problem please let me know, I would appreciate all the help I can get.
***********
Passwords are not stored on the Kerberos server; only keys derived
> from passwords are stored in the Kerberos database.
... and this derivation performed using a cryptographic hash function, such
that it is impossible to recover the original password from the keys stored
in the Kerberos database
***********
Why Kerberos?
But why store the user passwords in the Kerberos database in the first place? Why not just use it for/when we need a replica (or replicas)? We only really need Kerberos to have a service key, right? Nope, not quite true. The answer is quite simple actually. Kerberos is designed solely as a secure password storage database (with a secure authentication protocol) on an insecure network. And contrary to popular belief, a local network IS NOT to be considered a secure environment! LDAP, on the other hand, is designed to be a database for distributed, public information.
Kerberos replacement software
Put simply, passwords are more secure in a Kerberos database, than in a LDAP ditto. Besides, with at least MIT Kerberos, there are special, kerberised binaries that replace the original ones. This will give you a more secure way of authentication (you don't have to go through PAM etc). The software to let this be possible, is libnss-ldap. It will get all the public information (such as UID/GID numbers, home directory etc, etc) from LDAP, but look at the Kerberos server fo the password. Thus, all sensitive information is encrypted, even before leaving the binary. The binaries/services that can be replaced right-out-of-the-box is login, ftpd, ftp, rlogind, rlogin, rshd, rsh, telnetd, telnet and passwd.
I only have one machine (called papadoc for 'historical' reasons). This system 'only' hosts five domains, with about 50 users (most of them family and friends). Having users (and all there relevant information, such as UID/GID number, home directory, passwords, mail address, mail aliases etc, etc) in an LDAP database, using libpam-ldap to help authentication, was my main reason for LDAP.
***********
kinit— This program obtains a TGT. You can think of it as a program that "logs you into" a Kerberos realm; before running kinit (or using equivalent functionality, as described in the upcoming section, "Using Kerberos for User Logins"), you can't use any Kerberos client. When you run kinit, the program contacts the KDC to obtain a TGT. Thereafter, Kerberized applications use the TGT to obtain authorization to use Kerberos application servers.yani tgt olmadan her önüne gelen bağlanamaz telnetd ye.mesela...
***********
login— This controls the login program. If you install Kerberized PAM support, you can forego the official Kerberos login.krb5 program
Naturally, there are other programs whose PAM control files you might want to modify to add Kerberos support. The details depend on your system. Note that you don't need to modify the PAM files for services you're explicitly Kerberizing. For instance, if you install a Kerberos-enabled FTP server, you don't need to modify the /etc/pam.d/ftp file. Explicitly Kerberized applications can communicate with the KDC for authentication, bypassing PAM and the need to explicitly enter a username and password that PAM requires.
If you need to modify a PAM-using program to use Kerberos, you must add or replace certain lines in the PAM configuration file. These files specify four authentication services: auth (authenticating a user), account (checking that an account is valid), password (changing a password), and session (setting up and terminating sessions).
**********
örnek /etc/pam.d/vlock konfigurasyonu
migfer:/etc/pam.d# cat vlock
#%PAM-1.0
auth sufficient pam_unix.so
auth required pam_krb5.so use_first_pass
vlock authentication için önce /etc/shadow a bakıyor.orada şifresi yoksa kdc(sarge26)' ya soruyor.kerberos ilk verilen şifreyi kullanıyor.
Summary
Kerberos is an extremely powerful tool for centralizing authentication in a network. The protocol uses encryption and a centralized user database to allow application servers and workstations to rely on the main Kerberos server to handle authentication tasks. If used to its fullest, the result is that users can log into any workstation and then use network services within the network without providing a password again. Even the initial password is never sent over the network, so the risk of passwords being compromised is greatly reduced. The centralized user database also greatly simplifies account maintenance.
There are several Kerberos implementations available for Linux, some of which may be easier to use with any given distribution than others. Configuring a Kerberos network requires installing at least a subset of the Kerberos software on all computers. One system must be configured as a key distribution center (KDC), which houses the user database. Servers and workstations need Kerberized versions of their server and client programs, respectively. If a single-login configuration is required, workstations require modified login software. Although configuring this software can be tedious, particularly if your distribution doesn't ship with appropriate Kerberos packages, the benefits in security and centralized user administration can be substantial in a mid-sized or large network.
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Kerberos was designed under the assumption that attackers can read, copy, and create network traffic at will.
The Windows 2000 and 2003 Domain Controller is the Windows equivalent of a Unix-based KDC. You'll need Windows 2000 Server or Windows 2003 Server to create a domain controller.
Therefore, to establish a Windows-based KDC, you must establish an Active Directory domain.
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
win logon kerberos realm ine authenticate olduktan sonra tgt ti leash de urdan alıyor.leash in aldığı tgt yi kermit95 telnet client ı görebiliyor.
No comments:
Post a Comment