Sicherheitsfeatures von Live Share

Zusammenarbeitssitzungen in Visual Studio Live Share sind leistungsstark, da sie es einer beliebigen Anzahl von Personen ermöglichen, an einer Sitzung teilzunehmen und gemeinsam zu bearbeiten, zu debuggen und vieles mehr. Angesichts dieser Zugriffsebene sind Sie jedoch sehr an den Sicherheitsfeatures interessiert, die Live Share bietet. In diesem Artikel werden einige Empfehlungen und Optionen zum Schützen Ihrer Umgebung nach Bedarf erläutert.

Denken Sie wie bei jedem Zusammenarbeitstool daran, dass Sie Ihren Code, Ihre Inhalte und Ihre Anwendungen nur für Personen freigeben sollten, denen Sie vertrauen.

Konnektivität

Beim Initiieren einer Sitzung zwischen Peers versucht Live Share, eine Peer-zu-Peer-Verbindung herzustellen, und nur dann, wenn dies nicht möglich ist (z. B. aufgrund von Firewalls/NATs), erfolgt ein Fallback auf die Verwendung eines Cloud-Relays. Bei beiden Verbindungstypen (P2P oder Relay) werden jedoch alle zwischen Peers übertragenen Daten mithilfe des SSH-Protokolls end-to-end verschlüsselt. Bei einer Relayverbindung wird die SSH-Verschlüsselung auf TLS-verschlüsselten WebSockets überlagert. Dies bedeutet, dass Live Share aus Sicherheitsgründen nicht vom Cloud Relay-Dienst abhängig ist. Selbst wenn das Relay kompromittiert wurde, konnte es keine der Live Share Kommunikation entschlüsseln.

Die Rolle des Live Share-Diensts ist auf die Benutzerauthentifizierung und Sitzungsermittlung beschränkt. Der Dienst selbst speichert keinen Inhalt einer Sitzung oder hat jemals Zugriff darauf. Alle Benutzerinhalte in Live Share werden über die SSH-Sitzung übertragen. Dazu gehören Code, Terminals, freigegebene Server und alle anderen Zusammenarbeitsfunktionen, die von Live Share oder Erweiterungen bereitgestellt werden, die darauf aufbauen.

Weitere Informationen zum Ändern dieser Verhaltensweisen und der Konnektivitätsanforderungen Live Share finden Sie unter Konnektivitätsanforderungen für Live Share.

Wire Encryption

Das SSH-Protokoll verwendet einen Diffie-Hellman Schlüsselaustausch, um ein gemeinsames Geheimnis für die Sitzung einzurichten, und leitet sich von diesem Schlüssel für die symmetrische AES-Verschlüsselung ab. Der Verschlüsselungsschlüssel wird während der gesamten Dauer der Sitzung regelmäßig rotiert. Das gemeinsame Sitzungsgeheimnis und alle Verschlüsselungsschlüssel werden nur von beiden Seiten im Arbeitsspeicher verwaltet und sind nur für die Dauer der Sitzung gültig. Sie werden nie auf den Datenträger geschrieben oder an einen Dienst gesendet (einschließlich Live Share).

Peerauthentifizierung

Die SSH-Sitzung wird ebenfalls in zwei Richtungen authentifiziert. Der Host (SSH-Serverrolle) verwendet die Authentifizierung mit öffentlichem/privatem Schlüssel gemäß dem Standard für das SSH-Protokoll. Wenn ein Host eine Live Share Sitzung gemeinsam nutzt, generiert er ein eindeutiges öffentliches/privates RSA-Schlüsselpaar für die Sitzung. Der private Hostschlüssel wird im Hostprozess nur im Arbeitsspeicher gespeichert. Sie wird nie auf den Datenträger geschrieben oder an einen Dienst gesendet, einschließlich des Live Share Diensts. Der öffentliche Hostschlüssel wird zusammen mit den Sitzungsverbindungsinformationen (IP-Adresse und/oder Relayendpunkt), auf die Gäste über den Einladungslink zugreifen können, im Live Share-Dienst veröffentlicht. Wenn ein Gast eine Verbindung mit der SSH-Sitzung des Hosts herstellt, verwendet der Gast das SSH-Hostauthentifizierungsprotokoll, um zu überprüfen, ob der Host den privaten Schlüssel enthält, der dem veröffentlichten öffentlichen Schlüssel entspricht (ohne dass der Gast den privaten Schlüssel tatsächlich sehen kann).

