Einblicke in SharePointVerwalten von Anmeldeinformationen für Sicherheitskonten

Pav Cherny

Inhalt

Kennwortänderungen in einer SharePoint-Umgebung
Problembehandlung bei Farmanmeldeinformationen
Schlussbemerkung

Das häufige Ändern von Farmanmeldeinformationen und Kennwörtern für Sicherheitskonten sind wichtige Maßnahmen zum Sichern einer Microsoft Office SharePoint Server (MOSS)-Farm. Für Administratoren sind diese sich wiederholenden Aufgaben jedoch mühsam. Die Verwendung der Tools ist schwierig, die zugrunde liegenden Prozesse sind komplex, gute Dokumentation lässt sich nur schwer finden, und es besteht ein gewisses Risiko, die Serverfarm zu beschädigen, selbst wenn die richtigen Verfahren angewendet werden.

Hinzu kommt problematischer technischer Rat durch den Microsoft-Produktsupport. Einerseits gibt es nützliche Knowledge Base (KB)-Artikel, z. B. Ändern von Dienstkonten und Kennwörtern von Dienstkonten in SharePoint Server 2007 und in Windows SharePoint Services 3.0. Andererseits gibt es Katastrophen wie beispielsweise Fehlermeldung beim Versuch, die SharePoint-Produkte und den Technologieassistenten zu verwenden: „Ausnahme: System.ArgumentException: Fehler bei der Ver- oder Entschlüsselung“.

Im obigen Artikel heißt es, dass Sie eine neue Konfigurationsdatenbank erstellen müssen, wenn die Anmeldeinformationen für das Konto einer Webanwendung nicht mehr entschlüsselt werden können. Dies kann geschehen, wenn Sie einen kritischen Befehlsschalter zur falschen Zeit verwenden oder wenn der Prozess beim Aktualisieren von Farmanmeldeinformationen aus irgendeinem Grund erfolglos abgeschlossen wird. Dieser KB-Artikel hat es geschafft, Administratoren Furcht einzuflößen, da es darin heißt, dass das Ändern von Farmanmeldeinformationen eine Serverfarm irreparabel beschädigen kann. Wer kann von Kunden erwarten, dass sie die Sicherheit in ihren SharePoint-Umgebungen gewährleisten, indem sie die Kennwörter für Farm- und Sicherheitskonten häufig ändern, wenn sie einem solchen Risiko ausgesetzt sind?

Kunden löschen Active Directory nicht, um Benutzerkonten zurückzusetzen, und sie sollten auch nicht gezwungen werden, ihre SharePoint-Konfigurationsdatenbanken zu löschen, nur weil das Kennwort für eine Webanwendung verloren gegangen ist. Es ist nicht erforderlich, eine neue Konfigurationsdatenbank zu erstellen. In den meisten Fällen reicht es aus, das Standardtool „Stsadm.exe“ zu verwenden, um beschädigte Anmeldeinformationen zu überschreiben. In allen anderen Fällen können Sie die Kennwörter zurücksetzen und Ihre Konfigurationsdatenbank mithilfe der im Begleitmaterial enthaltenen Tools bewahren, die im Codedownload vom Februar 2008 zur Verfügung stehen. Für das Zurücksetzen von Kennwörtern in Windows SharePoint Services (WSS) 3.0- und MOSS 2007-Umgebungen sind weder Zugriff auf alte Anmeldeinformationsschlüssel noch eine neue Konfigurationsdatenbank erforderlich. Aber es sind bessere Supporttools von Microsoft und eine bessere Dokumentation der zugrunde liegenden Prozesse erforderlich, die Kennwortänderungen vereinfachen.

Dies ist der erste Artikel einer zweiteiligen Reihe, in der die Standardverfahren und -tools zum Verwalten von SharePoint-Sicherheitskonten untersucht, ihre Einschränkungen erörtert und die Risiken hervorgehoben werden. Zudem wird ein alternativer Ansatz vorgeschlagen, um bessere Sicherheit zu erzielen, den Verwaltungsaufwand zu verringern und damit die Gesamtkosten in SharePoint-Umgebungen zu senken. Dieser erste Teil behandelt die architektonischen Details und den komplizierten Prozess beim Durchführen von Kennwortänderungen.

