Azure ADConnect und HTTP-Proxy

Der Azure AD Connect steht in der Regel im Intranet und oft dürfen Server nicht direkt mit dem Internet kommunizieren. Der Weg geht über einen HTTP-Proxy und so wird es konfiguriert.

Workload

Die Verbindung von AADConnect erfolgt gegen einen Webservice von Office 365, bzw. genauer dem Azure AD, über den die Identitäten in der Cloud anhand von lokalen Objekten verwaltet werden. Je nach aktivierter Option (z.B. Kennwort Management aus AzureAD) werden auch einzelne Felder der Objekte aus der Cloud in das lokale Medaverse repliziert und dann weiter auf das lokale AD-Objekt angewendet. Für ganz wenige Elemente (z.B. Office Groups, Exchange Public Folder) werden sogar neue Elemente angelegt und aktualisiert.

All diesen Aktionen ist aber gemeinsam, dass der lokale AzureAD Connect-Dienst die aktive Komponente ist und die Verbindung immer von Intern nach Extern aufgebaut wird. Zudem besteht Sie nicht permanent. Der AADConnect-Service verbindet sich in der Regel alle 15 Minuten um Updates nach extern zu übertragen. Es gibt aber Sonderfälle, z.B. bei aktiviertem Office 365 Password Hash Sync. Dennoch ist es eher eine Job-Verarbeitung und es ist in der Regel auch nicht schlimm. wenn ein Sync einige Stunden nicht funktioniert. Es werden dann einfach keine Änderungen übertragen. Das kann stören, z.B. weil Gruppenmitgliedschaften und damit verbundene Berechtigungen, Mailverteiler etc. nicht sofort greifen und neue Benutzer noch nicht arbeiten können.

Aber grundlegend ist HTTP hierfür vollkommen ausreichend und es ist keine permanente TCP-Connection und erst recht keine "Veröffentlichung" des lokalen Service für einen Zugriff aus der Cloud erforderlich. Umgekehrt sind aber schon einige URLs oder Hostnamen zu öffnen, damit AADConnect sich verbinden kann. Diese sind:

Hostname/URL Protokoll Verwendung. 

mscrl.microsoft.com
*.verisign.com
*.entrust.com

HTTP/80

Es wird gerne vergessen aber jede Kommunikation über HTTPS nutzt Zertifikate und jeder Zugriff durch einen Client sollte mit einer Überprüfung des Zertifikats hinsichtlich des Namens, der Gültigkeitsraums aber auch der Rückrufliste erfolgen. Dazu muss der Client natürlich die CRLs erreichen können.

 

*.windows.net

HTTPS/443

Dienste unter dieser URL werden für die Anmeldung am AzureAD genutzt

 

secure.aadcdn.microsoftonline-p.com
https://secure.aadcdn.microsoftonline-p.com

HTTPS/443

Erforderlich für die Multi Faktor Authentifizierung

 

*.microsoftonline.com
https://login.microsoftonline.com 
https://adminwebservice.microsoftonline.com/ProvisioningService.svc

HTTPS/443

Unter dieser URL befinden sich letztlich die Dienste, mit denen AADConnect zum Datenaustausch kommuniziert.

 
aadcnd.msftauth.net
u.a.

HTTPS/443

Es kann immer mal wieder sein, dass speziell der AzureAD Connect Assistent weitere URLs erreichen muss,

Ohne einen HTTP-Proxy muss ihre AADConnect diese Namen per DNS auflösen und die entsprechenden Ziele direkt erreichen können. Hier kann eine Firewall natürlich versuchen die Namen selbst aufzulösen und entsprechende IP-Adressen zu erlauben. Bessere Firewalls aber beobachten den TLS-Handshake mit dem Vorweisen der Zertifikate und erkennen So das Ziel direkt anhand der Namen im Zertifikat um den Zugriff zu erlauben oder zu verhindern. Das ist flexibler und letztlich auch sicherer als IP-Adressen.

Proxy einrichten

Natürlich können die den Kampf gegen Windmühlen führen und darlegen, warum ein direkter Zugriff auf die Office 365 Dienste für alle letztlich der bessere Weg wäre aber meist sind Sie mit AADConnect der erste in der Kette, der diese Bitte stellt. Und allzu viel Gewicht haben sie zu dem Zeitpunkt noch nicht. Das Gewicht kommt erst, wenn auch die Anwender z.B. Exchange Online, SharePoint Online, Skype for Business, Microsoft Teams, OneDrive u.a. nutzen und dabei natürlich auch "von Intern" kommen und über den Proxy-Server gehen. Irgendwann kommt dann doch die Frage der Skalierbarkeit und Performance auf und dann werden ganz andere Personenkreise fordern, dass Office 365 "endlich funktioniert". Siehe dazu auch:

„We recommend bypassing your proxy or inspection infrastructure for direct Office 365 network requests.“
https://support.office.com/en-us/article/Managing-Office-365-endpoints-99cab9d4-ef59-4207-9f2b-3728eb46bf9a#ID0EACAAA=2._Proxies

Aber bist dahin können Sie zumindest AADConnect auch über einen HTTP-Broxy betreiben.