Der Gast verwendet ein Live Share Token, um sich beim Host zu authentifizieren. Das Token ist ein vom Live Share-Dienst ausgestelltes signiertes JWT, das Ansprüche über die Benutzeridentität enthält (abgerufen über MSA, AAD oder GitHub Anmeldung). Das Token verfügt auch über Ansprüche, die angeben, dass der Gast auf diese bestimmte Live Share Sitzung zugreifen darf (da er den Einladungslink hatte und/oder vom Host speziell eingeladen wurde). Der Host überprüft dieses Token und überprüft die Ansprüche (und abhängig von den Optionen kann den Hostbenutzer auffordern), bevor der Gast an der Sitzung teilnehmen kann.

Einladungen und Zugriff auf Den Beitritt

Jedes Mal, wenn Sie eine neue Zusammenarbeitssitzung starten, generiert Live Share einen neuen eindeutigen Bezeichner, der im Einladungslink platziert wird. Diese Links bieten eine solide, sichere Grundlage zum Einladen der vertrauenswürdigen Benutzer, da der Bezeichner im Link "nicht erraten" ist und nur für die Dauer einer einzelnen Zusammenarbeitssitzung gültig ist.

Entfernen eines unerwarteten Gasts

Als Host werden Sie automatisch benachrichtigt, wenn ein Gast an der Zusammenarbeitssitzung teilnimmt.

In Visual Studio Code:

Visual Studio Code Joinbenachrichtigung

In Visual Studio:

Visual Studio Joinbenachrichtigung

Besser noch: Die Benachrichtigung bietet Ihnen die Möglichkeit, einen Gast zu entfernen, der beigetreten ist, wenn Sie sie aus irgendeinem Grund nicht kennen. (Wenn Sie z. B. versehentlich Ihren Link in einem unternehmensweiten Chatsystem gepostet haben und ein zufälliger Mitarbeiter beigetreten ist.) Klicken Sie einfach in der angezeigten Benachrichtigung auf die Schaltfläche "Entfernen", und sie werden aus der Zusammenarbeitssitzung eingefügt.

In VS Code können Sie auch dann einen Teilnehmer entfernen, wenn Sie eine Joinbenachrichtigung verworfen haben. Indem Sie die Live Share Ansicht im Explorer oder auf der benutzerdefinierten Registerkarte in der VS Code Aktivitätsleiste öffnen, können Sie mit der mauszeigeren Maustaste auf den Namen eines Teilnehmers zeigen oder mit der rechten Maustaste darauf klicken und das Symbol oder die Option "Teilnehmer entfernen" auswählen.

Entfernen eines Teilnehmers in VS Code

Erfordern einer Gastgenehmigung

In der Regel werden Teilnehmer, die an einer Zusammenarbeitssitzung teilnehmen, mithilfe eines Microsoft-Arbeits-, Schul- oder Schulkontos (AAD), persönlichen Microsoft-Konto oder GitHub-Kontos bei Live Share angemeldet. Während die Standardeinstellung "Benachrichtigung + Entfernen" für angemeldete Benutzer eine gute Mischung aus Geschwindigkeit und Kontrolle für diese Gäste bietet, sollten Sie etwas mehr sperren, wenn Sie etwas Sensibles tun.

Darüber hinaus kann es unter bestimmten Umständen problematisch sein, alle Gäste zur Anmeldung an einer Zusammenarbeitssitzung zu zwingen. Beispiele hierfür sind das Bitten einer neuen Person, Live Share als Gast beizutreten, Classroom-/Lernszenarien oder die Zusammenarbeit mit einer Person, die nicht über einen der unterstützten Kontotypen verfügt. Aus diesen Gründen können Live Share Benutzern, die nicht angemeldet sind, die Teilnahme an Zusammenarbeitssitzungen als schreibgeschützte Gäste gestatten. Während der Host diese Gäste genehmigen muss, bevor sie standardmäßig beitreten können, sollten Sie diese "anonymen" Gäste entweder nicht zulassen oder stattdessen immer genehmigen.

Erfordern einer Gastgenehmigung für angemeldete Benutzer

