Monthly archives: december, 2016

XENAPP/XENDESKTOP 7.12 – Local Host Cache

Citrix har släppt Xenapp/XenDesktop 7.12 och åter introducerat en mycket efterfrågad funktion som tidigare funnits i XenApp 6.x versioner. Funktionen är local host cache (LHC) och tillåter användare att ansluta till publicerade applikationer, även om SQL-databasen är otillgänglig. Det sker genom att information från databasen cacheas ner lokalt på Delivery Controllers varannan minut.

Local Host Cache Architecture

Local Host Cache Architecture

Citrix-databasen håller reda på vilka applikationer som är publicerade på vilken server. I tidigare versioner av XenApp/XenDesktop 7.x har man fått använda sig av Connection Leasing som nu ersätts av LHC.

Med Connection Leasing kunde användare endast använda sig av resurser som de tidigare anslutit sig till om databasanslutningen var otillgänglig. Med LHC har de möjlighet att ansluta till samtliga resurser oavsett om de tidigare anslutning till dem.

Aktivera Local Host Cache

Funktionen LHC blir aktiverad vid en nyinstallation av XenApp 7.12. Utför man däremot en uppdatering till 7.12, från 7.11 eller tidigare förblir Connection Leasing aktiverat.

För att se nuvarande status på Local Host Cache och Connection Leasing, kör följande kommando på Delivery Controller.

För att aktivera LHC efter en uppgradering kör man nedan PowerShell kommando på Delivery Controller.

Ovan kommando laddar in Citrix-snapin och aktiverar LHC och inaktiverar Connection Leasing funktioner.

Källa: http://docs.citrix.com/



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:

 



Using callout to validate API token

I have a scenario where I need to use AAA / Unified Gateway to authenticate users, but would like to pass-through valid tokens directly to the API without using AAA – if the token is valid.

My solution was to create a callout in NetScaler to validate the token, and if valid allow access through to the backend. This may also be used in other cases like providing cached API responses from NetScaler.

It works like a charm! If you have any feedback or questions, feel free to leave a comment.



GCM ciphers causing issues

I’ve seen issues with multiple backend applications (Exchange 2013 and custom built web application) where there has been sporadic issues with content being delivered to and from the backend. In the Exchange case, emails got stuck in outbox (was able to recreate the issue by sending large attachments) and the other case where a PDF was generated on the site.

We are usually using the following ciphers:

The issue has been resolved by removing the following four ciphers:

I’ve only seen the issue on hardware so far (nitrox 2), both MPX and SDX. I’ve created two cases for two different customers, send me an email if you need the case numbers for reference.

The issue is so far present in version 11.1 build 49.16 and build 50.10.



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:

 



Hämta Office 365 IP-adresser via PowerShell

I vissa Office 365 uppsättningar, främst Hybrid behöver man tillåta att Office 365’s tjänster får kommunicera emot sina interna resurser.

Exempelvis behöver man i Exchange Hybrid uppsättningar tillåta IP-adresserna som Exchange Online använder sig utav i en Receive Connector lokalt för att få skicka mail inom samma organisation mellan Office 365 och on-premise. För detta har Microsoft ett inbyggt kommando Get-HybridMailflowDatacenterIPs i PowerShell-modulen för Exchange Online som hämtar ut nödvändiga IP-adresser.

För att automatisera processen med Get-HybridMailflowDatacenterIPs och uppdatera det dynamiskt finns det en bloggpost från Microsoft här som går igenom stegen:
Exchange Online: Keeping your ‘Inbound From Office 365’ Receive Connector Current with Microsoft Public IP’s

Det kan däremot finnas andra tillfällen när man vill ha ut samtliga IP-adresser som Office 365 använder sig utav, t.ex om man har ett eget antispam-system eller låsa ner i en brandvägg vilka IP-adresser som får kommunicera med sina interna resurser.

Dessa IP-adresser har Microsoft släppt i en publik lista där samtliga URL:er och IP-adresser som Office 365 och respektive tjänst använder sig utav, Office 365 URLs and IP address ranges som också finns i XML-format, O365IPAddresses.xml

Då adresserna finns tillgänlgigt i XML-format kan man via PowerShell läsa ut dessa och få samtliga adresser i en variabel som kan användas för att automatiskt och dynamiskt uppdatera sina regler. I exemplet nedan läser jag ut samtliga IPv4-adresser som Exchange Online Protection använder sig utav:

Resultatet blir:

$address kan jag sedan använda mig för att göra olika API-anropp till min brandvägg eller tredjepartstjänst och dynamiskt uppdatera mitt regelverk.



Visio Online och Visio Viewer för iOS

Bild: blogs.office.com

Microsoft har gått ut med att ytterligare en produkt i Office 365 sviten kommer finnas tillgänglig direkt i webbläsaren, nämligen Visio i form av Visio Online. I Visio Online får man möjlighet att se Visio-diagram direkt i webbläsaren men även valet att öppna och redigera diagramet direkt i fullversionen.

I skrivande stund finns Visio Online som Preview och tillgänglig för de kunder med följande Office 365 licenser:

  • Office 365 Business Essentials
  • Office 365 Business Premium
  • Office 365 Enterprise E1
  • Office 365 Government E1
  • Office 365 Enterprise K1
  • Office 365 Government K1
  • OneDrive for Business Plan 1
  • OneDrive for Business Plan 2
  • SharePoint Online Plan 1

Mer information om Visio Online Preview och hur man kommer igång finns att läsa här:
products.office.com/en-US/visio/visio-online

Utöver det kommer även Visio till iOS i form av Visio Viewer där du kommer ha möjlighet att se diagramen direkt i iPhone eller iPad.  Just nu finns den enbart tillgänglig för iPad men kommer inom närmaste månaderna även till iPhone.

Mer information och nedladdning av Visio Viewer finns att läsa här:
products.office.com/en-US/visio/visio-for-ipad

 



Tenant isolering i Office 365

Att Microsoft använder en delad infrastruktur i Office 365 för sina kunder är inte någon nyhet men hur separerar de kundinformationen mellan olika kunder (tenants)?

I en uppdaterat whitepapper sammanfattar och förklarar Microsoft hur de ur ett säkerhet, integeritet och tillgänglighetsperspektiv separerar informationen mellan olika tjänster och kunderna.

Dokumentet senaste version finns att ladda ner här: aka.ms/Office365TI