Ändern der CUCM-Serverdefinition von IP-Adresse oder Hostname in FQDN-Format

Einführung

In diesem Dokument wird beschrieben, wie Sie die Definition des Cisco Unified Communications Manager (CUCM)-Clusters vom IP-Adressen- oder Hostnamenformat in ein FQDN-Format (Fully Qualified Domain Name) ändern.

Hintergrund

CUCM hat die Möglichkeit, festzulegen, ob IP-Adressen oder DNS (Domain Name Service) für die Kommunikation zwischen Knoten und Endpunkten verwendet werden sollen.

Für Systeme vor 10.x wurde empfohlen, die DNS-Abhängigkeit nicht zu verwenden, es sei denn, dies ist aufgrund bestimmter Designs oder Anforderungen erforderlich.

Ab CUCM 10.x aufgrund der engen Integration zwischen CUCM und Cisco Unified Communications Manager IM & Presence Service (IM&P) hat sich diese Empfehlung geändert. Obwohl die Verwendung von DNS in grundlegenden IP-Telefoniebereitstellungen noch akzeptabel ist, wurde die Verwendung vollqualifizierter Domänennamen anstelle von IP-Adressen zur Anforderung, dass einige Schlüsselfunktionen funktionieren:

• Single Sign-On (SSO)
• Jabber-Bereitstellungen, für die eine automatische Benutzerregistrierung erforderlich ist
• Zertifikatsbasierte Sicherheit für sichere Signalisierung und Medien

Um eine sichere Verbindung einzurichten, muss ein Client die Identität des Servers überprüfen, der das Zertifikat vorlegt.

Der Client führt die Validierung in zwei Schritten durch: 

• Im ersten Schritt überprüft der Client, ob das Serverzertifikat vertrauenswürdig ist, indem er den Vertrauensspeicher überprüft. Wenn dieses Identitätszertifikat oder ein Zertifikat der Zertifizierungsstelle, das zum Signieren des Identitätszertifikats verwendet wurde, im Trusted Store des Clients vorhanden ist, gilt das Zertifikat als vertrauenswürdig.
• Im zweiten Schritt überprüft der Client die Identität des Servers im Zertifikat anhand der Identität des Servers in der lokalen Client-Konfiguration. Mit anderen Worten: Der Client überprüft, ob Der Servername im Zertifikat und die Verbindungsanforderung sind identisch.

Die Identität des Servers im Zertifikat wird vom Common Name-Attribut (CN) oder dem Subject Alternative Name (SAN)-Attribut des empfangenen Zertifikats abgeleitet.

Hinweis: SAN hat, sofern vorhanden, Vorrang vor CN.

Die Identität des Servers in der lokalen Konfiguration wird von der Gerätekonfigurationsdatei abgeleitet, die über das Trivial File Transfer Protocol (TFTP) und/oder von Benutzerdatendienste (UDS)-Interaktionen heruntergeladen wird. Die TFTP- und UDS-Dienste leiten diese Konfiguration von der Datenbank-Prozessknotentabelle ab. Sie kann auf der Webseite CM Administration > System > Server konfiguriert werden. 

Verwechseln Sie nicht die Seite CM Administration > System > Server, auf der Server definiert werden, mit OS Administration > Settings > IP Ethernet, auf der Netzwerkparameter für Server konfiguriert werden. Die Parameter auf der Seite "OS Administration" (Betriebssystemverwaltung) wirken sich auf die tatsächliche Netzwerkkonfiguration des Servers aus. Die Änderung des Hostnamens oder der Domäne führt zur Regenerierung aller Zertifikate für den Knoten. Die Einstellungen auf der Seite "CM Administration" definieren, wie sich CUCM über Konfigurationsdateien oder UDS an Endpunkte meldet. Die Änderung dieser Einstellung erfordert keine Erneuerung der Zertifikate. Diese Einstellung muss mit einem der folgenden Netzwerkparameter des Knotens übereinstimmen: IP-Adresse, Hostname oder FQDN
   
Beispielsweise stellt Ihr Endgerät eine sichere Verbindung mit server.mydomain.com her. Es prüft das empfangene Zertifikat und prüft, ob "server.mydomail.com" in diesem Zertifikat als CN oder SAN vorhanden ist. Wenn die Prüfung nicht erfolgreich ist, schlägt die Verbindung entweder fehl, oder ein Endbenutzer erhält eine Popup-Meldung, in der er aufgefordert wird, ein nicht vertrauenswürdiges Zertifikat zu akzeptieren, abhängig von der Client-Funktionalität. Da CNs und SANs in Zertifikaten in der Regel das FQDN-Format haben, müssen Sie die Serverdefinition von IP-Adresse in das FQDN-Format ändern, um Popups oder Verbindungsausfälle zu vermeiden.

