Atualmente estou com problemas de autenticação em um site do SharePoint. Rotineiramente, as contas de usuário (apenas uma ou mais de cada vez) serão bloqueadas e receberão erros 401 não autorizados. A implementação do SharePoint está usando somente contas de usuários locais, tem SSL e autenticação NTLM. Não tenho certeza da configuração exata da rede (não sou o administrador da rede), mas um proxy pode estar envolvido. No momento em que o problema é investigado pelo administrador de rede, a conta está funcionando novamente. Tão intermitente também. Minhas perguntas para isso são:
1.) Alguém já se deparou com isso antes?
2.) Mudar para a autenticação básica resolveria isso? Há breves sussurros da mutilação do NTLM no WSS quando um proxy está envolvido.
3.) O SSL e IWA juntos são um pouco exagerados em primeiro lugar? Quero dizer, a senha e o login seriam enviados criptografados na autenticação básica com SSL, certo? E os benefícios da IWA em uma extranet não-domínio parecem inúteis para mim.
Seria bom verificar os arquivos de log do IIS, para ver se há um padrão - são recursos específicos que obtêm 401s ou são genéricos.
Um problema comum é que certos recursos podem estar em uma pasta de servidor (sistema de arquivos) e podem não estar acessíveis a todos os usuários. Esses recursos podem ser vinculados a partir de páginas específicas, portanto, os erros podem ser intermitentes. Lembre-se de que o SharePoint executa solicitações em um contexto representado por padrão.
If it was Kerberos I would expect to see a Negotiate (or am I assuming wrong?)
Negociar pode ser kerberos ou ntlm. ntlm definitivamente significa ntlm.
Para confirmar o método de autenticação usado, verifique o primeiro caractere do cabeçalho de autenticação. Se é um "T", é ntlm. Se é um "Y", é o kerberos.
Observe que você pode configurar o IIS para exigir o NTLM, mas não funciona ao contrário (requerer o kerberos). Seria legal embora.
O SSL não é excessivo se você precisar criptografar o conteúdo. O Kerberos sem SSL é seguro o suficiente para a autenticação, mas não criptografa o conteúdo.
O que você quer dizer com contas "locais"? Você tem um servidor sharepoint independente / não de domínio em uma extranet e os usuários fazem logon com contas que não são de domínio / locais?
Existem vários casos em que a autenticação NTLM é obtida por meio de proxies, embora eu espere que a maioria dos proxies tenha esse comportamento corrigido até agora.
Eu verificaria se o site do WSS está configurado como um site / intranet confiável e se as configurações do seu navegador são tais que a credencial de autenticação é transmitida automaticamente. Provavelmente seria útil se estivesse em um domínio, mas parece que não é o caso.
Você sempre pode voltar para a autenticação básica, mas certifique-se de usar SSL se estiver seguindo esse caminho.
Aqui está a coisa. Sharepoint usa representação. Isso significa que você NÃO deveria estar usando o NTLM - você deveria estar usando o Kerberos. Essa é uma distinção muito grande. NTLM não significa "Autenticação Integrada do Windows".
Então, aqui está o que você precisa fazer. Vá para o servidor Sharepoint no log de eventos de segurança. Lá, você deve ver que todos os seus usuários estão sendo autenticados usando "Kerberos", não "NTLMSSP". Se você ver que as pessoas estão recebendo acesso usando NTLM, isso provavelmente significa (eu diria 80% do tempo) que você precisa definir um Nome Principal de Serviço para o SharePoint. Se você estiver executando o seu site do SharePoint sob um alias, você precisará definir um nome principal de serviço para esse alias, porque o IE7 tem um bug em que ele solicita tickets para os SPNs incorretamente de forma intermitente.
Então, minhas três dicas são:
Tags authentication ssl sharepoint ntlm