SPMigrateUsers-Tool zum Ändern von Kontoidentitäten in SharePoint 2010

Veröffentlichung des Originalartikels: 03.06.2012

In SharePoint kommen Situationen vor, in denen die Kontoidentität geändert werden soll oder muss. Das beste Beispiel hierfür sind SAML-Forderungen. In beinahe all meinen Beispielen verwende ich die E-Mail-Adresse als Identitätsforderung für Benutzer. Grund dafür ist, dass a) die meisten Benutzer über eine E-Mail-Adresse verfügen, und b) eine E-Mail-Adresse etwas ist, was die meisten Benutzer verstehen. Was hin und wieder jedoch gegen die Verwendung der E-Mail-Adresse spricht, ist, dass sie von Benutzern geändert werden kann. Wenn Sie Ihre E-Mail-Adresse ändern, gehen natürlich alle Ihre Berechtigungen verloren. Offen gesagt ist das kein häufiges Szenario, denn sonst würde ich E-Mail-Adressen von vorneherein nicht verwenden. Ich muss jedoch zugeben, dass es doch ab und zu vorkommt. Was machen Sie also, wenn SharePoint vollständig über E-Mail-Adressen gesichert ist?

Wie Sie diese Situation in den Griff bekommen, habe ich in einem früheren Blogbeitrag über die IMigrateUserCallback-Schnittstelle beschrieben:  https://blogs.msdn.com/b/sharepoint_de/archive/2011/03/08/migrating-user-accounts-from-windows-claims-to-saml-claims.aspx. In diesem Blogbeitrag beschreibe ich, wie Identitäten mithilfe dieser Schnittstelle migriert werden und stelle ein Beispiel bereit, wie eine Windows-Forderungsidentität in eine SAML-Forderungsidentität konvertiert wird. Ich habe also beschlossen, eine kleine Windows-Anwendung zu schreiben, in die Sie die Anmeldeinformationen, die geändert werden sollen, eingeben können und die die Änderung dann für Sie vornimmt. Der einzige Zweck dieses Tools besteht darin, einmalig diese Änderungen durchzuführen. Selbstverständlich können Sie auch etwas Kreativeres mit dem Quellcode (den ich in diesem Blog bereitstelle) anfangen, wie etwa eine Liste von Benutzern aus einer Datei oder Datenbank einzulesen und selbst Vergleiche anzustellen.

Ein weiterer Vorteil dieses Tools besteht darin, dass es sogar für verschiedene Szenarien verwendet werden kann. Sie können es also nicht nur für die Konvertierung einer E-Mail-Adresse in eine andere verwenden, sondern auch, um einen Gruppennamen in einen anderen zu konvertieren. Dies ist ein weiterer Fall, in dem manche Praktiker mir empfehlen, besser SIDs für die Gruppennamen (Rollenforderungen in SAML) zu verwenden, da die SID beim Umbenennen der Gruppe unverändert bleibt. Obwohl das stimmt, a) kommt auch das wieder nur selten vor, b) wie viele von Euch wollen schon SID-Gruppennamen eingeben und SharePoint-Gruppen hinzufügen (wenn Ihre Antwort hier "Ja" lautet, sollten Sie mal daran denken, professionelle Hilfe in Anspruch zu nehmen), und c) haben SIDs außerhalb des lokalen Active Directory keinerlei Bedeutung - sobald Sie zu einem cloudbasierten Dienst wie Azure, Google, Yahoo und Facebook usw. wechseln, ist die SID so nutzlos wie ein... [einfach nach Belieben ergänzen].

Ein weiterer Vorteil dieses Tools liegt darin, dass Sie nicht darauf beschränkt sind, nur Änderungen innerhalb eines einzelnen Anbieters vorzunehmen. Sie möchten eine Windows-Gruppe zu einer SAML-Rollenforderung ändern? Kein Problem. Sie möchten eine SAML-Identitätsforderung in einen Benutzer mit FBA-Mitgliedschaft ändern? Kein Problem. Sie möchten eine FBA-Rolle in eine AD-Gruppe ändern? Auch das kein Problem. Sie verstehen schon, was ich meine - ich habe so gut wie alle Kombinationen aus "Benutzern" und "Gruppen" verschiedenster Anbieter getestet und konnte alle bisher erfolgreich hin- und herkonvertieren.

Die Verwendung des Tools ist ziemlich einfach; Sie sehen hier eine Abbildung:

