Azure AD Application Proxy

Jede Firma hat irgendwelche Webseiten oder Webservices, die sicher veröffentlicht werden müssen. Anstatt sich selbst im Reverse Proxy, öffentliche IP-Adresse, Zertifikat, MultiFaktor-Auth und DoS-Attacken zu kümmern, kann diese Funktion auch Azure übernehmen. Der Azure AD Application Proxy ist vermutlich bei den Administratoren die am wenigsten bekannte Möglichkeit. Es ist Zeit das zu ändern. Denn auch wenn Microsoft die Zusammenhänge und selbst die Konfiguration selbst sehr ausführlich dokumentiert hat, sind Kunden immer wieder überrascht, wenn ich ihnen diese Funktion von Azure vorstelle.

Funktionsweise

Ehe ich die technischen Schritte erläutere, möchte ich eine Lanze für den Azure AD Application Proxy brechen, denn damit können speziell mittlere und kleine Firmen selbst lokal bereit gestellte Webseiten einfach und vor allem Sicher im Internet und für Partner veröffentlichen. Das gilt nicht nur für neue Dienste sondern quasi für jeden Webservice, der auch heute schon On-Premises betrieben wird. Ob ein Service im Internet diesen Dienst nutzt, können Sie entweder direkt an der Adresse oder einem CNAME erkennen. Microsoft nutzt die Domain "msappproxy.net" für die Veröffentlichung und wenn Sie einen eigenen Namen nutzen, dann reicht ein CNAME auf diese Adresse. Also muss ich mal schnell die Funktion erklären. Der Service bietet nämlich durchaus etwas mehr als nur ein HTTP-Reverse Proxy, wie es auch heute schon jede bessere Firewall kann.

Die Komponenten sind schnell aufgeführt:

  1. Der Webservice ...
    ... steht wie bisher im internen LAN und ist aus dem Internet nicht erreichbar. Er sollte natürlich dennoch per HTTPS erreichbar sein aber das Zertifikat kann notfalls auch "Self Signed" sein. Besser ist natürlich ein richtiges Zertifikat, denn auch interne Clients sprechen vielleicht den Services von intern direkt an.
  2. On-Premises Connector
    Auf einem Server im LAN wird der Azure AD Proxy Connector installiert. Dieser Windows Dienst baut dann von intern eine ausgehende Verbindung zu Azure auf und wartet auf Anfragen durch Azure, die er dann intern an die verschiedenen Webserver weiterreichen kann. Die eigene Firewall muss also weder Reverse-Proxy spielen noch benötigen Sie öffentliche IP-Adressen oder Zertifikate.
  3. Azure AD App Proxy
    Dies ist eigentlich "nur" eine Konfiguration in Azure AD, mit der sie einen Service im Internet freigeben und über den bereits installierten Connector zu einem internen Server verbinden. Der AzureAD App Proxy ist der Schlüssel, denn hier können Sie nicht einfach nur die Zugriffe durchreichen, sondern auch eine Authentifizierung gegen ihre eigenes AzureAD oder sogar gegen alle Azure AD Tenants durchführen lassen. Sie können auch die Benutzer und Gruppen schon hier beschränken, die den Dienst überhaupt nutzen dürfen und über Conditional Access noch weitere Kriterien umsetzen.
  4. Der Client
    Der Nutzer des veröffentlichten WebService kann ein Browser im Internet aber auch im Intranet sein. Es kann ein anonymer Client oder ein Firmen-System sein. Letztlich bestimmen Sie ja auf dem AzureAD App Proxy, ob die Anfrage durchkommt
  5. DNS-CNAME
    Sie können den Service natürlich unter "<servicename>.msappproxy.net" ansprechen. Schöner ist aber natürlich ein "sprechender Name" aus ihrer Domain. Das ist auch einfach möglich, indem Sie in ihrer DNS-Zone einen CNAME auf den von Microsoft vergebenen Namen einrichten.

Es klingt so einfach und es ist eigentlich auch so einfach.

Vorteile

