Einleitung

In diesem Workshop zeigen wir, wie anynode im Microsoft Azure Active Directory als Anwendung registriert werden kann und wie das Azure Active Directory beim Routing im anynode verwendet wird.

In unserem Lernvideo werden wir die wesentlichen Konfigurationsschritte dafür beschreiben. Dies ermöglicht anynode, auf die Azure AD-bezogenen Benutzerinformationen zuzugreifen, indem ein Azure Dial String Directory erstellt wird. Dieses Verzeichnis wird bei verschiedenen Einstellungen und flexiblen Filterbedingungen mit allen abgerufenen Daten gefüllt. Um die Dial Strings und dazugehörenden Informationen abzurufen, werden die Daten zwischengespeichert und nach einem definierten Intervall abgerufen. Durch die zentrale Verwaltung im Azure Active Directory benötigt anynode keine Änderungen im Falle, wenn Benutzer gelöscht oder hinzugefügt werden.

Die neu erstellten Azure Dial String Directories können an die Routenfilter der Routing-Domänen von anynode gebunden werden. Ein Beispiel für eine Routing-Domäne wird später in diesem Lernvideo behandelt.

Anforderungen

Für eine erfolgreiche Registrierung von anynode und den Zugang zum Azure AD benötigen Sie die folgenden Voraussetzungen: 

• ein Azure AD-Mandanten, der der entsprechenden Office 365-Umgebung entspricht.
• eine Azure AD für Office 365-Lizenz.
• ein zusätzliches Zertifikat im Falle von Zertifikat-Pinning, wie später in diesem Lernvideo beschrieben
• eine anynode-Installation mit der zertifizierten Version 4.2 (oder höher).
• entsprechende Netzwerkzugriffs-, Netzwerk-Routing- und Administrationsrechte.
• Zugriff auf die installierte und konfigurierte VoIP-Umgebung.
• VoIP-Anmeldeinformationen für die beteiligten Nodes, um entsprechende Konfigurationen zu ermöglichen.

Azure AD Mandantenkonfigurationen für anynode

Für die Microsoft Azure Active Directory-Konfigurationen loggen Sie sich bitte entweder in das Azure Portal https://portal.azure.com/ oder das Azure Active Directory Verwaltungszentrum https://aad.portal.azure.com/.

App-Registrierung

[02:04 – Video Time-Code]

Um anynode als Anwendung im Azure AD-Mandanten zu registrieren, ändern Sie die Portalansicht in das Dialogfeld App-Registrierungen und klicken Sie auf Neue Registrierung. Als nächstes wird anynode_workshop_video_ad als Name eingegeben.

Bei den unterstützten Kontotypen wählen wir aus, dass nur TE-SYSTEMS GmbH als einzelner Mandant die Anwendung verwenden darf. Verwenden Sie diese Option, wenn Ihre Zielgruppe sich innerhalb Ihrer Organisation befindet. Alle Benutzer- und Gastkonten in Ihrem Verzeichnis können Ihre Anwendung oder API verwenden.  Anschließend starten Sie die Registrierung.

Die registrierte Anwendung für anynode wird nun mit einer Anwendungs-(Client-)ID erstellt und ist  mit der Directory (Mandaten)-ID verknüpft.

Bitte beachten Sie, dass beide IDs für die Einrichtung des anynode Azure Dial String Directory erforderlich sind. Das werden wir später in diesem Workshop noch zeigen.

Zertifikate und Geheimnisse

[03:23 – Video Time-Code]

Eine geheime Zeichenfolge, die von anynode für das „anynode_azure_ad“ verwendet wird, muss generiert werden. Diese Zeichenfolge kann als Passwort bezeichnet werden, das von der Anwendung zum Nachweis ihrer Identität verwendet wird.

Für diese Aufgabe wechseln Sie bitte in den „Zertifikaten und Geheimnisse“-Dialog. Wenn Sie dort angekommen sind, benutzen Sie die Schaltfläche „Neuer geheimer Clientschlüssel“. Im nächsten Dialogfeld Client-Geheimnisse fügen wir den frei wählbaren Namen hinzu.

Die Gültigkeit legen wir auf 1 Jahr fest. Wenn alles korrekt ist, erzeugen Sie den geheimen Clientschlüssel mit einem Klick auf „Hinzufügen“. Der neu erstellte geheime Clientschlüssel wird nun mit einem Zufallswert generiert.

Verwenden Sie die Funktion „In die Zwischenablage kopieren“, da dieser Wert verfügbar sein und als Client-Secret eingegeben werden muss.

