Archiv für den Monat: September 2014

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.

Probleme bei TMG und Web Application Proxy

Heute hatte ich mal wieder eine interessant Konstellation: Für eine ADFS-Authentifizierung für Office 365 sollte ein ADFS Proxy über das Internet verfügbar gemacht werden. In Windows Server 2012 R2 gibt es hierfür den Web Application Proxy, der gleichzeitig ADFS Proxy ist. Eine separate Rolle gibt es in ADFS 3.0 nicht mehr.

Sollte eigentlich einfach sein: TMG ist bereits im Einsatz, Listener ohne Authentifizierung und mit passendem Zertifikat existiert bereits. Also einfach neue Web Publishing Rule anlegen, mit der entsprechenden URL und auf den WAP zeigen lassen.

Resultat:

Obwohl die Pfade und Adressen alle stimmen, sagt er, er könne den Host nicht finden.

Lösung: Derzeit gibt es keine für dieses Szenario, der Web Application Proxy kann nicht über eine Web Publishing Rule veröffentlicht werden. Wenn man allerdings den ADFS Server direkt published, funktioniert es, aus Sicherheitsgründen empfiehlt es sich aber nicht.

Es gibt zwei Möglichkeiten, dieses Szenario umzusetzen:

  1. Authentifizierung auf TMG und Kerberos-Authentifizierung am ADFS. Nachteil: Der eingegeben Benutzername im Office 365 wird nicht in das TMG-Formular übernommen, das müsste dann noch per JavaScript implementiert werden. Und damit geht natürlich auch nur die interne Authentifizierung, kaskadierte ADFS-Konstrukte sind damit nicht möglich.
  2. Port-Weiterleitung auf den WAP. Sollten allerdings noch andere Publishing Rules auf dem Listener liegen und keine weitere IP-Adresse zur Verfügung stehen, müssen die bestehenden Veröffentlichungen dann auch auf den WAP umgezogen werden und damit der TMG komplett umgangen werden.