Archiv der Kategorie: Uncategorized

WAP-Trust mit ADFS kann nicht mit secondary node aufgebaut werden

Etwas ungewöhnliches Szenario bei einem Kunden:

ADFS-Farm mit zwei Servern (Windows Server 2019) intern, wir nennen sie nun mal ADFS1 und ADFS2. Zusätzlich zwei Web Application Proxies (WAP1 und WAP2) in der DMZ.

ADFS1 ist der primäre Knoten in diesem Verbund. Aufgrund von Netzwerkanforderungen muss der WAP1 direkt mit ADFS1 sprechen (hosts-Datei) und der WAP2 direkt mit ADFS2. Bei WAP1 ist der Aufbau des Trusts einwandfrei gelaufen. Beim WAP2 schlägt das Hinzufügen zum ADFS mit einem HTTP-Fehler 400 (Bad Request) fehl.

Hintergrund: Der WAP2 erzeugt ein Client-Auth-Zertifikat und schickt dieses über den Endpunkt /adfs/proxy/establishtrust an den ADFS2. Da dieser nicht der primäre Knoten ist, schickt ADFS2 das Zertifikat über den Aufruf von /adfs/proxy/primarywriter/establishtrust an den ADFS1 weiter.

In diesem Aufruf ist nun der Hostname des Ziel-ADFS-Servers enthalten, in diesem Fall also ADFS1. Allerdings schlägt dieser fehl, da der ADFS-Server den Hostname mit den registrierten Hostnames abgleicht. Und wenn man sich mit Get-ADFSFarmInformation die registrierten Servernamen anschaut, steht dort der FQDN drin, also adfs1.firma.de.

Lösung: ADFS2 einreißen und neu zur Farm hinzufügen, aber diesmal mit dem FQDN des ADFS1, also adfs1.firma.de. Danach funktioniert auch der Aufbau des Trusts von WAP2 über den Stellvertreter ADFS1.

Und wo findet man diesen Fehler: Im AD FS Tracing des Event-Logs (das muss aktiviert werden) findet sich in diesem Fall eine Informations-Meldung mit ID 54:
“HTTPListener: Unexpected exception: The host name adfs1 in the incoming request did not match the AD FS host name.”

Merke: ADFS-Nodes immer mit FQDN des Primary Nodes hinzufügen.

Nützlicher Schalter beim Anlegen eines Identity Providers: SignOutUrl

Vor Kurzem habe ich festgestellt, dass eine derzeit noch undokumentierte Eigenschaft in SharePoint gibt, die es einem erlaubt, beim Anlegen (und auch danach) eines Identity Providers in SharePoint eine SignOut-URL anzugeben.
Dies ist sehr nützlich, da hiermit das Ausloggen aus einer SAML-basierte Infrastruktur, wie z.B. ADFS möglich ist.

Die neue Option lässt sich bei der Verwendung von “New-SPTrustedIdentityTokenIssuer” mit dem Parameter SignOutUrl nutzen oder später mit Hilfe der Eigenschaft ProviderSignOutUrl festlegen.

Für die Nutzung in Verbindung mit ADFS könnte das Setzen der Eigenschaft per PowerShell beispielsweise so aussehen (vorausgesetzt, es gibt nur einen Identity Provider):

$ti = Get-SPTrustedIdentityTokenIssuer
$ti.ProviderSignOutUri = "https://login.firma.de/adfs/ls/?wa=wsignout1.0&wreply={UrlZurWeiterleitungNachSignOut}
$ti.Update()

Damit erspart man sich das leidige Anpassen der Login-Infrastruktur per Code. Die Eigenschaft kam mit einem der letzten Post-SP1-Updates, also zwischen April und Juli.

Seltsames Verhalten der Office Web Apps bei Sites im SharePoint 2010-Modus

Heute habe ich bei einem Kunden wieder ein seltsames Verhalten feststellen können, dass sich als Bug herausgestellt hat. Der Kunde hat seine Produktivumgebung auf SharePoint 2013 angehoben, lässt die meisten Sites aber noch im 2010-Modus laufen, da das neue Design noch nicht fertig ist. Einige Sites, z.B. das Search Center werden aber bereits im 2013er-Modus betrieben.

Zusätzlich wurden natürlich die Office Web Apps eingebunden. Wenn man nun von einer 2010er-Site ein Dokument in den Web Apps öffnet und dieses über Datei –> Beenden wieder schließt, sollte man eigentlich zur letzten URL zurück kommen. In diesem Fall kann es jedoch sein, dass man auf einer “beliebigen” SharePoint 2013-Site landet.

