Obtendo 401/403 no aplicativo High Trust para Sharepoint 2013

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

Pergunta

eu tenho isto Ambiente CloudShare consistindo em 3 máquinas:

  • Um para Sharepoint 2013 (é aqui que desenvolvo com o VS2012 instalado)
  • Outro para SQL Server 2012
  • E outro para Active Directory

Estou tentando criar um aplicativo básico de alta confiança para o Sharepoint 2013 usando o protocolo servidor para servidor.

Eu segui vários guias:

Quando executo o projeto (código de modelo padrão) do VS e confio no aplicativo, recebo uma exceção na seguinte linha:

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

em Padrão.aspx.cs

A exceção pode ser qualquer uma das seguintes:

O servidor remoto retornou um erro:(403) Proibido.

O servidor remoto retornou um erro:(401 não autorizado.

Tentei várias dicas de solução de problemas sem sorte.Não sou especialista em SP2013, então qualquer ajuda será apreciada.

Obrigado

ATUALIZAR

Aqui estão as entradas de log do ULS relacionadas à solicitação:http://pastie.org/pastes/8395956/text

Foi útil?

Solução

para simplificar, direi o óbvio!

o usuário não está autenticado e o recurso requer autenticação

isso me diz que há algo errado acontecendo com o tremor de mão (seu certificado não foi enviado ou está errado), como é um produto da Microsoft, o melhor lugar é dar uma olhada no msdn.

para deixar claro, leia isto:

A etapa a seguir é opcional.No entanto, recomendamos que você desenvolva e teste com HTTPS ativado.Desativar o HTTPS pode fazer com que você seja um desenvolvedor para perder certos problemas ao criar um aplicativo que ocorreria durante uma implantação de produção em que HTTPS é necessário.

agora você leu a nota, leia o problema que você está tendo!

O OAuth agora requer que o SharePoint execute HTTPS, não apenas para seu serviço mas também para o SharePoint 2013.Você receberá uma mensagem 403 (proibido) ao tentar fazer uma chamada para o SharePoint usando um teste certificado.

No computador onde você tem o SharePoint 2013 instalado, você pode ativar fora do requisito HTTPS durante o desenvolvimento usando o seguinte Cmdlets do Windows PowerShell.

então esse é o seu problema aí!para contornar isso durante o desenvolvimento, faça:

isso no PowerShell para teste/desenvolvimento:

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

quando terminar, devolva-o ao que estava!

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

agora eu também gostaria de observar:

Em um aplicativo de alta confiança, não há nenhum token de contexto, mesmo se você usar o appredirect.aspx arquivo.O token de contexto é específico para configurações que usam o ACS (Serviço de Controle de Acesso) do Windows Azure.No entanto, um O token de acesso ainda é necessário. Se você estiver usando um configuração, seu aplicativo Web precisa autenticar o usuário em da mesma forma que o SharePoint 2013 faz (ou seja, o aplicativo é responsável pela criação da parte de usuário do token de acesso).

você está usando a classe tokenhelper para obter o contexto do cliente?

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

também o que exatamente você está tentando fazer, pois pode precisar de mais permissões dependendo do que está fazendo!

Para acessar outras propriedades, talvez seja necessário solicitar permissões no host web.

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

espero que o texto acima responda à sua pergunta!você precisa ter certeza de que o procedimento acima foi feito corretamente para que funcione!

se isso ainda for um problema, então há algo errado com o guid emitido pelo vs2012, que é enviado automaticamente quando você pressiona F5, isso é definido em web.config nesta linha:

<add key="IssuerId"

altere o guia de maiúsculas para minúsculas:

de:

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

para 

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

obviamente seu guia será diferente do anterior;)

também gostaria de observar que você precisa de um certificado exclusivo para cada aplicativo individual!também certifique-se de que o guia seja igual ao guia do PowerShell usando Get-SPTrustedSecurityTokenIssuer deve ser igual ao web.config!

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

ATUALIZAR

Acabei de olhar seu arquivo de log!

para quebrar, está falhando imediatamente com a autenticação!qual método você está usando?ntlm?Kerbos?etc...

Isso é fundamental para saber como você configurou seu farm e autenticação!

agora pode haver vários problemas acontecendo aqui pela aparência dos erros!Recomendo que você leia os links abaixo!Eu recomendo fortemente que, depois de ler os links, se tudo estiver correto em sua configuração para executar New-SPTrustedSecurityTokenIssuer este exemplo pode ser encontrado no meu último link no final da página!isso pode resolver seu problema com a parte do token e o handshake correto entre dois servidores (validando um ao outro).