Einen Teil der Vorteile habe ich schon aufgezählt aber ich möchte Sie hier noch einmal als Liste zusammenfassen.

  • Eine ausgehende und keine eingehende Verbindung
    Sie benötigen keine eingehende HTTPS-Veröffentlichung in ihrer Firewall auf einen internen Webserver. Der Connector intern macht eine ausgehende Verbindung auf. Allerdings kann das auch bedeuten, dass eine Fachabteilung mit einer eigenen Azure-Subscription über den Weg interne Dienste ohne Wissen der Firewall veröffentlicht.
  • Keine Public-IP
    Dies ist besonders interessant, wenn Sie nur wenig oder keine freie öffentliche IP-Adresse mehr haben oder ihre IP-Adresse sich doch immer mal wieder verändert. Es macht eine Verfügbarkeit aber auch einfacher, wenn sie einen Backup-Leitung eines anderen Providers haben und kein Provider-Independend Subnetz mit BGP veröffentlichen.
  • Kein öffentliches Zertifikat
    Die Client Verbindung kann bei Nutzung des *.msappproxy.net-Namens ohne kostenpflichtiges Zertifikat auskommen. Auch er interne Server muss kein öffentliches Zertifikat nutzen.
  • PreAuth, Conditional Access, MFA
    Sie können auch "Passthough" auswählen aber die Vorqualifizierung der Nutzer ist ein großer Schutz gegen Angriffe auf Konten, da Azure diese Anmeldungen schon abwehren kann
  • DDoS-Schutz
    Da ihr eigener Webserver immer hinter den Azure-Diensten verborgen ist, haben Sie einen sehr guten DoS-Schutz gleich mit eingebaut.
  • Login Tracking
    Wenn der Azure AD App Proxy die Anmeldungen vorab prüft, dann protokolliert Azure auch diese Vorgänge wie jede andere Anmeldung an einem Office 365 oder Azure Dienst. Das kann für Compliance-Anforderungen und Analysen bei Missbrauch sehr wichtig werden
  • Guest Access
    Die Pre-Authentifizierung ist nicht auf ihren eigenen Tenant beschränkt. Sie können auch die Anwender anderer Tenants über den Azure AD App Proxy legitimieren
  • OAUTH
    Wenn sich ein Anwender nun schon am AzureAD Ap Proxy authentifiziert hat, dann möchte man vielleicht eine zweite Anmeldung am eigentlichen Backend vermeiden. Das ist über OAUTH-Tokens  möglich. Der Azure AD App Proxy "kennt" ja nun den Benutzer und ihre Backend App ist ebenfalls in Azure AD bekannt. Dann können Sie dem Anwender auch ein passendes Token übermitteln, welches er an den Backend-Service weiterreicht. Ihre BackendApp muss also einfach nur diese Bearer-Tokens decodieren und dem Aussteller vertrauen. Immer mehr Applikationen unterstützen diese Anmeldung.

Das alles gibt es natürlich nicht "kostenfrei".

Kosten

Über die Lizenzseite von Microsoft können Sie direkt sehen, welche Lizenz sie für den Einsatz des Azure AD App Proxy benötigen


Quelle: https://azure.microsoft.com/en-us/pricing/details/active-directory/

Allerdings spreche ich bei jedem Kunden aktiv das Thema "Azure AD P1" an, da ohne diese Funktion auch kein "Conditional Access" nutzbar ist und damit jeder Anwender mit gültigem Benutzernamen und Kennwort auf jedem Client der Welt mal eben Outlook und OneDrive installieren kann und damit Firmendaten per OST-Datei oder OneDrive-Replikation auf einem ungesicherten Endgerät landen könnten. Insofern sollte jeder Office 365 Kunde auch immer Azure AD P1 mit lizenzieren. Azure AD P1 ist übrigens auch in EMS E3 und Microsoft E3 mit enthalten. Irritieren ist dann aber wieder die Anzeige im Azure Portal

Auf der einen Seite wird von AAD Premium aber auch "Basic" gesprochen, was definitiv nicht stimmen kann. Als Trial angeboten bekomme ich aber Azure AD P2 oder EMS E5 (enthält AzureAD P2) aber nicht Azure AD P1. Hier sollten Sie also ganz genau prüfen, welche Lizenz Sie kaufen.

Freischaltung

