In diesem Artikel wird beschrieben, wie mithilfe eines OmniSwitches, OV2500/UPAM und einem freeradius ein Alcatel IP Telefon (8088) per 802.1x mit Zertifikat (EAP-TLS) sicher ins Netzwerk eingebunden wird.

Zuerst installieren wir den freeradius auf unserem Linux System Debian 10.6. Eine Internetverbindung für das System wäre vom Vorteil.

apt-get install freeradius (freeradius 3.0)
apt-get install vim (Editor, um Dateien anzupassen)

Sobald die Installation erfolgreich druchgelaufen ist, kann mit der Konfiguration des freeradius begonnen werden. Es müssen Dateien im freeradius angepasst werden und die Zertifikatskette muss erstellt werden.

In der Datei „clients.conf“ müssen die sogennaten NAS-Geräte eingetragen werden, da diese auf den Radius-Server zugreifen. (z.B. Switche, APs, etc…) In unserem Fall muss hier der OV2500/UPAM hinterlegt werden, da dieser als Radius-Proxy-Server fungiert.

# IP Subnetz/Host von OmniVista 2500 UPAM
client ov2500-upam-radius {
          ipaddr          = 192.168.26.10
          secret          = Alcatel01!
}

In der Datei können die direkten Benutzerkonten hinterlegt werden. Bei unserem Fall gibt es auf den Alcatel-IP-Telefonen einen Standard-User namens „ALCIPT“. Diesen hinterlegen wir in der Datei „users“.

# Alcatel-IP-Telefon Standard-User
ALCIPT  Auth-Type := EAP, Cleartext-Password := "password"

Da wir unsere IP-Telefone per EAP-TLS authentifizieren wollen, werden Zertifikate benötigt. Diese können mithilfe von „openssl“ auf dem Debian erstellt werden. In unserem Fall benutzen wir eine Zertifikatskette aus eigenen Zertifikaten und den öffentlichen Zertifikaten der Alcatel-IP-Telefone.

Wie die Zertifikatskette mit eigenen Zertifikaten und den öffentlichen Zertifikaten erstellt wird, ist in der Dokumentation „IP-PCX Networks“ unter Punkt 7.9.2 beschrieben. Auch diese Dokumentation kann im Alcatel Business Portal heruntergeladen werden. "IP-PCX Networks" aus dem Business Partner Portal

Nachdem, wie in der Dokumentation beschrieben die openssl.cnf kopiert wurde (cp /etc/ssl/openssl.cnf openssl.cnf), muss die kopierte Datei angepasst werden.

Ausschnitt aus der openssl.cnf:

[ CA_default ]

dir             = /etc/freeradius/3.0/certs/CA
certs           = $dir/certs
crl_dir         = $dir/crl
database        = $dir/index.txt
#unique_subject = no
new_certs_dir   = $dir/newcerts
certificate     = $dir/cacerts.pem
serial          = $dir/serial 
crlnumber       = $dir/crlnumber
crl             = $dir/crl.pem
private_key     = $dir/private/cakey.pem
x509_extensions = usr_cert

Wenn die Datei angepasst ist, kann in der Dokumentation mit Punkt 7.9.3 „Generating Root and Server Certificates“ weitergemacht werden. In dem Punkt geht es um die Erstellung unserer eigenen Zertifikate. Anschließend werden unter Punkt 7.9.4 „Registering Alcatel-Lucent Certificates“ die eben erstellen Zertifikate mit den Alcatel-Zertifikaten gekoppelt. Dazu sollten die öffentlichen Alcatel-Zertifikate heruntergeladen sein.

Die öffentlichen Alcatel-Zertifikate müssen dann auf den freeradius kopiert werden. Ich benutze dazu einen WINSCP und kopiere die entpackten Alcatel-Zertifikate in das Verzeichnis /tmp/ALE_Certificate

Mit dem folgenden Befehl werden nun meine eigenen Zertifikate mit den Alcatel-Zertifikaten verknüpft.