Wenn Sie verhindern möchten, dass angemeldete Gäste ihren Zusammenarbeitssitzungen beitreten, bis Sie sie "genehmigt" haben, ändern Sie die folgende Einstellung:

  • Fügen Sie in VS Code Folgendes hinzu, um settings.jsauf (Datei-> Einstellungen > Einstellungen):

    "liveshare.guestApprovalRequired": true
    
  • Legen Sie in Visual Studio tools > Options > Live Share > "Require guest approval" (Gastgenehmigung erforderlich) auf True fest.

    Visual Studio Einstellungsfenster mit hervorgehobener Einstellung für die Gastgenehmigung

Ab diesem Zeitpunkt werden Sie aufgefordert, jeden Gast zu genehmigen, der beitritt.

In Visual Studio Code:

Genehmigungsanforderung für einen Beitritt zur Sitzung in Visual Studio Code

In Visual Studio:

Genehmigungsanforderung für einen Beitritt zur Sitzung in Visual Studio

Wenn Sie als Gast einer Sitzung beitreten, in der diese Einstellung für den Host aktiviert ist, werden Sie in der Statusleiste oder im Dialogfeld zum Beitreten benachrichtigt, dass Live Share auf die Genehmigung durch den Host wartet.

Automatisches Ablehnen oder Akzeptieren von Benutzern, die nicht angemeldet sind (anonym)

Wie oben beschrieben, können Live Share so konfiguriert werden, dass Benutzer, die nicht angemeldet sind, einer Zusammenarbeitssitzung als schreibgeschützte Gäste beitreten können. Während diese "anonymen" Gäste beim Beitritt einen Namen eingeben müssen, bietet ein einfacher Name nicht die gleiche Sicherheitsstufe wie eine echte Anmeldung. Daher wird der Host standardmäßig aufgefordert, anonyme Gastbenutzer unabhängig von der oben beschriebenen Einstellung "Gastgenehmigung erforderlich" zu genehmigen.

Sie können anonyme Gäste jederzeit ablehnen (deaktivieren) oder anonyme Benutzer stattdessen wie folgt akzeptieren:

  • Legen Sie in VS Code in settings.jsliveshare.anonymousGuestApproval on (Datei->-Einstellungen > Einstellungen) auf accept , oder reject prompt (Standardeinstellung) fest.

  • Legen Sie in Visual Studio Extras > Optionen > Live Share > "Anonyme Gastgenehmigung" entsprechend auf Akzeptieren, Ablehnen oder Eingabeaufforderung fest.

Denken Sie jedoch daran, dass Sie nur Live Share Einladungslinks an Personen senden sollten, denen Sie vertrauen.

Steuern des Dateizugriffs und der Sichtbarkeit

Als Gast bietet ihnen Live Share Remotemodell schnellen Lese-/Schreibzugriff auf Dateien und Ordner, die der Host für Sie freigegeben hat, ohne den gesamten Inhalt eines Projekts synchronisieren zu müssen. Sie können daher unabhängig durch Dateien in der gesamten freigegebenen Dateistruktur navigieren und diese bearbeiten. Diese Freiheit birgt jedoch ein gewisses Risiko für den Host. Im Konzept könnte sich ein Entwickler dafür entscheiden, Quellcode ohne Ihr Wissen zu ändern oder sensiblen Quellcode oder "Geheimnisse" in der freigegebenen Dateistruktur anzuzeigen. Daher möchten Sie als Host möglicherweise nicht immer, dass der Gast Zugriff auf das gesamte Projekt hat, das Sie freigeben. Glücklicherweise ist ein zusätzlicher Vorteil dieses Remotemodells, dass Sie Dateien ausschließen können, die Sie nicht ohne Einbußen bei der Funktionalität für niemanden freigeben möchten. Ihre Gäste können weiterhin an Debugsitzungen teilnehmen, die normalerweise Zugriff auf diese Dateien benötigen, wenn sie dies selbst tun möchten.

Sie können dies erreichen, indem Sie dem freigegebenen Ordner oder Projekt eine .vsls.js in der Datei hinzufügen. Alle Einstellungen, die Sie dieser JSON-formatierten Datei hinzufügen, ändern die Verarbeitung von Dateien durch Live Share. Zusätzlich zur direkten Steuerung können diese Dateien auch der Quellcodeverwaltung übergeben werden, damit jeder, der ein Projekt klont, diese Regeln ohne zusätzlichen Aufwand nutzen kann.

Hier sehen Sie ein Beispiel .vsls.jsfür die Datei:

{
    "$schema": "http://json.schemastore.org/vsls",
    "gitignore":"none",
    "excludeFiles":[
        "*.p12",
        "*.cer",
        "token",
        ".gitignore"
    ],
    "hideFiles": [
        "bin",
        "obj"
    ]
}

Hinweis

Sie können auch alle Dateien/Ordner, die Sie freigeben, schreibgeschützt machen, wenn Sie eine Zusammenarbeitssitzung starten. Weitere Informationen finden Sie unten.

Im Folgenden wird erläutert, wie diese Eigenschaften die Möglichkeiten von Gästen ändern.

Eigenschaften

Mit der excludeFiles-Eigenschaft können Sie eine Liste von Globdateimustern angeben (ähnlich wie die gefundenen GITIGNORE-Dateien), die verhindern, dass Live Share bestimmte Dateien oder Ordner für Gäste öffnen. Beachten Sie, dass dies szenarien wie das Folgen eines Gasts oder das Springen zu Ihrem Bearbeitungsspeicherort, schrittweises Durchlaufen einer Datei während des gemeinsamen Debuggens, alle Codenavigationsfeatures wie "Gehe zu Definition" und vieles mehr umfasst. Sie ist für Dateien vorgesehen, die Sie unter keinen Umständen freigeben möchten, z. B. für Dateien, die Geheimnisse, Zertifikate oder Kennwörter enthalten. Da sie beispielsweise die Sicherheit steuern, werden .vsls.jsfür Dateien immer ausgeschlossen.

Die hideFiles-Eigenschaft ist ähnlich, aber nicht ganz so streng. Diese Dateien werden einfach in der Dateistruktur ausgeblendet. Wenn Sie z. B. während des Debuggens in eine dieser Dateien einzelschritten, wird sie immer noch im Editor geöffnet. Diese Eigenschaft ist in erster Linie nützlich, wenn Sie keine GITIGNORE-Datei einrichten (wie dies bei Verwendung eines anderen Quellcodeverwaltungssystems der Fall wäre), oder wenn Sie einfach das bereits vorhanden ist erweitern möchten, um Überladenheit oder Verwirrung zu vermeiden.

Die Gitignore-Einstellung legt fest, wie Live Share den Inhalt von GITIGNORE-Dateien in freigegebenen Ordnern verarbeiten soll. Standardmäßig werden alle Globs in GITIGNORE-Dateien so behandelt, als wären sie in der Eigenschaft "hideFiles" angegeben. Sie können jedoch ein anderes Verhalten auswählen, indem Sie einen der folgenden Werte verwenden:

Option Ergebnis
none .gitignore-Inhalte sind für Gäste in der Dateistruktur sichtbar (vorausgesetzt, sie werden nicht durch eine Gast-Editor-Einstellung gefiltert).
hide Der Standardwert. Globs in .gitignore werden so verarbeitet, als befänden sie sich in der Eigenschaft "hideFiles".
exclude Globs in .gitignore werden so verarbeitet, als befänden sie sich in der Eigenschaft "excludeFiles".

Ein Nachteil der Einstellung ist, dass sich der Inhalt von Ordnern wie node_modules häufig in .gitignore befindet, aber beim Debuggen hilfreich sein exclude kann. Folglich unterstützt Live Share die Möglichkeit, eine Regel mithilfe von "!" in der excludeFiles-Eigenschaft umzukehren. Beispielsweise würde dieser .vsls.jsDatei alle Dateien in ".gitignore" ausschließen, mit Ausnahme von node_modules:

{
    "$schema": "http://json.schemastore.org/vsls",
    "gitignore":"exclude",
    "excludeFiles":[
        "!node_modules"
    ]
}

Die Regeln zum Ausblenden und Ausschließen werden separat verarbeitet. Wenn Sie also weiterhin node_modules ausblenden möchten, um die Übersichtlichkeit zu reduzieren, ohne sie tatsächlich auszuschließen, können Sie die Datei einfach wie folgt bearbeiten:

{
    "$schema": "http://json.schemastore.org/vsls",
    "gitignore":"exclude",
    "excludeFiles":[
        "!node_modules"
    ],
    "hideFiles":[
        "node_modules"
    ]
}

.vsls.jsfür Dateien in Unterordnern

