FreeBSD handboek
Terug | Hoofdstuk 14. Beveiliging | Volgende

# 14.7. KerberosIV

Bijgedragen door Mark Murray. Gebaseerd op een bijdrage van Mark Dapoz.

Kerberos is een netwerkdienst, protocol en systeem waarmee gebruikers zich kunnen aanmelden met behulp van een dienst op een veilige server. Diensten als op een andere server aanmelden, op afstand kopiëren, veilig tussen systemen kopiëren en andere taken met een hoog risico worden aanmerkelijk veiliger en beter controleerbaar.

De onderstaande instructies kunnen gebruikt worden als handleiding voor het opzetten van Kerberos op FreeBSD. Voor een volledige beschrijving wordt verwezen naar de relevante handleidingen.

## 14.7.1. KerberosIV installeren

Kerberos is een optioneel component van FreeBSD. De meest eenvoudige manier om de software te installeren is het selecteren van de `krb4` of `krb5` distributie in sysinstall tijdens de initiële installatie van FreeBSD. Hierdoor wordt de “eBones” (KerberosIV) of “Heimdal” (Kerberos5) implementatie van Kerberos geïnstalleerd. Deze implementaties zijn beschikbaar omdat ze ontwikkeld zijn buiten de VS/Canada en dus zijn ze beschikbaar voor systeemeigenaren buiten die landen in dit tijdperk waarin er beperkingen gelden ten aanzien van de export van coderingsprogramma's uit de VS.

Het is ook mogelijk te kiezen voor de MIT-implementatie van Kerberos via de Portscollectie: `security/krb5`.

## 14.7.2. Maken van de initiële database

Dit hoeft alleen op de Kerberos gedaan te worden. Er dienen geen oude Kerberos databases rond te slingeren. Controleer in de map `/etc/kerberosIV` of de volgende bestanden aanwezig zijn:

    # cd /etc/kerberosIV
    # ls
    README      krb.conf        krb.realms

Als er nog meer bestanden zijn (zoals `principal.*` of `master_key`), dan kan met het programma `kdb_destroy` de oude Kerberos database vernietigd worden of de overige bestanden kunnen verwijderd worden als Kerberos niet draait.

Nu moeten de bestanden `krb.conf` en `krb.realms` gewijzigd om de Kerberos wereld te definiëren. In dit geval heet de wereld `EXAMPLE.COM` en de server heet `grunt.example.com`. Wijzig of creëer het bestand `krb.conf`:

    # cat krb.conf
    EXAMPLE.COM
    EXAMPLE.COM grunt.example.com admin server
    CS.BERKELEY.EDU okeeffe.berkeley.edu
    ATHENA.MIT.EDU kerberos.mit.edu
    ATHENA.MIT.EDU kerberos-1.mit.edu
    ATHENA.MIT.EDU kerberos-2.mit.edu
    ATHENA.MIT.EDU kerberos-3.mit.edu
    LCS.MIT.EDU kerberos.lcs.mit.edu
    TELECOM.MIT.EDU bitsy.mit.edu
    ARC.NASA.GOV trident.arc.nasa.gov

In dit geval hoeven de andere werelden er niet te zijn. Ze staan er als voorbeeld van hoe een machine attent gemaakt kan worden op het bestaan van meerdere werelden. In een eigen test kan ervoor gekozen worden ze weg te laten.

De eerste regel benoemt de wereld waarin het systeem opereert. De andere regels bevatten werelden/hosts. Het eerste deel van een regel bevat de wereld en het tweede deel is een host in die wereld die fungeert als “sleutel distributiecentrum”. De woorden `admin server` achter een hostnaam betekenen dat een host ook administratieve database server is. In de handleidingen van Kerberos wordt hierover meer uitleg gegeven.

