Anbinden eines Radius-Servers an LDAP und Kerberos Bis jetzt habe ich immer Artikel zum Thema OpenLDAP geschrieben, dabei ist die Anbindung von Diensten an den OpenLDAP immer recht kurz gekommen. In einer losen Reihenfolge möchte ich diese Lücke jetzt schließen, und nach und nach verschiedene Dienste an dennLDAP-Server anbinden. Dabei soll es nicht nur um die Anbindung an OpenLDAP gehen, sondern auch gleich um die Nutzung von Kerberos zur Authentifizierung. In einer OpenLDAP-Umgebung OHNE Kerberos ist immer nur ein "simple bind" möglich, das erfordert immer einen Benutzer und ein Passwort in Klartext in der Konfiguration des Dienstes. Der einzige "Schutz" der Anmeldedaten ist die Einschränkung der Rechte an den Konfigurationsdatei. Ein echter Schutz ist das aber nicht. Zusammen mit Kerberos ist aber eine wirksamer Schutz der Anmeldeinformationen möglich. Alle Dienste die kerberisiert werden können, sollten auch so konfiguriert werden. Anfangen möchte ich mit der Konfiguration des Radius-Servers mit "freeradius". Damit Sie die einzelnen Schritte einfacher nachvollziehen können und Kommandos und Listings direkt per copy&past übernehmen können, finden Sie das gesamte Vorgehen in dieser Textdatei. Hier geht es nicht um die vollständige Konfiguration des Radius-Server, sondern lediglich darum, zu zeigen, wie Sie den Radius-Server für die Suche nach Benutzen und Computern an den LDAP-Server anbinden und am Ende auch Kerberos für die Authentifizierung nutzen können. In der Testumgebung laufen zwei OpenLDAP-Server, die als Cluster mit einer Multiproviderreplikation eingerichtet sind. Zwei Kerberos-Server sind an den OpenLDAP angebunden. Auch die Replikation der beiden OpenLDAP-Server ist schon über Kerberos abgesichert. Die Konfiguration dazu finden Sie im OpenLDAP-Buch. Als Distribution kommt auf allen Systemen Debian 12 zu Einsatz. Als erstes werden die folgenden Pakete installiert: apt-get install freeradius freeradius-ldap freeradius-utils freeradius-krb5 Die gesamte Konfiguration des freeradius liegt im Verzeichnis /etc/freeradius/3.0. Um LDAPS nutzen zu können und um die Verbindung eines Clients zum späteren Radius-Server verschlüsselt aufbauen zu können, werden Zertifikate für den Radius-Server benötigt. Ich verwende hier die Serverzertifikate example-cert.pem, example-key.pem und cacert.pem. Diese Dateien werde in das Unterverzeichnis certs/ kopiert. Im Verzeichnis sites-enable/ kann die Datei "default" gelöscht werden. Die Datei "inner-tunnel" muss erhalten bleiben, da es sonst später beim Start zur Fehlermeldung "Failed to find 'Auth-Type EAP' section. Cannot authenticate users." kommt. Wenn "eap" nicht genutzt werden soll, kann auch einfach das Modul "eap" aus dem Verzeichnis "mods-enable/" gelöscht werden. Dann kann auch die Site "inner-tunnel" gelöscht werden. Da hier, im Moment, noch keine "eap" genutzt werden soll, werden jetzt die entsprechenden Dateien aus dem Verzeichnis "mods-enable/" gelöscht. Die Einrichtung von eap ist auch nicht Bestandteil dieses Artikels. Im nächsten Schritt richten Sie den Zugriff auf den LDAP ein. Das geht über das Modul "mods-available/ldap" um das Modul anschließend zu aktivieren, muss die Datei nach "mods-enable/" verlinkt werden. Wie Sie im folgenden Listing sehen, wird hier erst einmal die Authentifizierung via simple-bind eingerichtet. Änderungen an der Datei: ldap { ... server = 'ldaps://ldap-r01.example.net' server = 'ldaps://ldap-r02.example.net' identity = 'cn=admin,dc=example,dc=net' password = geheim base_dn = 'dc=example,dc=net' ... } tls { ... ca_file = ${certdir}/cacert.pem certificate_file = /etc/freeradius/3.0/certs/example-net-cert.pem private_key_file = /etc/freeradius/3.0/certs/example-net-key.pem random_file = /dev/urandom ... } Jetzt wird die eigene "site" erstellt und zwar im Verzeichnis "sites-available/" hier wird der Name "my_server" verwendet. Es folgt der Inhalt der Datei: --------- server my_server { listen { type = auth ipaddr = 192.168.56.47 port = 1812 } authorize { ldap if (ok || updated) { update control { Auth-Type := ldap } } } authenticate { Auth-Type LDAP { ldap } } } --------- Anschließend wird die Datei nach "site-enable/" verlinkt. In der Datei ./clients.conf wird jetzt noch der eigene Radius-Server eingetragen: --------- client radius-r01.example.net { ipaddr = radius-r01.example.net secret = Passw0rd } --------- Jetzt kann der Radius-Server das erste Mal im Testmodus gestartet werden. ACHTUNG bei Debian ist der Radius-Server bereits aktiv, daher müssen Sie den Dienst erst mit "systemctl stop freeradius.service" stoppen. Dann kann der Server mit "freeradius -X" im Debugmodus gestartet werden. Am Ende sollten die folgenden Zeilen stehen: --------- Listening on auth address 192.168.56.47 port 1812 bound to server my_server Listening on proxy address * port 33515 Ready to process requests --------- Startet der Server ohne Fehler im Debugmodus, können Sie den Dienst wieder über den Systemd starten und den ersten Test mit dem Zugriff auf den LDAP-Server wir folgt durchführen: --------- root@radius-r01:# radtest u1-verw geheim 192.168.56.47 1812 Passw0rd Sent Access-Request Id 93 from 0.0.0.0:44903 to 192.168.56.47:1812 length 77 User-Name = "u1-verw" User-Password = "geheim" NAS-IP-Address = 192.168.56.48 NAS-Port = 1812 Message-Authenticator = 0x00 Cleartext-Password = "geheim" Received Access-Accept Id 93 from 192.168.56.47:1812 to 192.168.56.47:44903 length 20 --------- Damit stellen Sie sicher, dass der Zugriff auf den LDAP-Server funktioniert. Erst Wenn das klappt, können Sie mit der Umstellung auf Kerberos fortfahren. Im nächsten Schritt soll die LDAP-Suche des Radius-Servers auf gssapi, also über Kerberos durchgeführt werden. Dazu wird als erstes das Pakete "libsasl2-modules-gssapi-mit" installiert. Auf dem Kerberos-Server wird ein Principal radius/radius-r01.example.net (als Principal für den Dienst) und ein Principal host/radius-r01.example.net (für den Host selber) erzeugt. Beide mit der Option "randkey". Anschließend wird für beide Principals eine eigene keytab-Datei erzeugt. Die host-keytab soll krb5.keytab heißen und wird in das Verzeichnis /etc kopiert. Die keytab-Datei für den Radius-Dienst heißt radius-radius-r01.keytab und wird auf dem Radius-Server in das Verzeichnis /etc/freeradius/3.0 kopiert. Die Datei muss die Rechte 600 haben und dem Benutzer "freerad" gehören. Ist das nicht der Fall, startet der Server später nicht. Für die Kommunikation mit dem Kerberos-Server wird noch die /etc/krb5.conf vom Kerberos-Server auf den Radius-Server kopiert. Es folgt der Inhalt der Datei: -------------- [libdefaults] default_realm = EXAMPLE.NET [realms] EXAMPLE.NET = { admin_server =kerberos-r01.example.net } [domain_realm] .example.net = EXAMPLE.NET [logging] kdc = FILE:/var/log/kdc.log admin_server = FILE:/var/log/kadmind.log default = SYSLOG:NOTICE:DAEMON -------------- Zu Testzwecken kann noch das Paket "ldap-utils" und "krb5-user" installiert werden. In diesen Paketen befinden sich die benötigten Kommandos um den LDAP-Server und den Kerberos-Server testen zu können. Damit die LDAP-Kommandos auch den richtigen LDAP-Server ansprechen können muss noch die Datei /etc/ldap/ldap.conf wie folgt angepasst werden: -------------- # # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. #BASE dc=example,dc=com #URI ldap://ldap.example.com ldap://ldap-provider.example.com:666 BASE dc=example,dc=net URI ldaps://ldap-r01.example.net ldaps://ldap-r02.example.net #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never # TLS certificates (needed for GnuTLS) TLS_CACERT /etc/freeradius/3.0/certs/cacert.pem TLS_REQCERT demand -------------- Jetzt kann als erstes getestet werden, ob eine Kerberos-Authentifizierung mit der Keytabdatei des Dienstes möglich ist. Das geschieht mit dem Kommando: -------------- root@radius-r01:~# kinit -k -t /etc/freeradius/3.0/radius-radius-r01.keytab radius/radius-r01.example.net root@radius-r01:/etc/freeradius/3.0# klist Ticketzwischenspeicher: FILE:/tmp/krb5cc_0 Standard-Principal: radius/radius-r01.example.net@EXAMPLE.NET Valid starting Expires Service principal 31.10.2023 19:11:25 01.11.2023 05:11:25 krbtgt/EXAMPLE.NET@EXAMPLE.NET erneuern bis 01.11.2023 19:11:25 -------------- Bevor der erste Zugriff auf den LDAP-Server getestet werden kann, sorgen Sie noch dafür, dass der Kerberos-Principal für den Radius-Server über eine ACL die entsprechenden Rechte erhält. Da es sich bei dem Principal nicht um ein Benutzerobjekt handelt, sondern nur um einen Kerberos-Principal tragen Sie den folgenden DN in Ihre entsprechende ACL ein: -------------- by dn.exact=uid=radius/radius-r01.example.net,cn=gssapi,cn=auth read -------------- Ein "ldapwhoami" sollte das folgende Ergebnis zeigen: -------------- root@radius-r01:/etc/freeradius/3.0# ldapwhoami SASL/GSSAPI authentication started SASL username: radius/radius-r01.example.net@EXAMPLE.NET SASL SSF: 256 SASL data security layer installed. dn:uid=radius/radius-r01.example.net,cn=gssapi,cn=auth -------------- Erst wenn das klappt, kann mit der Konfiguration weitergemacht werden. Sollten Sie weiterhin nach einem Passwort gefragt werden, prüfen Sie als erstes, ob Sie das Paket "libsasl2-modules-gssapi-mit" installiert haben. Jetzt wird das Modul "ldap" von Radius, im Abschnitt "SASL parameters to use for admin binds" wie folgt angepasst: -------------- ldap { ... # identity = 'cn=admin,dc=example,dc=net' # password = geheim ... } ... sasl { ... # SASL mechanism mech = 'gssapi' # SASL authorisation identity to proxy. # proxy = 'autz_id' # SASL realm. Used for kerberos. realm = 'example.net' } -------------- Hier ist dem Hinweis: -------------- At a minimum you probably want to set KRB5_CLIENT_KTNAME. -------------- unbedingt zu folgen, denn ohne diese Variable wird die keytab-Datei nicht gefunden. Ohne die Variable startet der freeradius zwar und es wird auch im Log angezeigt das die Datei genutzt wird, zusammen mit dem entsprechenden Principal, aber die spätere Suche nach Benutzern funktioniert nicht. Am besten wird die Variable in die Datei /etc/freeradius/3.0/radiusd.conf wir folgt eingetragen: -------------- ENV{ ... KRB5_CLIENT_KTNAME=/etc/freeradius/3.0/radius-radius-r01.keytab ... } -------------- Jetzt fehlt noch das Modul "krb5". Dazu wird die Datei "mods-available/krb5" wie folgt angepasst: -------------- keytab = /etc/freeradius/3.0/radius-radius-r01.keytab service_principal = radius/radius-r01.example.net -------------- In manchen Anleitungen finden Sie den Hinweis, dass Sie die Variable in die Datei "/etc/default/freeradius" eintragen sollen, das funktioniert auch, habt aber einen Nachteil. Es lässt sich so zwar der Server starten und auch die Suche funktioniert, aber der Debugmodus kann so nicht genutzt werdne. Denn die Datie "/etc/default/freeradius" wird nur beim Starten des Dienst über den Systemd ausgelesen. Tragen Sie die die Variable aber in die Konfigurationsdatei des freeradius ein, wird auch im Debugmodus die Variable gelesen und der Debugmodus ist weiterhin nutzbar. Und anschließend durch die Verlinkung nach mods-enabled aktiviert. Jetzt kann der freeradius neu gestartet werden. Im Log des LDAPs tauchen beim Start einige Fehler mit der Nummer "err=14" auf. Das ist aber normal, den der freeradius führt eine "challange respons" Anmeldung aus und "probiert" alle Möglichkeiten durch, bis dann die Richtige gefunden wird. Wichtig ist nur die Meldung: ------------- BIND dn="uid=radius/radius-r01.example.net,cn=gssapi,cn=auth" mech=GSSAPI bind_ssf=56 ssf=256 RESULT tag=97 err=0 qtime=0.000006 etime=0.000171 text= ------------- Eine weitere Fehlermeldung die auftaucht ist: ------------- SASL username: radius/radius-r01.example.net@EXAMPLE.NET SASL SSF: 256 SASL data security layer installed. SASL/GSSAPI authentication started ber_get_next failed, errno=11. ber_get_next failed, errno=11. ------------- Das ist auch kein Fehler, denn der Radius-server kann zu dem Zeitpunkt die GSSAPI noch nicht nutzen und versucht es immer wieder, bis es klappt. Nur wenn die Meldung dauerhaft angezeigt wird, liegt ein echter Fehler vor. Die Meldung kommt eigentlich vom OpenLDAP und nicht vom freeradius und wird in der Dokumentation vom OpenLDAP wie folgt beschrieben: ------------- This message is not indicative of abnormal behavior or error. It simply means that expected data is not yet available from the resource, in this context, a network socket. slapd(8) will process the data once it does becomes available. ------------- Jetzt ist der Radius-Server mit dem LDAP verbunden und die erste Authentifizierung kann wie folgt getestet werden: ------------- root@radius-r01:~# radtest u1-verw geheim 192.168.56.47 1812 Passw0rd Sent Access-Request Id 7 from 0.0.0.0:57077 to 192.168.56.47:1812 length 77 User-Name = "u1-verw" User-Password = "geheim" NAS-IP-Address = 192.168.56.47 NAS-Port = 1812 Message-Authenticator = 0x00 Cleartext-Password = "geheim" Received Access-Accept Id 7 from 192.168.56.47:1812 to 192.168.56.47:57077 length 20 ------------- Hier wurde nicht die Art der Authentifizierung der Benutzer angepasst, sondern lediglich die Art und Weise wie der Freeradius die Suche auf dem LDAP-Server durchführt. Schema für freeradius in OpenLDAP einbinden. Damit später die Benutzer und Hosts mit den entsprechenden Attributen versehen werden können, muss der LDAP-Server um die Schemata für freeradius erweitert werden. Dazu werden aus dem Verzeichnis "/usr/share/doc/freeradius/schemas/ldap/openldap/" die beiden Dateien "freeradius-clients.ldif" und "freeradius.ldif.gz" auf die LDAP-Server in das Verzeichnis "/opt/symas/etc/openldap/schema" kopiert. Die Datei "freeradius.ldif.gz" wird erst entpackt, danach können die beiden LDIF-Dateien eingespielt werden. Hier gibt es eine Replikation der Konfiguration, also ist es lediglich notwendig die Dateien auf einem der LDAP-Server einzuspielen. Jetzt steht der Einrichtung des Freeradius zusammen mit OpenLDAP und Kerberos nichts mehr im Wege.