Der Azure AD Proxy Connector muss natürlich eine ausgehende HTTPS-Verbindung zu Azure aufbauen können, um dort die anstehenden Anfragen abzuholen. Je nach ihrem Netzwerk bedeutet das zusätzliche Freischaltungen auf einem HTTP-ProxyServer, eine entsprechende Namensauflösung und Firewall-Regeln. Microsoft hat die entsprechenden Adressen und DNS-Namen veröffentlicht. Genauso wird beschrieben, wie bei der Verwendung eines Proxy-Servers dieser zu konfigurieren ist.

Einrichtung Connector

Die Nutzung von Azure AD App Proxy beginnt mit der Installation des ersten Connectors auf einem Server in der Nähe ihres Dienstes.

Der Einsatz ist nicht auf lokale On-Premises Installationen beschränkt. Sie können genauso gut eine AzureVM mit einem WebServer über diese Funktion veröffentlichen. Wichtig ist nur, dass die Weg möglichst kurz sind. Der Zugriff aus dem Internet über einen On-Premises Connector und dann über ein AzureVPN zu einer VM in Azure ist vielleicht nicht optimal gelöst.
Über mehrere "Connector Groups" können wie später je veröffentlichter Applikation bestimmen, welche Connectoren genutzt werden.

 Es gibt hier verschiedene Überlegungen zu beachten hinsichtlich Netzwerklatenz, Bandbreite, Verfügbarkeit etc. Microsoft hat dazu eine nette Anleitung veröffentlicht:

Sie starten einfach im Azure Portal unter "Active Directory" und dann "Application Proxy":

Den Download gibt es aber auch eigenständig:

Azure AD Application Proxy Connector Download
https://download.msappproxy.net/subscription/d3c8b69d-6bf7-42be-a529-3fe9c2e70c90/connector/download

Bei der Installation müssen Sie Tenant Admin sein, denn der Connector authentifiziert sich über ein Client Zertifikat am Azure AD App Proxy, welches alle 180 Tage automatisch erneuert wird. Bei der Installation kann das initiale Zertifikat nur als Tenant Admin erstellt werden. Der Connector holt sich dann aus Azure die Konfiguration, d.h. welche Dienste er bereitstellen soll.

Um Updates müssen Sie sich eigentlich nicht kümmern:

The Azure AD team regularly updates Application Proxy with new features and functionality. Application Proxy connectors are updated automatically when a new major version is released.
Quelle: Azure AD Application Proxy: Version release history https://docs.microsoft.com/en-us/azure/active-directory/app-proxy/application-proxy-release-version-history

Für eine bessere Verfügbarkeit können Sie mehrere Connectoren als "Gruppe" zusammenfassen. Dann ist es auch einfacher anstehende Updates mal schnell auszuführen. Es gibt auf dem Connector selbst als keine GUI o.ä.

Outbound Proxy

Zum Ende der Installation kommen ein Hinweis, wie ein ausgehender HTTP-Proxy einzurichten ist:

Achtung:
Das Skript "ConfigureOutBoundProxy.ps1" addiert nur den Proxy in die application.config des Connectors und des Update Service aber hat keinen Code um einmal gemachte Eintragungen wird zu entfernen.

Sie können natürlich per Notepad die beiden Dateien manuell konfigurieren
C:\Program Files\Microsoft AAD App Proxy Connector\ApplicationProxyConnectorService.exe.config
C:\Program Files\Microsoft AAD App Proxy Connector Updater\ApplicationProxyConnectorUpdaterService.exe.config

Aber es gibt natürlich eine PowerShell, Eventlogs und Performance Counter:

AppProxy aktivieren

Es kann sein, dass die Funktion App Proxy noch deaktiviert ist. Dann ist es aber nur einen Mausklick entfernt

Ich denke, es ist einfach ein doppelter Schutz. Sie werden darauf hingewiesen, dass Sie immer noch die einzelnen Apps einrichten müssen.

An der gleichen Stelle können Sie den Service auch deaktivieren.

 

Einrichtung App Proxy

Nach dem Sie den Connector installiert haben, können Sie direkt auf dem Connector ein "Configure an App" starten:

Im dann folgenden Dialog stellen Sie die zumindest die "Internal URL" ein.

Standardmäßig ist eine "Pre Authentication" am Azure AD erforderlich. Die externe URL können Sie natürlich anpassen.

Translate URLs