Nu moet `grunt.example.com` aan de wereld `EXAMPLE.COM` toegevoegd worden en er moet ook een instelling gemaakt worden voor alle hosts uit het `.example.com` domein in de wereld `EXAMPLE.COM`. Het bestand `krb.realms` dient dan als volgt gewijzigd te worden:

    # cat krb.realms
    grunt.example.com EXAMPLE.COM
    .example.com EXAMPLE.COM
    .berkeley.edu CS.BERKELEY.EDU
    .MIT.EDU ATHENA.MIT.EDU
    .mit.edu ATHENA.MIT.EDU

Nogmaals: de andere werelden hoeven er niet te staan. Ze staan er als voorbeeld hoe een machine van het bestaan van andere werelden op de hoogte gebracht kan worden. Om het overzichtelijker te maken, kan mogen ze verwijderd worden.

De eerste regel plaatst het specifieke systeem in de genoemde wereld. De rest van de regels geeft aan hoe standaardsystemen uit een bepaald subdomein in een wereld plaatst worden.

Nu kan de database aangemaakt worden. Dit hoeft alleen op de Kerberos server gedaan te worden (of Sleutel Distributie Centrum) met het commando `kdb_init`:

    # kdb_init
    Realm name [default  ATHENA.MIT.EDU ]: EXAMPLE.COM
    You will be prompted for the database Master Password.
    It is important that you NOT FORGET this password.

    Enter Kerberos master key:

Nu moet de sleutel opgeslagen worden zodat diensten op de lokale machine er gebruik van kunnen maken met het commando `kstash`:

    # kstash

    Enter Kerberos master key:

    Current Kerberos master key version is 1.

    Master key entered. BEWARE!

Nu is de gecodeerde hoofdsleutel opgeslagen in `/etc/kerberosIV/master_key`.

## 14.7.3. Help het aan de praat

Voor ieder systeem dat met Kerberos wordt beveiligd moeten twee principals worden aangemaakt. Die heten `kpasswd` en `rcmd`. Deze twee principals worden aangemaakt voor iedere systeem en de instantie is de naam van het systeem.

Deze daemons, kpasswd en rcmd, staan andere systemen toe om Kerberos wachtwoorden te wijzigen en commando's als rcp(1), rlogin(1) en rsh(1) uit te voeren.

Deze worden nu toegevoegd:

    # kdb_edit
    Opening database...

    Enter Kerberos master key:

    Current Kerberos master key version is 1.

    Master key entered.  BEWARE!
    Previous or default values are in [brackets] ,
    enter return to leave the same, or new value.

    Principal name: passwd
    Instance: grunt

    <Not found>, Create [y] ? y

    Principal: passwd, Instance: grunt, kdc_key_ver: 1
    New Password:                    <---- hier RANDOM invoeren
    Verifying password

    New Password: <---- hier RANDOM invoeren

    Random password [y] ? y

    Principal's new key version = 1
    Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
    Max ticket lifetime (*5 minutes) [ 255 ] ?
    Attributes [ 0 ] ?
    Edit O.K.
    Principal name: rcmd
    Instance: grunt

    <Not found>, Create [y] ?

    Principal: rcmd, Instance: grunt, kdc_key_ver: 1
    New Password:       <---- hier RANDOM invoeren
    Verifying password

    New Password:           <---- hier RANDOM invoeren

    Random password [y] ?

    Principal's new key version = 1
    Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
    Max ticket lifetime (*5 minutes) [ 255 ] ?
    Attributes [ 0 ] ?
    Edit O.K.
    Principal name:         <---- hier niks invoeren stopt het programma

## 14.7.4. Aanmaken van het serverbestand

Nu moeten alle instanties die de diensten op iedere server definiëren geëxtraheerd worden. Dat kan met het commando `ext_srvtab`. Dit commando maakt een bestand aan dat veilig gekopieerd moet worden naar de map `/etc` van iedere Kerberos-cliënt. Dit bestand moet aanwezig zijn op iedere server en op iedere cliënt en is van doorslaggevend belang voor de werking van Kerberos.

    # ext_srvtab grunt
    Enter Kerberos master key:

    Current Kerberos master key version is 1.

    Master key entered. BEWARE!
    Generating 'grunt-new-srvtab'....