Voraussetzungen

Anforderungen

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf den folgenden Software- und Hardwareversionen:

• CUCM 10.X oder höher

Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen. 

Vorgehensweise

Aufgaben vor dem Ändern

Es wird dringend empfohlen, vor der Konfiguration sicherzustellen, dass die Voraussetzungen erfüllt sind.

Schritt 1: Überprüfen Sie die DNS-Konfiguration.

Führen Sie diese Befehle über die CUCM-CLI aus, um sicherzustellen, dass der DNS-Dienst konfiguriert ist und FQDN-Einträge für Knotennamen sowohl lokal als auch extern aufgelöst werden können.

admin:show network eth0
<omitted for brevity>

DNS
Primary : 10.48.53.194 Secondary : Not Configured
Options : timeout:5 attempts:2
Domain : mydomain.com
Gateway : 10.48.52.1 on Ethernet 0

    

admin:utils network host cucm105pub.mydomain.com
Local Resolution:
cucm105pub.mydomain.com resolves locally to 10.48.53.190

External Resolution:
cucm105pub.mydomain.com has address 10.48.53.190
admin:

  

Schritt 2: Netzwerkdiagnosetest.

Stellen Sie sicher, dass der Netzwerkdiagnosetest mit diesem CLI-Befehl bestanden wird.

  

admin:utils diagnose module validate_network

Log file: platform/log/diag3.log

Starting diagnostic test(s)
===========================
test - validate_network : Passed

Diagnostics Completed

  

Schritt 3: DHCP-Konfiguration für Endpunkte

Stellen Sie sicher, dass die erforderliche Dynamic Host Configuration Protocol (DHCP)-Konfiguration hinzugefügt wird, damit die registrierten Telefone die DNS-Auflösung durchführen können.

Schritt 4: Datenbankreplikation.

Stellen Sie sicher, dass die CUCM-Datenbankreplikation funktioniert. Der Cluster-Replikationsstatus muss für alle Knoten 2 sein.

admin:utils dbreplication runtimestate
<output omitted for brevity>
Cluster Detailed View from cucm105pub (2 Servers):
                             PING     DB/RPC/   REPL.   Replication   REPLICATION SETUP
SERVER-NAME   IP ADDRESS     (msec)   DbMon?    QUEUE   Group ID      (RTMT) & Details
-----------   ----------     ------   -------   -----   -----------   ------------------
cucm105pub    10.48.53.190   0.027    Y/Y/Y     0       (g_2)         (2) Setup Completed
cucm105sub1   10.48.53.191   0.292    Y/Y/Y     0       (g_3)         (2) Setup Completed

  

Schritt 5: Sicherung.

Führen Sie die Sicherung des Cisco Disaster Recovery System (DRS) für die aktuelle Konfiguration aus. 

Konfiguration

Ändern Sie die IP-Adresse (oder den Hostnamen) von der IP-Adresse in das FQDN-Format auf der Webseite zur Cisco Unified CM-Administration.

Schritt 1: Navigieren Sie zu System > Server, und ändern Sie das Feld Hostname/IP-Adresse von der IP-Adresse in FQDN.

Der Hostname kann aus dem Anzeigestatus abgerufen werden, und die Domäne kann aus der Befehlsausgabe Netzwerk eth0 abgerufen werden.

Schritt 2: Wiederholen Sie Schritt 1 für alle aufgeführten CUCM-Server.

Schritt 3: Um Konfigurationsdateien zu aktualisieren, starten Sie den Cisco TFTP-Dienst auf allen CUCM-Knoten neu.

Schritt 4: Um aktualisierte Konfigurationsdateien auf die registrierten Geräte zu übertragen, starten Sie den Cisco Callmanager-Service auf allen CUCM-Knoten neu.

Überprüfen

Stellen Sie sicher, dass alle Endpunkte erfolgreich bei CUCM-Knoten registriert wurden.

Dies kann mithilfe der RTMT-Hilfe (Real-Time Monitoring Tool) erreicht werden.

Falls eine Integration mit anderen Servern über SIP, SCCP und MGCP-Protokolle erfolgt, ist möglicherweise eine Konfiguration auf den Servern von Drittanbietern erforderlich.

Stellen Sie sicher, dass die Änderung erfolgreich an alle Knoten im CUCM-Cluster weitergeleitet wird und die Ausgabe für alle Knoten gleich ist.

Führen Sie diesen Befehl auf allen Knoten aus.

admin:run sql select name,nodeid from processnode
name                     nodeid
======================== ======
EnterpriseWideData       1
cucm105pub.mydomain.com  2
cucm105sub1.mydomain.com 3
imp105.mydomain.com      7

  

Zugehörige Informationen

• Fehlerbehebung bei der CUCM-Datenbankreplikation in Linux Appliance-Modell