Sie müssen verstehen, wie SharePoint Sicherheitskonten und Kennwörter behandelt, und zwar unabhängig davon, ob Sie die Sicherheit manuell mithilfe von Skripts verwalten oder eine vollautomatisierte Lösung verwenden, beispielsweise die Lösung, die ich im Artikel des nächsten Monats vorstellen werde. Damit meine Erläuterungen realistisch und praxisorientiert sind, verwende ich wieder eine Testumgebung. In diesem ersten Teil reicht eine einfache Einzelserverinstallation aus, wie in den Arbeitsblättern im Begleitmaterial beschrieben. Wie immer sind meine Arbeitsblätter und Begleittools nur für Testumgebungen gedacht und dürfen nicht in Produktionsumgebungen verwendet werden. Die Nutzung meiner Tools erfolgt auf eigenes Risiko.

Kennwortänderungen in einer SharePoint-Umgebung

Das Ändern des Kennworts eines SharePoint-Sicherheitskontos oder des Konfigurationskontos der Farm ist ein erstaunlich komplexes Unterfangen. Unter anderem müssen Sie Änderungen in Active Directory und in der lokalen SAM-Datenbank (Security Account Manager) des SharePoint-Servers, in der SCM-Datenbank (Service Control Manager, Dienststeuerungs-Manager), in der IIS-Metabasis, in SQL Server und natürlich in der SharePoint-Inhalts- und Konfigurationsdatenbank anwenden.

Zudem müssen Sie die Änderungen auf allen anderen Servern in der Farm replizieren, damit die Änderungen konsistent angewendet werden. Möglicherweise müssen Sie alle Kennwörter aller SharePoint-Dienste und Anwendungspools für alle Server in der Farm neu verschlüsseln, wenn sich Ihre Änderungen auf den Anmeldeinformationsschlüssel der Farm auswirken, bei dem es sich um den Verschlüsselungsschlüssel handelt, den SharePoint zum Schützen der Kennwörter der Sicherheitskonten in der Konfigurationsdatenbank verwendet. Wenn das Kennwort für das Konfigurationskonto der Farm geändert wird, ändern Sie implizit den Anmeldeinformationsschlüssel der Farm. Abbildung 1 zeigt den Prozess in einer Serverfarm mit zwei Front-End-Servern. Es ist ehrlich gesagt beeindruckend, dass dieser Prozess so gut funktioniert.

Abbildung 1 Ändern des Kennworts eines SharePoint-Sicherheitskontos

Alle Änderungen von Kennwörtern von Sicherheitskonten beginnen in Active Directory. Von diesem Augenblick an ist die Farm in einem inkonsistenten Zustand, bis das betroffene Kennwort in SharePoint aktualisiert wird. Das Kennwort ist jetzt in IIS und an anderer Stelle veraltet, aber SharePoint ist immer noch betriebsbereit.

Dies sind gute Nachrichten für Organisationen mit Hochverfügbarkeitsanforderungen. Bei Kennwortänderungen ist kein Systemneustart erforderlich. Windows-Dienste und IIS können das Sicherheitstoken weiterhin verwenden, das sie erhalten haben, als sie sich beim letzten Start des Servers beim betroffenen Sicherheitskonto mit dem alten Kennwort angemeldet haben. Aber Sie dürfen IIS oder den gesamten Server während der Übergangsphase der Kennwortinkonsistenz nicht neu starten.

IIS und andere Dienste wären nicht in der Lage, sich während des Neustarts mit dem alten Kennwort anzumelden, und der betroffene Anwendungspool oder Dienst könnte nicht mehr verfügbar gemacht werden. In dieser Situation schreibt IIS eine Warnung in das Ereignisprotokoll des Servers (siehe Abbildung 2). Warten Sie also nach der Kennwortänderung in Active Directory nicht zu lange mit der Kennwortaktualisierung in SharePoint.

