Azure Multi-Faktor-Authentifizierung (lokal)

[wznutzer 35]

Hallo,

 

um die Azure MFA mit einem lokalen AD zur Authentifizierung eines Remote-Desktop-Gateay zu verwenden muss die lokale Installation verwendet werden. Es gibt jede Menge Infos dazu im Netz, so dass ich keine Bedenken habe das zum Laufen zu bringen. Was mir aber gar nicht gefällt, ist dass ich für den lokal installierte MFA-Server einen Port zu meinem Netzwerk aufmachen muss. Die eine Tür sichere ich doppelt ab um gegenüber eine neue Tür zu öffnen.

 

Hat das jemand von euch im Einsatz und wenn ja wie habt ihr das abgesichert?

 

Variante 1

Port auf und fertig. Das Exchange-Team sagt ja inzwischen auch, dass ein Exchange mit einer einfachen Portweiterleitung sicher genug ist.

 

Variante 2

Port auf und fertig, aber nur IP-Adressen erlauben die von Azure kommen? Habe keine Doku gefunden in der z. B. ein IP-Adressen Bereich genannt wird.

 

Variante 3

Lokaler MFA-Server in ein sep. Netzsegment. Da müsste ich aber soviel zum Produktivnetz öffnen, dass mir das nicht sicherer erscheint als den MFA-Server direkt in der Domäne zu betreiben.

 

Variante 4

Zugriffe über einen Reverse-Proxy absichern. Doku habe ich keine gefunden. Wenn ich dann aber so viele Regeln abschalten muss, dass es funktioniert ist das dann auch wieder nur Scheinsicherheit.

 

Habt ihr mir dazu ein paar Tipps?

 

Natürlich gibt es andere Anbieter, aber die Microsoft-Lizenzen, nennt man das Pläne bei Azure, sind sowieso schon vorhanden.

[testperson 1.675]

Hi,

 

du _musst_ AFAIK nichts nach innen öffnen. Und wenn wäre es https für die Webdienste der Mobile-App. Ob man das Portal im Web veröffentlicht, wäre eine andere Frage. Aber dort würdest du dich dann mit dem zweiten Faktor anmelden.

 

Theoretisch könntest du ja die Devices mit der App auch ausschließlich im eigenen Netz provisionieren sowie das Portal auch nur dort bereitstellen.

 

Gruß

Jan

[wznutzer 35]

Guten Abend,

du _musst_ AFAIK nichts nach innen öffnen. Und wenn wäre es https für die Webdienste der Mobile-App. Ob man das Portal im Web veröffentlicht, wäre eine andere Frage. Aber dort würdest du dich dann mit dem zweiten Faktor anmelden.

 

Theoretisch könntest du ja die Devices mit der App auch ausschließlich im eigenen Netz provisionieren sowie das Portal auch nur dort bereitstellen.

Deine Aussage passt nicht zu dem Bild das ich mir im Kopf gemalt habe. Allerdings basiert mein Wissen bisher ausschließlich auf dem Lesen von Dokus, also potentiell falsch. Das Portal will ich nicht veröffentlichen, aber mit der Smartphone-App arbeiten. Dazu muss ich dann doch einen Port nach "innen" öffnen, weil die Webdienste für die Mobile-App bei mir installiert sind. Oder kann ich diese Webdienste auch zu Azure auslagern? Alternativ müsste ich mit der Authentifizierung per SMS arbeiten. Aber die App wäre halt eleganter. Um den Port für die Webdienste der Smartphone-App geht es mir. Dahinter ist dann ein IIS direkt in meinem Produktivnetz. Das will mir nicht gefallen. Habe ich da was falsch verstanden?

[NorbertFe 2.034]

Bist du dir sicher, dass du eingehend was aufmachen mußt? Als ich mich das letzte Mal mit dem Thema beschäftigt habe, stand dort nur, dass der MFA onpremise Server nach aussen kommunizieren können muß. AFAIR https.

https://docs.microsoft.com/de-de/azure/multi-factor-authentication/multi-factor-authentication-get-started-server

 

Oder meinst du was anderes?

 

Bye

Norbert

[testperson 1.675]

Eingehend wäre es halt max. HTTPS. Aber es bliebe die Frage, ob man das zwingend will / muss.

Und nur ein Reverse-Proxy davor macht es auch nicht direkt wirklich sicherer ;)

[NorbertFe 2.034]

Also ich mag mich ja irren, aber wo steht da was von eingehend? Ich hatte das mal PoC für Cisco Jabber bei einem Kunden konfiguriert mittels Telefonn und SMS (ohne App) und da wurde definitiv nix eingehendes geöffnet.

[testperson 1.675]

Aus https://docs.microsoft.com/de-de/azure/multi-factor-authentication/multi-factor-authentication-get-started-server-webservice

 

 

...

• Der Webdienst der mobilen App ist über eine öffentliche URL erreichbar.

...

• Wenn sich vor dem Webserver mit dem Webdienst der mobilen App ein Reverseproxy oder eine Firewall befindet und eine SSL-Abladung durchführt, können Sie die Datei „web.config“ des Webdiensts der mobilen App bearbeiten, damit der Webdienst der mobilen App HTTP anstelle von HTTPS verwenden kann. Für die Verbindung zwischen der mobilen Anwendung und der Firewall/dem Reverseproxy ist weiterhin SSL erforderlich. Fügen Sie dem Abschnitt <appSettings> den folgenden Schlüssel hinzu:

 

Zum Einen heißt das nicht zwingend, dass die Webdienste im Internet veröffentlicht sein müssen und zum Anderen bleibt die Frage, ob man die veröffentlichen will.

HTTPS wird nur gebraucht um die Authenticator App am Telefon / Tablet von extern zu konfigurieren (QR Code scannen / Code eingeben). Ansonsten _muss_ nichts erreichbar sein.

[NorbertFe 2.034]

Danke für die Info.

[wznutzer 35]

Hi,

HTTPS wird nur gebraucht um die Authenticator App am Telefon / Tablet von extern zu konfigurieren (QR Code scannen / Code eingeben). Ansonsten _muss_ nichts erreichbar sein.

 

danke. Dieser Teil hat mir gefehlt. Ich werde das jetzt einfach mal installieren.

 

Grüße