Teil 3: VerSAMLung – SSO mit SAML und FAS für Citrix CVAD

(von Benjamin Rodewald und Denis Junger)

Nachdem wir uns in Teil 1 und Teil 2 der Serie „VerSAMLung“ mit Webapplikationen beschäftigt haben, betrachten wir in Teil 3 die Anbindung von Citrix Virtual Apps and Desktops (CVAD) mit Azure Active Directory Anmeldung. Da auch hier kein Kennwort vorliegt, welches für ein Single Sign on genutzt werden könnte und der Storefrontserver kein KCD unterstützt, kommt eine weitere Citrix Komponente „Citrix Federated Authentication Service“ (FAS), welche eine virtuelle Smartcard Anmeldung am Citrix Desktop ermöglicht zum Einsatz.

Dies ermöglicht dem User ein einmaliges Anmelden an seinem Azure AD integriertem Notebook und danach ohne weitere Passworteingabe direkt auf Citrix CVAD zuzugreifen.

Vorbereitenden Maßnahmen

Installation Citrix FAS, vollständige Anleitung unter: Install and configure | Federated Authentication Service 2112 (citrix.com)

Federation Service

Editieren der Default Rule auf dem Citrix FAS
Storefront Server Berechtigungen
Dieses Bild hat ein leeres Alt-Attribut. Der Dateiname ist image.png
VDA Berechtigungen (in dieser kleinen Testumgebung haben wir keine spezielle Ausnahme gemacht)
Benutzer Berechtigungen (Auch hier dürfen alle Benutzer die Regel nutzen) 

FAS integration für den Storefront Store aktivieren (Per Powershell auf dem Storefrontserver ausführen, dabei Storenamen anpassen): 

Get-Module "Citrix.StoreFront.*" -ListAvailable | Import-Module
$StoreVirtualPath = "/Citrix/Store"
$store = Get-STFStoreService -VirtualPath $StoreVirtualPath 
$auth = Get-STFAuthenticationService -StoreService $store 
Set-STFClaimsFactoryNames -AuthenticationService $auth -ClaimsFactoryName "FASClaimsFactory" 
Set-STFStoreLaunchOptions -StoreService $store -VdaLogonDataProvider "FASLogonDataProvider" 

Powershell Kommandozeile

Storefront Konfiguration

Als nächstes muss nun überprüft werden ob die entsprechenden Authentication Methods aktiviert sind. Hierbei ist darauf zu achten, dass unter „Pass-through from Citrix Gateway“ der Haken unter „Configure Delegated Authentication“ gesetzt ist:

Authentication Methods
Das Setzen des Hakens veranlasst den Storefront komplett dem Gateway zu vertrauen für die Anmeldedaten. Hierfür ist dann allerdings ein sog. Callback erforderlich, den wir im nächsten Schritt konfigurieren.
Es sollte später geprüft werden, ob die Callback URL eingetragen und auch von den Storefrontservern erreichbar ist.
Wichtig: das Gateway/ Callback -RL Zertifikat muss dabei vom Storefront als Vertrauenswürdig betrachtet werden, sonst funktioniert der Callback nicht.

Einrichtung Gateway Virtual Server auf dem ADC

Als nächstes muss man das Citrix Gateway konfigurieren. Wenn noch kein Gateway existiert kann mit dem Wizard eins mit Standard Settings erstellt werden:

Erstellen des Citrix Gateway via Wizard

Name, VIP, FQDN und Port festlegen

Zertifikat anbinden

zu Testzwecken haben wir ein selbst signiertes Zertifikat genommen (welches wir auch auf dem Storefront als vertrauenswürdig hinzugefügt haben)

Als Primäre Authentication haben wir Radius genommen (entfernen wir später wieder), andernfalls läuft der Wizard nicht weiter. Dann wählen wir das Portaltheme aus.

Die Anbindung von CVAD erfolgt im Abschnitt „Applications“. Auf Add Applications klicken um die Applikationen hinzuzufügen.

in unserem Fall wählen wir XenApp & XenDesktop (der neue Name scheint im Wizard noch nicht angekommen) und wählen als Integrationspunkt den Storefront aus.

Storefront URL und STA Adresse hinzufügen

Mit Done wird der Wizard geschlossen und das Gateway ist gebaut.

Einrichtung Enterprise Application im Microsoft Azure Portal

Auch hier benötigen wir wieder eine Enterprise Applikation in Azure AD wie in Teil 1 schon beschrieben.

Gateway/ SAML SP Konfiguration auf dem ADC

Nun entfernen wir die Dummy Radius Policy, die wir mit dem Wizard erstellt haben.
Statt der Radius Policy legen wir jetzt einen AAA Virtual Server an, an den wir die SAML Policies binden und den wir später selber in Netscaler N-Factor Manier per Authentication Profile an das Gateway binden.
add authentication vserver aaamwdemo SSL 0.0.0.0