Sie haben bei den Einstellungen sicher auch die beiden Schieber unter "Translate URLs in" für "Headers" und ApplicationBody" gesehen. Diese Einstellung muss erklärt werden, denn sie ist immer dann wichtig, wenn die Werte bei "Internal URL" und "External URL" sich unterscheiden:

Ich bin ein Fan der "Ein Service = Ein Name = Ein Port". Egal wo der Clients ist, muss er mit der URL immer den gleichen Service erreichen. Die Zwischenstationen können natürlich unterschiedlich sein.

Wenn die angesprochene URL identisch ist, gibt es keinen Bedarf etwas umzuschreiben. Ansonsten muss die Umschreibung dem Server dabei helfen, die richtigen Daten und URLs zu liefern. Nehmen wir an ich greife von Extern aus www.msxfaq.de zu und ein Reverse Proxy, eine Firewall, ein Loadbalancer oder eben der AzureAD Application Proxy muss den Request intern auf einen anderen Namen, z.B. server1.msxfaq.net umsetzen, dann müssen mehrere Dinge beachten.

  • DNS und TLS
    Der Request wird vom AzureAD App Proxy per HTTPS angenommen decodiert und liegt in Reinform vor. Damit der Request zum Backend-Server gesendet wird, muss der ProxyAgent nicht nur den Namen auslösen und eine IP-Verbindung aufbauen sondern auch das Zertifikat prüfen. Wenn der interne Server nur ein Zertifikat für den internen Namen hat, muss der AppProxy dies verstehen. Hier könnte auch der Subject Name Indication (SNI) mitspielen.
  • HostHeader
    Wenn er dann den Request an den veröffentlichten Webserver sendet, muss er eventuell den HostHeader im HTTP-Request umschreiben. Der interne Server "reagiert" vielleicht gar nicht auf den externen Namen. HostHeader-Checks sind üblich. Darauf bezieht sich das "Rewrite auf den Header". Überall, wo die externe URL enthalten ist, kann die interne URL eingesetzt werden. Das ist nicht trivial, weil Servernamen z.B. auch in einem Authentication-Cookie codiert enthalten sein können und damit ein einfaches Rewriting nicht möglich ist.
  • Serverantwort
    Der Webserver bearbeitet die Anfrage und generiert die Rückantwort. Es ist natürlich höflich mit relativen URLs zu arbeiten, in denen kein Hostname vorkommt. Aber wenn Sie auch die Pfade in den externen URL umschreiben, dann muss im Body auch diese Änderung angewendet werden. Wenn der Server aber weiss, wie er "extern" heißt, dann kann er das schon selbst.
    Heute liefern Webserver aber nicht nur HTML,CSS und Bilder sondern viele moderne Apps nutzen JSON/REST/WebSockts und da wird es schwer für einen AppProxy die relevanten Strings zu erkennen und umzuschreiben.
  • Pfade
    Wenn sie nicht den ganzen Server sondern nur einen Teilpfad veröffentlichen, dann müssen Sie sicher sei, dass wirklich alle Inhalte auch unter diesem Pfad sind. Sehr oft erlebe ich aber, dass z.B. Style Sheets (CSS) oder JavaScript (js) aus allgemeinem Verzeichnissen nachgeladen werden. Hier müssen Sie dann die Anwendung ggfls. doch komplett veröffentlichen. Auch wenn das ein Risiko beinhaltet, dass andere URLs ebenfalls erreichbar werden
  • Port Umsetzung / SSL Offload
    Sie können mit dem AzureAD AppProxy externe Anfragen nur auf Port 443 annehmen. Die interne URL kann aber natürlich auf einen abweichen Port gehen oder z.B. auch Verschlüsselung verzichten. Dann kommen Sie ohne Rewriting nicht aus, das der interne Webserver per HTTP oder auf einem anderen Port angesprochen wird und diese Vorkommen im Header oder Body ebenfalls umgeschrieben werden müssen.