Wie bei .gitignore können .vsls.jsDateien in Unterordnern platziert werden. Regeln zum Ausblenden/Ausschließen werden bestimmt, indem sie mit dem .vsls.jsin der Datei im freigegebenen Stammordner beginnen (sofern vorhanden) und dann an jedem Unterordner von dort aus durchgehen, was zu einer bestimmten Datei führt, um nach .vsls.jsfür zu verarbeitende Dateien zu suchen. Der Inhalt von .vsls.jsDateien in Ordnern weiter unten in der Dateistruktur und ergänzt (oder überschreibt) regeln, die auf höheren Ebenen eingerichtet wurden.

Deaktivieren der externen Dateifreigabe

Standardmäßig werden Live Share dateien, die vom Host geöffnet werden und sich außerhalb des freigegebenen Ordners bzw. der freigegebenen Projektmappe befinden, freigegeben. Dies erleichtert das schnelle Öffnen anderer verwandter Dateien, ohne erneut freigeben zu müssen.

Wenn Sie diese Funktion lieber deaktivieren möchten:

  • Fügen VS Code folgendes hinzu, um settings.jshinzuzufügen:

    "liveshare.shareExternalFiles": false
    
  • Legen Visual Studio tools options > Live Share > > "Share External Files" (Externe Dateien freigeben) auf False fest.

Schreibgeschützter Modus

Wenn Sie Ihren Code als Host freigeben, möchten Sie manchmal nicht, dass Ihre Gäste Änderungen ausführen. Möglicherweise müssen Sie ihren Gast einen Blick auf Ihren Code werfen, oder Sie zeigen Ihr Projekt einer großen Anzahl von Gästen an und möchten nicht, dass unnötige oder versehentliche Änderungen vorgenommen werden. Live Share bietet die Möglichkeit, Projekte im schreibgeschützten Modus gemeinsam zu verwenden.

Als Host haben Sie bei der Freigabe die Möglichkeit, den schreibgeschützten Modus für eine Zusammenarbeitssitzung zu aktivieren. Wenn ein Gast beitreten kann, kann er den Code nicht bearbeiten, obwohl Sie weiterhin die Cursor und Highlights des jeweils anderen sehen und durch das Projekt navigieren können.

Sie können weiterhin das Co-Debuggen mit Gästen ausführen, während Sie sich im schreibgeschützten Modus befinden. Gäste haben nicht die Möglichkeit, den Debugprozess schrittweise zu durchschritten, können aber trotzdem Haltepunkte hinzufügen oder entfernen und Variablen überprüfen. Darüber hinaus können Sie Server und Terminals (schreibgeschützt) weiterhin für Gäste freigeben.

Weitere Informationen zum Starten einer schreibgeschützten Zusammenarbeitssitzung finden Sie unter  VS Code  VS.

Gemeinsames Debuggen

Wenn Sie schwierige Programmierprobleme oder Fehler beheben, kann es sehr nützlich sein, beim Debuggen ein zusätzliches Augenpaar zu haben. Visual Studio Live Share ermöglicht "gemeinsames Debuggen" oder "Gemeinsames Debuggen", indem die Debugsitzung für alle Gäste gemeinsam verwendet wird, wenn der Host mit dem Debuggen beginnt.

Als Host haben Sie die vollständige Kontrolle darüber, wann eine Debugsitzung gestartet oder beendet wird. Das co-Debuggen birgt jedoch einige Risiken, wenn Sie die Freigabe für eine Person machen, der Sie nicht vertrauen. Live Share können Gäste, die Sie einladen, Konsolen-/REPL-Befehle ausführen. Daher besteht das Risiko, dass ein böswilliger Akteur einen Befehl ausführt, der nicht ausgeführt werden soll.

Daher sollten Sie nur mit denen, denen Sie vertrauen, co-debuggen.

Weitere Informationen:  VS Code  VS

Freigeben eines lokalen Servers