1) o token não está sendo enviado devido às configurações de segurança que não são compatíveis!

Se você estiver usando o modo de declarações do Windows para autenticação de usuário e o O aplicativo Web está configurado para usar somente a autenticação Kerberos sem voltar para NTLM como o protocolo de autenticação, em seguida, aplicativo A autenticação não funciona.

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

ou e

2) você está usando autenticação de servidor para servidor, é aqui que pode estar errado!seu perfil foi sincronizado??

para 2013, de servidor para servidor, certifique-se de que as associações de grupo estejam sincronizadas com o aplicativo de serviço de Perfil de Usuário.

Se existir um perfil de usuário para um usuário e as associações de grupo relevantes não estão sincronizados, o acesso pode ser negado quando o usuário é suposto ter acesso a um determinado recurso.Portanto, certifique-se de que as associações de grupo são sincronizadas com o serviço de Perfil de Usuário aplicação.

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

agora isso é necessário para que a configuração de servidor para servidor funcione!

A autenticação de servidor para servidor permite servidores capazes de autenticação de servidor para servidor para acessar e solicitar recursos de uns aos outros em nome dos usuários.Portanto, o servidor que é executado SharePoint Server 2013 e que atende à solicitação de recurso de entrada deve ser capaz de concluir duas tarefas:

Para reidratar a identidade de um usuário, um servidor que pode executar autenticação de servidor para servidor solicita acesso ao SharePoint Recursos.O SharePoint Server 2013 recebe as declarações da entrada token de segurança e resolve-o para um usuário específico do SharePoint.Por padrão, o SharePoint Server 2013 usa o serviço de Perfil de Usuário interno para resolver a identidade.

e o resultado do acima é:

Se um perfil de usuário e as associações de grupo relevantes para o usuário forem não sincronizado, SharePoint Server 2013 pode negar acesso incorretamente a um determinado recurso.Portanto, certifique-se de que as associações de grupo sejam sincronizado com o aplicativo de serviço de Perfil de Usuário.Para Windows declarações, o aplicativo de serviço de Perfil de Usuário importa os quatro usuários-chave atributos descritos anteriormente e associações de grupo.

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

o ponto é o token e a autenticação não está funcionando corretamente porque sua configuração está errada com o tipo ou configuração de segurança!saber o que você fez determinará onde está errado!claramente parece que a autenticação de servidor para servidor está sendo rejeitada porque o token não foi enviado corretamente.

Se você acredita que o protocolo de autenticação está correto, você pode seguir este guia depois de ler os links acima:

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

o link acima explica e demonstra as etapas de servidor para servidor para cenários específicos

para criar uma relação de confiança entre dois servidores (cria uma relação de confiança entre um servidor e o servidor principal).

siga este guia!usando New-SPTrustedSecurityTokenIssuer

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

desculpe pelo texto longo e muitos links!como é servidor para servidor e o log é genérico/configuração posso te dar uma resposta definitiva!mas o que eu sei é que o aperto de mão entre dois servidores está errado, o que significa que você perdeu algo na configuração inicial!Esperamos que os links acima resolvam seu problema entre o aperto de mão para passar as credenciais corretas para funcionar corretamente!

Outras dicas

Eu tive problemas semelhantes.Em vez de usar ClientContext ou TokenHelper, mudei para o novo SharePointContext, sobre o qual você pode ler aqui: http://blogs.msdn.com/b/kaevans/archive/2013/09/24/introduzindo-sharepointcontext-for-provider-hosted-sharepoint-apps.aspx

Depois que fiz essa mudança, meus problemas 401 e 403 desapareceram.O novo SharePointContext usa o TokenHelper subjacente, portanto, certifique-se de ter também a versão mais recente do arquivo TokenHelper.

Acho que sei qual era o seu problema, os pontos de log do servidor para a máquina cliente/servidor não estão sincronizando o tempo. 

"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."

Eu havia enfrentado um erro semelhante há alguns dias e a solução era fazer com que o servidor e a máquina cliente estivessem sincronizados. 

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."}

How to set the machine time in sync with the internet

Licenciado em: CC-BY-SA com atribuição
Não afiliado a sharepoint.stackexchange
scroll top