Archiv der Kategorie: Uncategorized

Microsoft 365 Sharing und OTP Auth

23. Mai 2024Microsoft 365, UncategorizedGuest Access, Microsoft 365, SharePoint OnlineUwe Grohne

Letztes Jahr hat Microsoft hinsichtlich Sharing in OneDrive for Business und SharePoint Online eine große Änderung vorgenommen. Wenn anonyme Links nicht zugelassen waren, musste der Externe entweder über einen Entra ID-Account oder Microsoft Account verfügen.

Seit letztem Jahr wurde diese Funktion zur Anlage eines Gastaccounts seitens Microsoft verändert. Bei Einladung von Externen zu Teams und SharePoint Sites bleibt alles wie gehabt. Lediglich beim Teilen von Dateien und Ordnern in OfB und SPO ergibt sich ein anderes Bild:

Der Empfänger erhält eine E-Mail mit dem Link auf die Datei. Dort muss er dann seine E-Mail-Adresse erneut eingeben und erhält ein OTP zur einmaligen Authentifizierung und kann danach auf die Datei zugreifen.

Die Unterschiede der drei Varianten beleuchtet folgender Artikel auch mit Screenshots sehr gut: SharePoint and Microsoft 365 External Sharing with Non-Microsoft Accounts | SharePoint Maven

Problem ist nun, dass das Verhalten aus meiner Sicht nicht konsistent ist. Damit werden MFA-Anforderungen und auch das Abnicken von Nutzungsbedingungen (die teilweise von Unternehmen gefordert werden) umgangen.

Um das alte Verhalten auch für Datei- und Ordnerlinks zu implementieren, bringt es leider auch nichts, den IdP “Email one-time passcode” zu deaktivieren, am Verhalten ändert sich nichts:

Stattdessen muss die AAD-B2B-Integration aktiviert werden. Dies erfolgt mit einem einfachen PowerShell-Befehl für den SharePoint Online-Tenant, der in folgendem Artikel beschrieben ist: : https://learn.microsoft.com/en-us/sharepoint/sharepoint-azureb2b-integration#enabling-the-integration

Damit erfordern die Links zukünftig wieder, dass der Externe einen Gast-Account anlegen und sich mit MSA oder EntraID authentifizieren muss. Und die Terms of Use müssen auch wieder abgenickt werden.

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

27. November 2019UncategorizedUwe Grohne

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

10. September 2014Authentifizierung, SharePoint 2013, UncategorizedUwe Grohne

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

22. August 2014SharePoint 2013, UncategorizedUwe Grohne

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

13. August 2014UncategorizedUwe Grohne

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

12. März 2014UncategorizedUwe Grohne

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.