Sandro Reiter

vCard und IT-Blog

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.

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.

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-AzureRmAccount

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

#peer vnet in tenant A to vnet in tenant B
$vNet = Get-AzureRmVirtualNetwork -Name $vNetTenantA -ResourceGroupName $vnetResourceGroupTenantA
Add-AzureRmVirtualNetworkPeering -Name $peerAtoBname -VirtualNetwork $vNet -RemoteVirtualNetworkId "/subscriptions/$subscriptionTenantB/resourceGroups/myResourceGroupB/providers/Microsoft.Network/virtualNetworks/vNetinTenantB"

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

#peer vnet in tenant B to vnet in tenant A
$vNet = Get-AzureRmVirtualNetwork -Name $vNetTenantB -ResourceGroupName $vnetResourceGroupTenantB
Add-AzureRmVirtualNetworkPeering -Name $peerBtoAname -VirtualNetwork $vNet -RemoteVirtualNetworkId "/subscriptions/$subscriptionTenantA/resourceGroups/myResourceGroupB/providers/Microsoft.Network/virtualNetworks/vNetinTenantA"

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.

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.

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?

Cloud: Was ist das eigentlich?

Cloud, dieses Wort ist in aller Munde. Viele wissen gar nicht was dahinter steckt und sind daher skeptisch. Genau hier liegt das Problem: Die Angst der Menschen vor Veränderung und der Ungewissheit.

Dieser Beitrag soll Klarheit bringen was „die Cloud“ eigentlich ist und als kleinen Spoiler vorab: Viele nutzen dieses Modell bereits in abgespeckter Form und das seit Jahren, nur ohne diesen „Cloud“-Begriff!

 

Also, was ist nun diese Cloud? Eine gute Definition findet sich (natürlich) in Microsofts Repertoire:

Cloud Computing ist die Bereitstellung von Computingdiensten (Server, Speicher, Datenbanken, Netzwerkkomponenten, Software, Analyseoptionen und mehr) über das Internet („die Cloud“). Unternehmen, die diese Computingdienste anbieten, werden als Cloudanbieter bezeichnet und stellen Cloud Computing-Dienste, üblicherweise basierend auf der jeweiligen Nutzung, in Rechnung.

Kurz sacken lassen…

Und jetzt denken wir uns die ganzen „Cloud“s in diesem Zitat mal weg. Wir werden feststellen, das es solche Anbieter – zumindest in ihren Nischen – schon deutlich länger gibt als den Cloud-Hype.

 

Als Beispiel fallen mir dazu Website-Hoster ein:
Sämtliche Homepage-Baukasten-Anbieter haben bereits vor Jahrzehnten mit DIY-Homepages auf dieses Modell gesetzt. Das Motto war immer: „Bezahle X Euro im Monat und wir stellen dir eine Webserver Instanz für deinen Webauftritt bereit.“ Hosted E-Mail-Lösungen, sind da nichts anderes. Und wer kennt nicht Dropbox, Google Drive, iCloud und Co. als Cloudspeicher-Dienste?

 

Aber was ist jetzt der nennenswerte Mehrwert des größten Public Cloud Anbieters? Mit einem Milliarden-Invest hat Microsoft es geschafft, ein riesiges und ständig wachsendes Portfolio an Produkten aus der Hand von einem einzigen Anbieter als Cloud-Dienste bereitzustellen: Exchange Online als E-Mail-Lösung, SharePoint Online als Intranet-Lösung, Azure Web Apps als Webhosting-Lösung, Azure Compute zum VM-Hosting und viele weitere Services.

Die Cloud ist somit nichts anderes als ein oder mehrere Rechenzentren des jeweiligen Anbieters, deren Ressourcen gegen eine Gebühr dem Kunden zur Verfügung gestellt werden. Und schon klingt’s doch gar nicht mehr so schlimm, oder?

 

Wer hat immer noch Angst vor’m schwarzen Mann?
Der eine oder andere kennt vielleicht diese Firma aus Redmond, mit ca. 120.000 Mitarbeitern und knapp 90 Milliarden US Dollar Umsatz. Warum sollte man heutzutage noch einen Riesenbatzen Geld in eigene Hardware, Software und Security investieren, wenn sich viele tausend schlaue Köpfe mit dem nötigen Kleingeld auf der hohen Kante darüber bereits Gedanken gemacht haben und uns dies im bequemen Abo-Modell sogar zur Verfügung stellen? Wer meint umweltfreundlicher, kosteneffizienter, performanter und vorallem sicherer eine IT-Infrastruktur betreiben zu können: Versuch‘ es, aber sage nicht das ich Dich nicht gewarnt hätte.

Azure: Ein Blick hinter die Kulissen

Wer wollte schon immer einmal Mäuschen spielen und mehr über Microsofts Cloud Plattform Azure erfahren? Einen spannenden Einblick über den Milliarden-Invest von Microsoft bietet das nachfolgende Video aus der zweiten Jahreshälfte 2016.

 

Seitdem stehen die Uhren bei Microsoft natürlich nicht still. Zum heutigen Zeitpunkt steht die Cloud Plattform auf 54 globalen Rechenzentren zur Verfügung, 10 davon befinden sich derzeit in der Bauphase bzw. Fertigstellung – 2 davon auch in Deutschland!

Persönliche Besuche in den Mega-Rechenzentren sind nahezu unmöglich zu bekommen. Wer trotzdem einmal hinter die Kulissen schauen möchte, dem kann ich einen virtuellen Rundgang sehr empfehlen: Tour starten.