Beim gemeinsamen Debuggen kann es sehr hilfreich sein, Zugriff auf verschiedene Teile der Anwendung zu erhalten, die den Gästen vom Gastgeber für die Debugsitzung „serviert“ werden. Möglicherweise möchten Sie in einem Browser auf die App zugreifen, auf eine lokale Datenbank zugreifen oder über Ihre Tools auf einen REST-Endpunkt zugreifen. Live Share können Sie einen Server freigeben, der einen lokalen Port auf dem Computer des Hosts demselben Port auf dem Computer des Gasts zulässt. Als Gast können Sie dann genau so mit der Anwendung interagieren, als ob sie lokal auf Ihrem Computer ausgeführt würde (z. B. der Host und der Gast können auf eine Web-App zugreifen, die unter ausgeführt http://localhost:3000) wird.

Als Host sollten Sie jedoch sehr selektiv auf die Ports, die Sie für Gäste freigeben, und nur Anwendungsports anstelle von Systemports freigeben. Für Gäste verhalten sich freigegebene Ports so, als würde der Server oder Dienst auf dem lokalen Gastcomputer ausgeführt werden. Dies ist zwar sehr nützlich, kann aber auch riskant sein, wenn der falsche Port freigegeben wird. Aus diesem Grund Live Share keine Annahmen darüber, was ohne Konfigurationseinstellung freigegeben werden soll oder nicht, und der Host führt eine Aktion aus.

In Visual Studio wird der in ASP.NET-Projekten angegebene Webanwendungsport automatisch während des Debuggens freigegeben, um den Gastzugriff auf die Web-App bei der Ausführung zu erleichtern. Sie können diese Automatisierung jedoch deaktivieren, indem Sie tools > Options > Live Share > "Share web app on debug" (Web-App beim Debuggen freigeben) auf "False" festlegen.

In Visual Studio Code versucht Live Share, die richtigen Anwendungsports zu erkennen und diese zu teilen. Sie können dies jedoch deaktivieren, indem Sie Folgendes hinzufügen, um settings.jsaktivieren:

liveshare.autoShareServers: false

Achten Sie in beiden Fällen darauf, zusätzliche Ports gemeinsam zu nutzen.

Weitere Informationen zum Konfigurieren des Features finden Sie  hier: VS Code  VS

Freigeben eines Terminals

Die moderne Entwicklung nutzt oft eine Vielzahl von Befehlszeilentools. Glücklicherweise ermöglicht Live Share es Ihnen als Gastgeber, für Gäste optional „ein Terminal freizugeben“. Das freigegebene Terminal kann schreibgeschützt oder vollständig für die Zusammenarbeit eingerichtet sein, damit Sie und Ihre Gäste Befehle ausführen und die Ergebnisse anzeigen können. Als Host können Sie anderen Projektmitarbeitern erlauben, entweder nur die Ausgabe zu sehen oder eine beliebige Anzahl von Befehlszeilentools zum Ausführen von Tests, Builds oder sogar zum Seligen umgebungsspezifischer Probleme zu verwenden.

Nur Hosts können freigegebene Terminals starten, um zu verhindern, dass Gäste ein Terminal starten und etwas tun, was Sie nicht erwarten oder ansehen. Wenn Sie ein freigegebenes Terminal als Host starten, können Sie angeben, ob es schreibgeschützt sein oder lesen/schreiben soll. Im zweiten Fall kann jede Person einschließlich des Gastgebers Befehle im Terminal eingeben. Dadurch können unerwünschte Gastaktionen leicht unterbunden werden. Die Lese- und Schreibberechtigungen sollten Sie aus Sicherheitsgründen ausschließlich Gästen bereitstellen, die darauf angewiesen sind. Terminals mit Leseberechtigungen sollten Sie in Szenarios einsetzen, in denen Gäste nur die Ausgabe der von Ihnen ausgeführten Befehle sehen dürfen.

In Visual Studio werden Terminals standardmäßig nicht gemeinsam genutzt. In VS Code werden Terminals standardmäßig automatisch schreibgeschützt freigegeben. Sie können dies jedoch deaktivieren, indem Sie Folgendes hinzufügen, um settings.jsaktivieren:

"liveshare.autoShareTerminals": false

Weitere Informationen:  VS Code  VS

Wenn Sie sich mit einer von Microsoft unterstützten E-Mail-Adresse für Ein- oder Schulkonto anmelden, wird bei der Anmeldung möglicherweise eine Meldung mit dem Text "Administratorgenehmigung erforderlich" angezeigt. Dies liegt daran, dass Live Share Lesezugriff auf Benutzerinformationen für seine Sicherheitsfeatures erfordert und Ihr Azure AD-Mandant so eingerichtet ist, dass für neue Anwendungen, die auf den Inhalt des Verzeichnisses zugreifen, die "Administrator-Zustimmung" erforderlich ist.

Ihr AD-Administrator muss dies mithilfe der folgenden Informationen für Sie beheben:

Dies muss nur einmal für alle Personen erfolgen, die Live Share. Weitere Informationen finden Sie hier und hier.

Weitere Informationen

Gibt es Probleme? Lesen Sie Troubleshooting oder Feedback geben.