Category: Azure

Recursively search Azure Ad group members

When working with on-premise Active Directory an administrator often has to recursively search AD groups, this is easy using the ActiveDirectory module with cmdlet ”Get-AdGroupMember <Group> -Recusive”.
For the AzureAD equivalent this is no longer an option, the cmdlet Get-AzureADGroupMember has three parameters.

PARAMETERS
-All <Boolean>
If true, return all group members. If false, return the number of objects specified by the Top parameter
-ObjectId <String>
Specifies the ID of a group in Azure AD.
-Top <Int32>
Specifies the maximum number of records to return.



(tech preview) Using multiple IPs on one NIC with NetScaler in Azure

Microsoft has released a tech preview to support multiple IPs on the same NIC in Azure. I’ve tried it with NetScaler and seems to be working like expected!

More info about it can be found here: Assign multiple IP addresses to virtual machines using PowerShell

As always, logon and select your subscription using PowerShell:

FYI: This may take a few minutes. Even after registring the features (and seeing them being registered), I received the following error message when trying to assign multiple IP configurations to one NIC: Subscription <ID> is not registered for feature Microsoft.Network/AllowMultipleIpConfigurationsPerNic required to carry out the requested operation.

It started working for me after running Register-AzureRmResourceProvider, but maybe I just didn’t wait long enough.

Verify that they have the state ”Registered”:

You can now go to the portal and assign new IP configurations, or do it from PowerShell. See below for how I added new IPs to an already existing NetScaler:

Now, just add a SNIP and then start working with your VIP or VIPs in NetScaler. Remember, this is still a Tech preview and shouldn’t be used in production – you may not get support from Microsoft or Citrix if something stops working.



Använd Bidirectional Forwarding Detection ihop med BIRD

I mitt senaste inlägg skrev jag lite kort om hur OSPF kan användas för att skapa en dynamisk routing med BIRD. Det finns en ytterligare funktion för att snabba upp feldetektering och förändra routing-tabellen så fort det bara går.

Funktionen kallas Bidirectional Forwarding Detection (BFD) och går snabbt att lägga till.

Första delen är att vi aktiverar funktionen på samtliga noder:

När detta är gjort på samtliga noder kan vi ladda om konfigurationen och sedan verifiera att det fungerar:

Så enkelt var det!



Använd OSPF för routing mellan StrongSwan VTI med BIRD

Jag skrev här om dagen ett inlägg angående att använda OSPF mellan StrongSwan VTIs. Många använder BIRD istället för Quagga för att hantera routing i Linux. I detta inlägg tänkte jag kort visa hur vi kan byta ut det vi gjorde med Quagga och göra det med BIRD istället.

Eftersom vi förra inlägget använde Quagga så tar vi och stänger av det:

Därefter installerar vi BIRD och konfigurerar (tar bara med ett exempel):

Konfigurationen (väldigt enkel, för att reflektera hur jag gjorde med quagga):

Aktivera autostart och starta BIRD:

För att få ut information om routing kan vi använda birdc:

 



Använd OSPF för routing mellan StrongSwan VTI

I mitt tidigare inlägg beskrev jag hur IPSec-tunnlar kan sättas upp med hjälp av CentOS och StrongSwan. För att slutföra det hela vill vi ju så klart skapa en dynamisk routing mellan noderna så vi inte behöver sitta och konfigurera sånt manuellt.

Installation och grundkonfiguration:

Därefter, konfigurera en statisk route till ”Client” nätet för respektive router och konfigurera dem för OSPF.

Nu kan du verifiera att det fungerar genom exempelvis köra följande på en av dem:

Genom att vi kör broadcast kan du testa att stänga av olika vti och se hur trafiken ändrar path. I mitt fall använde jag Windows 10-maskiner på mina ”Client” subnät som kommunicerade med varandra. Värt att tänka på är att inte glömma user defined routes för subnät 01.



Skapa IPSec VPN med StrongSwan mellan Azure VM