Beim Starten der Anwendung wird zunächst eine Liste aller Webanwendungen geladen. Für jede Webanwendung werden die beiden Kombinationsfelder unten durch eine Liste aller für diese Webanwendung verwendeten Anbieter aufgefüllt. Bei mehreren SAML-Anbietern oder FBA-Anbietern werden diese einzeln in der Dropdownliste aufgeführt. Wählen Sie den Anbieter aus, von dem Sie migrieren, sowie den Anbieter, zu dem Sie migrieren möchten. Im Abschnitt "Claim Value" geben Sie die Werte vor und nach der Migration ein. Geben Sie die Werte einfach in die Bearbeitungsfelder "Plain Text Value" ein, und klicken Sie entweder auf die Schaltfläche für die Identitätsforderung (die Schaltfläche links) oder für die Gruppenforderung (die Schaltfläche rechts). Die Beschreibung enthält eine vollständige Erklärung hierzu, und der Schaltflächentext ändert sich, abhängig vom verwendeten Identitätsanbieter.

Angenommen, Sie verwenden nur die SAML-Authentifizierung und möchten die E-Mail-Adresse “steve@contoso.com” zu “stevep@contoso.com” ändern. Sie wählen in diesem Fall Ihre Webanwendung aus, während der SAML-Authentifizierungsanbieter standardmäßig im Dropdownfeld ausgewählt wird. Im Abschnitt "Before Value" geben Sie “steve@contoso.com” in das Bearbeitungsfeld "Plain Text Value" ein, und klicken auf die Schaltfläche "ID Claim". Dadurch wird der korrekt verschlüsselte Forderungswert in das Bearbeitungsfeld "Encoded Value" eingefügt. Als Nächstes geben Sie “stevep@contoso.com” in das Bearbeitungsfeld "Plain Text Value" unter "After Values" ein. Wenn Sie noch einmal auf die Schaltfläche "ID Claim" klicken, wird der richtige Wert in das Bearbeitungsfeld "Encoded Value" eingefügt (HINWEIS: In der Abbildung oben im Abschnitt "After Values" wird anstelle von "ID Claim" die Bezeichnung “User” angezeigt, da es sich bei diesem Beispiel um eine Migration von SAML-Forderungen zu Windows-Forderungen handelt). Wenn alle Werte vorhanden sind, klicken Sie einfach auf die Schaltfläche Migrate, um den Vorgang zu beenden. Es wird ein Meldungsfeld angezeigt, in dem Sie benachrichtigt werden, wenn die Migration abgeschlossen ist.

Beim Testen mit verschiedenen Webanwendungen und mehreren Authentifizierungstypen bin ich auf ein paar Probleme gestoßen, die ich hier ansprechen möchte, falls Sie bei Ihnen ebenfalls auftreten. In einem Fall trat eine Fehlermeldung vom Typ Zugriff verweigert beim Versuch auf, Benutzer aus einer bestimmten Webanwendung zu migrieren. Es ist mir nicht gelungen, die Ursache hierfür herauszufinden, deshalb kann ich nur sagen, dass etwas in dieser Web App wackelig ist. Ich weiß jedoch nicht genau was, denn es funktionierte bei allen anderen vier oder fünf Web Apps, die ich in meiner Farm getestet habe.

Zweite Auffälligkeit war, dass die Migration einmal als erfolgreich abgeschlossen gemeldet wurde, ich mich jedoch nicht als migrierter Benutzer anmelden konnte. Bei genauerer Suche stellte ich fest, dass das Konto, von dem ich migrierte, durch die IMigrateUserCallback-Funktion nicht gepusht wurde (es handelt sich somit um ein SharePoint-Problem und nicht um ein Codierungsproblem dieser Anwendung). In einem solchen Fall empfehle ich, den Quellcode und Visual Studio zu verwenden und den Debugger zu durchlaufen, um sicherzustellen, dass das Konto, von dem Sie migrieren, aufgerufen wird. Ein einsamer Benutzer mit FBA-Mitgliedschaft ist mir auf diese Weise leider abhanden gekommen.

Und schließlich noch ein letzter Hinweis - keine Panik, wenn Sie ein Konto von einem Wert zu einem anderen migrieren, sich dann als neuen Benutzer anmelden und der alte Kontoname usw. im Begrüßungssteuerelement in der Ecke oben rechts auf der Seite angezeigt wird. Mit der Migrationsfunktion wird nur der Kontoname geändert. Wenn sich die anderen Benutzerinformationen überhaupt ändern, sollten die korrekten Informationen (sofern Sie die Benutzerprofile aktualisieren) bei der nächsten Synchronisierung mit dem Profilsystem an alle Websitesammlungen weitergegeben werden.

Hier also ist das Tool, viel Spaß damit. Wie oben erwähnt, ist der vollständige Quellcode enthalten, Sie können also nach Belieben experimentieren und Anpassungen für Ihr Szenario vornehmen.

Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter The SPMigrateUsers Tool for Changing Account Identities in SharePoint 2010