In 5 Minuten zur / zum performanten Website / Cloud-Service weltweit – mit Azure Traffic Manager

Der Azure Traffic Manager ist ein Netzwerk Service von Microsoft Azure. Grundlegend ist der Azure Traffic Manager für 4 Anwendungsszenarien entwickelt.

  • Verbessern der Verfügbarkeit wichtiger Anwendungen (automatisches Failover auf ein anderes Azure Rechenzentrum)
  • Verbessern der Performance (Auswertung des Aufrufers „welches Rechenzentrum erreiche ich am schnellsten“)
  • Wartung ohne Dienstausfall
  • Verteilung von Last auf verschiedene Rechenzentren

Wie funktioniert Azure Traffic Manager?

In der Konfiguration wird ein globaler DNS Name festgelegt. Dieser CNAME verweist auf den Traffic Manager Domänennamen. In der Konfiguration wird festgelegt, welche Endpunkte in welchen Rechenzentren über diese URL erreichbar sind. Weiterhin wird festgelegt nach welcher Lastenausgleichsmethode verteilt werden soll.

  • Leistung
  • Roundrobin
  • Failover

Der Preis wird dabei in Millionen Anfragen berechnet. Weitere Informationen findet ihr in der Azure Dokumentation und in den Preisdetails.

Zunächst erstelle ich in den Rechenzentren Nordeuropa und USA, Mitte/Norden je eine leere Azure Website. Möglich sind hier aber auch Cloud Services und damit letztlich auch eigene VMs mit eigenen Diensten.

127

130

128

129

Damit ich später sehe, in welchem Rechenzentrum ich lande, bearbeite ich die Startseite der Website. Hierzu nehme ich FileZilla. Die Anmeldedaten entnehme ich dem Veröffentlichungsprofil.

131

Dabei gilt:

  • FileZilla Server = publishUrl
  • Benutzername = userName
  • Passwort = UserPWD

132

Ich lade mir die Startseite herunter und ersetze im Text die Lokationen.

134

133

Der Traffic Manager benötigt mindestens den Standardplan. Ich muss also beide Web-Apps in den Standardplan ändern.

136

Als nächstes erstelle ich den Traffic Manager unter Verwendung eines globalen Namens …

135

… und füge die beiden Web-App Endpunkte hinzu.

137

138

Abschließend ändere ich den Überwachungseinstellungen den relativen Pfad auf die Startseite.

139

Zum Test rufe ich die Seite über meinen Browser auf. Ich werde in das Rechenzentrum Nordeuropa geleitet.

140

Verwende ich einen Webproxy aus den Staaten, lande ich im Rechenzentrum der USA.

141

Beende ich nun die Wep-App Nordeuropa werde ich durch die Überwachung automatisch in die Staaten umgeleitet.

142

Blogserie Azure MFA – Part 3 Installation Azure MFA User Portal / SDK

Normalerweise ist die Installation des Portals genauso einfach, wie die des Servers, eigentlich und auch nur laut MSDN! Werden alle Rollen auf einem Server ausgeführt, soll die Kommunikation intern über RPC funktionieren. Leider klappt das in der Praxis nicht. Bisher habe ich auch keine Anleitung im Netz gefunden, die überhaupt funktionierte. Mit einigem Aufwand und viel Troubleshooting habe ich es zum Laufen bekommen.

Zunächst wird auf dem MFA Server die IIS Serverrolle installiert. Dabei werden folgende zusätzliche Features der Rolle benötigt.

  • Basic Authentication
  • Windows Authentication
  • ASP.NET 3.5
  • ASP.NET 4.5
  • ISS 6 Metabase Compatibility

93

Die Kommunikation zwischen SDK und Userportal muss verschlüsselt sein. Dafür wird ein gültiges Zertifikat benötigt. In meinem Beispiel stammt das Zertifikat von einer internen CA. In der Praxis wird das Userportal und die Mobile App im Internet veröffentlicht, sodass sich hier ein öffentliches Zertifikat empfiehlt. Es sollte in jedem Fall der FQDN des MFA Servers bzw. der externen Adresse verwendet werden.

94

Zunächst installiere ich das Azure MFA SDK (ebenfalls ein Webservice) auf dem Server. Das SDK stellt die Verbindung zwischen dem MFA Server und dem User Portal her. Es kann über die Konsole des MFA Server installiert werden.

95

In der Installation wird die Active Directory Gruppe Phone Admins group erzeugt.

96

Ich habe die Website unter der Standardwebsite belassen. Hier kann aber auch im Vorfeld eine eigene erstellt und ausgewählt werden.

 97

Im zweiten Schritt installiere ich nun aus der MFA Konsole das User Portal.

98

In der Installation wird der Active Directory Benutzer PFUP_MFA Account erstellt.

99

Auch hier wird die Standardwebsite verwendet.

100

Das Passwort des Active Directory Benutzers wird während der Installation generiert. Ich benötige es jedoch später in einer Konfigurationsdatei, deshalb setze ich es nach der Installation zurück.