Zertifikat an den AAA Virtual Server binden (tritt hier nicht äußerlich in Erscheinung, muss aber vorhanden sein).
bind ssl vserver aaamwdemo -certkeyName mwdemo.cer
Zuerst legen wir ein SAML SP Server Objekt an.

Die „Redirect“ und die „Single Logout Url“ sind bei unserem Beispiel (Microsoft Azure AD) gleich und können den Settings der Enterprise Application im Azure entnommen werden („Reply URL“ und „Single Sign On Url“).

Dort laden wir uns ebenfalls das „SAML Signing“ als „Certificate (Base64)“ herunter und fügen es auf dem ADC als „IDP Certificate“ über den Knopf „Add“ hinzu (siehe nächster Screenshot).

Das EA Feld „Identifier“ im Azure und das Feld „Issuer“ auf dem ADC müssen den gleichen Text String enthalten, wir haben die URL/den FQDN des SAML-SP verwendet.

Nach Citrix Best Practices muss zur Absicherung eine Relaystate Regel konfiguriert werden (vergl. Citrix Application Delivery Controller and Citrix Gateway – SAML Configuration Reference Guide):
https://support.citrix.com/article/CTX316577

Relaystate Rule
add authentication samlAction AzureSSOHapp-Citrix-ADC-CVAD -samlIdPCertName Citrix-ADC-CVAD -samlRedirectUrl "https://login.microsoftonline.com/ddff6db-154e-4e33-bf57-17317fdfdfd/saml2" -samlIssuerName "https://mwdemo.michael-wessel.de" -relaystateRule "AAA.LOGIN.RELAYSTATE.EQ(\"https://mwdemo.michael-wessel.de\")" -logoutURL "https://login.microsoftonline.com/17db-154e-4e3d-b8f-f9eb1e8d/saml2"

Hinzufügen des SAML-IDP Zertifikats.
add ssl certKey Citrix-ADC-CVAD -cert "Citrix ADC CVAD.cer"
Das SAML SP Server Objekt verdrahten wir in einer neu angelegten SAML SP Policy die wir an den zuvor erstellten AAA Virtual Server binden.
add authentication Policy pol_AzureSSOHapp-Citrix-ADC-CVAD -rule true -action AzureSSOHapp-Citrix-ADC-CVAD

Binden an den AAA
bind authentication vserver aaamwdemo -policy pol_AzureSSOHapp-Citrix-ADC-CVAD -priority 100 -gotoPriorityExpression NEXT
Im nächsten Schritt legen wir ein Authentication Profile an, welches die AAA Settings zusammenfasst und die Bindung an das Gateway ermöglicht.
Im Profil wird der AAA Virtual Server verknüpft.
Die Domain kann leer gelassen werden oder wenn der Cookie von verschiedenen Virtual Servern genutzt werden soll, die übergeordnete Domain angegeben werden.
add authentication authnProfile auth_prof_aaamwdemo_Citrix_ADC_CVAD -authnVsName aaamwdemo

Über den Punkt „Authentication Profile“ wird das Profil an den Gateway Virtual Server gebunden.
Hinweis: Das Objekt sollte danach nicht mehr mit dem Wizard bearbeitet werden.

Dem aufmerksamen Betrachter sind vielleicht die SSL Settings des Gateways aufgefallen. Diese sind so vom Wizard erzeugt worden und nur für eine Testumgebung einzusetzen. Für den produktiven Einsatz wären diese anzupassen (z.B. SSL abschalten, Perfect Forward Secrecy implementieren, aktuelles Cipherset erstellen).

Test der fertigen Konfiguration

Wenn man sich nun von einem nicht Azure AD integrierten Gerät anmelden würde, erschiene je nach Azure Conditional Access Konfiguration ggf. einfach die Azure Anmeldeseite und/oder die Tokenabfrage auf dem Mobiltelefon und danach die Storefront oder RFWEBUI Oberfläche, von der aus man die Applikationen starten kann.

Wenn sich der User an einem Azure AD integrierten Gerät anmeldet, ist er danach direkt am Azure AD angemeldet. Greift er dann auf den ADC zu , wird er dort über die Vertrauensbeziehung zwischen ADC als SAML SP und Azure AD als SAML IDP direkt angemeldet und kann die Applikationen starten.

Wie im Folgenden Video zu sehen ist nur die Anmeldung am Notebook/ Desktop erforderlich, alles weitere erfolgt über Single Sign On:

SSO mit Azure AD Anmeldung

Teil 2: VerSAMLung – SSO mit SAML oder KCD für interne Webservices (mit Citrix NetScaler)

(von Stefan Kuscher und Benjamin Rodewald)

Im ersten Teil unserer Serie „verSAMLung“ haben wir den Citrix Application Delivery Controller (ADC) als SP an die MS Azure MFA Authentifizierung (als IdP) angebunden und so die bequeme und transparente Nutzung von Applikationen auf dem Citrix ADC möglich gemacht, welche mit einer Pre-Authentifizierung geschützt sind.