Bitte beachten Sie, dass Sie den Wert des geheimen Clientschlüssels unmittelbar nach der Erstellung kopieren und sichern müssen. Es ist nicht möglich, dies zu einem späteren Zeitpunkt zu tun.

API-Berechtigungen

[04:30 – Video Time-Code]

Die neu erstellte und registrierte anynode-Anwendung (anynode_workshop_video_ad) wird zunächst nur mit den Rechten User.Read aktiviert. Es ist notwendig, zusätzliche delegierte und anwendungsbezogene Berechtigungen hinzuzufügen. In unserem Beispiel verwenden wir die referenzierte Microsoft Graph API Berechtigungen wie folgt:

Delegierte Berechtigungen

• Directory.AccessAsUser.All (Zugriff auf das Verzeichnis als angemeldeter Benutzer)
• Presence.Read.All (Lesen Sie die Präsenzinformationen aller Benutzer in Ihrer Organisation)

Anwendungsberechtigungen

• User.Read.All (Lesen Sie die vollständigen Profile aller Benutzer)
• Group.Read.All (Alle Gruppen lesen)
• Directoy.Read.All (Lesen von Verzeichnisdaten)

Bitte überprüfen Sie die Microsoft Graph-Berechtigungen-Referenz für Details, Hinweise und bekannte Fragen. Um Berechtigungen hinzuzufügen, wählen Sie die registrierte Anwendung von anynode aus und ändern Sie die Ansicht der API-Berechtigungen. Wählen Sie dort „Berechtigung hinzufügen“, dann Microsoft Graph aus der Liste Microsoft-APIs.

Wenn die API-Berechtigungen festgelegt sind, fahren Sie mit der Administrator-Zustimmung des Administrators für den Mandaten fort. Sollte die Schaltfläche „Administrator Zustimmung für den Mandanten erteilen“ ausgegraut sein, prüfen Sie die zugewiesenen Rollen des letzten Benutzers, der im Azure Portal angemeldet ist. Einige Rollen sind für dieses Benutzerkonto möglicherweise nicht festgelegt, z. B. die Privilegierte Rolle Administrator.

Sobald die Administrator Zustimmgung für den Mandanten erteilt worden ist, wird der Zustand in der Spalte „Status“ jetzt mit „Gewährt“ angezeigt.

API-Berechtigungen: Übersicht der Funktionen

Schauen wir uns jetzt noch mal die API-Berechtigungen genau an, wozu wir welches Recht für welche Funktion in anynode benötigen:

• Die DirectoryAccessAsUser.All and Presence.Read.All Berechtigungen werden für den Zugriff auf den „Presence“ Benutzerstatus benötigt. In diesem Fall muss die MS Graph Passwort-Methode für die Authentifizierung verwendet werden. Wenn diese Option verwendet wird, sollte ein extra User im User AD für diesen Zugriff angelegt werden. Dieser User benötigt, soweit bekannt, keine extra Rechte. Wir werden später bei der anynode-Konfiguration in diesem Lernvideo noch ein Beispiel für die MS Graph Passwort Methode Authentifizierung zeigen.
• Directory.Read.All benötigt man, wenn Lizenzinformationen mit in den Filter einfließen sollen.
• Group.Read.All:  Diese Recht wird benötigt, wenn auch noch die Gruppen und die Zugehörigkeiten der User zu den Gruppen mit in den Filter einfließen sollen.
• User.Read.All ist das Basis-Recht, welches man braucht, um auf Benutzerattribute (wie z.B Business Phone) der User zuzugreifen.

Grundsätzlich werden die delegierten Berechtigungen nur benötigt, wenn auch auf den User Status zugegriffen werden soll.

Konfiguration im anynode Frontend

[08:48 – Video Time-Code]

anynode Azure Dial String Directories

Für den Zugriff auf einen Microsoft Azure Active Directory-Mandanten über das Anynode-Frontend muss ein neues Azure Dial String Directory erstellt werden. Die Konfigurationsaufgaben dafür werden mit Hilfe des Directoy-Assistenten von anynode durchgeführt.

Add Directory

[09:15 – Video Time-Code]

Sie können ein neues Azure Dial String Directory mit Hilfe des anynode Scenario Wizards hinzufügen und erstellen.  Alternativ verwenden Sie die Schaltfläche „Add Directory“ innerhalb des Konfigurationsdialogs von Directories.

Creation Type

[09:24 – Video Time-Code]

Wählen Sie im ersten Dialogfeld „Creation Type“ „Create new Azure Dial String Directory“ aus und fahren Sie mit „Next“ fort.

