Obtener 401/403 en la aplicación High Trust para Sharepoint 2013

sharepoint.stackexchange https://sharepoint.stackexchange.com//questions/79284

Pregunta

tengo esto Entorno compartido en la nube compuesto por 3 máquinas:

  • Uno para Sharepoint 2013 (aquí es donde desarrollo con VS2012 instalado)
  • Otro para SQL Server 2012
  • Y otro para Active Directory

Estoy intentando crear una aplicación básica de alta confianza para Sharepoint 2013 utilizando el protocolo de servidor a servidor.

He seguido varias guías:

Cuando ejecuto el proyecto (código de plantilla predeterminado) desde VS y confío en la aplicación, aparece una excepción en la siguiente línea:

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);
}

en Predeterminado.aspx.cs

La excepción podría ser cualquiera de las siguientes:

El servidor remoto devolvió un error:(403) Prohibido.

El servidor remoto devolvió un error:(401) No autorizado.

Probé varios consejos para solucionar problemas sin suerte.No soy un experto en SP2013, por lo que agradeceré cualquier ayuda.

Gracias

ACTUALIZAR

Aquí están las entradas del registro ULS relacionadas con la solicitud:http://pastie.org/pastes/8395956/text

¿Fue útil?

Solución

¡Para simplificar diré lo obvio!

El usuario no está autenticado y el recurso requiere autenticación.

esto me dice que algo anda mal con el apretón de manos (su certificado no se envió o es incorrecto), como es un producto de Microsoft, el mejor lugar es mirar msdn.

Para que quede claro lee esto:

El siguiente paso es opcional.Sin embargo, le recomendamos que desarrolle y pruebe con los HTTP activados.Desactivar HTTPS puede hacer que usted como desarrollador se pierda ciertos problemas al construir una aplicación que ocurriría durante una implementación de producción donde se requiere HTTPS.

¡Ahora lees la nota, lees el problema que tienes!

OAuth ahora requiere que SharePoint ejecute HTTPS, no solo para su servicio sino también para SharePoint 2013.Recibirá un mensaje 403 (prohibido) al intentar hacer una llamada a SharePoint utilizando un certificado de prueba.

En la computadora donde tiene SharePoint 2013 instalado, puede desactivar el requisito HTTPS durante el desarrollo utilizando los siguientes cmdlets de Windows PowerShell.

¡Así que ese es tu problema!Para evitarlo mientras se desarrolla, haga lo siguiente:

esto en powershell para pruebas/desarrollo:

$serviceConfig = Get-SPSecurityTokenServiceConfig
$serviceConfig.AllowOAuthOverHttp = $true
$serviceConfig.Update()

Una vez terminado, ¡devuélvelo a como estaba!

$serviceConfig = Get-SPSecurityTokenServiceConfig
$serviceConfig.AllowOAuthOverHttp = $false
$serviceConfig.Update()

Ahora también me gustaría señalar:

En una aplicación de alta confianza, no hay token de contexto, incluso si usa el archivo Apredirect.aspx.El token de contexto es específico de las configuraciones que utilizan el Servicio de Control de Acceso Azure (ACS) de Windows.Sin embargo, todavía se requiere un token de acceso. Si está utilizando una configuración de alto costo, su aplicación web debe autenticar al usuario de la misma manera que SharePoint 2013 (es decir, la aplicación es responsable de crear la parte del usuario del token de acceso).

¿Estás utilizando la clase tokenhelper para obtener el contexto del cliente?

        using (var clientContext = TokenHelper.GetS2SClientContextWithWindowsIdentity(hostWeb, Request.LogonUserIdentity))
        {
            clientContext.Load(clientContext.Web, web => web.Title);
            clientContext.ExecuteQuery();
            Response.Write(clientContext.Web.Title);
        }

Además, ¿qué estás intentando hacer exactamente? Es posible que necesites más permisos dependiendo de lo que estés haciendo.

Para acceder a otras propiedades, es posible que deba solicitar permisos en la web del host.

http://msdn.microsoft.com/en-us/library/fp179901.aspx

¡Espero que lo anterior responda a tu pregunta!¡Debes asegurarte de que lo anterior se haya hecho correctamente para que funcione!

Si eso sigue siendo un problema, entonces hay algún problema con el guid emitido por vs2012, que se envía automáticamente cuando presiona F5, esto está configurado en web.config en esta línea:

<add key="IssuerId"

cambie la guid de mayúsculas a minúsculas:

de:

<add key="IssuerId" value="F2AE6B96-1FC0-43C6-B5D0-900117C491A4"/>

a 

<add key="IssuerId" value="f2ae6b96-1fc0-43c6-b5d0-900117c491a4"/>

obviamente tu guía será diferente a la anterior;)

¡También me gustaría señalar que necesita un certificado único para cada aplicación individual!También asegúrese de que el guid sea el mismo que el guid de PowerShell usando Get-SPTrustedSecurityTokenIssuer ¡Debería ser el mismo que web.config!

http://www.jamestsai.net/Blog/post/SharePoint-Provider-Hosted-App-401-Unauthorized-error-on-clientContextExecuteQuery().aspx

ACTUALIZAR

¡Acabo de mirar su archivo de registro!

Para solucionarlo, ¡está fallando de inmediato con la autenticación!¿Qué método estás usando?¿ntlm?¿kerbos?etc...

¡Esto es fundamental para saber cómo ha configurado su granja y su autenticación!

