Wurde das neue PnP PowerShell Modul installiert wird es bei der ersten Verbindung einen Fehler geben es sei keine Berechtigung vorhanden. Die Azure App von PnP PowerShell muss einmalig für den Zugriff auf die APIs freigeschalten werden.
Damit PnP PowerShell auf den Microsoft 365 Tenant zugreifen kann muss es im ersten Schritt über Connect-PnPOnline eine Verbindung zu einer beliebigen SharePoint Site herstellen. Ohne Ersteinrichtung tritt dabei ein Fehler auf.
PnP PowerShell hat bei der ersten Anwendung keine Berechtigung Daten aus dem Tenant abzurufen. In Kurzform beschreibt die PnP Community 4 Anmeldemethoden. Allgemein ruft PnP PowerShell Daten nur noch über APIs aus Microsoft Graph oder anderen Endpunkten ab und bevorzugt deshalb die Methode einer Azure App Authentifizierung.
Praktisch sind alle Methoden für automatisierte Accounts (in Scripts) geeignet. Manche davon nicht für Accounts mit Multi-Faktor Authentifizierung. Die 4. Methode bietet Unterstützung für Cross-Platform und ist damit bei Windows, MacOS oder Linux gleichermassen einsetzbar.
Methode 1
Die einfache “All-in-one” Methode, eine PnP Management Shell App vorkonfiguriert mit allen erforderlichen Zugriffsrechten und APIs. Für die Art von Administratoren die sich nicht viel Gedanken über APIs und ähnliches machen wollen.
Methode 2
Eine PnP Management Shell App mit limitierten Basisberechtigungen und APIs. Weitere Berechtigungen/APIs werden nachträglich ergänzt oder entfernt.
Methode 3
Klassisch über Benutzername und Passwort bzw. diese im Windows Credential Manager abzulegen. Für Accounts mit Multi-Faktor Authentifizierung ist die Methode nur eingeschränkt geeignet.
Methode 4
Über den Einsatz des neuen Secrets Management Moduls für PowerShell 7. Damit können es Anwender von Windows, MacOS und Linux gleichermassen einsetzen. Für Accounts mit Multi-Faktor Authentifizierung ist die Methode nicht geeignet.
Die Einrichtung aller 4 Methoden ist nicht sonderlich viel Aufwand. Je nach Einsatzzweck ist es eine individuelle Wahl. Bei Bedarf lassen sich die Methoden kombinieren.
Für alle 4 Methoden gehe ich davon aus das neue PnP PowerShell Modul wurde installiert. Falls nicht folge der Anleitung für die Installation.
Methode 1
PnP Management Shell App vorkonfiguriert
Für den schnellen Zugriff kann PnP PowerShell die App mit allen erforderlichen Zugriffsrechten selbst erstellen. Es ist nur einmalig erforderlich. Bei der erstmaligen Einrichtung ist ein Global Admin erforderlich, später nicht mehr.
- Öffne PowerShell und führe Register-PnPManagementShellAccess aus.
Register-PnPManagementShellAccess- PowerShell wird ein Browserfenster öffnen und fordern den angezeigten Code einzugeben.
- Nachdem du den Code eingegeben hast muss sich bei der erstmaligen Verwendung ein Global Admin anmelden. Später ist kein Global Admin mehr erforderlich.
- Im nächsten Schritt folgt die Freigabe für die PnP Management Shell App. In dem langen Dialog stehen alle APIs und Berechtigungen auf die Zugriff erforderlich ist (= All-in-one). Ein Administrator hat die Wahl alle zuzulassen, oder die ganze App abzulehnen.
 |  |
