Sandro Reiter

vCard und IT-Blog

Neueste Beiträge

Kategorien

Archive

Exchange Online: Domain-Spoofing mit DKIM erschweren

Exchange Online bietet im Vergleich zu seinem OnPremises-Gegenstück die Möglichkeit, seine akzeptierten Domänen neben einem SPF-Record auch mittels DKIM (DomainKeys Identified Mail) zu schützen.
Dadurch wird es Angreifern erschwert Phishing- oder Spam-Mails im Namen von Domains (und damit Unternehmen) zu versenden, welche diesen nicht gehören.

DKIM ist eine Erweiterung, die beim Versenden einer E-Mail von einem autorisierten Absender, in diesem Fall aus Exchange Online (Microsoft 365), der Mail ein spezielles Attribut im Mail-Header beifügt.

Das Verfahren basiert auf asymmetrischer Verschlüsselung (Public- und Private-Key). Der sendende Mail-Server signiert die Mail mit einem Hash-Wert (generiert durch den privaten Schlüssel) und die empfangende Gegenstelle (Empfänger-Server) prüft mittels des zugehörigen frei verfügbaren Public-Keys den Hash-Wert im Header ab.

Stimmt der Hash-Wert im Header mit dem durch den Empfänger-Server generierten Hash-Werts, welcher anhand des Public-Keys generiert wurde, überein, wird die E-Mail in der Regel zugestellt, da der Absender als valide gilt.

Stimmen die Werte nicht überein, liegt es an der Konfiguration des empfangenden Mail-Systems was mit der Mail passiert – zum Beispiel verwerfen, zur Prüfung in Quarantäne, in den Spam-Ordner des Benutzers oder zurückweisen der Mail an den Absender.

 

Um DKIM in Exchange Online zu aktivieren, sind folgende Schritte nötig:

1. Setzen der nötigen CNAME-Einträge im öffentlichen DNS-Verzeichnis
2. Erzeugen der DKIM-Keys in Exchange Online
3. Aktivieren von DKIM in Exchange Online

 

Im DNS müssen CNAME Einträge gemäß der folgenden Syntax angelegt werden:

Hostname: selector1._domainkey
Ziel: selector1-domain-tld._domainkey.tenant.onmicrosoft.com
TTL: 3600

Hostname: selector2._domainkey
Ziel: selector2-domain-tld._domainkey.tenant.onmicrosoft.com
TTL: 3600

Mit Werten befüllt, könnte es dann so aussehen:

Hostname: selector1._domainkey
Ziel: selector1-meinefirma-de._domainkey.meinefirma.onmicrosoft.com
TTL: 3600

Hostname: selector2._domainkey
Ziel: selector2-meinefirma-de._domainkey.meinefirma.onmicrosoft.com
TTL: 3600

 

Ein Hinweis, der die Erstellung der Einträge erleichtert ist, das die Punkte der Domain im Ziel-Wert für den CNAME immer durch Bindestriche ersetzt werden.
Aus der Domain meinefirma.de wird im CNAME Eintrag also meinefirma-de.
Genauso auch für Subdomains: Aus mail.meinefirma.de wird mail-meinefirma-de.

Sind die DNS Einträge gesetzt und veröffentlicht, muss im Exchange Online nun noch die DKIM-Konfiguration angelegt werden.

Dazu wird das ExchangeOnlineManagement PowerShell-Modul benötigt.

Mit den folgenden PowerShell-Cmdlets wird DKIM letztendlich aktiviert:

#sign in to Exchange Online
Connect-ExchangeOnline -ShowBanner:$false

#create and enable DKIM config with more secure 2048 bit encryption keys
New-DkimSigningConfig -DomainName meinefirma.de -KeySize 2048 -Enabled $true

#remove active PowerShell session
Disconnect-ExchangeOnline

Anschließend ist DKIM für diese Domain aktiv und alle gesendeten Mails werden mit diesem Mechanismus zusätzlich abgesichert.

Zu erkennen ist es zum Beispiel im Mail-Header anhand folgender Werte:

dkim=pass (signature was verified) header.d=senderdomain.com; arc=pass (0 oda=1
ltdi=1 spf=[1,1,smtp.mailfrom=senderdomain.com]
dkim=[1,1,header.d=senderdomain.com] dmarc=[1,1,header.from=senderdomain.com])