101

Nun binde ich das SSL Zertifikat im IIS an die Standardwebsite mit dem Port 443.

102

Das Userportal muss wissen, dass es den Umweg über das SDK gehen soll. Dafür wird die Web.Config im Pfad C:\inetpub\wwwroot\MultiFactorAuth editiert.

<add key=“USE_WEB_SERVICE_SDK“ value=“true“/>

<add key=“WEB_SERVICE_SDK_AUTHENTICATION_USERNAME“ value=“domäne\PFUP_MFA“/>

<add key=“WEB_SERVICE_SDK_AUTHENTICATION_PASSWORD“ value=“Passwort“/>

<value>https://<MFASERVER FQDN>/MultiFactorAuthWebServicesdk/PfWsSdk.asmx</value>

103

In der Standardinstallation verwenden SDK und Userportal die .NET Version 4.o, jedoch benötigt das SDK die Version 2.0. Dazu wähle ich im IIS den Default App Pool und klicke auf View Applications.

104

Nun wähle ich die Website des SDK aus und ändere den Application Pool …

105

… auf Classic .NET App Pool.

106

Auf der Website des SDK ändere ich die Authentifizierung. Ich deaktiviere die anonyme Authentifizierung und aktiviere die Windows Authentifizierung.

107

Nun kann ich mich endlich mit der Konfiguration des User Portals selbst beschäftigen. In der Konsole des MFA Servers hinterlege ich die URL des Userportals und gebe einige Standardeinstellung an.

108
Nun funktioniert das Portal und der Login der Benutzer ist möglich.

109

Sofern nicht anders konfiguriert wird der Benutzer zuerst auf die Seite zur Beantwortung der Sicherheitsfragen weitergeleitet.

110

Was der Benutzer im Portal darf und was nicht regelt der Administrator in der Konsole des MFA Servers.

111
113

Sollte es beim Aufruf der Website zu folgenden Fehlern kommen, stimmt etwas in der Konfiguration nicht.

Web Service SDK: 3 – Web service requests must be protected with SSL. – Fehler bei der SSL Verschlüsselung vom SDK, tritt auch auf wenn der SDK ausgeschalten wird

 Web Service SDK: 4 – Web service requests must be protected with SSL. – Fehler bei der SSL Verschlüsselung vom SDK, tritt auch auf wenn der SDK ausgeschalten wird

 Azure MFA Web service requests must be protected by authentication. – Windows Authentifizierung auf der SDK Website fehlt 

Error communicating with the local Multi-Factor Authentication service. Please contact your administrator. – Verbindung zwischen User Portal und MFA Server funktioniert nicht

HTTP Error 500.24 – Internal Server Error – Entweder fehlt das .NET Framework oder die Zuordnung der Application Pools ist falsch

Server Error in ‚/MultiFactorAuth‘ Application. – Entweder fehlt das .NET Framework oder die Zuordnung der Application Pools ist falsch

Blogserie Azure MFA – Part 2 Installation Azure MFA

Kommen wir nun zur Grundinstallation. Aus meiner Sicht auch der einfachste Teil der ganzen Sache. Es wird ein Microsoft Azure Zugang benötigt. Im ersten Schritt erzeuge ich einen neuen Anbieter für die mehrstufige Authentifizierung.

In der Demo verwende ich die beiden Server dc.contoso.com (AD DS, AD CS) und mfa.contoso.com (MFA Server, MFA User Portal, MFA SDK, MFA Phone App).82

Anschließend wähle ich den neuen Anbieter aus und öffne die Verwaltung. Hier merkt man ganz gut, dass das Produkt noch nicht voll in Azure integriert ist.83

Im MFA Portal kann ich den Server herunterladen. Bei den Anmeldeinformationen handelt es sich um ein Einmalpasswort zur Installation des Servers. Es hat nur eine Gültigkeit von 10 Minuten.84

Auf dem Server selbst benötige ich das .NET Framework 3.5.

85

 Die Installation ist selbsterklärend, next, next, next finish.

86

 Der nachfolgende Assistent kann abgebrochen werden und sollte nur für komplexe Multi-Server-Deployment Szenarien verwendet werden.

87

Anschließend muss der Server bei dem Microsoft Azure Dienst registriert werden. Hier verwende ich das generierte Einmalpasswort und die E-Mail Adresse.

88

Nun kann der MFA Server einer bestehenden Gruppe hinzugefügt werden (für Hochverfügbarkeitsszenarien oder wenn der Server migriert wurde) oder eine neue Gruppe erstellt werden. Sollte die Gruppe nicht existieren wird sie automatisch angelegt.

89

 Abschließend füge ich die Benutzer einzeln hinzu oder konfiguriere eine Synchronisierung mit dem Active Directory. Sofern nicht schon aus dem Active Directory ausgelesen, erhält der Benutzer die Handynummer und die Art der Authentifizierung.

90

Nun kann ich den Dienst schon testen.

91

92