Tenant ID

[09:32 – Video Time-Code]

Als nächstes geben Sie die ID des Directories (Tenant) ein. Dies ist die Tenant-ID Ihrer Microsoft Azure Active Directory-Umgebung. Die Tenant-ID kann im Azure Active Directory Portal gefunden werden.

Authentication

[09:53 – Video Time-Code]

Setzen Sie für die Authentifizierung den Azure AD-Mandantennamen mit einem verifizierten Domänen Namen ein. In diesem Beispiel verwenden wir „anynodelab.onmicrosoft.com“ und die Application-(Client-)ID mit dem dazugehörigem geheimen Clientschlüssel, hier „Secret“ genannt.

Name

[10:17 – Video Time-Code]

Geben Sie im letzten Dialogfeld des Assistenten den Namen für das neu erstellte Azure Dial String Directory ein und schließen Sie die Konfigurationen mit der Schaltfläche „Finish“ ab. Das Azure Dial String Directory wird nun erstellt. Stellen Sie sicher, dass Sie auf Commit klicken, um die neu erstellte Konfiguration endgültig abzuspeichern.

Network Security Profile

[10:42 – Video Time-Code]

Aufgrund aktualisierter Microsoft Azure-Cloud-Dienste und TLS-bezogener Änderungen, sind zusätzliche Konfigurationen erforderlich, wenn Zertifikat-Pinning verwendet wird. Dies kann den Import zusätzlicher Microsoft Azure TLS-Zertifikate für das Azure Dial String Directory von anynode und dessen Netzwerk-Sicherheitsprofil erfordern. Bitte lesen Sie den Artikel der Microsoft Techcommunity für vollständige Details.

https://techcommunity.microsoft.com/t5/internet-of-things/azure-iot-tls-changes-are-coming-and-why-you-should-care/ba-p/1658456

Auch wenn anynode und sein Assistent in der Regel die erforderlichen Zertifikate bereitstellt, sind sie möglicherweise nicht mehr gültig, da einige Sicherheitseinstellungen geändert wurden.

Lesen Sie das Kapitel „To minimize future code changes“ und laden Sie die „Microsoft Azure TLS Issuing“-Zertifikate herunter.

Trusted Peer Certificate hinzufügen

[11:47 – Video Time-Code]

Um das gewünschte Zertifikat hinzuzufügen, ändern Sie bitte die Ansicht auf das Network Security Profile von dem Azure Dial String-Directory. Klicken Sie im Abschnitt Peer-Zertifikate auf die Schaltfläche „Add“.

Im Video zeigen wir die Konfigurationsschritte des Imports des Microsoft Azure TLS Issuing CA 01 -Zertifikats. Sobald der Upload abgeschlossen ist, wird das Zertifikat und sein Status angezeigt. Schließen Sie den Import ab, indem Sie auf „Finish“ klicken.

Das importierte Zertifikat ist nun für das Azure Dial String Directory eingestellt.

Vergessen Sie nicht, den Import mit „Commit“ endgültig zu speichern.

Richtige IP für den Zugang zum Azure AD wählen

[12:28 – Video Time-Code]

Schließlich müssen Sie sicherstellen, dass die automatisch ausgewählte IP in Ihrer Netzwerk-Controller-Ansicht auf das öffentliche Internet zugreifen kann.

Öffnen Sie „Advanced Configuration“ und wählen Sie, falls erforderlich, die richtige IP-Adresse aus.

Testen der Konnektivität

[13:02 – Video Time-Code]

Für den Konnektivitätstest empfohlen wir, zuerst den OAuth Client Authorization Test durchzuführen und bei Erfolg anschließend den Microsoft Azure Active Directory-Konnektivitätstest.

Azure Dial String Directory Test

[13:19 – Video Time-Code]

Die folgende Liste zeigt das Suchergebnis. Maximal 100 Einträge werden angezeigt. Falls die Suche fehlschlägt, überprüfen Sie bitte die Azure AD-Konfigurationen und ob anynode als registrierte und autorisierte Anwendung alle erforderlichen Berechtigungen hat. Überprüfen Sie auch die Verfügbarkeit des Microsoft Azure TLS Issuing Zertifikats wie vorhin beschrieben.

Bei diesem Test, bei dem die Rufnummern abgerufen werden, wird eine weitere TLS-Verbindung zu einem anderen Server von Microsoft aufgebaut, und der präsentiert in der Regel ein anderes Zertifikat, welchem anynode eventuell nicht vertraut. Man kann sich dieses Zertifikat auch anzeigen lassen. Fügen Sie den Remote Host und den Port manuell ein.

