In den letzten individuellen Azure Workshops kam immer wieder die Frage auf, wie man bestehende Applikationen in der lokalen Umgebung genauso vor unbefugten Zugriffen mit Azure schützen kann. Die kurze Antwort meinerseits war diesbezüglich “Mit Azure AD Application Proxy” und “Azure AD Domain Services”. Hierzu hatte ich in den letzten Jahren den einen oder anderen Vortrag gehalten bzw. im Blog geschrieben.

Nun haben sich die Technologien weiterentwickelt und zusätzlich stehen wir vor den Herausforderungen, bis zum 25 Mai 2018 auch die GDPR (Europäische Datenschutzgrundverordnung) umzusetzen. Daher beschreibe ich hier die Implementation von “Azure AD Application Proxy” zum Schutz einer lokalen Exchange Umgebung, welche in Azure als gemanagter IaaS Dienst zur Verfügung gestellt wird.

Die Umgebung selbst ist sehr einfach gehalten. Einen Active Directory Domain Controller und einen Exchange 2013 Server. Benutzer werden derzeit noch nicht mit Azure AD synchronisiert.

Vorbereitungen

Sofern noch keine Synchronisation mit einem Azure AD erfolgt ist, sind derzeit jeweils die lokale AD Domäne und die Azure AD Domäne untereinander nicht bekannt. Dies sollte auf jeden Fall nachträglich gemacht werden. Normalerweise existiert im Azure AD eine verifizierte Domäne, doch in diesem Fall fehlt diese noch. Der Weg im lokalen AD ist aber gleich. Im Menu von “Active Directory Doma and Trusts” klicken wir auf die erste Zeile und dann “Properties”

Den korrekten Azure AD Domain Namen finden wir im Azure Admin Portal unter “Namen der benutzerdefinierten Domänen”

Diesen fügen dann im Active Directory hinzu

Anschließend steht der UPB Suffix dem lokalen AD zur Verfügung

Für die weiteren Schritte muss ich nun von einer Annahme ausgehen. Die generelle Basis Entscheidung, wie geht man mit lokalen UPN Suffixen, der Cloud UPN Suffix und der eMail Adresse um. Am einfachsten und sichersten ist die Nutzung der eMail Adresse als genereller UPB Suffix sowohl in der Cloud als auch im lokalen AD. Daher ändere ich hier nun auch den Suffix des Benutzers auf die “virtuelle” eMail Adresse der “onmicrosoft.com” Domäne. In einem späteren Schritt kommen wir auch wieder zu dieser Domäne als Benutzer.

Als nächsten Schritt wird der “Azure AD Connector” lokal installiert. Hier wird die individuelle Installation gewählt, damit wir nur ausgewählte Benutzer synchronisieren. Die eigentliche Installation wird in einem anderen Beitrag beschrieben. Wichtig dabei ist nur, dass nun die “onmicrosoft.com” Domäne bzw. die tatsächliche eMail Domäne als eindeutige Kennzeichnung genutzt wird.

Im vorliegenden Use Case (oder auch Workload) installieren wir nun den “Azure AD Application Proxy Connector). Diesen finden wir innerhalb der Azure AD Application Proxy Konfiguration. Hierzu gehen wir in “Enterprise Applications” und fügen eine Proxy Verbindung hinzu.

In der nachfolgenden Konfiguration vergeben wir einen Namen und benennen die interne URL. Da sich immer nur ein Proxy Agent auf einem Server installieren lässt, müssen wir auch hier planen. Nehme ich nun die Exchange URL ohne Unterverzeichnis, kann ich auf alle weiteren Unterverzeichnisse zugreifen. Definiere ich hier schon eine komplette URL wie https://server/owa kann nur auf die Exchange Outlook Web Access Seite zugriffen werden. Zudem muss ich entscheiden, ob ich eine Vor Authentifizierung über Azure AD wünsche oder nicht. Im Moment sind wahrscheinlich keine User synchronisiert, daher benötigen wir die Passthrough Authentifizierung, oder ich nutze zusätzlich “Cloud Only” Benutzer, dann hätten wir aber zwei unterschiedliche Konten. Die zusätzliche Auswahl der externen Domäne hängt von den Azure AD Domänen Einstellungen ab.

Der Download des Connectors erfolgt dann im Menu “Application Proxy”

Die neue Webseite, welche sich dann öffnet, ist in der URL mit der Subscription ID verknüpft.

Nach der Installation werden die Anmeldedaten mit der “Modern Authentication” abgefragt.

Die Installation ist wenige Momente später abgeschlossen. Im Azure Portal wird der Connector direkt sichtbar.

