Sandro Reiter

vCard und IT-Blog

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.

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.

Azure: S2S-VPN und die IPSec-Policy

Wer kennt es nicht: Eingefleischte Netzwerkadmins, womöglich sogar angestellt bei einem Rechenzentrums-Dienstleister, die alles rund um die Cloud als total unsicher und sowieso überflüssig einschätzen (und in Wahrheit vermutlich nur Angst um den Ast haben, auf dem sie sitzen) meckern über alles wo Microsoft dran steht oder drin ist.

Da ist es doch ein willkommener Aufhänger, wenn eine VPN Verbindung zu Azure nicht die Anforderungen abbilden kann, welche das NOC gern hätte.

Aber falsch gedacht! Was viele nicht wissen: Es ist möglich die Site-to-Site IPSec-Richtlinie einer VPN-Verbindung mithilfe des Azure CLI und des AzureRM PowerShell-Moduls an die gewünschten Anforderungen anzupassen.

 

Um die Richtlinie zu konfigurieren, müssen wir uns zunächst in den Azure Resource Manager einloggen, das gelingt uns wie folgt:

$credentials = Get-Credential

Login-AzureRmAccount -Credential $credentials

$subscriptionId = ( Get-AzureRmSubscription | Out-GridView -Title "Select an Azure Subscription ..." -PassThru).SubscriptionId
Select-AzureRmSubscription -SubscriptionId $subscriptionId

 

Anschließend können wir mit dem nachfolgenden Skript die Parameter der IPSecPolicy festlegen und damit die VPN Verbindung zum VPN-Gateway auf „der anderen Seite“ aufbauen.

$rg = "GatewayResourceGroup"

$policy = New-AzureRmIpsecPolicy -IkeEncryption AES256 -IkeIntegrity SHA1 -DhGroup DHGroup2 -IpsecEncryption AES256 -IpsecIntegrity SHA1 -PfsGroup None -SALifeTimeSeconds 27000 -SADataSizeKilobytes 1024000

$vpngw = Get-AzureRmVirtualNetworkGateway -Name "GW1"  -ResourceGroupName $rg
$localvpngw = Get-AzureRmLocalNetworkGateway  -Name "Local-GW1" -ResourceGroupName $rg

New-AzureRmVirtualNetworkGatewayConnection -Name "MyConnection" -ResourceGroupName $rg -VirtualNetworkGateway1 $vpngw -LocalNetworkGateway2 $localvpngw -Location "Azure Region" -ConnectionType IPsec -IpsecPolicies $policy -SharedKey 'PSK' -RoutingWeight 0

Welche Werte von Azure unterstützt werden, können wir unter folgendem Link in den Microsoft Docs nachlesen:

https://docs.microsoft.com/de-de/azure/vpn-gateway/vpn-gateway-ipsecikepolicy-rm-powershell

 

Um zu prüfen, ob die Einstellungen korrekt übernommen wurden, führen wir  folgendes Code-Snippet aus:

$rg = "GatewayResourceGroup"
$con = Get-AzureRmVirtualNetworkGatewayConnection -Name "MyConnection" -ResourceGroupName $rg

Write-Output $con.IpSecPolicies

 

Nach ein paar Augenblicken und korrekter Konfiguration auf beiden Seiten, steht der VPN Tunnel.