Der Grund hierfür ist recht einfach: Die 2013er-Sites setzen ein WmaContext-Cookie, die 2010er nicht. Die Web Apps-Integration in SharePoint verwendet dieses Cookie, um den Parameter sc im Aufruf der Web Apps mit der zuletzt besuchten URL zu befüllen.

Folge: Man landet beim Schließen der Datei nicht mehr auf der 2010er-Site, sondern auf der letzten 2013er-Site, auf der man die Web Apps verwendet hat.

Mal schauen, ob es hierfür jemals einen Fix geben wird, denn diese Kombination ist auch nicht gerade alltäglich 😉

Aktualisierungen im Microsoft Azure Portal

Microsoft hat in den letzten Wochen und Monaten ein neu designtes Management-Portal für Microsoft Azure entwickelt und als Preview bereitgestellt. Inzwischen sind einige neue Komponenten dazu gekommen, die bestehende Funktionen des alten Portals abbilden und erweitern.

Details zu den Erweiterungen finden sich in ScottGu’s Blog: http://weblogs.asp.net/scottgu/azure-virtual-machine-machine-learning-iot-event-ingestion-mobile-sql-redis-sdk-improvements

Das neue Portal befindet sich unter dieser Adresse: https://portal.azure.com/

SPC 2014: Identity Federation, Load Testing und Power BI

Der Dienstag wurde für mich von Spencer Harbor mit einem Vortrag zur Identity Federation für Office 365 mit Windows Azure Active Directory eröffnet. Zunächst einmal stellte er klar, dass man Identity Mangement benötigt, sobald man SharePoint im Einsatz hat. Wer schon einmal mit Organisationsstrukturen in Genehmigungsprozessen, der Personensuche oder einer einfachen Auflistung von Mitarbeitern einer Abteilung in SharePoint zu tun hatte, weiß genau, wovon Spencer Harbar hier spricht. Und der technische Teil dieses Managements macht gerade einmal 10% aus, der Rest sind politische Themen innerhalb des Unternehmens.

 
 

Technisch zeigte Spencer dann wie man mit Hilfe von Windows Azure eine hochverfügbare Infrastruktur für die Identity Federation aufbauen kann. Wer eine solche haben möchte, muss mit insgesamt sieben Servern (2x ADFS Proxy, 2x ADFS, 2x SQL Server und 1x DirSync) eine ganze Reihe an Maschinen bereitstellen und warten. Diese sind in Windows Azure eventuell nicht weniger verfügbar und es ergibt sich unter Umständen auch ein Vorteil bei der Bandbreite für Internet-Clients. Die Maschinen bleiben trotzdem Teil der internen Domäne und kommunizieren über eine verschlüsselte VPN-Verbindung mit dem eigenen Netzwerk.

 
 

Das größte Problem bei der Identity Federation ergibt sich jedoch aus der Domänenstruktur: Wer eine größere Anzahl an Domänen oder sogar Forests hat oder dessen Domäne über eine nicht öffentlich verifizierbare Adresse verfügt (.local) muss besondere Wege gehen: Im ersten Fall wird ein separater FIM-Server benötigt, im zweiten muss der UPN der Benutzeraccounts entsprechend angepasst werden.

 
 

Weiter ging es mit einem sehr unterhaltsamen Beitrag von Shane Young und Todd Klindt, die zeigten, wie einfach Load Testing von SharePoint 2013 mit Visual Studio 2013 auch für Nichtentwickler sein kann. Sie unterschieden dabei auch zweckmäßig den Performance-Test, Last-Test und Stress-Test voneinander und wie diese umsetzbar sind, um beispielsweise zu bestimmen bis zu welcher Anzahl Benutzer die Farm ausgelegt ist und wo der Schwachpunkt liegt.

 
 

Den Abschluss bildete an diesem Tag für mich ein Vortrag über Power BI für IT Professionals. Matt Mason zeigte in diesem Vortrag die Mächtigkeit von Power BI in Office 365, indem er verschiedene Kennzahlen mit Hilfe von Power Query in Excel importierte, mit Power Pivot das Datenmodell erstellte, mit Power View und Power Map als Diagramm und als Landkarte visualisierte und diese dann auf Office 365 veröffentlichte. Dort lassen sich dann anhand der Datenquellen mittels Power Q&A menschliche Abfragen formulieren, um andere Visualisierungen zu erhalten, beispielsweise “issues by nr of tenants and priority”. Power Q&A erstellt dann eine passende Ansicht dieser strukturierten Datenquelle. Voraussetzung ist natürlich eine gute Datenmodellierung, damit Q&A die Begrifflichkeiten auch entsprechenden Dateneigenschaften zuordnen kann.