O cliente ldap deve usar credenciais diferentes do usuário final para fazer a autenticação do usuário final?

Question

forma resumida: Devo usar algum uid bem conhecido para autenticar um cliente ldap e, em seguida, outros meios dentro desse cliente para validar o uid e o pw inseridos pelo usuário?

forma longa: Temos um produto da Web comercial baseado em .net que é implementado em muitos sites de clientes e atualmente usa a autenticação interna do usuário.

Estou investigando o uso do LDAP para autenticação em um diretório. Como o nosso produto é implementado em vários ambientes, quero que ele seja compatível com o espectro mais amplo possível de serviços e configurações de diretório compatíveis com LDAP, incluindo, entre outros, o Active Directory.

Além da autenticação, desejo usar uma propriedade de diretório do usuário para determinar se eles estão autorizados a usar o aplicativo. Espero que isso seja indicado pela associação do usuário em um grupo específico. O nome do grupo será um ponto de configuração do aplicativo.

O serviço de diretório é usado apenas para confirmar a associação de usuário, pw e grupo. O aplicativo NÃO assumirá a identidade do usuário ao processar solicitações subseqüentes do usuário. Portanto, não há FormsAuthenticationTicket.

Uma das minhas primeiras perguntas vem dos exemplos de autenticação que analisei, como o link e link . Eles usam o ID e a senha inseridos pelo usuário para autenticar o cliente LDAP. Isso é razoável, suponho, mas no meu caso o cliente continuará fazendo outras pesquisas LDAP para confirmar a associação ao grupo. Preciso preocupar-me com o fato de o usuário final não ter privilégios de diretório suficientes para fazer uma verificação de associação? Parece-me que seria uma prática melhor usar credenciais reservadas para a autenticação de cliente ldap e, por algum outro meio, confirmar o uid / pw inserido pelo usuário. Ou, talvez, vincular duas vezes, uma vez com as credenciais do usuário para autenticá-las e, em segundo lugar, com credenciais internas para fazer a pesquisa. Devo fazer isso, ou estou apenas tornando as coisas mais difíceis do que precisam ser?

    

Answer 1

O princípio do menor privilégio se aplica aqui. A conta que você usa para vincular-se ao LDAP e enumerar usuários, grupos e qualquer outra informação pertinente deve ser definitivamente uma "conta de serviço" e não uma conta de um humano real .

Existem permissões diferentes necessárias para esta conta em comparação com a maioria dos usuários humanos. O assistente do vice-presidente não precisa ser capaz de enumerar todos os grupos e ver se uma determinada conta existe, mas a conta que você usa para vincular ao LDAP precisa disso.

    

Answer 2

Se você usa uma conta do sistema para conceder privilégios que suas contas de usuário regulares não têm, você tem um escalonamento de privilégios. (No seu exemplo, os usuários do seu aplicativo podem ver associações de grupo que não podem ver por conta própria.) Tudo bem, mas esteja ciente de que qualquer escalação de privilégios tem potencial para abusos.

Pessoalmente, prefiro escrever minhas ACLs de modo que as contas de usuários tenham quaisquer privilégios necessários e usar meu servidor LDAP (em vez de meu aplicativo downstream) para gerenciar o acesso. Por que suas contas de usuário não podem ver a quais grupos eles pertencem?

Quanto ao "privilégio mínimo", isso significa usar as credenciais do usuário, porque ele já tem acesso a elas. Se você usa uma conta de sistema compartilhada, isso é - por padrão - privilégios adicionais que usuários comuns não têm.