Bisher muss man sich nach der Anmeldung am Azure (welche der ADC nutzt) noch immer an der eigentlichen Applikation anmelden, aber auch dafür gibt es eine Lösung. Der ADC bietet die Möglichkeit Anmeldedaten zu extrahieren und die diese auch für den Single Sign On im Backend zu benutzen. Im einfachsten Fall, könnte die dem ADC bekannte Username/ Kennwort Kombination z.B. für eine 401 Header Based Authentication genutzt werden, hierfür wäre lediglich eine Traffic Policy, welche Web Single Sign On anschaltet, notwendig.

In Verbindung z.B. mit SAML oder Certificate based Authentication ist das Vorgehen ein klein wenig komplizierter, da auf dem ADC keine Anmeldedaten vorliegen (was dem Sicherheitsniveau natürlich sehr zuträglich ist). Hier muss ein Verfahren genutzt werden, welches alleine mit den im SAML Token vorhandenen oder im Zertifikat vorhandenen Informationen auskommt. Neben der Möglichkeit hier im Backend ebenfalls SAML für den SSO zu benutzen, gibt es die Möglichkeit Kerberos Constrained Delegation (KCD) zu nutzen. Da sämtliche Applikationen aus dem Windows Umfeld damit sehr einfach angebunden werden können, bietet sich diese Möglichkeit oft an um eine Applikationen zu verSAMLen (SAML fähig zu machen).

DNS und NTP auf dem ADC

Wie auch in den späteren Logs erkennbar sein wird, benötigt der Netscaler für die Nutzung von Kerberos eine funktionierende DNS Auflösung der Windows Active Direcory Domain und eine per NTP korrekt synchronisierte Uhrzeit. Für die Domain/ den DC kann theoretisch auf dem Netscaler auch manuell ein Ressource Record hinzugefügt werden. Zur Zeitsynchronisation sind idealerweise mindestens zwei NTP Server einzutragen und die Synchronisation einzuschalten.

Konfiguration AD Account / Delegation

Bei der Constrained Delegation wird ein Servcie Benutzer für den NetScaler angelegt, dem dann die Delegierung (Zugriff im Auftrag eines anderen Benutzers) erlaubt wird:

Nachdem der Benutzer angelegt wurde, muss der HOST SPN gesetzt werden, damit die Regsiterkarte „Delegation“ erscheint:

setspn -S HOST/[Name d. Deleg.-konto].[FQDN] [NetBIOS-Domainname]\[Name d. Deleg.-konto]

Setzen des Host SPN
Kerberos Delegierungskonto 1/2

Auf der Registerkarte „Delegation“ des Accounts wird dann die eigentliche Delegierung konfiguriert, der Service SPN „http/demoweb.mwdemo.local@MWDEMO.LOCAL“ für einen internen Microsoft IIS Webserver.

Kerberos Delegierungskonto 2/2

Konfiguration KCD auf dem ADC

Für den Account wird dann auf dem ADC ein KCD Objekt erstellt, welches in einer Traffic Policy eingebunden wird:

ADC / KCD-Account
add aaa kcdAccount wiakcd_appdelegation -realmStr MWDEMO.LOCAL -delegatedUser appdelegation -kcdPassword b616477dhgkjifdghuidf4757747593458930580f -encrypted -encryptmethod ENCMTHD_3 -kek -suffix 2021_yy_yy_yy8 -userRealm MWDEMO.LOCAL -serviceSPN "http/demoweb.mwdemo.local@MWDEMO.LOCAL"

Steuerung SSO mittels Traffic Policy und Profile

Mittels einer Traffic Policy und einem Traffic Profile, welches auf dem Load Balancing Vserver gebunden wird, wird gesteuert an welchen Stellen die KCD SSO Settings angewendet werden sollen:

Traffic Profile (unten ist der KCD Account ausgewählt)
add tm trafficAction prof_traf_wia_demoweb_kcd -SSO ON -persistentCookie OFF -InitiateLogout OFF -kcdAccount wiakcd_appdelegation

Traffic Policy über die das o.g. Profile angebunden wird
add tm trafficPolicy pol_traf_wia_demoweb_kcd true prof_traf_wia_demoweb_kcd

Debugging

Ein Debugging ist mittels cat /tmp/nkrb.debug möglich.

Bei unserem ersten Versuch in der Demo Umgebung gab es wegen den unterschiedlichen Realms in Verbindung mit dem Azure AD noch Probleme:

Log Fehler

Wir haben daraufhin in den KCD Settings das Feld „User Realm“ ergänzt, dies verhindert, dass wie oben eine Cross Realm Authentifizeirung zwischen Azure AD und AD Domäne versucht wird. Somit wird die Anfrage „Username@michaelwesseldemo.onmicrosoft.com“ zu der passenden Anfrage „Username@mwdemo.local“ umgewandelt. Dieser „Workaround“ betrifft unserer Testumgebung aufgrund der fehlenden routingfähigen Domäne.

Hier die Logs des Erfolgsfalls:

Log Erfolg – 1
Log Erfolg – 2
Log Erfolg – 3
Log Erfolg – 4
Log Erfolg – 5
Log Erfolg – 6
Log Erfolg – 7

Teil 1: VerSAMLung – Microsoft Azure SSO am Citrix ADC/ NetScaler mit SAML

(von Stefan Kuscher und Benjamin Rodewald)

Im Nachfolgenden erläutern wir die Vorteile, wenn Citrix ADC und Azure Active Directory verSAMLt sind und wie wir dies umgesetzt haben.

Folgende Vorteile ergeben sich:

  • Benutzer muss lediglich beim Anmelden am Arbeitsgerät ein Passwort eingeben (SSO) und ist somit automatisch beim Citrix NetScaler bekannt und bestenfalls alles was mit diesem verknüpft ist. Von dort aus kann z.B. der Zugriff auf Applikationen wie Citrix Xenapp/XenDesktop oder auch Web-Applikationen erfolgen. (Ohne zusätzliche Anmeldung)
  • Azure AD als der Zugangspunkt für Benutzer.
  • Benutzersteuerung/Berechtigungsverwaltung zentral in Azure AD.
  • Conditional Access\Begrenzter Zugriff + MFA (Azure AD P1 Lizenz)

Voraussetzungen

Ablauf

Abbildung Ablauf SAML

Das SAML Protokoll wurde geschaffen um über eine Teilung in Identity Provider (IdP) und Service Provider (SP) die Authentication für Zugriffe zu ermöglichen. Dabei kann sofern eine Applikation z.B. aus der Cloud bezogen wird, trotzdem gegen einem IdP, der unter Kontrolle des eigenen Unternehmens steht authentifiziert werden (in unserem Falle ist dieser in der Cloud als MS Azure AD ausgeprägt). Der SAML SP (AAA auf dem ADC) vertraut diesem IdP und lässt den Request beim Vorhandensein der Authentifizierungsinformationen passieren. Sind die Informationen nicht vorhanden, würde der Citrix ADC auf die Anmeldeseite des SAML IdP weiterleiten.

In unserem speziellen Fall meldet das Gerät bereits beim MS Windows Logon den Benutzer in der Cloud beim Azure AD an. Der Benutzer besitzt daher zum Zeitpunkt seines ersten Zugriffs schon die entsprechenden Anmeldeinformationen und der ADC (bzw. die AAA / SP Komponente) lässt den Benutzer mit SSO passieren.

Deployment einer Enterprise Applikation in Azure (IDP)

Um eine Kommunikation mit dem Citrix ADC via SAML herzustellen benötigt man auf der Azure Active Directory Seite eine Enterprise Applikation. Diese wird im Azure Active Directory -> Enterprise Applications -> New Application
bereitgestellt und wird benötigt um sich mit dem SP per SAML auszutauschen.

Auswählen einer Vorlage im Browse Azure AD Gallery für das Citrix SAML Add On
Microsoft bietet bereits diverse Vorlagen für Enterprise Applikationen an. In unserem Fall benötigen wir die Vorlage „Cirix ADC SAML Connector for Azure AD“.

In der Enterprise Applikation müssen die benötigten Informationen wie Identifier, Reply URL und Sign On URL des Citrix ADC hinterlegt werden.

1.) Enterprise Applikation -> Name der APP -> Single Sign-on
Identifier: https://FQDN
Reply URL: http(s)://FQDN der WebApplication/cgi/samlauth
Sign On URL: https://FQDN/CitrixAuthService/AuthService.asmx


Ebenfalls finden sich dort die Informationen die der Citrix ADC im späteren Verlauf benötigt z.B. die Login URL von Azure Active Directory oder die Metadaten URL.

2.) Mittels Metadaten URL kann der Austausch der Informationen zwischen AAD und ADC automatisch erfolgen. Voraussetzung hierfür ist dass die Version des CItrix ADC den Austausch via Metadaten bereits unterstützt.

3.) Falls ein Austausch via Metadaten nicht in Frage kommt ,können die Informationen auch manuell dem Citrix ADC übergeben werden (Login URL, Zertifikat…).

Screenshot aus dem Citrix ADC SAML Connector

Berechtigungskontrolle für die Enterprise Applikation

Im Anschluss müssen die Benutzer noch die Berechtigungen erhalten, um die Enterprise Applikation nutzen zu können. In unserem Fall stellen wir die Applikation für alle Benutzer zur Verfügung. Wir deaktivieren somit die Zuweisung für einzelne Benutzer komplett:

Assignment required = No

Screenshot Zuweisung einzelner Gruppen und Nutzer
Falls eine Zuweisung an einzelne Benutzer erwünscht ist, einfach „Assignment required“ auf „Yes“ umstellen (Standardeinstellung) und die Zuweisung für Benutzer unter „Users and Groups“ durchführen.

Konfiguration des AAA Servers / SAML SPs auf dem ADC

