none
SP 2016 On-Premise, Provider-Hosted Add-In, Fehler 401 Not authorized beim Zugriff auf das Host-Web RRS feed

  • Frage

  • Hallo

    ich habe in einer SP 2016 On-Premise Umgebung das Template-Beispiel "SharePoint Add-in" vom Typ "Provider-Hosted" in Visual Studio 2015 erstellt.

    Beim Debugging-Test sollte im Code der default.aspx-Seite aus dem Host-Web der Titel ausgelesen und im App-Web angezeigt werden. An dieser Stelle erhalte ich den Fehler "401 not autorized".

    Wo könnten typische Fehler in der SharePoint-Konfiguration versteckt sein? Eigentlich sollte alles laut den einschlägigen MS-Beschreibungen eingerichtet sein und funktionieren. ("Normale" Add-Ins, die keinen Zugriff auf das Host-Web benötigen, funktionieren.)

    Das Add-In hat folgende Konfiguration:

    • Web.config: Client-Id, ClientSigningCertification, ClientSigningCertificatePassword und IssuerId sind gesetzt
    • AppManifest.xml: "Nur-App-Aufrufe" sind erlaubt; Read-Berechtigung auf das Web

    Hat jemand eine Idee, was sein könnte bzw. wie man die Ursachensuche am besten ansetzt?

    Danke!

    Sonntag, 20. August 2017 08:59

Antworten

Alle Antworten

  • Hi,
    ich vermute, dass etwas mit der Vertrauensstellung zwischen SharePoint und Remote Host nicht stimmt. Wie hast Du diese eingerichtet und überprüft?

    --
    Viele Grüsse
    Peter Fleischer (ehem. MVP)
    Meine Homepage mit Tipps und Tricks

    Sonntag, 20. August 2017 11:01
  • Folgende beiden Dinge sind konfiguriert:

    1) appregnew.aspx

    Über appregnew.aspx-Seite habe ich das Add-In als vertrauenswürdig bekannt gemacht. Also mittels Client-Id und Clientschlüssel sollten die beiden sich kennen. Was mir aufgefallen ist: Beim Debuggen (F5) ändert Visual Studio jedesmal die Client-Id - allerdings kommt auch im Ausgabefenster eine Meldung, die darauf hindeutet dass beim Starten des IIS-Express und des Add-Ins noch eine Aktion in Richtung SharePoint läuft.

    Ein Frage: Die Add-Ins laufen bei mir in der Domäne "mydevaddins.intra" (unser Intranet ist .intra). Als App-Domäne hatte ich "www.mydevaddins.intra" angegeben. Vielleicht sollte das nur "mydevaddins.intra" angegeben. Die Weiterleitungs-URI zeigt auf meinen Server "https://myserver/default.aspx". (Server ist nicht vollqualifiziert angegeben, da alles lokal läuft.)

    2) SSL-Zertifikat

    Ich habe über den Domain-Controller ein Zertifikat mit cer- und pfx-Datei erstellt. Das Zertifikat kennt der SharePoint (New-SPTrustedSecurityIssuer ...) und es ist wie oben erwähnt in der Web-Config mit Pfad und privatem Passwort dem Add-In bekanntgemacht.

    Frage: Mit welchen Mitteln kann man die Vertrauensstellung gezielt testen?

    Sonntag, 20. August 2017 16:28
  • Hi,
    hast Du alle Schritte aus "Intro to Provider Hosted Apps – Setup the Infrastructure" ausgeführt?

    --
    Viele Grüsse
    Peter Fleischer (ehem. MVP)
    Meine Homepage mit Tipps und Tricks

    • Als Antwort markiert L Zeitler Donnerstag, 24. August 2017 15:11
    Montag, 21. August 2017 06:23
  • Hallo Peter

    erst mal Danke für die Anleitung. Ich werde dies im Einzelnen prüfen. Der Punkt im Moment ist jedoch der, dass ich bereits beim "Approach 1", d.h. dem Debuggen aus dem Visual Studio heraus (mittels F5, SharePoint-Developer-Site, IIS-Express für das Remote-Web) keine Berechtigung auf das SharePoint Host-Web bekomme. Die Anleitung beschreibt den "Approach 2", also den "normalen" Einsatz eines fertigen Add-Ins (mit Packen und Deployen, App-Katalog, IIS).

    Alle meine Komponenten (SharePoint, IIS (für den SP), IIS-Express und VisualStudio) laufen auf einer einzigen Maschine.

    Aber vielleicht gibt es dennoch einen Hinweis, der auch den "Approach 1" in der Anleitung berührt.

    Gruß

    Lars

    Donnerstag, 24. August 2017 06:39
  • Das Problem scheint gelöst zu sein. Mit einem anderen Zertifikat funktioniert der Zugriff zum Host-Web.

    Anscheinend ist nicht egal, wo/wie man ein Zertifikat erstellt. Mein ursprüngliches Zertifikat hatte ich direkt am Domain Controller erstellt. Entsprechend der Anleitung habe ich ein neues Zertifikat erstellt, und zwar ein Domain Zertifikat über den IIS des SharePoint (mit dem Domain Controller als Zertifizierungsstelle), wie im Tutorial beschrieben. Alle weiteren mit dem Zertifikat zusammenhängenden Schritte (Export als CER- und PFX-Datei, Bekanntmachung im SharePoint und Einbindung in die web.config) hatte ich auch mit dem ersten Zertifikat analog durchgeführt.

    Der Unterschied der Zertifikate ist mir nicht klar, Tage der Suche sind für nix verstrichen - aber nun geht es wenigstens. Die beiden Teile der von dir genannten Anleitung sind prima, alles schön kompakt beisammen. Danke nochmal!

    Donnerstag, 24. August 2017 15:11