...

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=senderdomain.com;
s=selector2;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=/O9b+/4FCGiuPLbNWFW7dhg8/koNv10LLB+vHg4Zw1I=;
b=PPomU/kCR74JOUiAzKryl5BIag6ceftDWB2KTIl/NW6X1F9TKWT9LWVduM4fe8fWgDR4RzxDjUHMeVzmTK948pS8OdAcob+aV1XfRp4gqV6HrtgoltEG9ZHnR/hgKGR04MkHCZ9RWjPafMDe0hefDPI1Fd/IUXmHam0UxS+8i3g=

 

DKIM kann für mehrere Domains bzw. alle Domains die im Exchange Online zugeordnet sind aktiviert werden, die o.g. Schritte müssen dabei für jede Domain wiederholt werden.

Published by Sandro on | Permalink

ADFS: Certificate-Binding wird nicht korrekt ersetzt

Neben der klassischen Kombination aus Benutzername und Passwort zur Authentifizierung beherrschen die Active Directory Federation Services (ADFS) auch die Anmeldung per Nutzerzertifikat.

Hierzu wird von Microsoft empfohlen, dem ADFS Service-Communications-Certificate den alternativen DNS-Namen (SAN) certauth.adfs.meinedomäne.tld hinzuzufügen.

Während der ADFS-Konfiguration wird dieser Endpunkt entsprechend erstellt und das Zertifikat auf Port 443 gebunden.

Enthält das Zertifikat diesen SAN nicht, wird die zertifikatsbasierte Authentifizierung auf Port 49443 und den Service-Namen (adfs.meinedomäne.tld) gebunden.

 

So weit, so gut:

In einem Kundenszenario hatte ich nun den Fall, dass das Service-Communications-Zertifikat ersetzt werden musste. Gesagt, getan:
Zertifikat angefordert, PFX importiert und per PowerShell ersetzt

#replace adfs sts certificate, prequisite: certificate pfx has to be installed
Set-AdfsSslCertificate -Thumbprint "FC85DDB0FC58E63D8CB52654F22E4BE7900FE349"

Auf den Web Application Proxy (WAP) – Maschinen habe ich die Schritte zur Ersetzung des Zertifikats ebenfalls durchgeführt.

Die Umgebung lief bis zu dem Tage, als das alte Zertifikat abgelaufen ist, fehlerfrei. An dem Tag, nach dem das alte Zertifikat ungültig wurde, war der ADFS von extern nicht mehr erreichbar.

 

Der WAP meldete, das der ADFS-Services “unavailable” wäre mit dem Fehler-Code “503”. Eine Re-Konfiguration des WAP endete mit dem Fehler:

“An error occurred while attempting to establish a trust relationship with the Federation Server.

Nach diversen Netzwerk-/Firewall-Tests blieb die Vermutung das es am ADFS selbst liegt…

Eine Überprüfung der Bindings mit

#show adfs ssl bindings
Get-AdfsSslCertificate

bestätigte den Verdacht

HostName                           PortNumber  CertificateHash
--------                           ----------  ---------------
localhost                             443      FC85DDB0FC58E63D8CB52654F22E4BE7900FE349
adfs.meinedomäne.tld                  443      FC85DDB0FC58E63D8CB52654F22E4BE7900FE349
adfs.meinedomäne.tld                  49443    FC85DDB0FC58E63D8CB52654F22E4BE7900FE349
certauth.adfs.meinedomäne.tld         443      3F65896B1E2102515FC7942BD1FC6D9F3603C04A

 

Das Zertifikat für die zertifikatsbasierte Authentifizierung wurde nicht aktualisiert.
Der WAP lief nun in den Fehler, auf ein abgelaufenes Zertifikat zu treffen.

 

Auf dem primären ADFS-Node muss also zusätzlich noch das certauth-Zertifikat ersetzt werden. Das gelingt per PowerShell wie folgt:

#replace adfs sts alternate certificate, prequisite: certificate pfx has to be installed
Set-AdfsAlternateTlsClientBinding -Thumbprint "FC85DDB0FC58E63D8CB52654F22E4BE7900FE349"

Die anschließende erneute Überprüfung der Bindings mit

#show adfs ssl bindings
Get-AdfsSslCertificate

bestätigt die Änderung.

