Unsere nächste
Veranstaltung

Das nächste Communitytreffen findet am 08. Juni 2017 in Dortmund/Ruhrgebiet statt. Details zur Veranstaltung, Agenda und Anmeldung gibt es hier ...

 

Azure Stack - Liebling ich habe Azure geschrumpft

DRAzureStack

Einfach mal reinschauen ...  es lohnt sich!

Weiterlesen

Dr. AzureStack Sprechstunde

azureStack

Sie möchten Ihre Fragen zu AzureStack mit unserem Experten diskutieren? Dann schauen Sie in unserer AzureStack Sprechstunde vorbei.

Weiterlesen

Azure Stack Webinar starten wieder durch ...

azureStack

Nachdem wir im letzten Jahr bereits erste Webinare zu Azure Stack durchgeführt haben, starten wir mit der Verfügbarkeit vom TP3 refresh mit diesem Thema erneut durch. Melden Sie sich jetzt hier an.

Weiterlesen

Azure Stack TP3 refresh verfügbar

Seit wenigen Minuten steht der langersehnte Azure Stack TP3 Refresh zum Download zur Verfügung. Für alle, die wie wir in der letzten Woche in Redmond auf dem Azure Stack Airlift waren langersehnt, für alle anderen der passende Moment, jetzt mit der Hybrid Cloud Lösung aus dem Hause Microsoft durchzustarten.

Zu den zahlreichen neuen Features gehören:

  1. Azure App Service (Web apps, API apps, and Mobile apps)
  2. Azure Functions preview für AAD basierte Deployments
  3. Deployment in disconnected Umgebungen
  4. Deployment auf Basis von ADFS basiertem Azure Stack
  5. Installations und Deployment VerbesserungenAzure Resource Manager (ARM) API version 2016-03-01
  6. Synchronisation der SKUs mit Azure – z.B. F1, D1 und Standard (S1, S2, S3)
  7. Allgemeine Qualitätsverbesserungen

Es lohnt sich richtig, jetzt loszulegen.

Weitere technische Details sind in der Azure Stack Dokumentation vorhanden.

Bekannte Fehler sind:

  1. verlängerte Deployment Zeiten im Vergleich zu anderen Releases
  2. Anmelden im Portal via ADFS kann zu einer Fehlermeldung führen
  3. Falsche Angaben zu Cores pro Minute für Windows u. Linux VMs
  4. Beim Öffnen vom Storage Explorer für einen Storage Account kommt es zu einer Fehlermeldung
  5. Ein Deployment mittels ADFS ohne Internet Verbindung führt zu einer Fehlermeldung und der Host läuft nach 10 Tagen ab. Es wird empfohlen, während des Setups eine Internetverbindung zur Verfügung zu stellen
  6. Key Vault Dienste müssen aus dem Tenant Portal order der Tenant API erstellt werden
  7. VM Scale Sets sollten per Template erstellt werden
  8. Fehler beim Health State des Compute u. Health Controllers
  9. HSM Backup Vaults sind nicht unterstützt
  10. Es gibt die max. Anzahl von 1 für Fault Domains
  11. Beim Neustart werden die Infrastrukturdienste in der falschen Reihenfolge gestartet
  12. Das Einbinden des SLB via Portal schlägt fehl
  13. Die Anzahl des "Totalen Speichers" in der Region ist MB statt GB

Weiterlesen

Automatisierung der ADFS Home Realm Discovery bei mehreren Azure AD Tenants/Domains und Identity Providern

Automatisierung der ADFS Home Realm Discovery bei mehreren Azure AD Tenants/Domains und Identity Providern

Bei einem Kunden war der folgenden Anwendungsfall gegeben: Office 365 und Azure wird eingesetzt, dabei erfolgt das Identity Management allerdings mit unterschiedlichen Domains (Sowohl DNS als auch ADDS Domains), beziehungsweise Azure AD Tenants. Allerdings war die Anforderungen, dass die Authentifizierung wiederum mittels einer Zentralen ADFS Farm erfolgen soll an die wieder zwei Claims Provider verknüpft sind.

Föderation von Azure AD zu ADFS   

Grundsätzlich ist das Föderieren von zwei oder mehreren Azure AD Domains/Tenants kein Problem und relativ einfach zu lösen. Seit geraumer Zeit ist kann man beim Einrichten des ersten „Relying Party Trusts“ zwischen Azure AD und ADFS mittels PowerShell einrichten. Dabei gibt es verschiedene CmdLets die eine Föderierung einrichten und den Switch –SupportMultipleDomains unterstützen. Dabei wird auf ADFS der Trust für mehrere Domains einrichten. Der Switch sorgt unter anderem dafür, dass der FederationServiceIdentifier auf Azure AD, als auch der IssuerID Claim in ADFS, Domain-spezifisch konfiguriert eingerichtet wird.

In ADFS wird so eine neue Claim Rule hinzugefügt die anhand des Claims UPN, den Wert des IssuerID Claims dynamisch setzt:

c:[Type == “http://schemas.xmlsoap.org/claims/UPN“]
=> issue(Type = “http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid“, Value = regexreplace(c.Value, “^((.*)([.|@]))?(?<domain>[^.]*[.].*)$”, “http://${domain}/adfs/services/trust/“));

In meinem Anwendungsfall hatte ich allerdings mit der Schwierigkeit zu kämpfen, das ich pro registrierter Domain ebenfalls einen anderen Identity Provider hatte und (das wäre noch relativ einfach) einer von beiden IdPs ist kein Active Directory sondern ein SAML 2.0 IdP.

Well I tried…

Da bei dem Kunden-Setup die Azure AD pro Tenant getrennt voneinander betrachtet werden, war meine erste Idee zwei Relying Party Trusts einzurichten. Dabei habe ich das Tenant spezifische MetaData-XML von den beiden Azure AD Tenants heruntergeladen und die beiden Trusts eingerichtet. 

Nach dem Ausführen des Powershell-CmddLets zur Konfiguration der Föderierung hat sich herausgestellt, dass ein neuer Trust erstellt wird. Zusätzlich zu den Tenant spezifischen Relying Party Trusts wird der Standard Relying Party Trust mit der oben angesprochenen Claim Rule, eingerichtet. Wenn man diesen wieder löscht (ich habe ja schon zwei Relying Party Trusts mit der Tenant spezifischen Metadata XML) funktioniert nichts mehr.

Warum?

Nun ja, Microsoft bietet zwar die Tenant spezifischen Metadata XML an, allerdings aus einem anderen Grund und zwar für Multi-Tenant Apps die gezielt nur spezifische Azure AD Tenants eingebunden haben und so nicht (zumindest theoretisch) sämtlichen Azure AD Identitäten Zugriff erlauben.

Wenn man sich den wtrealm Claim in der URL anschaut (kommend vom Azure oder Office 365 Login Portal an den ADFS), merkt man wo das eigentliche Problem ist. Während das Attribut username in der URL den Username, welcher der User in den Office 365 oder Azure Portal eingegeben hat liefert, sendet Microsoft standardmäßig (und nicht änderbar!) als wtrealm das Attribut urn:federation:MicrosoftOnline. Dieses Attribut wird mit dem NameIdentifier im ADFS gemappt. Der NameIdentifider Wert muss innerhalb der ADFS Umgebung „unique“ sein. Das bringt die zwei folgenden Probleme mit sich:

  1. Da der Wert „unique“ sein muss, kann nicht ein zweiter Trust aufgebaut werden
  2. Die Tenant spezifischen Trusts haben zwar unterschiedliche NameIdentifider Werte, allerdings schickt das Azure oder Office 365 Login Portal (im Backend nachher Azure AD) nicht den Tenant spezifischen NameIdentifider (sts-windows.net/{TenantID}) sondern den globalen Wert (urn:federation:MicrosoftOnline)

Ergebnis: Alles muss über einen Relying Party Trust abgewickelt werden!

User Friendly Home Realm Discovery

Beim Hinzufügen eines zusätzlichen Claims Provider zum ADFS Server, ändert sich auch die Home Realm Discovery Seite bei ADFS. Dies hat Auswirkung auf die User Experience. Dabei wird zwischen zwei verschiedene Authentifizierung unterschieden.

Bei passiver (Meist Browser-based) Authentifizierung wird der User standardmäßig vor die Wahl gestellt, ob er sich mittels Claims Provider 1 oder Claims Provider 2 authentifizierenden möchte. Thick Clients von Microsoft unterstützen ab Office 2013 mit dem Update „Modern Authentication/ADAL“ die Möglichkeit der passiven Authentifizierung.   

Bei aktiver Authentifizierung ist der Client nicht „SSO/ADFS-Aware“. Deshalb verbindet sich Azure AD (On-behalf-Of User/Client), sobald solch ein Request aufschlägt, zum ADFS Server bzw. Proxy. Beispiele wo eine solche Form der Authentifizierung genutzt wird sind: Exchange Active Sync (EAS) und der Outlook 2010/Lync Thick Client.

Mehr zum Thema Aktive/Passive Authentifizierung kann hier und hier gefunden werden.

Die Art wie die Home Realm Discovery Seite sich verhält kann mittels Powershell so verändert werden, dass nur ein Claims Provider ausgewählt werden kann bzw. das gleich an Claimsprovider x verwiesen wird (indem man den Relying Party Trust konfiguriert bzw. Argument ergänzt). Wie so etwas zu konfigurieren ist, kann man sehr gut hier nachlesen. In dem Kunden Use Case wird allerdings nur ein Relying Party Trust verwendet und somit scheiden sämtliche Wege die Home Real Discovery über PowerShell zu automatisieren aus.

Letze Chance: Java Script

Die letzte Chance noch eine automatisierte Home Realm Discovery hinzubekommen erinnert an ADFS 2.0 Zeiten. Nun hilft nur noch Java Script weiter. Seit ADFS 3.0 basiert die ADFS Website nicht merh auf IIS . Sämtliche Webserver-Daten wurden in eine DLL ausgelagert.

Doch nur nicht Aufgeben:
Es gibt weiterhin die Möglichkeit das ADFS-Theme (u.a. die Home Realm Discovery Seite) zu exportieren und durch ein neues zu ersetzen. Bei dem Export Vorgang erhält man Zugriff auf sämtliche HTML Seiten und auch auf die JavaScript Datei „onload.js“ (die beim Start geladen wird).

Mit wenigen Zeilen Javas Script (am Ende der Datei) kann das gewünschte Ergebnis erreicht werden. In dem Code wird geprüft ob in der URL die Domain „firstdomain.de“ gefunden wird und wenn ja wird ein Redirect auf den SAML IdP ausgeführt, wenn nicht wird der AD Claims Provider verwendet:

//Check domain in url and act accordingly

var locationUrl = window.location.href;

var locationUrlToLower = window.location.href.toLowerCase();

var result = /azuredomain.de/.test(locationUrlToLower);

if (result == true)

    //URL to redirect the user to either AD or to my SAML IdP

    {

        var myRedirectURL = locationUrl + "&RedirectToIdentityProvider=my.SAMLIdP.com";

        window.location.href = myRedirectURL;

    }

else

     {    

HRD.selection('http://adfs.mydomain.de/adfs/services/trust');

     }

Authentifizierungs-Requests des Typs „Aktiv“ sollten hierbei nicht beeinflusst werden, da sich die Domains unterscheiden anders sind und die Office 365 Domain nicht beeinflusst wird. 
Mehr Infos und Anleitungen zum Manipulieren der Home Realm Discovery Seite findet man hier.

Ich hoffe der Blog war interessant und man konnte etwas mitnehmen!

Viele Grüße,

Lennart 

Weiterlesen

Azure Stack TP3 – wie wird das Azure in your datacenter aussehen?

Microsoft hat im Mai 2015 angekündigt, Azure in einem kleineren Footprint für ihr Rechenzentrum zur Verfügung zu stellen. Seither ist ziemlich viel passiert: es gab drei Technical Previews, das dritte ist vor wenigen Tagen veröffentlicht worden. Die TP3 ist die letzte Vorabversion des Produkts vor seiner Veröffentlichung, welche für Mitte 2017 erwartet wird.

Ein Azure Container in einem Azure Rechenzentrum sind mehrere tausend Server, Azure Stack wird mit einem kleinsten Footprint von 4 Servern inkl. Switch veröffentlicht werden. Neben dem Hardware-TAP gibt es weiterhin die „Single Host Edition“ (aka Azure Stack PoC) welche umbenannt werden wird zu „Microsoft Azure Stack Development Kit“ und weiterhin gepflegt.

TP3 brachte folgende neuen Features:

  1. ADFS Szenarien, d.h. es ist jetzt möglich Azure Stack aufzusetzen ohne direkte Anbindung an AzureAD. Das ist insbesondere für Service Provider interessant. Gleichzeitig bedeutet das jedoch auch, dass nur ein ADFS angebunden werden kann. Ebenfalls ist ein Wechsel von ADFS zu AzureAD und vice versa nicht angedacht. Dazu muss Azure Stack neu aufgesetzt werden.
  2. Unterstützung von Scale Out Workloads durch die Möglichkeit der Nutzung von Virtual Machine Scale Sets
  3. Unterstützung für Azure D-Serien VM templates
  4. Erstellen und anbinden von Azure Temporären Disks, konsistent zu Azure
  5. Isoliertes Administrationsportal getrennt vom Kundenportal
  6. Erweiterte Möglichkeit zur Überwachung und für Kapazitätsmanagement
  7. Marketplace Syndication mit Azure, d.h. es können komplette Templates aus Azure geladen und in Azure Stack zur Verfügung gestellt werden (nicht nur das zugehörige ARM Template), so dass es – vorausgesetzt der jeweilige Service ist in Azure Stack verfügbar – recht einfach ist, Services von Azure nach Azure Stack zu transferieren.

Wie schon aus den bisherigen Azure Stack Technical Previews bekannt, wird es zu TP3 ebenfalls ein Refresh werden, welches die Funktionen:

  • Blockchain
  • Cloud Foundry
  • Mesos Templates

zur Verfügung stellt.

Nach GA wird es regelmäßige Updates für Azure Stack geben, welches weitere Features zur Verfügung stellen wird. Welche Features und Services in welcher Priorität hier zur Verfügung gestellt werden, hängt stark von „User Voice“ ab.

Zudem besteht die Möglichkeit, die Azure Stack Lizenzierung an bestehende Azure Subscriptions zu binden. Auch hier besteht zu GA keinerlei Wechselmöglichkeit, wenn man sich einmal für eine Subscriptionversion entschieden hat.

Wer sofort testen möchte, der kann hier die aktuelle TP3 herunterladen.

Wir werden in Kürze weitere Details zu Azure Stack in unserem Portal zur Verfügung stellen.

Weiterlesen