Direkt zum Hauptbereich

Claims Based Authentication to Classic Mode Authentication

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):

  1. Backup der WebApplication (Worst Case)
  2. Backup der Inhaltsdatenbank/en
  3. WebApplication löschen (nur die IIS-Site => auf der bestehenden Webanwendung konnte ich das unten folgende PowerShell Script nicht erfolgreich ausführen)
  4. WebApplication neu anlegen
  5. Eventuell vorhandene AAM's neu setzen
  6. Mounten der Inhaltsdatenbank/en
  7. Zurücksetzen der Site-Collection-Administratoren (haben noch den Claim)
  8. 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

Beliebte Posts aus diesem Blog

Microsoft Teams und Kanäle

Kanäle (oder auch Channels) in Microsoft Teams sind dafür da, um innerhalb eines Teams die Zusammenarbeit und Kommunikation zu ermöglichen. Jedes erstellte Team startet mit dem Kanal Allgemein. Ein Kanal beinhaltet derzeit 3 Registerkarten bei Erstellung:
UnterhaltungenDateienWikiweitere Registerkarten können hinzugefügt werden. Zudem kann man jedem Kanal Konnektoren hinzufügen. Jeder Kanal erhält ebenfalls eine eigene Email-Adressse, die man entsprechend für den Zugriff konfigurieren kann. Die Namensgebung der Adresse ist derzeit noch etwas kryptisch, wird aber hoffentlich in der Zukunft lesbarer und nachvollziehbarer werden.
Wenn wir uns im Team über die unterschiedlichsten Themen oder auch Projekte unterhalten, macht es wenig Sinn dies ausschließlich im Kanal Allgemein zutun, denn so verlieren wir sehr schnell die Übersicht und eine effektive Kommunikation und Zusammenarbeit ist auch trotz der Nutzung von MS Teams nicht gegeben. Hier gibt es die Möglichkeit weitere Kanäle zu erstelle…

Benutzer einer SharePoint-Gruppe auslesen (Data One Power Activity for Nintex Workflow)

Ich habe dieser Tage ein kleines Problem mit der Nintex-Aktivität << Data Request >> gehabt. Derzeit ist es leider nur möglich dieser Aktivität einen Benutzer zuzuweisen. Was nun aber tun, wenn mehrere Benutzer diese Dateneingabe vornehmen sollen. Man kann das Ganze umgehen, indem man eine neue SharePoint-Gruppe anlegt und die Benutzer in dieser Gruppe einpflegt.
Hier bin ich dann jedoch auf das nächste Problem gestoßen. Die SharePoint-Gruppe wird nicht aufgelöst, so dass die Aufgabe nicht in den Nintex-Webpart << Meine Workflowaufgaben >> angezeigt wird. Ich habe mir nun Gedanken über eine mögliche Lösung gemacht und bin zu folgendem Ergebnis gekommen.

Schritt 1: SharePoint Webservice
Auslesen der SharePoint-Gruppe mit dem SharePoint Webservice (http://sharepoint/_vti_bin/UserGroup.asmx) und der Methode << GetUserCollectionFromGroup >>. Als Ergebnis bekommen wir folgendes XML-Konstrukt (aus Darstellungsgründen habe ich es auf den LoginName beschränk…

Nutzung der Mehrsprachigkeit in SharePoint 2013

Heute wollte ich mich mit dem Thema <Mehrsprachigkeit und SharePoint 2013> auseinandersetzen. Wie in SharePoint 2010 bietet Microsoft auch diverse Sprachpakete für SharePoint 2013 an. Zum heutigen Zeitpunkt stehen Sie leider noch nicht zum freien Download bereit. Wenn Ihr jedoch eine MSDN-Subscription besitzt, so könnt Ihr die verfügbaren Sprachpakete hier herunterladen. Die folgenden Sprachpakete stehen derzeit zum Download bereit.




















Nachdem ich mir die Pakete installiert und den Config-Wizard laufen gelassen habe (Es hat keine 10 Minuten gedauert, das sieht mir nach Optimierung aus) stehen die Pakete zur Verfügung und ich kann Sie auf den einzelnen Site-Collections aktivieren. Dazu gehe ich wie gewohnt in die <Site-Settings>








und wähle dort die <Language settings> aus und markiere die gewünschte Sprache.


























Das sind alles keine Änderungen gegenüber SharePoint 2010. Meine Seite öffnet sich nun wie erwartet in Deutsch. Nun möchte ich jedoch wieder in die englische Sprache …