Sie sehne, dass hier ganz schön viel schief gehen kann und nur weil ihre ersten Tests erfolgreich waren, ist das noch lange keine Stabilitätsgarantie. Daher wünsche ich ihnen, dass Sie am besten ganz ohne Rewriting auskommen und alle Server über die Standardport 80/443 und dem gleichen Namen aus dem internen LAN als auch aus dem Internet angesprochen werden können. Nebenbei hat der App Proxy damit auch weniger Arbeit und sie müssen Link in Mails, auf anderen Webseiten, in Favoriten und sonst wo nicht nach "Intern/Extern" unterscheiden. Mir ist natürlich bewusst, dass Sie sich dann auch über "SplitDNS" Gedanken machen müssen.

Custom Domains

Im DropDown-Feld können sie jede Domain nutzen, die sie in ihrem Tenant registriert haben. Das Portal weist sie dann schon darauf hin, dass Sie natürlich den entsprechenden DNS-CNAME noch eintragen müssen aber auch, dass Sie ggfls. noch ein Zertifikat bereitstellen müssen.

Für die "Pre Authentication" muss der App Proxy ja den SSL-Tunnel aufbrechen.

Authentifizierung anpassen

Sie haben zwar nun den Connector und die App eingerichtet, aber bezüglich der Authentifizierung gibt es noch etwas zu tun, da aktuell noch niemand diese App nutzen kann. Das Portal springt aber schon auf die passende Seite, auf der Sie nun auch die Benutzer oder Gruppen zulassen müssen.

Im gleichen Zug können Sie steuern, ob die App auf dem Portal der Anwender erscheint, welche "Conditional Access"-Policy angewendet wird und welche Berechtigungen die App bekommt. Hierüber steuern sie, welche Inhalte das OAUTH-Ticket bekommt, welches später an die Applikation weitergereicht werden kann. Unter "Activity" können Sie später nachvollziehen, welche Anwender die App genutzt haben.

Single SignOn

Die Enterprise Application kann so konfiguriert werden, dass Sie von den Anwendern schon eine Authentifizierung erfordert. Das macht Sinn, um schon sehr früh zu filtern aber auf der anderen Seite möchte man dem Anwender natürlich eine "doppelte" Anmeldung ersparen. Also sollten dann die erhaltenen Anmeldedaten zum Backend Server weiter gereicht werden. Dazu gibt es gleich eine ganze Menge:

Wenn die Dienste heute schon die Authentifizierung per Kerberos nutzen, dann würde ich den Weg auch für den AzureAD Application Proxy nutzen. Die Menge an Optionen kann Sie natürlich erschlagen. Da ist es hilfreich zu wissen, welche Möglichkeit mit welchem Backend und Frontend harmoniert. Wenn z.B. ein Server "integrated" anbietet, was bei vielen Windows Services der Regelfall ist, dann können Sie "Kerberos Contraint Delegation" die AzureAD Authentifizierung einfach nutzen. Ich versuche mich mal an einer Tabelle, dann SSO möglich sein könnte. Nur wenn der Azure AD Proxy die Authentifizierung macht, können Sie über Conditional Access weitere Kriterien abprüfen.

Was kann das Backend Azure AD Proxy Einstellung für SSO/Preauth Client

Windows Auth/SPNEGO

  • "Windows Integrated"
    + Kerberos Contraint Delegation Konfiguration

 

Header Based Authentication

  • Disabled
  • "Header Based" mit Ping Federated

Ein Client könnte aber SSO über ein "JWT_Bearer Grant" ermöglichen

OAUTH2

  • Nicht möglich. auf "Disabled" Stellen

Ein Client könnte aber selbst mi einem OAUTH Token ein SSO ermöglichen

SAML - WS/FED

  • Enabled:SAML
  • Disabled

Bei der Einstellung "Disabled" könnte ein Client aber selbst ein Token per SSO liefern

Basic/NTLM

  • Disabled

Der AzureAD App Proxy kann bei NTLM/Basic nicht unterstützen. Der Client könnte aber selbst direkt NTLM machen, wenn er denn dies kann.

SOAP

  • Disabled

Eine Unterstützung durch den AzureAD Proxy aber Clients könnten direkte Tokens senden und damit SSO erlauben.

Client Zertifikat

  • Nicht möglich

Der gerade für Remote User gerne genutzte Ansatz mit Zertifikaten (Smartcard etc) wird vom AzureAD Proxy aktuell nicht unterstützt.