Zur besseren Steuerung und Übersicht kann man virtuelle Gruppen erstellen.

Da weiter oben die Konfiguration der Azure Pre Authentifizierung deaktiviert wurde, haben wir nun auch keine Single-Sign On Konfiguration mehr.

Aber testen wir erst einmal die Verbindung.

Diese Fehlermeldung ist hier nun nichts anderes, als dass wir ja die Root URL zugewiesen haben.
Wir müssen die gewünschten Unterverzeichnisse in der Adresszeile hinzufügen, hier OWA

Die Adresszeile wird dabei wie jede andere genutzt, eine Anpassung hat in Exchange bisher nicht stattgefunden (Interne URL und Externe URL).
Es gubt nur das Problem, das unser “Edge” die Webseite nicht anzeigen möchte….

Nicht nur, das wir mit unserem internen Zertifikat (Exchange Self Service) keinen Hinweis erhalten haben, auch der URL Abruf in der Webseite bleibt von unseren internen Informationen versteckt.

Selbstverständlich ist auch der Zugriff auf die Administrationsseite möglich, bzw. bei einem Endbenutzer die Profilseite

 

Nun kommt die zusätzliche Absicherung

Wir nutzen dazu zusätzliche Optionen aus der Azure AD Premium P1 Lizenzierung (auch enthalten in EMS (Enterprise Mobility and Security) E3).

Dazu müssen wir die Azure Pre Authentifizierung ändern…

Nachdem “Speichern” wird die Option fast zeitnah aktiv. Ein einfacher Refresh der Webseite, ausgelöst durch klicken auf ein Element, setzt den Endbenutzer sofort zur Anmeldeseite von Azure / Microsoft Online um und die Anmeldedaten müssen eingegeben werden.

Die hat dann den Haken, dass wir einen lizenzierten Azure AD Benutzer benötigen.

Login ohne Lizenz bzw. Berechtigung die App zu nutzen.

Dies passen wir dann in der Konfiguration an und aktualisieren die Webseite.

Anschließend funktioniert die Anmeldung direkt. Hierbei wurde ein “Cloud Only User” für die Azure AD Anmeldung genutzt.
Eine weitere Steigerung der Anmeldesicherheit wäre die Nutzung von MFA (Multi Faktor Authentifizierung)

Und bei der nächsten Anmeldung erscheint dann auch schon die Aufforderung zur Registration

Nach Eingabe des SMS Codes oder nach Beantwortung des Anrufs wird die Anmeldeseite automatisch weitergeleitet und man landet wieder auf der lokalen Exchange Anmeldeseite.

Zwei Faktor Authentifizierung Azure (MFA) sofort aktiv, ohne weitere Konfiguration, ohne Client Rollout, ohne Software Installation.
Sicher gibt es noch weitere Konfigurationsmöglichkeiten, diese werde ich in einem späteren Artikel beschreiben.
Nur zur Sicherheit, es gibt zwei Konfigurationsoberflächen… Einmal in Azure und einmal für Office 365 Benutzer.

Beide Links kommen aber auf die gleiche Einstellungsseite.

Zusammenfassung

Microsoft Azure AD Application Proxy kann uns unterstützen, webbasierte Anwendungen schnell aber sicher im Internet verfügbar zu machen. Dazu muss der Endbenutzer nicht mit dem Azure AD synchronisiert werden, dass dies aber Vorteile mitbringen würde, zeige ich im nächsten Artikel.

Zusätzliche Absicherung durch einen “Cloud Only User” kann ich mit Azure MFA erreichen. Die Zwei Faktor Authentifizierung arbeitet sofort und ich kann eigene Regelwerke der zu berücksichtigten Ziele definieren, von Benutzer bis hin zu Geräte bzw. Plattformen (Windows, iOS, MacOS und Android).

Je nach weiterer Konfiguration kann ich die erfolgten Zugriffe ausreichend Protokollieren und Dokumentieren. Als Gesamtbild erfülle ich dadurch schon einen erheblichen Teil der gesetzlichen Anforderungen nach GDPR. “Ich weiß, wo sich die Dokumente befinden – auf einem Exchange Server” “Ich weiß, wer auf die Dokumente Zugriff hatte – durch die dedizierten und sicheren Anmeldungen.”


 

Ach ja, und dann habe ich auch noch ein Webportal, wo die neue “App” mit den anderen Applikationen aufgelistet wird: myapps.microsoft.com

 

Das wars…..

Bis zum nächsten Mal.

Viele Grüße
Michael

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

The short URL of the present article is: https://wp.me/p1MQAv-1ct

Filed under: GDPR / EU-DSGVO