Erhalten Sie 401/403 in der High Trust App für Sharepoint 2013
https://sharepoint.stackexchange.com//questions/79284
-
10-12-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianFrage
ich habe das Cloudshare-Umgebung bestehend aus 3 Maschinen:
- Eine für Sharepoint 2013 (hier entwickle ich mit installiertem VS2012)
- Ein weiterer für SQL Server 2012
- Und noch eine für Active Directory
Ich versuche, mithilfe des Server-zu-Server-Protokolls eine einfache App mit hoher Vertrauenswürdigkeit für Sharepoint 2013 zu erstellen.
Ich bin mehreren Anleitungen gefolgt:
- http://msdn.microsoft.com/en-us/library/fp179901.aspx
- http://blogs.msdn.com/b/shariq/archive/2013/05/07/how-to-set-up-high-trust-apps-for-sharepoint-2013-amp-troubleshooting-tips.aspx
- http://ranvijaysingh.blogspot.com.ar/2013/04/develop-provider-hosted-app-on-single.html
Wenn ich das Projekt (Standardvorlagencode) von VS aus ausführe und der App vertraue, erhalte ich eine Ausnahme in der folgenden Zeile:
Uri hostWeb = new Uri(Request.QueryString["SPHostUrl"]);
using (var clientContext = TokenHelper.GetS2SClientContextWithWindowsIdentity(hostWeb, Request.LogonUserIdentity))
{
clientContext.Load(clientContext.Web, web => web.Title);
clientContext.ExecuteQuery(); // throws exception
Response.Write(clientContext.Web.Title);
}
in Default.aspx.cs
Die Ausnahme könnte eine der folgenden sein:
Der Remote-Server hat einen Fehler zurückgegeben:(403 Verboten.
Der Remote-Server hat einen Fehler zurückgegeben:(401 nicht Autorisiert.
Ich habe mehrere Tipps zur Fehlerbehebung ausprobiert, ohne Erfolg.Ich bin kein SP2013-Experte, daher bin ich für jede Hilfe dankbar.
Danke
AKTUALISIEREN
Hier sind die ULS-Protokolleinträge im Zusammenhang mit der Anfrage:http://pastie.org/pastes/8395956/text
Lösung
Der Einfachheit halber sage ich das Offensichtliche!
Der Benutzer ist nicht authentifiziert und die Ressource erfordert eine Authentifizierung
Das sagt mir, dass mit dem Händeschütteln etwas nicht stimmt (Ihr Zertifikat wird nicht gesendet oder ist falsch). Da es sich um ein Microsoft-Produkt handelt, ist es am besten, einen Blick auf msdn zu werfen.
Zur Verdeutlichung lesen Sie bitte Folgendes:
Der folgende Schritt ist optional.Wir empfehlen jedoch, dass Sie sich mit HTTPS -AUSGABEN entwickeln und testen.Das Ausschalten von HTTPs kann dazu führen, dass Sie als Entwickler bestimmte Probleme beim Erstellen einer App erstellen, die während einer Produktionsbereitstellung auftritt, in der HTTPS erforderlich ist.
Jetzt lesen Sie die Notiz, lesen Sie das Problem, das Sie haben!
OAuth verlangt nun, dass SharePoint HTTPS nicht nur für Ihren Service, sondern auch für SharePoint 2013 ausführen muss.Sie erhalten eine 403 (verbotene) Nachricht, wenn Sie versuchen, mithilfe eines Testzertifikats einen Anruf bei SharePoint zu tätigen.
Auf dem Computer, auf dem Sie SharePoint 2013 installiert haben, können Sie die HTTPS -Anforderung während der Entwicklung deaktivieren, indem Sie die folgenden Windows PowerShell -CMDLets verwenden.
Das ist also genau dort Ihr Problem!Um dies während der Entwicklung zu umgehen, gehen Sie wie folgt vor:
Dies in Powershell zum Testen/Entwicklung:
$serviceConfig = Get-SPSecurityTokenServiceConfig
$serviceConfig.AllowOAuthOverHttp = $true
$serviceConfig.Update()
Sobald Sie fertig sind, bringen Sie es wieder in den ursprünglichen Zustand zurück!
$serviceConfig = Get-SPSecurityTokenServiceConfig
$serviceConfig.AllowOAuthOverHttp = $false
$serviceConfig.Update()
Jetzt möchte ich noch anmerken:
In einer App-App gibt es keinen Kontext-Token, auch wenn Sie die Datei apprect.aspx verwenden.Der Kontext -Token ist spezifisch für Konfigurationen, die Windows Azure Access Control Service (ACS) verwenden.Ein Zugangstoken ist jedoch noch erforderlich. Wenn Sie eine Konfiguration mit hoher Trust verwenden, muss Ihre Webanwendung den Benutzer genauso authentifizieren wie SharePoint 2013 (dh die App ist für das Erstellen des Benutzerabschnitts des Zugriffs-Tokens verantwortlich).
Verwenden Sie die Tokenhelper-Klasse, um den Clientkontext abzurufen?
using (var clientContext = TokenHelper.GetS2SClientContextWithWindowsIdentity(hostWeb, Request.LogonUserIdentity))
{
clientContext.Load(clientContext.Web, web => web.Title);
clientContext.ExecuteQuery();
Response.Write(clientContext.Web.Title);
}
Außerdem: Was genau versuchen Sie zu tun? Je nachdem, was Sie tun, benötigen Sie möglicherweise mehr Berechtigungen!
Um auf andere Eigenschaften zuzugreifen, müssen Sie möglicherweise Berechtigungen im Host -Web anfordern.
http://msdn.microsoft.com/en-us/library/fp179901.aspx
Ich hoffe, das Obige beantwortet deine Frage!Sie müssen sicherstellen, dass die oben genannten Schritte korrekt ausgeführt werden, damit es funktioniert!
Wenn das immer noch ein Problem ist, stimmt etwas mit der von vs2012 ausgegebenen GUID nicht, die automatisch gesendet wird, wenn Sie F5 drücken. Dies wird in web.config in dieser Zeile festgelegt:
<add key="IssuerId"
Ändern Sie die Anleitung von Groß- in Kleinschreibung:
aus:
<add key="IssuerId" value="F2AE6B96-1FC0-43C6-B5D0-900117C491A4"/>
Zu
<add key="IssuerId" value="f2ae6b96-1fc0-43c6-b5d0-900117c491a4"/>
Offensichtlich wird deine Anleitung anders sein als oben ;)
Bitte beachten Sie auch, dass Sie für jede einzelne App ein eindeutiges Zertifikat benötigen!Stellen Sie außerdem sicher, dass die Guid mit der verwendeten PowerShell-Guid übereinstimmt Get-SPTrustedSecurityTokenIssuer sollte mit der web.config identisch sein!
AKTUALISIEREN
Habe mir gerade deine Log-Datei angesehen!
Um es aufzuschlüsseln, es schlägt sofort mit der Authentifizierung fehl!Welche Methode verwenden Sie?ntlm?Kerbos?ect...
Dies ist von grundlegender Bedeutung, um zu wissen, wie Sie Ihre Farm und Authentifizierung eingerichtet haben!
Nun, so wie es aussieht, könnten hier mehrere Probleme vorliegen!Ich empfehle Ihnen, die folgenden Links durchzulesen!Sobald Sie die Links gelesen haben, würde ich Ihnen wärmstens empfehlen, Ihr Setup auszuführen, wenn alles korrekt ist New-SPTrustedSecurityTokenIssuer Dieses Beispiel finden Sie in meinem letzten Link unten auf der Seite!Dies könnte Ihr Problem mit dem Token-Teil und dem korrekten Handshaking zwischen zwei Servern (die sich gegenseitig validieren) lösen.
1) Der Token wird aufgrund nicht kompatibler Sicherheitseinstellungen nicht gesendet!
Wenn Sie den Windows -Angabenmodus für die Benutzerauthentifizierung verwenden und die Webanwendung so konfiguriert ist, dass nur die Kerberos -Authentifizierung verwendet wird, ohne als Authentifizierungsprotokoll auf NTLM zurückzukehren, funktioniert die App -Authentifizierung nicht.
http://technet.microsoft.com/en-us/library/ee806870.aspx
oder und
2) Wenn Sie die Server-zu-Server-Authentifizierung verwenden, könnte hier ein Fehler auftreten!Wurde Ihr Profil synchronisiert?
Stellen Sie für 2013 von Server zu Server sicher, dass die Gruppenmitgliedschaften mit der Benutzerprofildienstanwendung synchronisiert werden.
Wenn ein Benutzerprofil für einen Benutzer vorhanden ist und die zuständigen Gruppenmitgliedschaften nicht synchronisiert sind, kann der Zugriff abgelehnt werden, wenn dem Benutzer den Zugriff für eine bestimmte Ressource gewährt wird.Stellen Sie daher sicher, dass die Gruppenmitgliedschaften mit der Anwendung "Benutzerprofil -Service" synchronisiert werden.
http://technet.microsoft.com/en-us/library/jj219806.aspx
Jetzt ist dies erforderlich, damit die Server-zu-Server-Einrichtung funktioniert!
Die Server-zu-Server-Authentifizierung ermöglicht Server, die zur Server-Server-Authentifizierung in der Lage sind, im Namen der Benutzer auf Ressourcen zuzugreifen und voneinander anzufordern.Daher muss der Server, der SharePoint Server 2013 ausführt und der die eingehende Ressourcenanforderung dient, zwei Aufgaben ausführen können:
Um die Identität eines Benutzers zu rehydrieren, fordert ein Server, der Authentifizierungsversand von Server zu Server ausführen kann, Zugriff auf SharePoint-Ressourcen an.SharePoint Server 2013 nimmt die Behauptungen vom eingehenden Sicherheitstoken auf und behebt es an einen bestimmten SharePoint -Benutzer.Standardmäßig verwendet SharePoint Server 2013 die integrierte Anwendung für Benutzerprofile, um die Identität zu beheben.
und das Ergebnis des oben Gesagten ist:
Wenn ein Benutzerprofil und die relevanten Gruppenmitgliedschaften für den Benutzer nicht synchronisiert sind, kann SharePoint Server 2013 den Zugriff auf eine bestimmte Ressource fälschlicherweise verweigern.Stellen Sie daher sicher, dass die Gruppenmitgliedschaften mit der Anwendung "Benutzerprofil -Service" synchronisiert werden.Für Windows -Ansprüche importiert die Benutzerprofil -Dienstanwendung die vier zuvor beschriebenen Benutzerattribute und Gruppenmitgliedschaften.
http://technet.microsoft.com/en-us/library/jj729797.aspx
Der Punkt ist, dass das Token und die Authentifizierung nicht richtig funktionieren, weil entweder Ihr Setup mit dem Sicherheitstyp oder der Konfiguration falsch ist!Wenn Sie wissen, was Sie getan haben, können Sie feststellen, wo es schief gelaufen ist!Offenbar sieht es so aus, als ob die Server-zu-Server-Authentifizierung abgelehnt wird, da das Token nicht ordnungsgemäß gesendet wird.
Wenn Sie glauben, dass das Authentifizierungsprotokoll korrekt ist, können Sie dieser Anleitung folgen, nachdem Sie die obigen Links gelesen haben:
http://technet.microsoft.com/en-us/library/jj655400.aspx
Der obige Link erklärt und demonstriert Server-zu-Server-Schritte für bestimmte Szenarien
um eine Vertrauensstellung zwischen zwei Servern zu erstellen (Erstellt eine Vertrauensstellung zwischen einem Server und einem Serverprinzipal.)
Folge dieser Anleitung!verwenden New-SPTrustedSecurityTokenIssuer
http://technet.microsoft.com/en-us/library/jj219695.aspx
Entschuldigung für den langen Text und die vielen Links!Da es sich um Server zu Server handelt und das Protokoll generisch/eingerichtet ist, kann ich Ihnen eine definitive Antwort geben!Aber was ich weiß, ist, dass der Handshake zwischen zwei Servern schief geht, was bedeutet, dass Sie bei der Ersteinrichtung etwas verpasst haben!Die obigen Links sollten hoffentlich Ihr Problem zwischen dem Handshaking und der Übergabe der richtigen Anmeldeinformationen lösen, damit es ordnungsgemäß funktioniert!
Andere Tipps
Ich hatte ähnliche Probleme.Anstatt Clientcondext oder Tokenhelper zu verwenden, wurde ich auf den neuen SharePointContext umgewandelt, über den Sie hier lesen können: http://blogs.msdn.com/b/kaevans/archive/2013/09/24/Levans/archive/2013/09/24/loducing-sharepointcontext-for-provider-hosted-Sharepoint-apps.aspx
Nachdem ich diesen Switch gemacht habe, verschwanden meine 401- und 403 Probleme.Der neue SharePointContext verwendet den zugrunde liegenden Tokenhelper, daher stellen Sie sicher, dass Sie die neueste Version der Tokenhelper-Datei haben.
Ich glaube, ich weiß, was Ihr Problem war, das Server-Protokollpunkt auf Client / Server-Computer ist nicht in Synchronisierung von Zeit. generasacodicetagpre.
Ich hatte ein paar Tage zurückgesichts ähnlicher Fehler, und die Auflösung bestand darin, den Server- und Client-Maschinenzeit in Synchronisierung zu haben. generasacodicetagpre.