Um eine Applikation auf dem Netscaler mit einer Preauthentication zu schützen, kommt die AAA Funktion zum Einsatz. Hierfür wird ein AAA Virtual Server Objekt angelegt, welches in der SAML Welt gleichzeitig den SAML Service Provider (SP) darstellt, der in unserem Fall dem Microsoft Azure Identity Provider (IdP) vertraut. Um für eine Web Applikation die Anmeldung am AAA bzw. dem SAML IdP zu erzwingen, wird der AAA Vserver auf dem enstprechenden Load Balancer oder Content Switch Objekt über die „Authentication“ Registerkarte verknüpft.

Anlage des AAA Virtual Servers

Screenshot  Anlage des AAA im Authentication Virtual Servers
add authentication vserver aaademo SSL 0.0.0.0

Ein SSL Zertifikat muss gebunden werden, auch wenn der AAA Vserver nicht direkt angesprochen wird.

bind ssl vserver aaademo -certkeyName AAA_test
bind ssl vserver aaademo -eccCurveName P_256
bind ssl vserver aaademo -eccCurveName P_384
bind ssl vserver aaademo -eccCurveName P_224
bind ssl vserver aaademo -eccCurveName P_521

Screenshot SSL Virtual Server Server Certificate Binding

SAML SP Server

Falls der Import der Metadaten nicht funktioniert, können die Daten auch aus dem XML extrahiert werden und manuell hinterlegt werden. Das IdP Zertifikat lässt sich auf der Azure Enterprise Appliacation im Azure Portal exportieren (Base64 bietet sich an).

Screenshot mögliche Konfiguration aus dem Configure Authentication SAML Server
SAML Action 1/3
SAML Action 2/3

Nach Citrix Best Practices muss zur Absicherung eine Relaystate Regel konfiguriert werden (vergl. Citrix Application Delivery Controller and Citrix Gateway – SAML Configuration Reference Guide):

SAML Action 3/3 – Relaystate Regel
add authentication samlAction AzureSSOHapp-SAMLServer -samlIdPCertName ADC-SAML-Connector -samlRedirectUrl "https://login.microsoftonline.com/883dfdf-154e-4fdf33-b857-1dfdf8d/saml2" -samlIssuerName "https://vipdemo.michael-wessel.de" -relaystateRule "AAA.LOGIN.RELAYSTATE.EQ(\"https://vipdemo.michael-wessel.de/\")" -logoutURL "https://login.microsoftonline.com/8dda6db-dde-4e33-dddd7-173179eb1e8d/saml2"

SAML SP Policy

Screenshot Configure Authentication Policy
add authentication Policy pol_AzureSSOHapp -rule true -action AzureSSOHapp-SAMLServer

Die erstellte SAML SP Policy muss dann an den AAA Virtual Server / SAML SP gebunden werden und der AAA Virtual Server auf der Registerkarte „Authentication“ des Load Balancers oder Content Switches verknüpft werden. Auf ADCs mit einer aktuellen Firmware haben sich zudem die Defaults für die Athorization geändert, so dass eine pasende Authorization Policy anzulegen ist.

Ausblick

Mit dem Vorliegen der Anmeldeinformationen kann auf dem Netscaler auch eine detaillierte Berechtigung auf bestimmte URLs anhand von z.B. Gruppenmitgliedschaften über Authorization Policies erfolgen.

Außerdem ist es möglich authentifizierte Benutzer z.B. per SAML oder KCD an Servern hinter der Pre-Authentication automatisch anzumelden.

Im MS Azure sind umfangreiche Möglichkeiten der Multi Faktor Authentifizierung und des Conditional Access möglich.

Mehr zu diesen und anderen Möglichkeiten werden sie in den weiteren Artikeln unserer Serie „verSAMLt“ lesen.

Microsoft <3 Europe

Microsoft kündigte gestern in einem Blogpost an, künftig alle Daten ihrer EU-Kunden innerhalb der EU zu halten und spricht dabei von einer „EU Data Boundary for the Microsoft Cloud“. Dies gilt für Azure, Microsoft 365 und Dynamics 365.

Wir haben heute ein wichtiges Versprechen für unsere Kunden in Europa gegeben. Microsoft wird es in der EU ansässigen Kunden aus dem öffentlichen Sektor und Unternehmenskunden künftig ermöglichen, all ihre Daten innerhalb der EU zu verarbeiten und zu speichern. In anderen Worten: Wir werden keine Daten dieser Kunden aus der EU heraus transferieren müssen.

https://news.microsoft.com/de-de/unsere-antwort-an-europa-microsoft-ermoeglicht-speicherung-und-verarbeitung-von-daten-ausschliesslich-in-der-eu/

Zuletzt gab es immer wieder Kritik von Datenschützern, die sich gegen einen Einsatz von modernen Tools, wie Microsoft Teams ausgesprochen haben. Teilweise aus technischem Unverständnis oder aus Angst über den Kontrollverlust der Daten. Ob dies alles auch berechtigte Kritik gewesen ist, sei mal dahingestellt. Nichtsdestotrotz ist das ist ein starkes Versprechen, seitens Microsoft und wird hoffentlich so manchen Zweifler milde stimmen.