¡Ahora podría haber varios problemas aquí por la apariencia de los errores!¡Te recomiendo que leas los enlaces a continuación!Recomiendo encarecidamente que, una vez que haya leído los enlaces, si todo está correcto en su configuración, ejecute New-SPTrustedSecurityTokenIssuer ¡Este ejemplo se puede encontrar en mi último enlace al final de la página!esto podría resolver su problema con la parte del token y el protocolo de enlace correcto entre dos servidores (validándose entre sí).

1) ¡el token no se envía debido a que la configuración de seguridad no es compatible!

Si está utilizando el modo de reclamos de Windows para la autenticación del usuario y la aplicación web está configurada para usar solo la autenticación de Kerberos sin volver a caer a NTLM como protocolo de autenticación, entonces la autenticación de la aplicación no funciona.

http://technet.microsoft.com/en-us/library/ee806870.aspx

o y

2) estás utilizando la autenticación de servidor a servidor, ¡aquí es donde podría estar yendo mal!¿Se ha sincronizado tu perfil?

para 2013, de servidor a servidor, asegúrese de que las membresías de grupo estén sincronizadas con la aplicación de servicio de perfil de usuario.

Si existe un perfil de usuario para un usuario y las membresías del grupo relevantes no están sincronizadas, se puede negar el acceso cuando se supone que el usuario se le otorga acceso a un recurso determinado.Por lo tanto, asegúrese de que las membresías del grupo estén sincronizadas con la aplicación de servicio de perfil de usuario.

http://technet.microsoft.com/en-us/library/jj219806.aspx

¡Ahora esto es necesario para que funcione la configuración de servidor a servidor!

La autenticación de servidor a servidor permite servidores que son capaces de autenticación de servidor a servidor para acceder y solicitar recursos entre sí en nombre de los usuarios.Por lo tanto, el servidor que ejecuta SharePoint Server 2013 y que atiende la solicitud de recursos entrantes debe poder completar dos tareas:

Para rehidratar la identidad de un usuario, un servidor que puede realizar la autenticación de servidor a servir solicita acceso a los recursos de SharePoint.SharePoint Server 2013 toma los reclamos del token de seguridad entrante y lo resuelve a un usuario específico de SharePoint.Por defecto, SharePoint Server 2013 utiliza la aplicación de servicio de perfil de usuario incorporada para resolver la identidad.

y el resultado de lo anterior es:

Si un perfil de usuario y las membresías del grupo relevantes para el usuario no están sincronizadas, SharePoint Server 2013 puede negar incorrectamente el acceso a un recurso determinado.Por lo tanto, asegúrese de que las membresías del grupo estén sincronizadas con la aplicación de servicio de perfil de usuario.Para los reclamos de Windows, la aplicación de servicio de perfil de usuario importa los cuatro atributos de usuario clave descritos anteriormente y las membresías del grupo.

http://technet.microsoft.com/en-us/library/jj729797.aspx

El punto es el token y la autenticación no funciona correctamente porque su configuración es incorrecta con el tipo de seguridad o la configuración.¡Saber lo que has hecho determinará dónde va mal!Claramente, parece que la autenticación de servidor a servidor se rechaza porque el token no se envía correctamente.

Si cree que el protocolo de autenticación es correcto, puede seguir esta guía una vez que haya leído los enlaces anteriores:

http://technet.microsoft.com/en-us/library/jj655400.aspx

El enlace anterior explica y demuestra los pasos de servidor a servidor para situaciones específicas.

para crear una confianza entre dos servidores (crea una confianza entre un servidor y el servidor principal).

¡sigue esta guía!usando New-SPTrustedSecurityTokenIssuer

http://technet.microsoft.com/en-us/library/jj219695.aspx

¡Perdón por el texto tan largo y muchos enlaces!Como es de servidor a servidor y el registro es genérico/configurado, ¡puedo darle una respuesta definitiva!¡Pero lo que sí sé es que el protocolo de enlace entre dos servidores va mal, lo que significa que te has perdido algo con la configuración inicial!Es de esperar que los enlaces anteriores resuelvan su problema entre el protocolo de enlace para pasar las credenciales correctas para que funcione correctamente.

Otros consejos

tuve problemas similares.En lugar de usar ClientContext o Tokenhelper, cambié al nuevo SharePointContext que puede leer aquí: http://blogs.msdn.com/b/kaevans/archive/2013/09/24/introduciendo-sharepointcontext-for-provider-hosted-SharePoint-Apps.aspx

Una vez que hice este interruptor, mis problemas 401 y 403 desaparecieron.El nuevo SharePointContext utiliza el tokenhelper subyacente, así que asegúrese de tener la última versión del archivo Tokenhelper también.

Creo que sé cuál era su problema, el registro del servidor apunta a la máquina cliente / servidor no tiene tiempo en sincronización. 

"SPApplicationAuthenticationModule: No valid access token exists in the Authorization header, you should see a 401 challenge as a response to this request."

"SPSecurityTokenExtensions: Not Valid Before:10/11/2013 21:15:38, Valid To:09/06/2015 07:55:38."

Me había enfrentado un error similar a un error similar, y la resolución era que el tiempo de máquina del servidor y el cliente estuviera en sincronización. 

Foundation  Application Authentication ajezq High SPApplicationAuthenticationModule: 
Error authenticating request, Error details: 
Header: 3000002;reason="The access token has expired.
It's valid from '4/29/2015 2:50:44 PM' and to '4/30/2015 2:50:44 AM'.";
category="invalid_client", Body: {"error_description":"Invalid JWT token. The token is not yet valid. 
Current time is 4\/29\/2015 10:44:25 AM and the token is Valid from 4\/29\/2015 2:50:44 PM."}

Cómo configurar el tiempo de la máquina en la sincronización con Internet

Licenciado bajo: CC-BY-SA con atribución
scroll top