anynode versucht dann, eine Verbindung zu graph.microsoft.com aufzubauen. Es besteht die Möglichkeit, dieses Zertifikat zu den Trusted Zertifikaten hinzuzufügen und das bisher in der Liste vorhandene Zertifikat zu ersetzen. Dabei wird dann auch gleichzeitig das mitgelieferte Route Zertifikat mit eingefügt.

Dashboard

[15:02 – Video Time-Code]

Das anynode Dashboard gibt einen Überblick über verschiedene Konfigurationszustände. Ein Doppelklick auf einen Eintrag öffnet ein neues Fenster mit einigen weiteren Details.

MS Graph Password Methode

[15:15 – Video Time-Code]

Wie vorhin bei den API-Berechtigungen schon erwähnt, müssen wir die „MS Graph Password“ Methode mit einer User Authentifizierung beim OAuth-Client auswählen, damit anynode Zugriff auf den „Presence User State“ erhält. Dafür empfehlen wir einen zusätzlichen Azure AD User. Nach dem derzeitigen Stand benötigt dieser User keine zusätzlichen Rechte. Ein Beispiel geben wir hier.

Routing Domain

[16:08 – Video Time-Code]

In unserem Beispiel verwenden wir eine Routing-Domäne mit einer Route-Filter-Relation, einem Azure Dial String Directory. Wenn ein Dial String nicht mit der Azure Dial String Directory-Anforderung mit ihren Bedingungen übereinstimmt, zum Beispiel bei dieser Nummer +4953639469931, wird der Anruf nicht an die Microsoft Teams Direct Node geroutet. Stattdessen wird er der zweiten Filterregel entsprechen, und der Anruf wird an den PBX-Node geroutet. Sie können das Azure Dial String Directory im Routenfilter auswählen.

Praxisbeispiel: Routing abhängig vom Benutzerstatus in Teams

[16:52 – Video Time-Code]

Jetzt möchten wir in unserem Praxisbeispiel ein Routing abhängig vom Microsoft Teams Benutzerstatus einrichten. Wenn ein Teams-Benutzer seinen Anwesenheitsstatus auf „nicht stören“ gesetzt hat, offline ist oder gerade telefoniert, soll der Ruf nicht zu dem Teams-Benutzer geroutet werden.

Dazu haben wir vorhin bei den API-Berechtigungen den Zugriff auf DirectoryAccessAsUser.All and Presence.Read.All gewährt und die MS Graph Password Methode verwendet. Diese Einstellungen werden für den Zugriff auf den „Presence“ Benutzerstatus benötigt.

Öffnen Sie die „Settings“ in dem Azure Dial String Directory. Unter Azure Dial String Directory Filter kann festgelegt werden, welcher User Presence State berücksichtigt wird. In unserem Beispiel entfernen wir jetzt die zum Standard gehörenden Haken bei „Busy, Busy Idle, Do not disturb und Offline“. Damit wird jetzt der erste Eintrag in der Routentabelle nur genommen, wenn der Teams-Benutzer gerade nicht telefoniert und seinen Benutzerstatus auf „Grün“ oder „Gelb“ hat.

Jetzt müssen wir noch eine zweite Route mit dem Azure Active Directory anlegen, bei dem die Felder alle weiterhin angekreuzt sind, damit der Ruf abgelehnt werden kann. Dazu klonen wir das bisherige Active Directory, um nicht alle Einstellungen noch mal machen zu müssen. Den Namen können wir bei Bedarf frei bestimmen. Die zum Standard gehörenden Haken fügen wir nun wieder hinzu, damit die Route aktiv wird, wenn der Teams-Benutzer keinen grünen oder gelben Status hat.  Im Routenfilter wählen wir dann das geklonte Active Directory aus. Bei Establishment wählen wir „Reject Call“ und als Status „Busy“ aus. Diese Route sollte in der Routentabelle gleich als zweite Route kommen, da die Routentabelle von oben nach unten abgearbeitet wird.

Wir haben also die erste Route, die aktiv wird, wenn ein Teams-Benutzer angerufen wird, der im Azure Dial String Directory steht und einen grünen oder gelben Benutzerstatus hat. Die zweite Route wird aktiv, wenn ein Teams-Benutzer angerufen wird, der einen roten Benutzerstatus hat oder offline ist. Die dritte Route wird aktiv, wenn ein PBX-Benutzer angerufen wird.