Het bovenstaande commando maakt een tijdelijk bestand aan dat hernoemd moet worden naar `srvtab` zodat alle diensten erbij kunnen. Met mv(1) kan het op de juiste plaats op het originele systeem gezet worden:

    # mv grunt-new-srvtab srvtab

Als het bestand voor een cliëntsysteem is en het netwerk is niet veilig, dan kan het bestand ``client`-new-srvtab` dan naar een verwijderbaar medium gekopieerd worden en dan fysiek veilig getransporteerd worden. Op de cliënt dient het bestand `srvtab` te heten in de map `/etc` en in modus 600 te staan:

    # mv grumble-new-srvtab srvtab
    # chmod 600 srvtab

## 14.7.5. De database vullen

Nu moeten de gebruikers in de database. In dit voorbeeld wordt de gebruiker `jane` als eerste ingevoerd. Hiervoor is het commando `kdb_edit`:

    # kdb_edit
    Opening database...

    Enter Kerberos master key:

    Current Kerberos master key version is 1.

    Master key entered.  BEWARE!
    Previous or default values are in [brackets] ,
    enter return to leave the same, or new value.

    Principal name: jane
    Instance:

    <Not found>, Create [y] ? y

    Principal: jane, Instance: , kdc_key_ver: 1
    New Password:                <---- hier een veilig wachtwoord invullen
    Verifying password

    New Password:                <---- hier het wachtwoord nogmaals invoeren
    Principal's new key version = 1
    Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
    Max ticket lifetime (*5 minutes) [ 255 ] ?
    Attributes [ 0 ] ?
    Edit O.K.
    Principal name:                   <---- hier niks invoeren stopt het programma

## 14.7.6. Alles testen

Eerst moeten de Kerberos daemons gestart worden. Als de juiste wijziging in `/etc/rc.conf` zijn gemaakt, dan gebeurt dit automatisch na een herstart. Dit hoeft alleen ingesteld te worden op de Kerberos server. Kerberos cliënten vinden automatisch wat ze zoeken in de map `/etc/kerberosIV`.

    # kerberos &
    Kerberos server starting
    Sleep forever on error
    Log file is /var/log/kerberos.log
    Current Kerberos master key version is 1.

    Master key entered. BEWARE!

    Current Kerberos master key version is 1
    Local realm: EXAMPLE.COM
    # kadmind -n &
    KADM Server KADM0.0A initializing
    Please do not use 'kill -9' to kill this job, use a
    regular kill instead

    Current Kerberos master key version is 1.

    Master key entered.  BEWARE!

Nu kan kan er getest worden of met het commando `kinit` een ticket (kaartje) gekregen kan worden voor het ID `jane` dat net is aangemaakt:

    % kinit jane
    MIT Project Athena (grunt.example.com)
    Kerberos Initialization for "jane"
    Password:

Met `klist` kan gecontroleerd worden of de tokens er echt zijn:

    % klist
    Ticket file:    /tmp/tkt245
    Principal:      jane@EXAMPLE.COM

      Issued           Expires          Principal
    Apr 30 11:23:22  Apr 30 19:23:22  krbtgt.EXAMPLE.COM@EXAMPLE.COM

Nu wordt het wachtwoord gewijzigd met passwd(1) om te controleren of de kpasswd daemon autorisatie krijgt van de Kerberos database:

    % passwd
    realm EXAMPLE.COM
    Old password for jane:
    New Password for jane:
    Verifying password
    New Password for jane:
    Password changed.

## 14.7.7. `su` rechten toewijzen