Ich würde bei internen Diensten, die z.B. Kerberos unterstützen, über diesen Weg eine Authentifizierung am AzureAD Proxy anfordern, der dann als Benutzer an den Backend-Service geht. Damit die per Kerberos möglich ist, müssen Sie mehrere Dinge tun:

  1. IIS Authentication auf "Windows Integrated"
    Gerade mit Exchange Servern wird intern gerne eine Anmeldung per "Formular" angeboten.
  2. Besorgen Sie sich den SPN des internen Servers
    Bei meinem Exchange Server ist das "HOST/ex01.msxfaq.de". Mit ADSIEDIT oder SETSPN können Sie für das Zielsystem diesen Eintrag schnell finden
  3. Kerberos Delegation eintragen
    Dann müssen Sie im Active Directory auf dem Computerkonto der AzureAD Connectoren diese Zielserver auf der Karteikarte "Delegation" addieren
  4. SPN in AzureAD eintragen
    Zuletzt tragen Sie den SPN auch noch in der Azure AD Enterprise Applikation ein

Anscheinend nutzt der Connector "genau" den angegebenen SPN. Wenn Sie hier "http/ex01.msxfaq.de" angeben, dann scheint er kein Fallback auf "host/ex01.msxfaq.de" zu machen.

Es kann einige Minuten dauern, bis all die Änderungen aktiv sind aber sollten Sie nach einer Anmeldung am Azure AD Application Proxy direkt zum Zielserver ohne weitere Anmeldung kommen.

Im Fehlerfall sehen Sie bei Kerberos dann folgende Seite:

Die Links führen direkt zu den Einstellungen im Azure Portal und folgenden Seiten in der Microsoft Dokumentation.

Manchmal ist die Seite aber auch "nichtssagend weil Sie innerhalb einer Webapplikation einen Fehler bekommen. Dann hilft zum einen Fiddler: 

Aber auch die Debugging Tools des Browsers sind hier manchmal hilfreich:

Hier blockiert der Browser das Nachladen wohl anhand einer CORS-Richtlinie

Auf die anderen Anmeldeverfahren gehe ich hier nicht weiter ein und verweise auf die Dokumentation von Microsoft.

Debugging

Auf der Fehlerseite bei Kerberos aber auch einen Link auf im Portal können Sie eine URL auslesen, mit der Sie einen "Debug-mode" aktivieren können.

Die URL ist einfach die Adresse der Application mit einem eigenen Parameter:

https://servicename.msxfaq.de/?appproxy=debug

Danach sehen Sie je nach Anwendungsfall oder Fehler ausführlichere Informationen, auf die ich aber nicht weiter hier eingehe.

Certificate Pinning

Ich habe meinen privaten PRTG-Server über einen AzureAppProxy veröffentlicht. Das funktioniert per Webbrowser sehr gut. Wenn ich aber die "mobile App" auf IOS nutze, dann bekomme ich bei jeder neuen Verbindung eine Warnung.

Das dürfte daran liegen, dass Microsoft auf ihrer Seite sicher viele eingehende Server bereitstellen, die aber nicht alle das gleiche Zertifikat nutzen. Aufgrund der Lastverteilung per DNS-RoundRobin oder Loadbalancer kann es also passieren, dass mein Client auf einem anderen Server landet. Der mobile PRTG-Client merkt sich allerdings das individuelle Zertifikat, was im Prinzip nicht schlecht ist. Nur mit dem AzureADProxy fällt dies bei der Nutzung der Microsoft-Adressen auf.

Enterprise Apps mit AppProxy finden

Leider gibt es keine einfache Möglichkeit (Stand Feb 2024), bei der Konfiguration des App Proxy zu erkennen, wie viele Dienste die Connector Group verwenden. Wenn Sie aber über die Enterprise Applications gehen, können Sie zumindest auf "Is App Proxy = true/false" filtern.

Leider gibt es weder eine Spalte noch einen Filter für eine einzelne "Connector Group". Wer also mehrere Connetor Groups mit weiteren App Proxy Gateways konfguriert hat, ist gut daran, eine Dokumentation zu führen oder im Namen des Services dies mit zu kodieren.

Reporting mit PowerShell

