O NTLM está sendo transportado para o Chrome. Consulte este . Apenas espere pela próxima versão.
Em uma resposta à Autenticação do Windows com o Google Chrome , é indicou que o Chrome ainda não é compatível com Autenticação NTLM Automática , o que significa que os usuários que estiverem se autenticando em sites usando a Autenticação do Windows serão solicitados a fazer login. Que é chato, mas não é um problema. Onde o problema reside é que a senha do usuário é enviada em texto não criptografado para o site de autenticação.
Eu peguei um rápido script ASP.NET que extrai a senha do AUTH_PASSWORD na coleção Request.ServerVariables. O Safari e o Opera solicitam credenciais de usuário, mas não enviam a senha em texto não criptografado no cabeçalho HTTP. Acho isso especialmente estranho, já que o Chrome, como o Safari, é baseado no WebKit.
Qual é a diferença entre o modo como o Chrome se autentica em comparação com outros navegadores e por que ele envia a senha para um site dessa maneira?
O NTLM está sendo transportado para o Chrome. Consulte este . Apenas espere pela próxima versão.
Uma possibilidade é que o chrome talvez não ofereça suporte ao NTLM, e o Chrome simplesmente retrocede à autenticação HTTP BASIC . Você consegue obter os cabeçalhos exatos em uso com o wireshark ou similar?
Em resposta ao seu comentário sobre a resposta de bdonlan:
I am guessing I won't be able to see the authentication because the site I am running against is using SSL.
A ferramenta proxy de arroto permite assistir (e até mesmo modificar) solicitações e respostas HTTP, e pode atuar como um proxy HTTPS também. (Pode ou não funcionar, dependendo de como o Chrome usa proxies HTTPS.)
Pelo que posso dizer via Wireshark, o Chrome suporta a autenticação NTLM. O que ele não suporta é o logon único, passando pelas suas credenciais existentes.
É por isso que o campo AUTH_PASSWORD está vazio.