Archiv der Kategorie: Authentifizierung

ADFS 2016: Invoke-AdfsFarmBehaviourLevelRaise schlägt fehl

Nachdem in einer größeren Farm alle ADFS-Server durch Windows Server 2016 ausgetauscht wurden, war das Anheben des Farm Behaviour Levels dran. In der Regel muss hierzu lediglich das Cmdlet Invoke-AdfsFarmBehavourLevelRaise ausgeführt werden, fertig.

Hier aber kam beim Aufruf des Cmdlets jedes Mal die Fehlermeldung:

Invoke-AdfsFarmBehaviorLevelRaise : Database upgrade could not be performed on localhost. Error: Unable to connect to the database. You may not have permission to create the AD FS configuration database in the specified SQL server. You can do one of the following: (1) have the SQL administrator grant permissions to you to create the AD FS configuration database in the specified SQL server or (2) have the SQL administrator create the AD FS configuration database by running  SQL scripts. Use the Export-ADFSDeploymentSQLScript to create the SQL scripts.

After the SQL administrator runs the scripts, try the command again specifying that the database is to be overwritten.

Die Accounts hatten alle die benötigten Rechte, daher war die Fehlersuche sehr schwer. Im Log des SQL Servers standen mehrere Fehlermeldungen:

Login failed for user 'DOMAIN\ADMINUSER'. Reason: Failed to open the explicitly specified database 'AdfsConfigurationV3'. [CLIENT: xx.xx.xx.xx]
Login failed for user 'DOMAIN\ADMINUSER'. Reason: Failed to open the explicitly specified database 'AdfsConfigurationV3'. [CLIENT: xx.xx.xx.xx] 
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. Reason: Failed to open the explicitly specified database 'AdfsConfigurationV3'. [CLIENT: xx.xx.xx.xx] 
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. Reason: Failed to open the explicitly specified database 'AdfsConfigurationV3'. [CLIENT: xx.xx.xx.xx] 

Das machte die Fehlersuche auch nicht einfacher, denn die Datenbank wurde gar nicht erstellt.

Die Lösung

Nach einem Blick in die Dokumentation des Cmdlets löste sich das Problem per Try-And-Error, denn in dieser Umgebung war die Konstellation etwas komplexer: Die ADFS-Datenbank lag auf einem eigenen Always-On Cluster, das scheint bei dem Cmdlet für Authentifizierungsprobleme zu sorgen.

Die Nutzung der Parameter Credentials und ServiceAccountCredentials, ersterer mit einem Admin-Account, zweiterer mit dem Service Account lief das Cmdlet fehlerfrei durchlaufen:

$admincred = Get-Credential #Admin-Account angeben
$cred = Get-Credential #Service Account angeben
Invoke-AdfsFarmBehaviorLevelRaise -ServiceAccountCredential $cred -Credential $admincred

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.

Änderungen der Forefront-Roadmap: FIM und UAG

Gestern gab es Neuigkeiten im Server & Cloud-Blog von Microsoft zum Forefront Identity Manager und Unified Access Gateway:

Im ersten Halbjahr soll eine neue Version des Identity Managers erscheinen, die vor allem Verbesserungen in den Bereichen Hybrid Environments mit Windows Azure, Benutzerverwaltung und Compliance bringen soll.

Das Forefront UAG jedoch wird Microsoft zum 01. Juli 2014 nicht mehr verkaufen. Die Supportzeiträume entsprechen denen vom TMG. Einige Features von Windows Server 2012 R2 stellen die Funktionalitäten hinsichtlich Application Publishing bereit (Web Application Proxy), womit der Haupteinsatzzweck von TMG und UAG rudimentär abgedeckt werden soll.

Den ganzen Beitrag finden Sie hier

On Breaking SAML: Single-Sign-On Systeme anfällig

Die Ruhr-Universität Bochum hat vor kurzem eine Untersuchung veröffentlicht, in der verschiedene auf SAML basierende Single-Sign-On-Systeme auf Sicherheitslücken untersucht wurden.

Von den 14 untersuchten Frameworks waren danach 12 anfällig für eine XML Signature Wrapping Attacke. Untersucht wurden unter anderem:

  • Apache Axis 2
  • Windows Identity Framework
  • OpenSAML
  • Salesforce
  • SimpleSAMLphp
  • WSO2
  • OneLogin

Bei einer XML Signature Wrapping Attack wird das XML-Dokument mit den SAML Assertions (die Identifikation des Benutzers) mit weiteren Assertions angereichert. Das Dokument ist in der Regel signiert, jedoch lassen sich die anfälligen Systeme austricksen, in dem die zusätzlichen Assertions in einem nicht signierten Bereich des Dokuments untergebracht werden. Bei den anfälligen Systemen sind die Signaturverifikation und die Regelverarbeitung getrennt, sodass die zusätzliche Assertions akzeptiert und verarbeitet werden, auch wenn sie nicht signiert sind.

Die beiden nicht anfälligen Systeme waren SimpleSAMLphp und das Windows Identitiy Framework, das auch das SAML-Framework für SharePoint 2010 und Active Directory Federation Services 2.0 darstellt.

Die anfälligen Frameworks werden beispielsweise in Shibboleth, Joomla, WordPress, SugarCRM, Drupal und von Salesforce verwendet.