Alle ADFS-Domains nutzen nun das neue, gültige Zertifikat.
Jetzt noch die Web Application Proxies re-konfigurieren, was nun fehlerfrei durchlaufen sollte. Check.

Die ADFS-Testseite (https://adfs.meinedomäne.tld/adfs/ls/IdpInitiatedSignon.aspx) war von extern wieder aufrufbar. Die Anmeldung der Nutzer war ebenso wieder möglich.

 

Warum dieses Verhalten beim Ersetzen des Zertifikats auftritt, erschließt sich mir nicht. Schließlich wird das Zertifikat bei der initialen ADFS-Einrichtung auch explizit auf diese Sub-Domain gebunden, also warum dann das neue Cert (mit den gleichen SANs) nicht auch für die zertifikatsbasierte Authentifizierung aktualisieren? Feature oder Bug?

Published by Sandro on | Permalink

Azure: Hub-Spoke in Tenant-übergreifenden VNet-Peerings

In meinem Blogpost zum Thema Tenant-übergreifendes VNet-Peering habe ich aufgezeigt, wie man zwei Azure Tenants mit einem VNet Peering verbinden kann. Zum Zeitpunkt, als ich den Artikel verfasst habe, gab es noch die Einschränkung, das die zu verbindenden VNets in den zwei Tenants in der selben Azure Region laufen müssen.

 

Ich habe mir diese Woche die Thematik nochmal auf den Tisch geholt und festgestellt: Die Limitierung wurde aufgehoben.

Dadurch ist es nun möglich Hub-Spoke-Topologien über mehrere Azure Tenants und mehrere Azure Regionen aufzubauen.

Die Maus-Klick Mandelas schauen dabei aber in die Röhre, denn die Funktionen für Hub-Spoke “UseRemoteGateways” & “AllowGatewayTransit” können (derzeit) nicht über das Azure Portal, sondern nur per PowerShell oder CLI gesetzt werden.

 

Ein bereits bestehendes Peering (siehe vorheriger Blogeintrag) vorausgesetzt, wird Hub-Spoke mit folgendem Skript aktiviert:

#declare variables
$subscriptionTenantA = "subscriptionID"
$vNetTenantA = "vNet"
$vnetResourceGroupTenantA = "vNetResourceGroup"
$subscriptionTenantB = "subscriptionID"
$vNetTenantB = "vNet"
$vnetResourceGroupTenantB = "vNetResourceGroup"

#connect to AzureRM
Connect-AzAccount

#select subscription in Tenant A
Select-AzSubscription -Subscription $subscriptionTenantA

#Activate GatewayTransit on Hub network
$peerSiteA = Get-AzVirtualNetworkPeering -ResourceGroupName $vnetResourceGroupTenantA -VirtualNetworkName $vNetTenantA
$peerSiteA.AllowGatewayTransit = $true
Set-AzVirtualNetworkPeering -VirtualNetworkPeering $peerSiteA

#select subscription in Tenant B
Select-AzureRmSubscription -Subscription $subscriptionTenantB

#use Remote Gateways on Spoke network
$peerSiteB = Get-AzVirtualNetworkPeering -ResourceGroupName $vnetResourceGroupTenantB -VirtualNetworkName $vNetTenantB
$peerSiteB.UseRemoteGateways = $true
Set-AzVirtualNetworkPeering -VirtualNetworkPeering $peerSiteB

Anschließend sind Ressourcen, bspw. von OnPremises, in der Lage über das Hub-Netzwerk mit Ressourcen in den jeweiligen Spoke-Netzwerken zu kommunizieren.

Published by Sandro on | Permalink

Citrix Cloud: Connector-Kommunikation absichern

Mit Citrix Cloud ist auch Citrix in das “as a Service”-Business eingestiegen und bietet damit einen wirklich mächtigen Cloud-Dienst mit vielen Produkten im Portfolio an.

App- und Desktopvirtualisierung mit dem Virtual Apps & Desktops, MDM mittels Endpoint Management oder File-Sharing via Content Collaboration sind nur einige der zur Verfügung stehenden Services.

In diesem Beitrag möchte ich auf eine Komponente des Virtual Apps & Desktops Service eingehen – den Citrix Cloud Connector.

Citrix Cloud Connector(en) verbinden das Active Directory sowie den lokalen oder in der Cloud befindlichen Hypervisor mit den Management-Komponenten in der Citrix Cloud.

Durch den Einsatz des VA/VD-Service wird Administratoren viel Arbeit und Zeit im Betrieb, Wartung und Erneuerung einer Vielzahl an Komponenten (Lizenz-Server, Delivery-Controller, Datenbank-Cluster,…) erspart.

Trotz all des neu gewonnenen Komforts sollte die Sicherheit dennoch nicht in den Hintergrund rücken. Deswegen ist es auch bei der Connector-Komponente zu empfehlen die Kommunikation mit den VDAs abzusichern.

 

Was wird dazu benötigt?

  • ein Server-Zertifikat
  • administrative Berechtigungen auf dem Server

 

Der Befehl zum Binden eines Zertifikats an einen Port sieht wie folgt aus:

::add SSL-Binding to Citrix Broker Service
netsh http add sslcert ipport=<IP address>:<Port Number> certhash=<Certificate Hash Number> appid={<Citrix Broker Service GUID>}

 

Die Platzhalter müssen noch durch die korrekten Werten ersetzt werden:

<IP address> = IP-Adresse des Servers

<Port Number> = Port an den das Zertifikat gebunden werden soll

<Certificate Hash Number> = Hash des installierten Serverzertifikats

<Citrix Broker Service GUID> = GUID des Citrix Broker Dienstes

Die GUID ist in der Windows Registry unter HKEY_CLASSES_ROOT\Installer\Products zu finden. Der Key stellt dabei die GUID dar und muss wie folgt aufgeschlüsselt werden: 8-4-4-4-12

→ Beispiel: 6B6FE0CF-3124-E654-C8C6-D40734B302EF

 

Sobald das Binding aktiviert wurde können die VDAs so konfiguriert werden, das über Port 443 mit den Cloud Connectoren kommuniziert wird.

Published by Sandro on | Permalink

Office 365: Neue Möglichkeit zur Zusammenarbeit

Heute habe ich durch Zufall eine spannende Option in den Azure AD Organisationseinstellungen entdeckt:

Auch wenn derzeit noch Preview dran steht, finde ich die Funktion enorm nützlich. Ich weiß gar nicht, wie viele der durch mich betreuten Kunden schon danach gefragt haben.

 

Aber was hat es mit dieser Einstellung auf sich?

Auch wenn Microsoft fleißig daran arbeitet, gibt es auch in 2019 immer noch Personen die keinen Microsoft Account oder ein Office 365 / Azure AD Konto besitzen (wollen/können/dürfen).

Oftmals ist die IT in großen Konzernen sehr restriktiv und so dürfen bspw. keine privaten Accounts genutzt werden und der Einsatz von OneDrive ist frühstens in 2054 geplant.

Mit OTP (one time password) als Alternative zu klassischen Einladungen für die Zusammenarbeit in Office 365 ist auch denjenigen geholfen, die zu dem oben beschriebenen Nutzerkreis gehören.

Ein einmaliger Code in Kombination mit der eigenen E-Mail-Adresse dient als Authentifizierungsmethode um auf Inhalte zuzugreifen – Gültigkeit eines OTP: 24 Stunden.

 

Und so sieht es, anhand eines OneDrive Sharing-Prozesses, für die Benutzer aus:

Die Datei oder der Ordner wird über das Teilen-Menü mit einem externen Benutzer geteilt.

Der teilende Benutzer sendet eine Einladung zur Zusammenarbeit an die angegebene E-Mail-Adresse. 

Microsoft prüft im Hintergrund ob zu dem Konto ein Microsoft-/Azure AD-Account existiert. Wenn dies nicht der Fall ist, wird der Eingeladene auf das OTP-Verfahren umgeleitet. Der eingeladene Benutzer gibt zur Verifizierung seine E-Mail-Adresse und den Einmalcode (OTP), welcher gesondert per E-Mail versendet wird, zur Authentifizierung ein.

Nach erfolgreicher Authentifizierung kann nun endlich kollaboriert werden.

Der Besitzer bzw. Absender der Datei-/Ordnerfreigabe bekommt außerdem eine Benachrichtigung darüber, das die eingeladene Person den OneDrive-Link geöffnet hat.

 

 

Microsoft zeigt damit wieder, das Feedback gehört und berücksichtigt wird. Ich bin gespannt was sich bis zur finalen Veröffentlichung hier noch tut.

Published by Sandro on | Permalink

Teams: E-Mail-Kommunikation in Kanälen anzeigen

Microsoft Teams ist in seinem Segment als “eierlegende Wollmilchsau” wohl einer der größten und gelungensten Würfe der IT-Branche in den letzten Jahren!

MS Teams hat sich so stark in meinen Arbeitsalltag integriert, das ich es nicht mehr missen möchte und vermutlich auch gar nicht kann. Ich bin bereits in Q4 2018 den Weg gegangen und habe mich als ersten User in unserem Tenant auf “teams-only”-Benutzung umgestellt.

Mein Skype for Business Client sagt mir beim Start nur noch freundlich:
Geh doch bitte zu Teams 😉
Meine letzte verbliebene S4B Funktionalität: An S4B-Meetings teilnehmen.

 

Teams auf Office 365 Gruppen aufzusetzen ist eine gelungene Entscheidung, mit einem großen Nachteil: Gruppenunterhaltungen – also E-Mails – tauchen nicht im jeweiligen Team auf. Ich muss zur Diskussion einer E-Mail diese immer erst an den Kanal weiterleiten.

 

Natürlich gibt es aber einen Workaround:

Jeder Teams-Kanal hat eine eigene E-Mail-Adresse welche auf @emea.teams.ms endet. Dieses Feature machen wir uns zu Nutze.

Als erstes empfiehlt es sich einen eigenen Kanal, beispielsweise namens “E-Mails”, im Team anzulegen.

Anschließend kann über das Kanal-Kontextmenü (•••) mit einem Klick auf “E-Mail-Adresse abrufen” die Kanal-E-Mail-Adresse ausgelesen werden.

Mit dieser E-Mail-Adresse wird im Azure AD ein Gast-Nutzer angelegt.

Der angelegte Gastnutzer muss anschließend nur noch als Mitglied zur Office 365 Gruppe hinzugefügt werden. Das erledigt am besten die PowerShell um zu garantieren das der Gastnutzer auch ein Abonnent der Gruppe wird:

#add guest user as member to o365 group
Add-UnifiedGroupLinks -LinkType Members -Identity "myO365Group" -Links "myTeamsChannelGuestUser"
#add guest user as subscriber to o365 group to receive emails
Add-UnifiedGroupLinks -LinkType Subscribers -Identity "myO365Group" -Links "myTeamsChannelGuestUser"

Ab diesem Moment werden E-Mails an die O365 Gruppe auch in dem jeweiligen Teams-Kanal zugestellt.

Published by Sandro on | Permalink

Azure: Tenant-übergreifendes VNet-Peering

Peerings zwischen virtuellen Netzwerken in Azure sind eine tolle Sache: Einfach zu konfigurieren, schnell bereitgestellt und die Performance ist ebenfalls klasse!

Zum Verbinden von virtuellen Netzwerken aus verschiedenen Azure Active Directory Tenants, wie es beispielsweise in Unternehmensgruppen der Fall ist, mussten bis vor Kurzem noch VPN-Gateways bereitgestellt werden.

Jetzt ist es möglich VNet-Peerings Tenant-übergreifend zu erstellen, derzeit allerdings nur über Azure CLI, PowerShell oder als ARM-Template.

Ich zeige Euch die PowerShell Variante.

Als Voraussetzung benötigt Ihr einen Azure AD-Benutzer, welcher sowohl in Tenant A als auch Tenant B (dann als Gast) die Berechtigung “Network Contributor” auf das jeweilige virtuelle Netzwerk hat, um das VNet “auf der anderen Seite” auslesen und das Peering erstellen zu können.

 

Ist das gegeben, kann es losgehen. Folgendes Skript erledigt alles nötige für Euch, wenn Ihr die Variablen korrekt befüllt:

#declare variables
$subscriptionTenantA = "subscriptionID"
$vNetTenantA = "vNet"
$vnetResourceGroupTenantA = "vNetResourceGroup"
$peerAtoBname = "TenantA-TenantB-Peer01"
$subscriptionTenantB = "subscriptionID"
$vNetTenantB = "vNet"
$vnetResourceGroupTenantB = "vNetResourceGroup"
$peerBtoAname = "TenantB-TenantA-Peer01"

#connect to AzureRM
Connect-AzAccount

#select subscription in Tenant A
Select-AzSubscription -Subscription $subscriptionTenantA

#peer vnet in tenant A to vnet in tenant B
$vNet = Get-AzVirtualNetwork -Name $vNetTenantA -ResourceGroupName $vnetResourceGroupTenantA
Add-AzVirtualNetworkPeering -Name $peerAtoBname -VirtualNetwork $vNet -RemoteVirtualNetworkId "/subscriptions/$subscriptionTenantB/resourceGroups/$vnetResourceGroupTenantB/providers/Microsoft.Network/virtualNetworks/$vNetTenantB"

#select subscription in Tenant B
Select-AzSubscription -Subscription $subscriptionTenantB

#peer vnet in tenant B to vnet in tenant A
$vNet = Get-AzVirtualNetwork -Name $vNetTenantB -ResourceGroupName $vnetResourceGroupTenantB
Add-AzVirtualNetworkPeering -Name $peerBtoAname -VirtualNetwork $vNet -RemoteVirtualNetworkId "/subscriptions/$subscriptionTenantA/resourceGroups/$vnetResourceGroupTenantA/providers/Microsoft.Network/virtualNetworks/$vNetTenantA"

Läuft, oder? 😉

 

Der Vollständigkeit halber noch folgender Hinweis zum Schluss:

Die Optionen “Allow gateway transit” und “Use remote gateway” stehen nur zur Verfügung, wenn sich die virtuellen Netzwerke in der selben Azure Region befinden. Bei einer Verbindung bspw. zwischen Westeuropa und Frankreich-Mitte funktioniert das derzeit leider noch nicht.

Published by Sandro on | Permalink

Office 365: Das Periodensystem der Produkte

Die Palette an Produkten welche in Microsofts Office 365 Plattform enthalten sind, scheint bereits heute unendlich zu sein. Dennoch wächst und verändert sich das Angebot ständig weiter. Produkte kommen dazu, weniger Beliebte fliegen raus oder Dienste werden zusammengelegt beziehungsweise durch Neue ersetzt.

Ein tolles und gelungenes Beispiel für eine Kombinierung von Diensten und der Ersetzung einer Altlast ist Microsoft Teams! Teams ersetzt Skype for Business, zumindest die in Office 365 betriebene Cloud-Version. Teams vereinigt zudem auch SharePoint-Seiten und -bibliotheken, Audio- und Videokonferenzen, die Office Online Apps und vieles mehr an einer zentralen Stelle in einer einheitlichen Ansicht.

Ich möchte hier aber gar keinen Beitrag über Teams schreiben, vielleicht ein anderes Mal.

 

Kommen wir zum Thema:

Jeder wird sich wohl noch an das

Periodensystem der Elemente

aus dem Chemie- und Physikunterricht erinnern können.

Ich gebe Euch ein wesentlich interessanteres Informationsmedium an die Hand: Jeder möchte den maximalen Nutzen für sich aus Office 365 ziehen.
Das geht aber nur, wenn man in all den Funktionen nicht untergeht und sich einen Überblick verschaffen kann. Die Kollegen von jumpto365 machen sich die Mühe und haben das Periodensystem für Office 365 erstellt und halten es aktuell.

Nachfolgend findet Ihr das interaktive Periodensystem mit der Bitte sich damit vertraut zu machen – nächste Woche schreiben wir eine Leistungskontrolle dazu! 😉

Published by Sandro on | Permalink

Azure AD: UPN eines Hybrid-Users ändern

Als wir vor Kurzem einen neuen Kollegen eingestellt haben, wünschte dieser sich einen kürzeren Anmeldenamen (UPN) für Office 365 und Co.
Da ich natürlich vorbildlich bereits vor seinem Dienstantritt das Active Directory-Konto erstellt habe, änderte ich einfach den UPN am AD-Objekt und auch die neue Adresse im ProxyAdresses-Attribut wurde veröffentlicht und als primär festgelegt.

Als nach mehrfachen automatischen AAD Connect Synchronisationen der kosmetische Eingriff noch nicht geglückt war, habe ich eine manuelle Synchronisation angestoßen…

Start-ADSyncSyncCycle -PolicyType Delta

… allerdings ebenfalls ohne Erfolg.

 

Ich musste ein wenig in meinem Gedächtnis kramen – denn genau diese Änderung habe ich bereits an meinem eigenen Benutzerkonto durchgeführt – Déjà-vu! Mir fiel wieder ein, was ich schon mal vergessen habe.

Es ist natürlich richtig und wichtig den UPN und die neue Mail-Adresse im OnPremises AD zu ändern. Wenn das Konto aber bereits synchronisiert ist und in Azure AD angelegt, muss der UPN auch nochmal auf Azure AD-Seite geändert werden. Das gelingt ganz einfach wie folgt:

#connect to Azure AD tenant
Connect-AzureAD

#change UPN to default tenant-domain
Set-AzureADUser -ObjectId user@contoso.com -UserPrincipalName user@contoso.onmicrosoft.com

#set the UPN like the UPN in OnPrem AD
Set-AzureADUser -ObjectId user@contoso.onmicrosoft.com -UserPrincipalName mrright@contoso.com

 

Nachdem das nun erledigt ist, gilt der neue UPN in beiden IDPs – sowohl im Active Directory als auch Azure AD.

 

Famous last words: Wenn der UPN geändert wird, ändert sich auch die SIP-Adresse des jeweiligen Benutzers. Diese Adresse wird u.a. im Skype for Business-Verzeichnisdienst verwendet. Das wiederum hat die Folge, das bereits bestehende Kontakte den Benutzer mit neuem UPN erneut zur Kontaktliste hinzufügen müssen.

Published by Sandro on | Permalink

Cloud Security: Microsoft Secure Score

In meinem letzten Post habe ich das Schlagwort “Cloud” genauer erklärt. Dabei habe ich die These aufgestellt, das es schwierig bis unmöglich wird eine genauso sichere Infrastruktur anzubieten wie es die großen Cloud-Anbieter tun. Zum Einstieg dazu ein paar bewegte Bilder:

 

Was möchte uns dieses Video nun sagen? Am Ende gibt es ja einen dezenten Hinweis auf des Rätsels Lösung – ich sehe das aber etwas anders: Wozu sollte sich jeder die “beste” Security-Lösung anschaffen und gut bezahltes Fachpersonal zur Wartung & Optimierung dieser Umgebung einstellen oder einen Dienstleister engagieren der dies erledigt?

Ja, wozu eigentlich? Ich habe auch keine wirklich gute Antwort, außer das Verlangen nach (scheinbarer) Sicherheit und Kontrolle unserer Gesellschaft – darf aber nix kosten!

 

Nur damit mich niemand falsch versteht, Security ist wichtig und sollte niemals als optional angesehen werden. Ich möchte nur sagen: Braut nicht Euer eigenes Süppchen und versucht nicht das Rad neu zu erfinden. Nutzt die Möglichkeiten die Euch von wirklichen Experten, die 24 Stunden 7 Tage die Woche nichts anderes machen und genau dafür ausgebildet und bezahlt werden, angeboten werden.

 

Soviel zum Teaser: Worauf will ich eigentlich hinaus? Wer kennt den Secure Score von Microsoft?
https://securescore.office.com/

Der Azure Secure Score befindet sich getrennt vom O365- und Windows Secure Score im Azure Security Center:
https://portal.azure.com/#blade/Microsoft_Azure_Security/SecurityMenuBlade/5

 

Der Microsoft Secure Score ist ein wunderbares Werkzeug um seine eigene Office 365-, Windows- und Azure-Umgebung einem Security-Check mit Empfehlungen direkt aus Microsofts Cloud-Security Abteilung zu unterziehen. Und das Beste: Jeder Microsoft Cloud Business-Kunde hat Zugriff auf den Secure Score und kann diesen Check durchführen.

 

Es werden Verbesserungen wie das Aktivieren von Multi-Faktor-Authentifizierung über die Modifikation der Exchange Transportregeln bis hin zu Windows Defender Optimierungen vorgeschlagen. Je nach gewünschtem Secure “Highscore” lassen sich die Maßnahmen auch einschränken. Die Task-Details schaffen Klarheit über Implementierungsaufwand und Auswirkungen auf die User, außerdem ist eine Beschreibung sowie weiterführende Links in jedem Vorschlag enthalten.

 

Ich empfehle Euch mal einen Blick in den Secure Score Eurer Umgebung zu werfen. Seid Ihr zufrieden mit dem Ergebnis?

Published by Sandro on | Permalink