Ich nutze mittlerweile sehr umfangreich die AzureADProxy-Funktion. So kann ich selbst WebServer in meinem Intranet, also auch zuhause hinter einer dynamischen IP-Adresse, sehr einfach im Internet verfügbar machen und muss mich nicht mehr DynDNS und einer Portweiterleitung im DSL-Router herum schlagen.

Etwas unglücklich ist aber aus meiner Sicht die Verwaltung, da ich zwar über den Punkt AzureADProxy die Agenten finde aber nicht, welche Applikationen über diese Agenten bereitgestellt werden. Ein Blick in die Applikationen liefert aber alle Apps und lässt sich in der GUI (Stand Jun 2020) nicht filtern. Daher muss die PowerShell her. Leider muss man dazu aber mehrere Befehle kombinieren

Nachdem Sie eine Verbindung zur AzureAD Powershell aufgebaut haben, müssen Sie mit "Get-AzureADServicePrincipal" die Objekte suchen, die im Feld "Tags" den Wert "WindowsAzureActiveDirectoryOnPremApp" stehen haben. Die Liste enthält aber z.B.: noch keine Informationen über das Zertifikat. und dann mit deren ObjectIDs die Details holen.

Connect-AzureAD

Write-Host "Hole Liste aller OnPremAzureADApps"
$AzureADAppServList = Get-AzureADServicePrincipal -Filter "Tags eq 'WindowsAzureActiveDirectoryOnPremApp'"

$list = foreach ($App in $AzureADAppServList) {
   Write-Host "Processing:$($app.displayname)"
   $application = Get-AzureADApplication -SearchString "$($app.Displayname)"
   $appProxy = Get-AzureADApplicationProxyApplication -ObjectId "$($application.objectid)"
   [pscustomobject][ordered]@{
      AccountEnabled                = $app.AccountEnabled
      DisplayName                   = $app.DisplayName
      ExternalAuthenticationType    = $appproxy.ExternalAuthenticationType
      ExternalUrl                   = $appproxy.ExternalUrl
      InternalUrl                   = $appproxy.InternalUrl
      IsTranslateHostHeaderEnabled  = $appproxy.IsTranslateHostHeaderEnabled
      IsOnPremPublishingEnabled     = $appproxy.IsOnPremPublishingEnabled
      VerifiedCustomDomainCertificatesMetadata = $appproxy.VerifiedCustomDomainCertificatesMetadata
   }
}

$list | select Displayname,{$_.VerifiedCustomDomainCertificatesMetadata.ExpiryDate}

Eine andere Variante besteht im Abrufen mit Get-AzureADApplication, wobei hier als Parameter nur eine GUID aber kein Name möglich ist. Also muss ein Skript auch hier erst alle Einträge holen und dann filtern.

$AllApps = Get-AzureADApplication -All $True
Foreach($App in $AllApps){ 
   try {
      write-host ("Displayname:$($app.displayname)") -nonewline
      $AppDetails = Get-AzureADApplicationProxyApplication -ObjectId $App.ObjectId
      write-host (" - Found")
      $AppDetails
   }
   catch {
      write-host (" - NotAppProxy")
   }
}

Die Abfrage jeder einzelnen Applikation per Suche mit "-SearchString" oder "-Filter" nach der GUID ist langsamer als die Liste komplett zu holen und danach zu filtern. Allerdings funktioniert dies hier auch in sehr großen Tenants mit sehr vielen Apps.

Zertifikat tauschen

Mittlerweile sind HTTPS-Zertifikate maximal ein Jahr gültig und leider liefert Microsoft selbst erst einmal keinen Support für Let's Encrypt. Sie müssen also schon selbst die Nutzung der Zertifikate überwachen und diese ggfls. tauschen. Bei der Überwachung gibt es zwei Optionen:

  • Die PKI meldet sich, dass ein Zertifikat ausläuft
    Wenn Sie dann eine gute Buchführung haben, wo die Zertifikate genau eingesetzt werden dann können Sie rechtzeitig ein neues Zertifikat einspielen
  • Eigenüberwachung per TLS
    Sie können mit ihrer Überwachungslösung (z.B. PRTG) oder PowerShell Test-CertificateStore oder TLS-Handshake die Gültigkeit auslesen

Ich habe leider noch nicht gesehen, das Azure von sich aus an die Manager oder Owner einer Application frühzeitig eine Warnung sendet.

