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