Wichtig: Während der Installation läuft der Code unter ihrem "Benutzernamen" und nutzt dessen Proxy-Einstellungen (Siehe auch Windows Proxy Konfiguration). Beim zweiten Schritt der Konfiguration kommuniziert die GUI aber mit dem darunterliegenden Service, der dann die "Machine-Einstellungen" des NET-Framework nutzt (->machine.config)

Leider nutzt AADConnect anscheinend nicht die eigene .CONFIG-Datei, sondern den Systemproxy. Sie müssen daher die folgende Datei ändern:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config

Als XML-Datei dürfen Sie hier die XML-Datei in der Art anpassen:

<configuration>
  <system.net>
    <defaultProxy>
      <proxy autoDetect="false" 
             bypassonlocal="false" 
             proxyaddress="http://proxy:8080" 
             usesystemdefault="false" />
    </defaultProxy>
  </system.net>
</configuration>

Pflegen Sie hier bitte ihren Proxy-Server und Port ein. Der Server bzw. AADConnect kann sich an dem Proxy dann nur mit dem Rechnernamen authentifizieren. Dennoch ist auch das nicht auf allen Proxy-Servern zuverlässig möglich. Zumindest habe ich bei Kunden immer wieder mal "Effekte", dass AADConnect manchmal Fehler hat.

Die Fehler sind geringer, wenn der Proxy für die oben genannten Zieladressen keine zusätzliche Authentifizierung anfordert, sondern einen anonymen Zugriff erlaubt. Das erspart zudem die zusätzliche Authentifizierung. Generell ist es wünschenswert und ratsam, dass zumindest die Office 365-Ziele keine weitere Authentifizierung erfordern. Aber das dürften Sie wieder mit ihrer IT-Security-Abteilung und deren bislang gültigen Policy abstimmen.

Prüfung

Ob der Proxy funktioniert, können Sie am einfachsten per PowerShell verifizieren. Die PowerShell nutzt ihrerseits ja auch das NET-Framework und wird damit auch den Systemproxy aus der machine.config verwenden. Folgender Aufruf sollte eine "200 OK"-Meldung liefern.

PS C:\> Invoke-WebRequest -Uri https://adminwebservice.microsoftonline.com/ProvisioningService.svc

StatusCode        : 200
StatusDescription : OK
Content           : <HTML><HEAD><STYLE type="text/css">#content{ FONT-SIZE: 0.7em; PADDING-BOTTOM: 2em; MARGIN-LEFT:
                    30px}BODY{MARGIN-TOP: 0px; MARGIN-LEFT: 0px; COLOR: #000000; FONT-FAMILY: Verdana;
                    BACKGROUND-COLOR: wh…
RawContent        : HTTP/1.1 200 OK
                    X-Powered-By: ASP.NET
                    Strict-Transport-Security: max-age=31536000; includeSubDomains
                    Date: Mon, 04 Jan 2021 22:24:17 GMT
                    Content-Type: text/html; charset=utf-8
                    Content-Length: 643…
Headers           : {[X-Powered-By, System.String[]], [Strict-Transport-Security, System.String[]], [Date,
                    System.String[]], [Content-Type, System.String[]]…}
Images            : {}
InputFields       : {}
Links             : {@{outerHTML=<a href="http://go.microsoft.com/fwlink/?LinkId=65455">http://go.microsoft.com/fwlink/
                    ?LinkId=65455</a>; tagName=A; href=http://go.microsoft.com/fwlink/?LinkId=65455}}
RawContentLength  : 6437
RelationLink      : {}

Wenn aber ein Fehler o.ä. kommt, dann sollten Sie auf dem Proxy-Server die Authentifizierung oder Bypass-Listen prüfen.

Hinweis: Auch der Test läuft mit ihrem Benutzernamen und ist kein Garant, dass der Computer die gleichen Berechtigungen hat. Notfalls hilft eine Powershell mit PSEXEC als LocalSystem zu starten.

Einschätzung

Der Einsatz eines HTTP-Proxy-Servers als Relay-Station zwischen AADConnect im internen LAN und Azure AD im Internet ist möglich und aufgrund des Kommunikationsprofils tolerierbar. Einen Sicherheitsgewinn kann ich darin aber nicht sehen. Mich würde eher stören, dass ein weiteres System als mögliche Fehlerquelle dazwischen steht und viele Firmen die Funktion von AADConnect nur rudimentär überwachen. Der Dienst ist zum Glück nicht zeitkritisch und kann oft unbemerkt mehrere Stunden oder sogar Tage ausfallen. Meist erkennen Administratoren ein Problem erst, wenn die Tickets aufgrund partiell nicht zugestellter Mails (Verteiler nicht aktuell) zunehmen oder neue Mitarbeiter immer noch kein Postfach haben.

Mittlerweile überwacht Microsoft Office 365 schon einmal, wie oft sich ihr On-Prem AADConnect-Dienst mit der Cloud verbindet und informiert den Office 365 Administrator. Das bringt aber nicht, wenn der Administrator seine Mails nicht liest. Sie wissen nun zumindest , wie Sie die Konfiguration entsprechend anpassen.

Weitere Links