Abbildung 2 IIS warnt vor veralteten Anmeldeinformationen für den Anwendungspool

Um das Kennwort eines Anwendungspoolkontos zu aktualisieren, sollten Sie die SharePoint 3.0-Zentraladministration (_admin/FarmCredentialManagement.aspx) oder den folgenden Stsadm.exe-Befehl verwenden:

stsadm -o updateaccountpassword -userlogin <DOMAIN\USER> 
  -password <PASSWORD> -noadmin

Als Reaktion verschlüsselt SharePoint das neue Kennwort mithilfe des Anmeldeinformationsschlüssels der Farm und überschreibt das alte verschlüsselte Kennwort in der Konfigurationsdatenbank. Als Nächstes aktualisiert SharePoint die Kontoinformationen in der IIS-Metabasis und an allen anderen notwendigen Stellen. Anschließend generiert SharePoint einen Zeitgeberauftrag des Typs „SPContentAppPoolCredentialDeploymentJobDefinition“, um die neuen Anmeldeinformationen auf den übrigen Servern in der Farm bereitzustellen, und platziert ihn in der Konfigurationsdatenbank.

Wie in Abbildung 1 dargestellt, verlässt sich SharePoint auf Zeitgeberaufträge, um administrative Einstellungen global auf allen Servern in der Farm anzuwenden. Die SharePoint-Zeitgeberdienste auf den übrigen Servern in der Farm rufen den Auftrag ab und aktualisieren entsprechend die lokalen Sicherheitseinstellungen auf ihren Servern mithilfe des WSS Administration (SPAdmin)-Diensts, um die Farm wieder in einen konsistenten Zustand zu bringen.

Dies ist der Prozess für Anwendungspoolkonten, aber es gibt viele andere Arten von SharePoint-Diensten, die Sicherheitskonten verwenden, beispielsweise den SharePoint-Zeitgeberdienst selbst, den WSS Help Search-Dienst und möglicherweise die Anbieter für gemeinsame Dienste (Shared Services Providers, SSPs), den Office SharePoint Server Search-Dienst und den Dienst für einmaliges Anmelden (single sign-on, SSO). Es gibt in Abhängigkeit von den Lösungen, die in Ihrer Farm installiert sind, möglicherweise sogar noch mehr Dienste, und für jeden Diensttyp gelten verschiedene Anforderungen bei der Kennwortaktualisierung. Der Artikel unter support.microsoft.com/kb/934838 enthält eine Liste der Befehle, die Sie für die Dienstkonten in WSS 3.0 und MOSS 2007 verwenden müssen. Prüfen Sie die Produktdokumentation zusätzlicher Lösungen, die Sie für weitere Tools, Befehle und Aktualisierungsverfahren verwenden.

Diese äußerst vielfältige und unkoordinierte Landschaft aus Tools und Befehlen ist einer der Nachteile der derzeitigen SharePoint-Sicherheitsarchitektur. Sie lässt sich nicht gut skalieren und kann die Gesamtkosten in Abhängigkeit von der Anzahl benutzerdefinierter Lösungen in Ihrer Serverfarm, die Sicherheitsanmeldeinformationen verwenden, in die Höhe treiben. Im zweiten Teil dieser Reihe erfahren Sie, wie sich dies unter Kontrolle bringen lässt, damit Sie eine einzelne Lösung verwenden können, um alle notwendigen Aktualisierungen unabhängig von den zugrunde liegenden Diensttypen durchzuführen.

Das wichtigste Aktualisierungsszenario betrifft die Farmanmeldeinformationen. Das Kennwort des Farmkontos ist etwas Besonderes, weil es sich auf den Anmeldeinformationsschlüssel der Farm auswirkt, der, wie bereits erwähnt, zum Verschlüsseln aller Kennwörter in der Farm verwendet wird. Daher müssen Sie nach dem Ändern des Kennworts des Farmkontos in Active Directory mithilfe des folgenden Befehls SharePoint aktualisieren:

stsadm -o updatefarmcredentials -userlogin <DOMAIN\USER>
  -password <PASSWORD>

SharePoint muss dann alle vorhandenen (verschlüsselten) Kennwörter in der Konfigurationsdatenbank neu verschlüsseln, das SharePoint-Zeitgeberdienstkonto (das das Farmkonto als seine Identität verwendet) muss aktualisiert werden, und diese Änderungen müssen wieder auf alle Server in der Farm mithilfe eines Zeitgeberauftrags des Typs „SPAdminAppPoolCredentialDeploymentJobDefinition“ übertragen werden.

Während dieser Phase kann viel schief gehen. Der Zeitgeberauftrag könnte in der Warteschlange stecken bleiben, wie in Abbildung 3 dargestellt, oder der Aktualisierungsprozess könnte aufgrund eines plötzlichen Stromausfalls unerwartet fehlschlagen, sodass alte verschlüsselte Kennwörter zurückbleiben, die SharePoint nun nicht mehr entschlüsseln kann, weil sich der Anmeldeinformationsschlüssel geändert hat.

Abbildung 3 Ein Auftrag zur Anmeldeinformationsbereitstellung ist in der Warteschlange steckengeblieben, weil der SharePoint-Zeitgeberdienst nicht auf allen Servern in der Farm ausgeführt wird

In einem anderen Szenario könnten Sie die Kennwörter der Anwendungspoolkonten aktualisieren, bevor die neuen Farmanmeldeinformationen alle Server in der Farm erreicht haben, wodurch Server mit dem veralteten Anmeldeinformationsschlüssel fehlschlagen, weil sie das aktualisierte Kennwort in der Konfigurationsdatenbank noch nicht entschlüsseln können. Dies ist in Abbildung 4 dargestellt. Dies ist ein interessantes Szenario und der Grund für den -noadmin-Schalter im updateaccountpassword-Befehl. Wenn das Farmkonto außerdem als Anwendungspoolkonto verwendet wird (was nicht empfehlenswert ist), sollten Sie die Farmanmeldeinformationen zuerst aktualisieren, warten, bis alle Server in der Farm den Zeitgeberauftrag verarbeitet haben, und dann die Anwendungspools aktualisieren.

Abbildung 4 Warten Sie mit Anwendungspoolaktualisierungen, bis der Auftrag des Verwaltungsanwendungspools zur Anmeldeinformationsbereitstellung verarbeitet wurde

Entsprechend prüft der updateaccountpassword-Befehl, ob das angegebene Sicherheitskonto das Farmkonto ist, und informiert Sie hinsichtlich der Abhängigkeiten, wenn dies der Fall ist, ohne dass die Aktualisierung durchgeführt wird. Mithilfe des -noadmin-Schalters deaktivieren Sie diese Überprüfung und wenden das geänderte Kennwort auf das Konto in der Anwendungspoolkonfiguration an, aber es ist schwierig, diese Verfahren in einem Skript mit geeigneter Verzögerungszeit zu automatisieren.

Problembehandlung bei Farmanmeldeinformationen

Betrachten wir nun den updatefarmcredentials-Befehl etwas näher. Er enthält einen gefährlichen Schalter, der große Schwierigkeiten verursachen kann, insbesondere wenn er wie im Artikel Fehlermeldung beim Versuch, die SharePoint-Produkte und den Technologieassistenten zu verwenden: „Ausnahme: System.ArgumentException: Fehler bei der Ver- oder Entschlüsselung“ beschrieben verwendet wird. Ich meine damit den Schalter „-local“. Die SharePoint-Entwickler haben diesen Schalter eingeführt, um lokale Aktualisierungen von Farmanmeldeinformationen durchzuführen. Dahinter steht der Gedanke, dass Sie einen Zeitgeberauftrag in der Zentraladministration (_admin/ServiceJobDefinitions.aspx) aus der Warteschlange löschen können, wenn der Auftrag beschädigt ist oder aus einem anderem Grund nicht verarbeitet wird, und dass Sie dann den notwendigen Aktualisierungsschritt direkt mithilfe des folgenden Befehls durchführen können:

stsadm -o updatefarmcredentials -userlogin <DOMAIN\USER> 
  -password <PASSWORD> -local

Der -local-Schalter weist den updatefarmcredentials-Befehl an, die Kennwortänderung nur auf dem lokalen Computer anzuwenden. Sie sollten sich jedoch vor Augen führen, dass sich diese Aktualisierung auf den Anmeldeinformationsschlüssel und den SharePoint-Zeitgeberdienst auswirkt, aber nicht auf die Anwendungspools, den Suchdienst, SSPs und so weiter. Es wird angenommen, dass Sie bereits den updatefarmcredentials-Befehl ohne den -local-Schalter auf einem anderen Server in der Farm ausgeführt und folglich alle Kennwörter in der Konfigurationsdatenbank wieder verschlüsselt haben. Es ist nicht notwendig, diesen Neuverschlüsselungsschritt erneut durchzuführen. Aber was geschieht, wenn Sie den -local-Schalter verwenden, ohne diesen Schritt durchzuführen?

Die Verwendung des -local-Schalters ohne vorheriges Ausführen des updatefarmcredentials-Befehls ohne diesen Schalter verursacht Probleme, da der -local-Schalter den Anmeldeinformationsschlüssel ändert. Die Kennwörter für den Anwendungspool sind mit dem alten Schlüssel in der Konfigurationsdatenbank verschlüsselt, aber dieser Schlüssel wurde nun überschrieben.

Sehen Sie sich Abbildung 5 an. Sie können den updatefarmcredentials-Befehl nicht mehr ohne den -local-Schalter ausführen, da dazu die erneute Verschlüsselung von Kennwörtern erforderlich ist, die nicht mehr entschlüsselt werden können. Wenn der Befehl fehlschlägt, finden Sie Einträge im Anwendungsereignisprotokoll, in denen es heißt: „Fehler beim erneuten Verschlüsseln der Anmeldeinformations-ID '022e607e-b49e-40e4-bd3f-f56a3c69f94d' mit der Besitzer-ID '431b6897-16eb-4b9a-be65-60f1f603008d' während der Bereitstellung von Anmeldeinformationen für den Administrationsanwendungspool. Erstellen Sie die Anmeldeinformationen erneut manuell. Der Vorgang ist aufgrund des aktuellen Zustands des Objekts ungültig.“

Abbildung 5 Kennwörter für den Anwendungspool können nicht neu verschlüsselt werden, da die Kennwörter nicht mehr entschlüsselt werden können

Wenn Sie gerade das Farmkonto in einer Einzelserverbereitstellung vom Netzwerkdienstkonto in ein Domänenkonto geändert haben, sind Sie wirklich in Schwierigkeiten, weil Sie in diesem Fall nicht zum alten Anmeldeinformationsschlüssel zurückwechseln können. Der Netzwerkdienst verwendet kein Kennwort, und der Anmeldeinformationsschlüssel ist deshalb zufällig.

Bei der Suche nach Hilfe könnten Sie auf den Artikel Fehlermeldung beim Versuch, die SharePoint-Produkte und den Technologieassistenten zu verwenden: „Ausnahme: System.ArgumentException: Fehler bei der Ver- oder Entschlüsselung“ stoßen, den ich bereits erwähnt habe, und wenn Sie nicht über weitere Kenntnisse verfügen, werden Ihre Schwierigkeiten noch größer, da Sie jetzt erfahren, dass Sie eine neue Konfigurationsdatenbank erstellen müssen, um diese Kennwörter, die nicht mehr entschlüsselt werden können, zu beseitigen. Es ist eine unglaubliche Verkettung ungünstiger Umstände. Sie sollten eigentlich überhaupt nicht in der Lage sein, den updatefarmcredentials-Befehl mit dem -local-Schalter auszuführen, oder der Befehl sollte eine Sicherungskopie des alten Anmeldeinformationsschlüssel erstellen, damit Sie die Kennwörter später erneut verschlüsseln können. Oder er sollte erkennen, dass die Kennwörter noch nicht neu verschlüsselt sind, und sie an dieser Stelle erneut verschlüsseln.

