Sandro Reiter

vCard und IT-Blog

Neueste Beiträge

Kategorien

Archive

Exchange Online: Auf welche Shared Mailboxes hat ein User Zugriff?

Erst kürzlich erhielt ich einen Anruf mit der Frage: “Sehe ich eigentlich irgendwo auf welche Shared Mailboxes ich Zugriff habe?”

Beunruhigende Stille machte sich auf meiner Seite der Leitung breit…

“Da muss ich nachsehen”, sagte ich und sicherte zu mich zeitnah zu melden.

Mir waren die Möglichkeiten bewusst die ein Nutzer hat um die Mitgliedschaft in O365 Gruppen und Verteilerlisten einzusehen, aber die geteilten Postfächer anzeigen auf die man selbst Zugriff hat, suchte ich vergeblich.

 

Lange Rede, kurzer Sinn: Der Kunde wartet – let’s script it!

Das nachfolgende Skript muss der Exchange-Admin ausführen, aber es geht allemal schneller als sich durch alle Shared Mailboxes zu klicken und nachzusehen wo der User berechtigt ist.

$usertosearch = "max@muster.de"
$sharedMailboxes = Get-Mailbox -RecipientTypeDetails SharedMailbox

foreach ($box in $sharedMailboxes) 
{ 
    $perms = Get-MailboxPermission -Identity $box.Alias

    foreach ($perm in $perms)
    { 
        if(
            $perm.User -like $usertosearch) 
            { 
                write-host $box.PrimarySmtpAddress 
            } 
    }
}

 

Published by Sandro on | Permalink

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.

Published by Sandro on | Permalink

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.

Published by Sandro on | Permalink