Resumo

  • A RFC 3062 separou a troca de senha tanto da identidade em formato DN quanto da exigência de que o segredo estivesse em um atributo de uma entrada LDAP.
  • O servidor só podia responder com sucesso depois de efetuar a alteração e precisava preservar a senha em caso de falha; isso não comprova um login posterior nem a propagação para todos os serviços.

A senha podia estar em outro lugar

A operação Modify do LDAP altera atributos de uma entrada identificada. É uma solução direta quando o usuário tem um Nome Distinto (DN) e a senha está, por exemplo, no atributo userPassword. A integração com serviços externos de autenticação enfraqueceu essa premissa: uma identidade podia não ser um DN e a senha podia ser mantida fora do diretório. Alterar a entrada LDAP já não significava necessariamente mudar o segredo usado no login.

Kurt Zeilenga publicou a RFC 3062 em fevereiro de 2001 com uma operação diferente, em vez de tratar toda senha como atributo. Password Modify é uma operação estendida identificada pelo OID 1.3.6.1.4.1.4203.1.11.1. A solicitação pode incluir userIdentity, oldPasswd e newPasswd; os três campos são opcionais. O protocolo especifica como pedir a troca, não onde toda senha deve residir.

Identidade da sessão ou identificador explícito

Quando presente, userIdentity é uma sequência de octetos que pode ser um DN, mas não precisa ser. Se o campo for omitido, a operação se aplica ao usuário associado à sessão LDAP atual. O cliente pode usar a identidade já autenticada ou enviar uma representação que o servidor saiba resolver. Nenhuma das opções informa ao cliente onde a senha está guardada ou como o servidor liga essa identidade à credencial que controla.

Essa foi a mudança de arquitetura: o LDAP oferecia uma fronteira comum para o pedido, sem exigir que a senha fosse um atributo do diretório. O servidor poderia usar um atributo, outro armazenamento ou um serviço externo de autenticação. A RFC 3062 permite essas configurações; não descreve uma implementação específica nem afirma que todos os servidores resolvem identidades da mesma forma.

O alcance do sucesso

O servidor só pode indicar sucesso depois de alterar a senha. Caso contrário, deve mantê-la intacta e devolver um resultado de falha. Uma senha antiga fornecida incorretamente também não pode levar à mudança. Se o cliente não enviar newPasswd, o servidor deve gerar uma senha e devolvê-la em genPasswd quando concluir com sucesso, ou falhar. Quando oldPasswd não aparece, outra política do servidor pode decidir se autoriza a troca; administradores também podem restringir a operação.

Isso cria um ponto de confirmação útil: a resposta distingue a alteração concluída da tentativa que falhou. Mas não é um comprovante de autenticação ponta a ponta. Ela não demonstra que um Bind posterior terá sucesso, que todas as réplicas de um serviço externo receberam o novo valor, que o usuário recebeu com segurança a senha gerada ou que a identidade corresponde a uma pessoa real específica. Cada uma dessas afirmações exige evidência própria.

A descoberta varia conforme a sessão

A RFC recomenda que o servidor anuncie o OID no atributo supportedExtension do Root DSE e que clientes verifiquem esse suporte antes de tentar a operação. Há uma ressalva: o servidor pode anunciar a extensão somente quando o cliente estiver autorizado e/ou quando a proteção de segurança necessária tiver sido estabelecida. A descoberta da capacidade pode, portanto, depender da sessão. A ausência do OID numa resposta é evidência sobre aquele contexto, não uma afirmação eterna sobre todo principal ou caminho de acesso.

A operação não fornece privacidade nem integridade por si só. A RFC proíbe uso anônimo e exige proteção de confidencialidade, como TLS. A solicitação pode transportar a senha antiga e a nova, e a resposta pode devolver uma senha gerada. Não adianta alcançar um armazenamento remoto se o próprio caminho expõe a credencial.

A RFC 3062 definiu a operação estendida dentro do LDAPv3 de RFC 2251. Mais tarde, a RFC 4511 substituiu a RFC 2251 e descreveu o quadro geral de ExtendedRequest e ExtendedResponse. Essa evolução mostra onde extensões se encaixam no protocolo; não prova que um servidor específico implementou Password Modify nem que implementações distintas se comportem da mesma maneira.

O RFC Editor registra duas erratas verificadas: a errata 340 troca “where” por “were” no contexto histórico, e a 4899 insere vírgulas na sequência de campos ASN.1. A correção de pontuação torna a notação formal mais clara, mas não altera a separação entre identidade, diretório e armazenamento da senha.

A RFC 3062 permitiu ao LDAP levar uma solicitação de troca sem exigir que a senha estivesse numa entrada ou que a identidade fosse um DN. Ainda cabia ao servidor ligar a solicitação à autoridade que realmente controlava a credencial. A resposta do protocolo descrevia apenas o resultado prometido naquela fronteira.

Fontes