Stattdessen beschädigt der -local-Schalter Ihre SharePoint-Konfigurationsdatenbank einfach ohne irgendeine Warnung, wie in Abbildung 5 dargestellt. Ein Supporttool von Microsoft zum Zurücksetzen der Kennwörter, die nicht mehr entschlüsselt werden können, wäre nützlich. Eine gute Produktdokumentation, die Sie hinsichtlich der Bedenklichkeit bestimmter Befehlszeilenvorgänge warnt und bei diesem Problem hilft, wäre ebenfalls angebracht.

Die gute Nachricht ist, dass der updateaccountpassword-Befehl neue Kennwörter von Anwendungspoolkonten verschlüsseln kann, ohne die alten Kennwörter entschlüsseln zu müssen. Verwenden Sie daher diesen Befehl, um alle Anwendungspools zu aktualisieren, die Domänenkonten verwenden. Damit sollte sich das Problem bei den meisten oder vielleicht sogar bei allen beschädigten Kennwörtern beheben lassen. Leider können Sie diesen Befehl nicht verwenden, um Anwendungspools zu aktualisieren, die das Netzwerkdienstkonto verwenden. Dieses Konto erfordert kein Kennwort, sodass der updateaccountpassword-Befehl in diesem Fall nicht gilt.

Interessanterweise könnte das Netzwerkdienstkonto mit Kennwortdaten in der Konfigurationsdatenbank verbunden sein. Neue Anwendungspools, die den Netzwerkdienst verwenden, haben keine Kennwörter, aber wenn Sie jemals den Anwendungspool ändern, um ein Domänenkonto zu verwenden, und dann wieder zurückwechseln, erbt der Netzwerkdienst den Kennwortverweis des Domänenkontos. SharePoint setzt das Kennwort nicht auf null (schlechte Codiermethode), und diese unsinnigen Daten verursachen nun Schwierigkeiten.

Es ist schon paradox: Von den Kunden wird erwartet, dass sie ihre Konfigurationsdatenbanken wegwerfen, weil unsinnige und völlig nutzlose Daten nicht mehr entschlüsselt werden können! Wenn Sie Glück haben, können Sie die Anwendungspoolkonfiguration in der Zentraladministration (_admin/FarmCredentialManagement.aspx) ändern und ein Domänenkonto angeben. Wenn Sie Pech haben, wird Ihnen der in Abbildung 6 dargestellte Ver-/Entschlüsselungsfehler angezeigt. Sie können das Konto in der Zentraladministration nicht ändern, Sie können den updateaccountpassword-Befehl nicht verwenden, Sie können den Konfigurations-Assistenten für SharePoint-Produkte und -Technologien nicht ausführen, und Sie können die Farmanmeldeinformationen nicht mithilfe des updatefarmcredentials-Befehls aktualisieren. Was nun?

Abbildung 6 Schwierigkeiten, die durch unbrauchbare Netzwerkdienstkennwörter verursacht werden, die in der Konfigurationsdatenbank zurückgelassen wurden

Um dieses Problem zu lösen, benötigen Sie ein Tool, das die unbrauchbaren Informationen direkt in der Konfigurationsdatenbank entfernt, beispielsweise das in Abbildung 7 dargestellte Reset AppPool Password-Tool, das mit seinem Quellcode im Begleitmaterial enthalten ist. Dieses Tool ist sehr einfach: Es zieht die Daten der Anwendungspools, die Konten mit zugeordneten verschlüsselten Kennwörtern verwenden, direkt aus der Konfigurationsdatenbank und verwendet dann das SharePoint-Objektmodell, um festzustellen, ob das Kennwort für den Anwendungspool entschlüsselt werden kann.

