Ich habe mich dieser Tage damit beschäftigen müssen die Authentifizierung einer SharePoint-Webanwendung umzustellen. Ich werde mich hier nicht weiter um die Beschreibung der Authentifizierungsmethoden kümmern, das wurde auf blogs.msdn.com von Russ Maxwell bereits erfolgreich und verständlich getan.
Ich habe nun das folgende Szenario:
Es läuft eine Webanwendung mit der Claims-Based-Authentication Methode. Diese Webanwendung muss auf Classic Mode Authentifizierung umgestellt werden. Zuerst ändern wir die Webanwendung einfach von Claims Based auf Classic Mode. Da wir hier nicht die Möglichkeit haben die Änderungen über die UI zu machen greifen wir auf die wunderbaren SharePoint-2010 cmdlets zurück ;-)
$web = Get-SPWebApplication http://MyWebApplication
$web.UseClaimsAuthentication = 0
$web.Update()
$web.ProvisionGlobally()
Nun überprüfen wir noch, ob die Änderungen auch gegriffen haben:
$web = Get-SPWebApplication http://MyWebApplication
$web.UseClaimsAuthentication
Als Ergebnis wird uns ein "false" zurückgeliefert, also die Webanwendung läuft jetzt wieder unter Classic Mode Authentifizierung. Als Benutzer erhält man nun einen "Access denied", Grund dafür sind die Claims der Benutzer (wir werden nicht als gültiger Benutzer authentifiziert), diese müssen nun noch entfernt/rückgängig gemacht werden.
Wenn man sich dann mal die verfügbaren Methoden zum Migrieren der Benutzer ansieht (msdn.microsoft.com) sollte es doch recht einfach sein. Wenn es jedoch wirklich so einfach wäre, dann müsste ich hier nicht weiter darauf eingehen :-)
Wenn wir den folgenden Befehl ausführen:
$web = Get-SPWebApplication http://MyWebApplication
$web.MigrateUser($false)
erhalten wir die folgende Fehlermeldung:
Hier haben wir dann auch das eigentliche Problem. Nach einigen Recherchen wurde ich dann auch fündig und scheinbar ist das Zurücksetzen von Claims Based auf Classic Mode derzeit noch nicht unterstützt. Aber bei meinen Recherchen sind mir dann ein paar Ideen gekommen, die mich zu dem folgenden Entschluss kommen ließen (Ich habe das Ganze zunächst natürlich in einer Stage-Umgebung getestet):
- Backup der WebApplication (Worst Case)
- Backup der Inhaltsdatenbank/en
- WebApplication löschen (nur die IIS-Site => auf der bestehenden Webanwendung konnte ich das unten folgende PowerShell Script nicht erfolgreich ausführen)
- WebApplication neu anlegen
- Eventuell vorhandene AAM's neu setzen
- Mounten der Inhaltsdatenbank/en
- Zurücksetzen der Site-Collection-Administratoren (haben noch den Claim)
- Folgendes PowerShell-Script ausführen (Farm-Administrator Account)
function GetClaimBasedUserName($user)
{
$username = ''
try
{
if ($user.IsDomainGroup)
{
if ($user.LoginName.StartsWith('c:0+.w|'))
{
$username = $user.LoginName.Substring(7)
}
}
else
{
if ($user.LoginName.StartsWith('i:0#.w|'))
{
$username = $user.LoginName.Substring(7)
}
}
}
catch [Net.WebException]
{
$WebExceptionMessage = $_.Exception.Message
Write-Host $WebExceptionMessage
}
return $username
}
$site = Get-SPSite 'http://portal.test.com'
$web = $site.RootWeb
foreach ($user in $web.AllUsers)
{
$username = GetClaimBasedUserName($user)
if (!$username.Equals(""))
{
write-host "Migrating..."
try
{
$farm = Get-SPFarm
$farm.MigrateUserAccount($user.LoginName, $username, $false)
write-host 'Done'
}
catch [Net.WebException]
{
$WebExceptionMessage = $_.Exception.Message
Write-Host $WebExceptionMessage
}
}
}
Ich wünsche dann mal viel Spaß beim Umstellen der Claims Based Authentication.
Viele Grüße
Patrick
Kommentare
Kommentar veröffentlichen