Angekündigt sind die Maßnahmen für Herbst 2021. Wir bleiben also als Partner dran und informieren unsere Kunden umgehend über die Entwicklungsschritte.

Zero Day Sicherheitslücke in Microsoft Exchange

Wie vor einigen Tagen bekannt wurde, hat eine Hacker-Gruppierung namens Hafnium mehrere Zero-Day-Sicherheitslücken in Microsoft Exchange ausgenutzt. Am vergangenen Freitag hat das Bundesamt für Sicherheit in der Informationstechnik (BSI) die „IT-Bedrohungslage Rot“ ausgerufen und aufgefordert, die Lücke schnell zu schließen. Ab 26. Februar begannen die Angreifer zusätzlich offenbar damit, automatisiert Hintertüren in verwundbare Exchange Server von Microsoft einzubauen, tausende Server pro Stunde wurden so attackiert. Erst am 3. März wurde zur Schließung der Sicherheitslücke ein Update von Microsoft zur Verfügung gestellt.

Bei uns auch?

Wie sicher sind Sie, dass Sie aktuell nicht betroffen sind?  

Microsoft hat für Sofort-Checks auf dem Exchange Server Analyse-Werkzeuge bereitgestellt, die wir sehr gerne für Ihren Schutz einsetzen. Wir haben in den letzten Tagen bereits zahlreiche betroffene Systeme bereinigt, neu aufgesetzt und für die Zukunft durch das Einspielen der aktuellen Patches neu abgesichert.

Gerne sind wir schnell für Sie mit Sofortmaßnahmen aktiv.
Sprechen Sie uns jederzeit an.

Outlook Mobile: Microsoft sendet Mitteilungen an Outlook-User

Microsoft aktualisiert die Ankündigung „Benachrichtigung über Outlook Mobile in Outlook“ (MC207028) und erweitert das Gebiet auch auf Europa.

Seit dem 12. August 2020 informiert Microsoft an Outlook Benutzer, die noch kein Outlook Mobile nutzen, darüber das es Outlook auch für iOS und Android gibt.

Außerdem befindet sich in dieser Benachrichtigung ein Link, über den sich der Nutzer komfortabel die Outlook Mobile App für Android oder iOS Herunterladen können bzw. wird hier auf die entsprechende App Stores der beiden Plattformen verwiesen.

Wird diese Benachrichtigung geschlossen oder der Benutzer installiert sich Outlook Mobile, erscheint keine erneute Benachrichtigung.
Jedoch kann die Benachrichtigung auch zentral administrativ über ein entsprechendes cmdlet in Powershell deaktiviert werden.

Sollten Sie diese Nachrichten bei Ihnen und ihren Nutzern nicht wünschen, können wir sie dabei gerne unterstützen.

Wenden Sie sich daher gerne vertrauensvoll an uns.

Aus der Microsoft Cloud Deutschland heraus migrieren

Nachdem Microsoft schon vor einiger Zeit die Microsoft Cloud Deutschland (MCD) im Treuhändermodell abgekündigt hat, fragten uns viele Kunden nach einer Migrationsmöglichkeit. Insbesondere, da Bestandskunden der MCD keine neuen Services mehr buchen können.

Bisher gab es nur direkte Migrationsmöglichkeiten von einigen Azure-Diensten, die möglich waren. Immer wieder mussten wir Office 365 Kunden leider mitteilen, dass eine Migration nicht ohne weiteres möglich ist. Besonders ärgerlich für Kunden, die vor nicht all zu langer Zeit erst von lokal in die Deutschlandcloud migriert sind. Es kamen also erneut Kosten und Ausfallzeiten hinzu. Ganz davon abgesehen, dass der technische Migrationspfad von Cloud zu Cloud nur über Umwege und nicht weniger aufwändig ist wie von lokaler Infrastruktur in die Cloud.

So waren wir überrascht, vor kurzem in den Microsoft Tech-Docs auf einen Artikel vom 09.12.2019 zu stoßen, der eine „geleitete“ Migration von Office 365-MCD zu den neuen deutschen Rechenzentrumsregionen verspricht.

Quelle:
https://docs.microsoft.com/de-de/office365/enterprise/ms-cloud-germany-transition

Zitat: „Die bestehenden Kunden von Microsoft Cloud Germany (Microsoft Cloud Deutschland) können nun mit der Migration ihrer Office 365, Dynamics 365 Customer Engagement und Power Platform BI beginnen. Der erste Schritt besteht darin, sich für die von Microsoft geleiteten Migration in unsere neuen deutschen Rechenzentrumsregionen anzumelden.“

Was muss man dafür tun?

Nun… diesen Knopf im Admincenter drücken.
Liebe MCD-Kunden, bitte lesen Sie erst weiter, bevor Sie das wild entschlossen tun.

Wo ist der Haken bei der Sache?