Abbildung 7 Zurücksetzen beschädigter Kennwörter auf null

Wenn der Zugriff auf das Kennwort über das Objektmodell mit einer Argumentausnahme fehlschlägt, ist das Kennwort beschädigt. Hier bietet das Tool Ihnen Gelegenheit, das Array verschlüsselter Bytewerte des Kennworts durch einen Nullverweis zu ersetzen, und speichert die Änderungen in der Konfigurationsdatenbank. Leere Zeichenfolgen müssen nicht entschlüsselt werden und verursachen daher keine Argumentausnahme. Das Problem ist gelöst.

Um den Reparaturprozess abzuschließen, empfehle ich, die Farmanmeldeinformationen und anschließend alle Anwendungspoolkonten mittels Stsadm.exe und mithilfe der Zentraladministrationen zu aktualisieren. Ihre Farm ist wieder in einem konsistenten Zustand, und Sie müssen Ihre Konfigurationsdatenbank nicht wegwerfen.

Schlussbemerkung

Trotz der Tatsache, dass das Ändern von Farmanmeldeinformationen und Kennwörtern für Sicherheitskonten ein mühsamer und fehleranfälliger Prozess ist, müssen Sie nicht befürchten, dass das Ändern von Farmanmeldeinformationen Ihre Serverfarm irreparabel beschädigt. Die Konfigurationsdatenbank kann repariert werden, selbst wenn Sie Ihren aktuellen Anmeldeinformationsschlüssel verlieren. Sie setzen einfach die betroffenen Kennwörter zurück, was mithilfe des Standardtools „Stsadm.exe“ oder mit einem geeigneten Datenbanktool wie „Reset AppPool Password“ möglich ist. Ändern Sie Farmanmeldeinformationen und Sicherheitskonten häufig, verwenden Sie sichere Kennwörter, und verwenden Sie den Netzwerkdienst nicht als Sicherheitskonto, da dies die Farmkonfiguration und die Problembehandlung erschwert. Verwenden Sie dedizierte Domänenkonten.

Nun, da Sie die Risiken der Datenbankbeschädigung durch Kennwortänderung kennengelernt haben, können Sie Ihre Aufmerksamkeit dem wirklichen Problem in der SharePoint-Sicherheitsarchitektur zuwenden, das darin besteht, dass die aktuelle Architektur nicht besonders gut für Kennwortänderungen geeignet ist. In Abhängigkeit von den Diensttypen, die in Ihrer Farm aktualisiert werden müssen, müssen Sie zu viele Befehle in einer mehr oder weniger spezifischen Reihenfolge anwenden. Einige Befehle haben gefährliche Schalter, andere nicht. Einige Befehle können Ihre Konfigurationsdatenbank beschädigen, andere sind harmlos. Einige Dienste müssen global über die ganze Farm hinweg aktualisiert werden, während andere lokal auf einen bestimmten Server beschränkt sind.

Auf jeden Fall ist der Verwaltungsaufwand aufgrund der Komplexitäten hoch, und aufgrund von seltenen Änderungen, schwachen Kennwörtern sowie Skripts, die Kennwörter in Klartext behandeln, ist die Sicherheit im Allgemeinen niedrig. In meinem nächsten Artikel erfahren Sie, wie diese Probleme behandelt und beseitigt werden, und zwar für alle Diensttypen (einschließlich noch nicht entwickelter) und unabhängig davon, worin ihre Anforderungen bei der Kennwortaktualisierung bestehen. Keine (manuellen) Kennwortänderungen mehr!

Pav Cherny ist IT-Experte und Autor und ist auf Microsoft-Technologien für Zusammenarbeit und einheitliche Kommunikation spezialisiert. Seine Veröffentlichungen enthalten Whitepaper, Produkthandbücher sowie Bücher mit dem Schwerpunkt IT-Vorgänge und Systemverwaltung. Pav Cherny ist Präsident der Biblioso Corporation. Dieses Unternehmen ist auf verwaltete Dokumentations- und Lokalisierungsdienste spezialisiert.