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.

Das erstelle User-Zertifikat „caroot.p12“ muss in einem Webserver zur Verfügung gestellt werden, damit es das Telefon herunterladen kann. Unser User-Zertifikat befindet sich in dem Ordner „/etc/freeradius/3.0/certs/CA/“.

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

Auf dem Alcatel-IP-Telefon müssen Einstellungen getätigt werden, damit das Telefon das Zertifikat von einem Web-Server herunterlädt und sich mit dem heruntergeladenen Zertifikat im Netzwerk authentifiziert.

Damit das IP-Telefon das Zertifikat von einem Webserver herunterzuladen kann, müssen am Telefon manuelle Änderungen durchgeführt werden. Zuerst starten wir das Telefon. Wenn im Display des Telefons Punkt 2/5 „network setup“ steht, kann mithilfe von „i + #“ in das Konfigurationsmenü des Telefons gesprungen werden. Um den Webserver und das Verzeichnis des Webservers anzugeben, muss in das Menü „Certificate → Get Certificate“ die IP-Adresse, der Port, das Verzeichnis und das Zertifikat angegeben werden.

Anschließend wird ein Passwort gefordert, dass ist das Passwort, welches wir beim erstellen des Zertifikates vergeben haben.

Wenn alles richtig gemacht wurde, sollte das Zertifikat erfolgreich auf dem Telefon installiert sein.

Im Grundmenü (Punkt 2/5 „network setup“ | i+#) findet man den Punkt „802.1x. Darunter befinden sich die Einstellungen, in welcher Form sich das Telefon mit 802.1x authentifizieren soll. In unserem Fall gehen wir auf „TLS Profile“ und aktivieren „Use 802.1x TLS“.

Anschließend bestätigt man die Eingabe und das Telefon macht einen Neustart.

Da wir den OV2500 als Radius-Proxy nutzen, können wir dort überprüfen, ob das IP-Telefon richtig authentifiziert ist. Den Authentication Record befindet sich unter dem Punkt „UPAM → Authentication“. Im Suchfeld kann man nach dem Account Name „ALCIPT“ suchen.

Im Switch haben wir folgende Möglichkeiten zu kontrollieren, ob das Telefon erfolgreich authentifiziert ist oder ob es zu Fehlern gekommen ist.

OS6465T-Home --> show unp user details port 1/1/6
Port: 1/1/6
    MAC-Address: 00:80:9f:a0:38:6a
      SAP                             = -,
      Service ID                      = 0,
      VNID                            = 0 ( 0. 0. 0),
      VPNID                           = 0 ( 0. 0. 0),
      ISID                            = 0,
      Access Timestamp                = 12/18/2020 14:17:25,
      User Name                       = ALCIPT,
      IP-Address                      = 192.168.26.80,
      Vlan                            = 26,
      Authentication Type             = 802.1x,
      Authentication Status           = Authenticated,
      Authentication Failure Reason   = -,
      Authentication Retry Count      = 0,
      Authentication Server IP Used   = 192.168.26.10,
      Authentication Server Used      = UPAMRadiusServer,
      Server Reply-Message            = -,
      Profile                         = IPPhone_802.1x_Pass_VLAN26,
      Profile Source                  = Auth - Pass - Server UNP,
      Profile From Auth Server        = IPPhone_802.1x_Pass_VLAN26,
      Session Timeout                 = 0,
      Classification Profile Rule     = -,
      Role                            = -,
      Role Source                     = -,
      User Role Rule                  = -,
      Restricted Access               = No,
      Location Policy Status          = -,
      Time Policy Status              = -,
      QMR Status                      = Passed,
      Redirect Url                    = -,
      SIP Call Type                   = Not in a call,
      SIP Media Type                  = None,
      Applications                    = None,
      Encap Value                     = -,
      Rule ID                         = -,

Total users : 1

Eine weitere Möglichkeit ist der Debug-Modus im Freeradius, den ich weiter oben schon beschrieben habe.

Zusätzlich würde man im Authentication Record (OmniVista 2500) ebenfalls Fehler erkennen, falls die Authentifizierung fehlschlägt.

Um bei 100 Telefonen nicht manuell an jedem Telefon die Einstellungen zu tätigen, gibt es die Möglichkeit mit Hilfe eines TFTP-Servers die sogenannte „lanpbx.conf“ auf die Telefone zu bringen. In dieser „lanpbx.conf“ sind dann die Informationen enthalten, welche zum Webserver führen (hier ist das Zertifikat abgelegt).

Hier ein Beispiel einer lanpbx.conf:

CERTSRV_IP=192.168.010.010 CERTSRV_PORT=8080 CERTSRV_PATH=/certserv