Kerberos biedt mogelijkheid iedere gebruiker die `root`rechten nodig heeft zijn eigen afzonderlijke su(1) wachtwoord te geven. Nu wordt een ID toegevoegd dat geautoriseerd is om su(1) te gebruiken naar `root`. Dit wordt geregeld door een instantie van `root` te verbinden met een principal. Met `kdb_edit` kan `jane.root` gemaakt worden in de Kerberos database:

    # kdb_edit
    Opening database...

    Enter Kerberos master key:

    Current Kerberos master key version is 1.

    Master key entered.  BEWARE!
    Previous or default values are in [brackets] ,
    enter return to leave the same, or new value.

    Principal name: jane
    Instance: root

    <Not found>, Create [y] ? y

    Principal: jane, Instance: root, kdc_key_ver: 1
    New Password:                    <---- hier een veilig wachtwoord invullen
    Verifying password

    New Password:                    <---- hier nogmaals het wachtwoord invullen

    Principal's new key version = 1
    Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
    Max ticket lifetime (*5 minutes) [ 255 ] ? 12 <--- Keep this short!
    Attributes [ 0 ] ?
    Edit O.K.
    Principal name:                         <---- hier niks invullen stopt het programma

Een lijst van de tokens kan bevestigen als alles werkt zoals verwacht:

    # kinit jane.root
    MIT Project Athena (grunt.example.com)
    Kerberos Initialization for "jane.root"
    Password:

Nu dient de gebruiker toegevoegd te worden aan het bestand `.klogin` van `root`:

    # cat /root/.klogin
    jane.root@EXAMPLE.COM

Na een su(1):

    % su
    Password:

kan de lijst met tokens bekeken worden:

    # klist
    Ticket file:    /tmp/tkt_root_245
    Principal:      jane.root@EXAMPLE.COM

      Issued           Expires          Principal
    May  2 20:43:12  May  3 04:43:12  krbtgt.EXAMPLE.COM@EXAMPLE.COM

## 14.7.8. Andere commando's gebruiken

In een eerder voorbeeld is een principal met de naam `jane` gemaakt met een instantie `root`. Dit was gebaseerd op een gebruiker met dezelfde naam als de principal en dit is de standaard binnen Kerberos: een `<principal>.<instantie>` in de vorm van `<gebruikersnaam>.` `root` staat die `<gebruikersnaam>` het gebruik van su(1) naar `root` toe als de benodigde instellingen in het bestand `.klogin` in de home directory van `root` zijn gemaakt:

    # cat /root/.klogin
    jane.root@EXAMPLE.COM

Zo werkt het ook als een gebruiker in zijn eigen home directory iets als volgt heeft opgenomen:

    % cat ~/.klogin
    jane@EXAMPLE.COM
    jack@EXAMPLE.COM

Hierdoor mag iedereen die zich in de wereld `EXAMPLE.COM` heeft geautenticeerd als `jane` of `jack` (via `kinit`, zie boven) bij `jane`'s account of de bestanden op dit systeem (`grunt`) met rlogin(1), rsh(1) of rcp(1).

Nu meldt bijvoorbeeld `jane` zich aan op een ander systeem met Kerberos:

    % kinit
    MIT Project Athena (grunt.example.com)
    Password:
    % rlogin grunt
    Last login: Mon May  1 21:14:47 from grumble
    Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
            The Regents of the University of California.   All rights reserved.

    FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995

Of `jack` meldt zich aan op `jane`'s account op dezelfde machine (`jane` heeft het bestand `.klogin` ingesteld zoals hierboven en de beheerder van Kerberos heeft een principal jack aangemaakt zonder instantie):

    % kinit
    % rlogin grunt -l jane
    MIT Project Athena (grunt.example.com)
    Password:
    Last login: Mon May  1 21:16:55 from grumble
    Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
            The Regents of the University of California.   All rights reserved.
    FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995

Terug | Begin | Volgende
TCP Wrappers | Omhoog | Kerberos5

Deze en andere documenten kunnen worden gedownload van ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.

Lees voor vragen over FreeBSD de documentatie alvorens contact te zoeken <questions@FreeBSD.org>.
Vragen over deze documentatie kunnen per e-mail naar <doc@FreeBSD.org>.