Wir können zum jetzigen Zeitpunkt leider noch nichts zu dem Ablauf sagen, da das auch für uns Partner aktuell noch eine Blackbox ist. Bisher konnten wir diese Migration auch noch nicht mit einem Kunden begleiten.

Wer in der Dokumentation weiter liest, wird folgende Passagen finden:

„Die Migrationen für Organisationen, die sich für den von Microsoft geleiteten Ansatz anmelden, werden voraussichtlich in 2020 durchgeführt. Als Ergebnis der Migration werden die wichtigsten Kundendaten und -abonnements in die neuen deutschen Regionen verschoben.“

Quelle:
https://docs.microsoft.com/de-de/office365/enterprise/ms-cloud-germany-migration-opt-in

Für uns stellen sich die Fragen:

  • Wie lange dauert denn tatsächlich so eine Migration, wenn sie „voraussichtlich“ in 2020 durchgeführt wird?
  • Welche Auswirkungen sind währenddessen zu spüren?
    • Microsoft verspricht zwar: „Mandantenmigrationen sind so angelegt, dass sie nur minimale Auswirkungen auf Endkunden und Administratoren haben“ aber was bedeutet denn „minimal“?
  • Auch ist die Aussage, dass die „wichtigsten“ Kundendaten migriert werden, recht schwammig. Was sind denn die wichtigsten Daten und welche fehlen?

Es ist auch noch hinzuzufügen, dass die ganze Migration nicht vollautomatisch abläuft, sondern auch noch einige Tätigkeiten für die Office-Administrationen oder uns als Partner anfallen. Zum Beispiel die DNS Updates und Records, die geändert werden müssen. Die lokalen Security-Systeme, wie Proxy, Firewall etc. müssen angepasst werden, da sich die Adressen der Cloud-Dienste ändern. Wer noch hybrid unterwegs ist, muss auch noch einiges dafür tun, damit das funktioniert.

Unser Fazit

Man muss also noch allerhand beachten, wenn man die geleitete Migration durchführen möchte. Viele Fragen bleiben offen, die auch wir im Moment nicht beantworten können.

UPDATE: Zwangsaktivierung von Microsoft LDAP-Kanalbindung und -Signatur

Bekanntermaßen ist LDAP das Protokoll zur Verwaltung eines Active Directory. Administratoren verwalten damit die Benutzer, die Gruppenmitgliedschaften und vieles mehr. Nicht nur Exchange-Server fragen den Domain Controller nach der Attributen des Benutzers ab, sondern auch Firewalls, Drucker oder andere Systeme.

LDAP-Verbindungen sind somit ein interessantes Ziel für Hacker, um diese abzufangen und Aktionen zu fälschen. Dagegen helfen Signaturen und Verschlüsselungen.

Im Jahr 2017 hat Microsoft bereits ein Update der Clients und Server bereitgestellt, welches die LDAP-Kanalbindung sowie LDAP-Signierung hinzufügt, aber noch nicht erzwingt.

Zunächst hatte Microsoft vor, die LDAP-Signierung beim kommenden Patchday im März zu erzwingen, doch hat nun Microsoft den Termin auf Mitte bzw. Ende 2020 erneut verschoben. Ein genauer Termin steht somit noch nicht endgültig fest.

Daten, die nicht verschlüsselt werden, können immer mitgelesen werden. Falls die Signierung fehlt, können Pakete sogar in beide Richtungen verändert werden. Für Angreifer ist natürlich der schreibende Zugriff auf das Active Directory ziemlich interessant, um sich eigene Konten anzulegen oder Gruppenmitgliedschaften zu ändern. Dazu hat Microsoft 2017 ein eigenes Security Advisory (CVE-2017-8563 | Windows Elevation of Privilege Vulnerability) veröffentlicht. Darin steht auch, dass Microsoft keine „Workarounds“ vorsieht.

Sind alle Systeme halbwegs aktuell, werden Sie keine Probleme mit den Windows Clients und Server bekommen, da diese bereits seit 2017 darauf eingestellt sind und alle Funktionen enthalten.

Probleme könnte es aber mit folgenden Systemen geben:

VoIP-Gateways

VoIP-Gateways beziehen ggf. die Rufnummer via LDAP vom Domain Controller, um die Anrufe zu Skype for Business, Teams oder einer TK-Anlage zu routen.

Scan2Mail

Professionelle Multifunktionsgeräte können eingescannte Dokumente per Mail als PDF/TIFF weiterleiten. Dafür kann der Anwender im Firmenadressbuch nach Personen suchen. Dazu wird meistens ein Dienstkonto mit Lese-Rechte und LDAP verwendet. Nach der Zwangsaktivierung wird zumindest das Adressbuch nicht mehr funktionieren.

AntiSpam-Systeme

AntiSpam-Systeme prüfen beim Erhalt von Mails aus dem Internet intern, ob der Empfänger tatsächlich vorhanden ist und kann so ohne einen NDR zu erzeugen ungültige Mails ablehnen. Dazu werden meistens mittels LDAP die Email-Adressen des Mailservers über einen Domain Controller eingelesen.