Die neue PFX können Sie mit dem Kennwort dann einfach einspielen. Sie ersetzt das bestehende Zertifikat. Wichtig ist dabei, dass sie jeden Dient individuell aktualisieren müssen. Es gibt keinen zentralen "Zertifikatsspeicher", in dem man das alte Zertifikat einfach global ersetzt.

Anscheinend gibt es Probleme bei der Auswahl der PFX-Datei, wenn die Extension nicht klein geschrieben ist. Ein "Pfx"-Datei konnte ich nicht hochladen während "pfx" funktioniert hat.

Keine On-Premises-Version

Leider gibt es die Funktion des AzureAD AppProxy nur als Plattform in der Cloud. Manchmal habe ich mich schon gefragt, wo es eine "On-Premises-Version gibt". Wenn ich interne Dienste über den AzureAD Application Proxy aus dem Internet mit Preauthentication etc. verfügbar mache dann könnte ich das intern ja genauso machen.

Heute greifen die internen Anwender direkt auf den Server zu undauthentifizieren sich per NTLM der Kerberos. ich könnte mir es schon interessant vorstellen, die internen Clients, denen ich auch nicht vertraue, ebenfalls auf eine solche Instanz zu leiten und alle Voraussetzungen (Conditional Access etc.) zu prüfen, ehe die Clients auf den Server weitergereicht werden.

Diese Funktion gibt es aber nicht und so muss jede Applikation selbst angepasst werden, damit Sie zur Authentifizierung das AzureAD nutzt. Exchange und Skype for Business können das übrigens schon:

Wann stellen Sie ihre On-Premises-Webanwendungen auf AzureAD um?

Einschätzung

Das war nur ein kleiner Appetithappe, um ihnen eine weitere Funktion von Azure vorzustellen, welche alle Firmen mit Azure AD P1 oder P2-Lizenz einfach so nutzen können. Schon heute können Sie die meisten internen Webseiten, die nur nach erfolgter Authentifizierung erreicht werden dürfen, einfach über diesen Weg deutlich sicherer veröffentlichen.

Wenn der Anwender noch nicht im Browser angemeldet ist, dann wird er sich natürlich beim ersten Zugriff authentifizieren müssen. Aber alle weiteren Dienste über den Azure AD App Proxy erfordern keine weitere Authentifizierung an Azure und landen direkt auf der internen Seite. Dort wird allerdings erneut nach Anmeldedaten gefragt, da eine Anmeldung per Kerberos oder NTLM so nicht möglich ist. Sobald aber die Backend-Applikation mit OAUTH umgehen kann, ist keine weitere Anmeldung erforderlich.

Ich erwarte, dass mehr und mehr Firmen im Besitz einer Azure AD P1-Lizenz sind (durch Microsoft 365 E3, EMS E3 oder Einzelkauf) und damit diese elegante Funktion für die sichere Veröffentlichung von internen Webseiten nutzen können.

AppProxy und Exchange

Natürlich können Sie auch Outlook Web App eines On-Premises Exchange Server per Azure Application Proxy veröffentlichen. Es ist erst einmal "nur" eine Webseite. Allerdings eine eher anspruchsvolle Seite, die auch verschiedene URLs einbindet. Eine einfache Veröffentlichung ohne Seamless Single SignOn erscheint möglich. Allerdings können nicht alle Dienste damit umgehen, dass eine doppelte Authentifizierung erforderlich ist. Wenn Sie nun aber Exchange On-Premises z.B. auf "Hybrid Modern Authentication (HMA)" umstellen um dann mit einem SAML-Token des Azure App Proxy eine Anmeldung zu versuchen, dann gelingt das aber ist nicht stabil. Diese Funktion wurde wohl von Microsoft getestet und als nicht zuverlässig eingestuft. Diese Konfiguration wird daher nicht unterstützt.

Outlook Web App and Exchange Control Panel do not work with hybrid Modern Authentication. In addition, publishing Outlook Web App and Exchange Control Panel through Azure AD Application Proxy is unsupported.
Quelle: https://learn.microsoft.com/en-us/microsoft-365/enterprise/configure-exchange-server-for-hybrid-modern-authentication?view=o365-worldwide#make-sure-you-meet-all-the-prerequisites

Weitere Links