cat /etc/freeradius/3.0/certs/CA/cacert.pem /tmp/ALE_Certificate/AIPT_BASE64/aipt*.pem /tmp/ALE_Certificate/Alcatel_Enterprise_Solutions.pem /tmp/ALE_Certificate/Alcatel_IP_Touch.pem >> /etc/freeradius/3.0/certs/CA/cacerts.pem

Zu guter Letzt müssen wir im freeradius die Datei eap.conf anpassen. Dort müssen unsere erstellten Zertifikate hinterlegt werden.

tls-config tls-common {
                private_key_file = /etc/freeradius/3.0/certs/CA/radius-req.pem
                certificate_file = /etc/freeradius/3.0/certs/CA/radius-cert.pem
                ca_file = /etc/freeradius/3.0/certs/CA/cacerts.pem
                dh_file = ${certdir}/CA/dh1024.pem
                random_file = ${certdir}/CA/dh1024.pem

Die Konfiguration des freeradius sollte nun erledigt sein und man kann ihn starten.

/etc/init.d/freeradius start -> freeradius starten
/etc/init.d/freeradius stop -> freeradius stoppen
/etc/init.d/freeradius restart -> freeradius neustarten
/etc/init.d/freeradius debug -> freeradius debugging starten

Es macht am Anfang Sinn den freeradius im “Debug-Modus“ zu starten, da man dort Fehlermeldungen besser erkennt.

In meinem Fall konnte der freeradius nicht gestartet werden, da Berechtigungen für das Zertifikat „radius-req.pem“ gefehlt haben. Mit dem Befehl „chmod -R 644 etc/freeradius/3.0/certs/CA/radius-req.pem“ habe ich die Berechtigung angepasst. Anschließend konnte ich den freeradius starten.

Der OmniVista2500/UPAM bietet zwei Vorteile, die die Umstellung auf 802.1x erleichtert und die ich in diesem Beispiel nutze. Einmal die Umstellung der Ports auf den Switchen und desweiteren die Nutzung des UPAM-Moduls als Radius-Proxy.

Im OmniVista 2500 gibt es den UPAM (Unified Policy Authentication Manager) der als Radius-Proxy-Server genutzt werden kann.

Zuerst muss unter „Home→UPAM→Settings→External Radius“ der Radius-Server angelegt werden. In unserem Fall ist das der freeradius. Hier wird das Passwort benötigt, welches man im freeradius in der Datei „clients.conf“ hinterlegt hat.

Anschließend wird ein „AAA Server Profile“ angelegt, indem der UPAM als Primary Authentication- und Accouting Server eingetragen wird. Die „AAA Server Profile“ findet man unter „Unified Access → Unified Profile → Template → AAA Server Profile“.

Um mehrere Ports auf einmal umzustellen, ist es am einfachsten Profile im OV2500/ UPAM anzulegen. Dies erleichtert die Umstellung auf 802.1x.

Hier werden Profile erstellt, die später die Geräte zugewiesen bekommen. In unserem Fall bekommt das Alcatel-IP-Telefon bei erfolgreicher Authentifizierung das Profil „IPPhone_802.1x_Pass_VLAN26“ zugewiesen. Sollte bei einem Gerät die Authentifizierung fehlschlagen, bekommt es das Profil „Dummy_VLAN10“. Wie in meiner Namensbegebung zu erkennen ist, wird den Profilen beim Ausrollen auf dem Switch (Applpy to Device) ein VLAN zugewiesen. In dem Profil „IPPhone_802.1x_Pass_VLAN26“ aktivieren wir noch den „Mobile Tag Status“, damit unsere Telefone nachher über ein getaggtes VLAN laufen.

In diesem Profil wird angegeben wie ein Port authentifiziert werden soll und über welchen Authentication Server die Authentifizierung laufen soll. Desweitern hinterlegen wir hier ein „Default Access Role Profile“, welches die Geräte zugewiesen bekommen, bei denen einen Authentifizierung fehlschlägt. In unserem Fall aktivieren wir 802.1x und wählen als „AAA Server Profile“ das oben erstellt AAA Server Profile „UPAM“ aus. Unter dem Punkt „No Auth/Failure/Alternate“ tragen wir als „Deafult Access Role Profile“ Dummy_VLAN10 ein.

Dieses „Access Auth Profile“ kann nun durch „Apply to Devices“ auf ein Switch und den dazugehörigen Ports ausgerollt werden. In diesem Fall haben wir den Swtich 192.168.26.100 und den Port 1/1/6.

Im UPAM müssen ebenfalls Profile angelegt werden. Es wird zuerst eine Authentifizierungsrichtlinie (Access Policy) erstellt, die dann auf eine Authentifizierungs-Strategie (Authentication Strategy) weist.

In der „Access Policy“ werden Attribute festgelegt, um die Geräte/User/Telefone einer „Authentication Strategy“ zuzuordnen. In unserem Fall benutzen wir das Advanced Attribute „User-Name“ und wählen aus, dass wenn ein „User-Name“ mit dem Wert „ALCIPT“ kommt, dann benutze die Authentication Strategy „802.1x_IPPhone_Strategy“. Wie bereits weiter oben im Doku-Wiki-Artikel erklärt, benutzt jedes Alcatel-IP-Telefon diesen Standardbenutzer.

In der Authentication Strategy habe ich die Möglichkeit anzugeben, über welchen Authentication Server der Client authentifiziert werden soll und was bei einer erfolgreichen Authentifizierung passieren soll. Wir nehmen für unsere Authentifizierung der IP-Telefon unseren freeradius als „External Radius“ und wählen als Default Access Role Profile „IPPhone_802.1x_Pass_VLAN26“ aus.

In dem wir die Profile mit „Apply to Device“ auf den OmniSwitch ausrollen, ändert sich die Konfiguration des Switches. Hier ein Auszug der wichtigsten CLI-Zeilen:

! DA-UNP:
unp profile "IPPhone_802.1x_Pass_VLAN26"
unp profile "IPPhone_802.1x_Pass_VLAN26" map vlan 26

unp port-template 802.1x_IPPhone_UPAM direction both aaa-profile "UPAM" ap-mode admin-state enable
unp port-template 802.1x_IPPhone_UPAM 802.1x-authentication

unp port 1/1/6 port-type bridge
unp port 1/1/6 port-template 802.1x_IPPhone_UPAM

! AAA:
aaa radius-server "UPAMRadiusServer" host 192.168.26.10 hash-key "52F5CDE6C8AD17D47FCA7E4815BF1B0A" hash-salt "7D535ECA7891630634B8C799636F2843C85A2556A68C8AC5034BD838D816844D" retransmit 2 timeout 5 auth-port 1812 acct-port 1813 vrf-name default

aaa profile "UPAM"
aaa profile "UPAM" device-authentication mac "UPAMRadiusServer"
aaa profile "UPAM" accounting mac "UPAMRadiusServer"
aaa profile "UPAM" device-authentication 802.1x "UPAMRadiusServer"
aaa profile "UPAM" accounting 802.1x "UPAMRadiusServer"
aaa profile "UPAM" device-authentication captive-portal "UPAMRadiusServer"
aaa profile "UPAM" accounting captive-portal "UPAMRadiusServer"

Damit das Alcatel-IP-Telefon einen VLAN-Tag sendet, können über die MED-Erweiterung des Link Layer Discovery Protocols (LLDP) bestimmte Konfigurationen automatisiert vom OmniSwitch auf das angeschlossene Endgerät übertragen werden.

! LLDP:
lldp network-policy 1 application voice vlan 26 l2-priority 5 dscp 46
lldp nearest-bridge chassis tlv med network-policy enable
lldp chassis med network-policy 1