Access-Gateways, WebApp Auth, Reverse Proxy und andere 3rd Party Apps

Firewall-Systeme, Access-Gateways, Proxys bieten meist einen Webserver-Schutz an, welcher Dienste vor Angreifern schützt und nach Anmeldedaten fragt. Diese Daten werden dann über ein Formular oder Basic Authentification abgefragt und ein Login-Versuch am Domain Controller mittels LDAP durchgeführt. Beispiele wären hier Sophos, Citrix ADC (NetScaler), Apache oder Azure ATP.

Empfohlende Aktionen

  • Finden Sie alle Systeme, die noch ungesicherte LDAP-Verbindungen zum Domain Controller aufbauen
  • Prüfen Sie die Systeme auf Kompatibilität für LDAP-Kanalbindung und LDAP-Signierung
  • Stellen Sie alle LDAP-Verbindungen auf das verschlüsselte Protokoll um
  • Falls noch keine Enterprise-PKI (Zertifizierungsstelle) in der Domäne vorhanden ist, sollte diese installiert und konfiguriert werden, da LDAPS natürlich ein gültiges Zertifikat benötigt.

Microsoft MyAnalytics

MyAnalytics ist ein Dienst in der Microsoft Office 365–Welt, um „Produktivitäts-Daten“, auf die ein Benutzer Zugriff hat, für sich selbst und automatisiert aufbereitet darzustellen. Der nett gemeinte Ansatz für sein eigenes Arbeitsleben Optimierungspotenziale zu erkennen, dürfte insbesondere für den datensensiblen Mitarbeiter ein unwillkommener Service sein. Besonders Betriebsräte wittern hier eine Mitarbeiterüberwachung.

MyAnalytics Dashboard (Bildquelle: Office.com)

Was macht MyAnalytics eigentlich?

Grob gesagt, nutzt es die Daten aus dem eigenen Kalender, Email, Chat, Skype, Teams, (ggf. auch Windows 10) und aggregiert sie zu einer Übersicht. Also Daten, auf die der Benutzer sowieso selbst zugreifen könnte. Hier kann ich mir dann anschauen, wie effizient ich meine Zeit einplane, mit wem ich häufig korrespondiere und andere Statistiken. Der Service macht auch Vorschläge zur Optimierung meines digitalen Tagesgeschäfts.

Und wer hat Zugriff auf diese Daten?

Die zusammengefassten Statistiken werden im Exchange Postfach jedes einzelnen Users gespeichert. Es gibt kein „Admin-Tool“ das eine zentrale Auswertung ermöglicht. Im Grunde kann jeder Benutzer selbst entscheiden, mit wem diese Daten anschließend geteilt werden sollen. Umgekehrt sehe ich als Anwender natürlich auch keine Daten meiner Kollegen.

Quelle:
https://docs.microsoft.com/de-de/workplace-analytics/myanalytics/overview/privacy-guide

Jetzt kommt das „Aber“…

Aber…es gibt eine Funktionserweiterung (Add-On) namens Workplace Analytics, als übergreifende Verwaltungsmöglichkeit für MyAnalytics. Dieses Tool ist aktuell noch nicht überall verfügbar oder käuflich zu erwerben. Damit können sehr wohl die Produktivitätsdaten von Mitarbeitern zentral ausgewertet werden, um dem Management Steuerungsmöglichkeiten an die Hand zu geben. Allerdings muss hier schon aktiv etwas getan werden um das zu ermöglichen (Gruppen hinzufügen, auswertende Benutzer benennen, etc.). Es lässt sich schlecht voraussagen, ob Workplace Analytics irgendwann in den höheren Plänen automatisch enthalten und standardmäßig aktiviert sein wird. IT-Verantwortliche sollten darauf achten, diese Funktion (sofern Verfügbar) nicht ohne entsprechende Vereinbarungen zu aktivieren.

Quelle:
https://docs.microsoft.com/de-de/workplace-analytics/privacy/data-protection-intro

Zusammengefasst:

Verwechseln Sie also bitte nicht MyAnalytics mit Workplace Analytics und klären Sie ihre Benutzer auf.

Einmal aktiviert, versendet MyAnalytics unglücklicherweise auch direkt Emails, die bei so manchem Mitarbeiter den Eindruck erwecken könnten, von nun an vollkommen überwacht zu werden.

Sollte jemand aus ihrem Unternehmen den Bedarf anmelden Workplace Analytics nutzen zu wollen, seien Sie aufmerksam und hinterfragen Sie den Einsatz.  

Deaktivieren von MyAnalytics

So schalten Sie MyAnalytics als Benutzer aus:

Gehen Sie auf ihr MyAnalytics Dashboard und öffnen die Einstellungen.

Anschließend kann man die Features deaktivieren.

Global als Administrator deaktivieren:

MyAnalytics kann man als Administrator unter „Einstellungen“ – „Services“ global konfigurieren (Eine Änderung kann bis zu 24h dauern).