Jag inledde min tidigare post med att förklara hur jag satte upp ett CentOS VM i Azure med flera NIC, detta för att kunna ta hand om exempelvis IPSec-tunnlar mellan olika Azure-siter men även mellan Azure och on-premises. Varför inte använda Azure Virtual Network Gateway? Den fungerar ju fantastiskt bra, men i större miljöer vill du köra route based VPN och blir väldigt lätt problem om många parter är inblandade med olika märken (Cisco ASA, Fortinet, CheckPoint, Juniper, Palo Alto Networks och så vidare). Många gånger går det att lösa, men många gånger är det bara enklare att sätta upp en enhet i Azure som hanterar det så som en Cisco CSR eller Palo Alto Networks VM-series för att underlätta konfiguration och felsökning – när många är inblandade och har olika krav på hur det skall hanteras.

Jag fick för mig att det kan vara roligt att göra något liknande med Linux, för att lära mig lite mer om StrongSwan men även Quagga och mer specifikt OSPF i Linux – men kanske mer om det en annan gång.

Jag satte upp en miljö i Azure uppdelat på tre regioner:

  • UK South
    • 1 virtual network med 3 subnät
      • 10.18.0.0/16 – address space
      • 10.18.0.0/24 – subnet 01 (”clients”)
      • 10.18.16.0/28 – subnet 02 (”router inside”)
      • 10.18.16.16/28 – subnet 03 (”router outside”)
    • 2 virtuella maskiner
      • rtr01 – 1 NIC på subnet 02 och ett NIC på subnet 03
      • win10 – 1 NIC på subnet 01
    • User defined route
      • Applicerad på subnet 01 och pekar ut de andra regionerna via rtr01 på subnet 02
  • West Europe
    • 1 virtual network med 3 subnät
      • 10.17.0.0/16 – address space
      • 10.17.0.0/24 – subnet 01 (”clients”)
      • 10.17.16.0/28 – subnet 02 (”router inside”)
      • 10.17.16.16/28 – subnet 03 (”router outside”)
    • 2 virtuella maskiner
      • rtr01 – 1 NIC på subnet 02 och ett NIC på subnet 03
      • win10 – 1 NIC på subnet 01
    • User defined route
      • Applicerad på subnet 01 och pekar ut de andra regionerna via rtr01 på subnet 02
  • West US
    • 1 virtual network med 3 subnät
      • 10.16.0.0/16 – address space
      • 10.16.0.0/24 – subnet 01 (”clients”)
      • 10.16.16.0/28 – subnet 02 (”router inside”)
      • 10.16.16.16/28 – subnet 03 (”router outside”)
    • 2 virtuella maskiner
      • rtr01 – 1 NIC på subnet 02 och ett NIC på subnet 03
      • win10 – 1 NIC på subnet 01
    • User defined route
      • Applicerad på subnet 01 och pekar ut de andra regionerna via rtr01 på subnet 02

Jag utgick i stort sett helt och hållet utifrån denna sida för att konfigurera StrongSwan. Utan att gå in på var enda detalj kan det vara värt att nämna att jag satte SELinux till permissive för att få StrongSwan att köra updown-skriptet, installerade en senare kernel än den som följde med mitt Azure VM (4.9.0 från elrepo – notera att jag fick manuellt tvinga den nya till att vara den aktiva med ”grub2-set-default 0”).

Själva installationen på samtliga maskiner är lika enkel som vanligt:

Därefter stängde jag av att routes samt virtuella ip skall installeras när tunnlar sätts upp:

Därefter konfigurerade jag up/down-skriptet på respektive nod:

Notering: Glöm inte att sätta ipsec-vti.sh till exekverbar. (chmod +x /etc/strongswan/ipsec-vti.sh)

Nästa steg är att sätta upp spelreglerna för hur tunnlarna skall förhandlas:

Och till sist behöver våra pre-shared keys konfigureras:

Därefter skall det bara vara att starta strongswan (systemctl start strongswan) och börja routa via de olika vti (virtual tunnel interface). Glöm inte att uppdatera eventuella network security groups för att tillåta UDP\500 och UDP\4500!

IP forwarding kan behövas i detta steg:

Det blev en del konfiguraiton, så eventuellt att jag missat något steg. Men tror inte det! Tänk på att använda swanctl för felsökning, hjälper helt klart när man missar ett ”i” i leftid!

 



Skapa VM med flera NIC i Azure ARM

Jag har suttit med ett antal virtual appliances från exempelvis Citrix (NetScaler), Cisco (CSR) och Palo Alto Networks (VM-series) och började fundera kring om jag kan ersätta exempelvis CSR med en billigare variant – exempelvis CentOS – som kan ge högre bandbredd utan några krav på licenser och liknande.

Efter att ha suttit i portalen och skapat VM fram och tillbaka kom jag fram till att även om exempelvis DS2_v2 har stöd för flera NIC så kan man lägga till dem där, så satte mig och gjorde det via powershell.

Värt att notera kring ovan är:

  • Jag hade redan skapat min resource group, virtual network, subnets och storage
  • Eftersom jag kör premium storage skapas en standard storage för diagnostics med ovan, vilket jag inte hade
  • Public IP kan endast bindas mot det NIC som är märkt som primary

Vill du byta primary NIC är det möjligt, jag gjorde det med tog för lång tid att slå igenom så valde att skapa om VM:et istället:

 



Sätt statisk DNS för ett VM i Azure med ASM

Med Azure Service Management går det endast att byta DNS-inställningar för VM genom att ändra det på virtual network, vilket kanske inte är önskvärt (exempelvis om det finns flera VM som behöver ha dessa DNS-inställningar för att fungera).

Lösningen är då att skapa VM:et med DNS-inställningarna från början. Har du redan skapat ditt VM och behöver göra det så behöver du tyvärr ta bort ditt VM (inte diskarna!) och sedan skapa det på nytt med rätt DNS-inställningar. Detta är löst med Azure Resource Manager / ARM, så självklart rekommenderat att köra det med har du ett befintligt virtual network i ASM och vill fortsätta använda det ett tag så kan du göra enligt nedan.

Jag utgår från min föregående post Flytta Hyper-V VM till Azure för nedan rader:

 



Flytta Hyper-V VM till Azure

Det finns många sätt att flytta Hyper-V VM till Azure, i detta fallet beskriver jag hur det kan göras till ett befintligt virtual network (classic / Azure Service Management – ASM).

Kortfattat är det följande som behöver hanteras: (denna guide utgår från att VM:et kört sysprep innan det importeras)

Innan ett VM flyttas från Hyper-V till Azure behöver det bekräftas att Remote Desktop är aktiverat samt att det är tillåtet i brandväggen för Domain, Public och Private networks.

Mer info om hur powershell för Azure installeras och används finn här: How to install and configure Azure PowerShell

Kortfattat, vad som behöver göras för att koppla upp sig innan ovan kan utföras:

När väl den virtuella maskinen är igång finns det några saker som är rekommenderade att utföra (enligt Windows IT Pro: Use a Non-SYSPREP VHD in Azure):

KMS Client Keys finns här: Technet – Appendix A: KMS Client Setup Keys

Jag valde även att installera Azure Windows VM agent, vilket även kräver .NET 4.5 om det inte redan är installerat. Mer information om detta finns här: About the virtual machine agent and extensions

Jag valde även att ta bort så kallade ”Ghost NICs” från den virtuella maskinen, då jag sett att det ibland kan ställa till problem:

Har du något mer du gör när du flyttar VM till Azure? Lämna gärna en kommentar!



Testa hastigheten till Azure datacenters

Intresset för Azure är enormt bland våra kunder, speciellt våra kunder som har kontor över hela världen. Men vilket datacenter ska man välja när man bygger sina tjänster i Azure? Är verkligen det datacenter som fysiskt ligger närmast det man har snabbast svarstider till? Det finns en bra tjänst för att testa detta: http://www.azurespeed.com/

Här kan man göra ett antal olika tester för att se vilket datacenter som passar just dig bäst inklusive svarstider och test att ladda upp filer.

Azure-speed-test

Det finns några andra som kan vara bra att testa också: