Acesso ao serviço da Web falha quando a senha do usuário está no período de notificação

Question

Temos vários aplicativos .Net instalados localmente que se comunicam por meio de serviços da web. A autenticação no IIS é tratada pela Autenticação do Windows, portanto, nenhum login adicional é necessário. Recentemente, começamos a ver um problema em que os usuários estão recebendo um bug do IIS 403 proibido quando sua redefinição de senha está dentro do período de notificação de expiração de senha (7 dias no momento).

Como isso às vezes acontece no meio do dia (faça o login de manhã OK, mas a senha alcança < 7 dias durante o dia), isso é uma surpresa, pois não foram avisados para alterar sua senha. É claro, eu esperaria que eles pudessem funcionar até que a senha expirasse.

Alguma idéia do que poderia estar acontecendo aqui? Por que o IIS rejeitaria um login se a senha não tivesse expirado? Podemos mudar esse comportamento?

Obrigado

\\ Greg

    

Answer 1

Você provavelmente verá o erro 403.18 em seus registros da web. Você tem uma página de erro configurada para ser executada a partir de um pool de aplicativos diferente? Dê uma olhada aqui: link

e aqui (que descreve um problema muito semelhante): link

    

Answer 2

Dado o quão difícil isso foi para resolver, eu quero responder a minha pergunta com o resultado final.

O problema tem a ver com as notificações do IIS e PasswordChange. Em todos os servidores, removemos o / IISpwdadm. Esta é a capacidade que o IIS cria para permitir que usuários interativos mudem sua senha.

Aparentemente, quando a senha de nossos usuários entrou em período de notificação, o serviço da Web tentava redirecioná-los para /iispwdadm/anot.asp. Como isso está fora do caminho do serviço da Web e em um pool de aplicativos diferente, o erro 403 foi gerado.

A solução foi usar o adsutil para alterar a configuração changepasswordflags para 6, que desabilitava as notificações e a funcionalidade de alteração de senha do IIS.

cscript adsutil.vbs set w3svc/passwordchangeflags 6
cscript adsutil.vbs set w3svc/1/passwordchangeflags 6

Uma outra observação, nossos serviços da Web estão em um pool por trás de um BigIP. Todos esses redirecionamentos foram canalizados para um único servidor no pool, pois o endereço de origem era o endereço do pool. Isso fez com que encontrar os eventos 403 nos logs fosse um pouco complicado.

Obrigado novamente a DmitryK por nos direcionar para o caminho certo.