- Wird die Abfrage akzeptiert ist der einmalige Schritt für die Erstellung der PnP Management Shell App abgeschlossen.
Zukünftig ist es ausreichend für die Anmeldung im Tenant eine Verbindung zu einer beliebigen SharePoint Site herzustellen. Über die Berechtigungen des Accounts wird der Benutzer Daten zurückbekommen auf die er/sie Zugriff hat. Bei Accounts mit Multi-Faktor Authentifizierung müsste für die Verbindung der Parameter UseWebLogin eingesetzt werden.
# Ohne Multi-Faktor Authentifizierung
Connect-PnPOnline [SharePointSiteUrl]
# Mit Multi-Faktor Authentifizierung
Connect-PnPOnline [SharePointSiteUrl] -UseWebLoginNachdem die Verbindung hergestellt ist können zum Beispiel Daten über Teams abgerufen werden.
Wurde die Abfrage oben akzeptiert hat es in Azure AD eine Enterprise App mit dem Namen “PnP Management Shell” erstellt. Die kann ein Administrator aufrufen und prüfen, deaktivieren oder löschen. Wird die App deaktiviert oder gelöscht sind alle Berechtigungen und möglichen Zugriffe inaktiv.
Hier findet ein Administrator ausserdem auf welche APIs die App über die Berechtigungen zugreift. Es sind die Angaben wie es oben bei der Abfrage gelistet war. An den Berechtigungen ist zu erkennen es sind Delegated Permissions. Angemeldete Accounts können also nur Daten abrufen auf die sie berechtigt sind bzw. Accounts mit einer Admin-Rolle erhalten Zugriff auf mehr Daten.
Methode 2
PnP Management Shell App mit Basisberechtigungen und Zertifikat
Mit der 2. Methode wird die Azure App vorab namentlich benannt und PnP PowerShell konfiguriert für die App ein Zertifikat und Basisrechte. Methode 2 kann für verschiedene Apps mehrfach ausgeführt werden um die Zugriffe pro Einsatzzweck einzuschränken. Das Zertifikat ist eine alternative Möglichkeit dich anstatt einem Passwort oder SecretKey anzumelden.
- Öffne PowerShell und führe das Command zur Registrierung der App aus. Passe die individuellen Angaben [ ] auf deinen Tenant an.
Register-PnPAzureADApp -ApplicationName "TAM-PnPPowerShell" -Tenant [Tenantname].onmicrosoft.com -OutPath [LocalPathToSavetheCertificate] -DeviceLogin
- PowerShell wird ein Browserfenster öffnen, fordern einen Code einzugeben und dich anzumelden.
- Danach dauert es 60 Sekunden bis du dich erneut anmelden und deiner App Basisrechte gewähren musst. Im Vergleich zur Methode 1 sind es weniger Zugriffe.
- Wurde der Zugriff bestätigt wird das Zertifikat erstellt.
- Im angegebenen Ordnern finden sich nun zwei Zertifikate mit dem Namen der App.
- Über das PFX-Zertifikat ist die Anmeldung mit PowerShell und der Abruf von Daten möglich. Beachte, du wirst in der Basiskonfiguration nur Inhalte abrufen können auf die dein Account berechtigt ist.
Connect-PnPOnline [SharePointSiteUrl] -ClientId [AppID] -CertificatePath [PathtoPFXCertificate] -Tenant [Tenantname].onmicrosoft.com
Nachdem die App erstellt wurde findet sie ein Administrator in Azure AD im Bereich App Registrations.
Dort sind die Berechtigungen vermerkt und berechtigte Personen können bei Bedarf der App weitere Rechte geben.
Methode 3
Benutzername und Passwort bzw. mit Windows Credential Manager
Die Methode beschrieb ich in ähnlicher Form im Mai 2020, siehe Verwendung von Passwörtern mit PnP PowerShell. Bei Accounts mit Multi-Faktor Authentifizierung müsste für die Verbindung der Parameter UseWebLogin eingesetzt werden.
# Ohne Multi-Faktor Authentifizierung und mit Einsatz von Windows Credential Manager
Connect-PnPOnline [SharePointSiteUrl] -Credentials TAM365
# Mit Multi-Faktor Authentifizierung
Connect-PnPOnline [SharePointSiteUrl] -UseWebLogin Methode 4
Secrets Management Modul für PowerShell 7
Es ist ähnlich wie Methode 3. Das Passwort wird in einem gesicherten Credential Manager gespeichert. Da es mit PowerShell 7 kompatibel ist wäre es für die Anwendung auf Windows, MacOS und Linux geeignet. Es sind die PowerShell Module Microsoft.PowerShell.SecretManagement und Microsoft.PowerShell.SecretStore erforderlich. Für Accounts mit Multi-Faktor Authentifizierung ist die Methode nicht geeignet.
Ein Test zeigt die Anmeldedaten wurden korrekt erfasst, nach einer Anmeldung lassen sich Daten abrufen.
