O SSTP autentica primeiro o servidor e depois o usuário

Um cliente SSTP pode concluir o TLS e ainda rejeitar o usuário um segundo depois. Essa sequência não é um bug, é a pilha de protocolos: primeiro a segurança do transporte, depois a autenticação do usuário. Como as duas etapas falham com mensagens diferentes, também exigem correções diferentes. Ler qual etapa produziu o erro é a maior parte do diagnóstico.

Um certificado confiável prova o endpoint; não diz nada sobre a conta.

O que o handshake TLS estabelece

O cliente valida o certificado apresentado pelo servidor contra seu repositório de confiança, o nome de host solicitado, a janela de validade e qualquer política adicional aplicada pela plataforma. Isso protege a conexão com o endpoint pretendido. Não prova que determinada conta esteja habilitada, não expirada ou autorizada ao acesso remoto. São perguntas separadas feitas mais tarde por outro componente.

Por isso, remover as verificações de certificado para chegar ao prompt de login é a correção errada. Você obtém um prompt de login numa conexão que não consegue verificar. Um erro de certificado pertence ao nome de host, ao relógio, à cadeia ou à configuração de confiança.

O que o SSTP e o PPP acrescentam

O SSTP funciona sobre HTTPS e carrega PPP dentro, com sua própria troca de controle em torno da conexão. O PPP então executa suas fases de enlace e autenticação, e o método de autenticação depende da política do servidor e da capacidade do cliente. PAP, CHAP, MS-CHAPv2 e EAP são todas opções de autenticação PPP com propriedades muito diferentes. A verificação de usuário da VPN é essa fase PPP, não a camada TLS por baixo.

Uma rejeição de usuário pode, portanto, significar credenciais, uma restrição de conta ou uma incompatibilidade de método.

O motivo do lado do servidor é muito mais útil do que redefinir cada segredo do perfil. Um evento de conta desabilitada e uma falha de negociação de método parecem semelhantes no cliente e não têm nada em comum no servidor.

Associe o erro à etapa

Verifique se a conexão chega ao TLS, depois à troca HTTP do SSTP e depois à fase PPP. Mantenha os carimbos de tempo dos logs alinhados entre tentativas para que uma falha anterior não seja confundida com um sucesso posterior. Um cliente que registra duas tentativas numa janela, de outra forma, parecerá ter falhado na última etapa alcançada. Leia o primeiro erro relevante, não a última linha.

O mesmo alinhamento importa no lado do servidor, onde o registro de autenticação e o log de transporte costumam ser arquivos separados com relógios separados. Dois minutos de desvio bastam para fazer uma causa óbvia parecer impossível.

Depois do login, a autorização continua separada

Um login bem-sucedido não concede todos os recursos privados. As rotas determinam o que é alcançável, o DNS determina o que é resolvido, e cada serviço ainda aplica suas próprias permissões. Uma sessão exibida como conectada é uma afirmação sobre o túnel, não sobre o compartilhamento de arquivos. Quando um usuário consegue conectar e não consegue alcançar um host, a fase do túnel já terminou.

É a mesma estratificação que o handshake mostrou, um nível acima.

Mantenha a recuperação da conta no processo suportado pelo operador em vez de alterar as configurações de transporte em resposta a uma negação explícita do usuário. Alterar o transporte para corrigir uma conta desabilitada é o tipo de reparo que parece funcionar quando a conta é reabilitada por um motivo não relacionado.