Azure Automation: Anfordern eines Ad-Hoc SAS Tokens

Wer mit Azure Storage arbeitet, kommt über kurz oder lang nicht daran vorbei die Verarbeitung von Dateien zu automatisieren. Was über die Web-UI so einfach geht, ist via PowerShell nicht ganz so trivial.

In einem Container mit dem AccessLevel „private“ wird ein SAS Token benötigt um auf die Dateien zuzugreifen und mit diesen zu arbeiten.

Wie genau dieser Token in einem Azure Automation PowerShell RunBook angefordert werden kann, zeigt das folgende Skript:

#define parameter
Param(
    [Parameter(Mandatory=$True)]
    [string]$AzureAutomationAccount,

    [Parameter(Mandatory=$True)]
    [string]$FileWebUrl,

    [Parameter(Mandatory=$True)]
    [string]$StorageAccountName,

    [Parameter(Mandatory=$True)]
    [string]$StorageResourceGroup,

    [Parameter(Mandatory=$True)]
    [string]$StorageContainerName,

    [Parameter(Mandatory=$True)]
    [string]$BlobName,

    [Parameter(Mandatory=$false)]
    [ValidateSet("r","rw","rcw","rwcd")] 
    [string]$AccessRights = "r",
    
    [Parameter(Mandatory=$false)]
    [int]$TokenLifeTime = 2
)

#get credentials from Azure Automation vault
$myCredential = Get-AutomationPSCredential -Name $AzureAutomationAccount

#sign in to AzureRM
Login-AzureRmAccount -Credential $myCredential

#get current utc time for sas token starttime and expiration
$TokenStartTime = Get-Date
$TokenStartTime = $TokenStartTime.ToUniversalTime()
$TokenEndTime = $TokenStartTime.AddHours($TokenLifeTime)

#get storageaccount key, set context to container and request adhoc SAS token
$StorageAccountKey = (Get-AzureRmStorageAccountKey -ResourceGroupName $StorageResourceGroup -AccountName $StorageAccountName).Value[0]
$StorageContext = New-AzureStorageContext $StorageAccountName -StorageAccountKey $StorageAccountKey
$SASKey = New-AzureStorageBlobSASToken -Protocol HttpsOnly -Container $StorageContainerName -Blob $BlobName -Context $StorageContext -Permission $AccessRights -StartTime $TokenStartTime -ExpiryTime $TokenEndTime

#join file-uri and SAS token to full download uri
$FullUri = "$FileWebUrl$SASKey"

 

Sobald das Skript in einem RunBook hinterlegt ist, können die Parameter übergeben und das Snippet im Azure Automation Kontext ausgeführt werden.

 

Das Skript verarbeitet die Datei nicht, sondern fordert nur den Token an. Die komplette URL (Blob+Token), welche am Ende als Variable ($FullUri) bereitsteht, kann für Dateioperationen, bspw. der Import des Dateiinhalts in eine Variable, verwendet werden solange der SAS-Token gültig ist.

#import csv content into variable
$content = ConvertFrom-Csv -Delimiter ";" (Invoke-WebRequest -Uri $FullUri).ToString()

Citrix Cloud: Verwaiste Managed-Disks in Azure

Vor Kurzem habe ich in einem Kunden-Tenant eine ungewöhnlich hohe Anzahl an verwalteten Datenträgern entdeckt (>8000). Die Datenträger stammten alle von Worker-VMs welche durch den MCS in der Citrix Cloud erstellt wurden.

Auf der Suche nach der Ursache des Problems bin ich nicht wirklich fündig geworden und habe während meiner Recherche ebenfalls den Citrix Support hinzugezogen, von dem ich eine spannende Antwort erhalten habe.

 

On, or about, 3/21/2018, Citrix was notified that customers in certain Azure regions were unable to use the products listed earlier. Preliminary investigations showed that the Azure infrastructure was rejecting booting VMs which did not have an identity disk of at least 1GB in size. As a result of this denial, the cloned OS (system) disk may be left around as an “orphaned” disk in your Azure subscription, leading to an unexpected large number of disks in your storage resource groups.

 

Was zusammenfassend bedeutet, das Azure VMs am Starten gehindert hat, wenn diese nicht mindestens eine 1 GB große „Identity disk“ besaßen. Als Resultat hinterließ der MCS eine besitzlose Managed Disk. Je nachdem, wann man dieses Problem bemerkt hat und wie viele Worker provisioniert sind, wurden entsprechend viele Datenträger in Azure hinterlassen.

 

On, or about, 4/6/2018, the Azure infrastructure began reporting the size of the identity disks as 1GB, thereby allowing your workloads to boot successfully thereafter. This temporary outage may have gone unnoticed but you may still be affected. While our investigation is still underway, we felt it was important that we reach out to you today in order for you to remove these unwanted orphaned disks from your Azure subscription to avoid overage charges.

 

Der Fehler wurde, relativ zeitnah, behoben und der Start der Maschinen ist wieder, so wie man es eigentlich erwartet, möglich.

 

Citrix legt betroffenen Kunden nahe, die verwaisten Datenträger aus Azure zu entfernen. Vorher sollte man sich aber an den Azure Support wenden um die dadurch entstandenen Kosten gutschreiben zu lassen. Das notwendige Support-Ticket ist am besten gleich aus dem betroffenen Azure Tenant zu erstellen.