Onde armazeno dados confidenciais no Active Directory?

Question

Estou essencialmente armazenando uma chave privada (Hash) em qualquer um dos atributos OctetString no Active Directory.

Minha pergunta é: qual atributo é seguro por padrão e faz sentido manter os dados privados lá? Esse valor deve ser considerado semelhante a uma senha, onde até mesmo os administradores não devem ter acesso (se possível), assim como a senha atual do AD.

Aqui está o início de uma lista de atributos que estão ativados por padrão em um domínio do Windows 2008R2 + Exchange 2010.

Atualização:

Alguémsabedeumatributodeseqüênciadecaracteresdeoctetoquenãoexponhapermissõesde"leitura" para todos os usuários no domínio por padrão? Eu não quero armazenar meu hash publicamente e permitir que alguém construa uma tabela de arco-íris baseada nos hashes.

    

Answer 1

O problema que a maioria das pessoas enfrenta ao armazenar dados no AD é

• Estendendo o esquema (que geralmente tem implicações políticas na empresa)

• Usando um atributo existente e editando as permissões (o que resulta em um aumento de volume do AD / ACL que aumenta seu DIT e o tamanho de replicação subsequente)

Existe uma alternativa ... a melhor opção na minha mente é usar esse recurso menos conhecido do AD para pegar um atributo existente e marcá-lo como Confidencial.

Aqui estão detalhes sobre o processo

As permissões padrão no Active Directory são tais que os Usuários Autenticados têm acesso de leitura geral a todos os atributos. Isso dificulta a introdução de um novo atributo que deve ser protegido de ser lido por todos.

Para atenuar isso, o Windows 2003 SP1 introduz uma maneira de marcar um atributo como CONFIDENCIAL. Esse recurso obtido modificando o valor searchFlags no atributo no esquema. SearchFlags contém vários bits representando várias propriedades de um atributo. Por exemplo. bit 1 significa que o atributo está indexado. O novo bit 128 (7º bit) designa o atributo como confidencial.

Nota: você não pode definir esse sinalizador nos atributos do esquema base (aqueles derivados de "top", como common-name). Você pode determinar se um objeto é um objeto de esquema base usando LDP para exibir o objeto e verificar o atributo systemFlags do objeto. Se o 10º bit estiver definido, é um objeto de esquema base.

Quando o serviço de diretório executa uma verificação de acesso de leitura, ele verifica se há atributos confidenciais. Se houver, além do acesso READ_PROPERTY, o Serviço de Diretório também exigirá o acesso CONTROL_ACCESS no atributo ou em seu conjunto de propriedades.

Por padrão, somente os administradores têm acesso CONTROL_ACCESS a todos os objetos. Assim, somente administradores poderão ler atributos confidenciais. Os usuários são livres para delegar esse direito a qualquer grupo específico que desejarem. Isso pode ser feito com a ferramenta DSACLs, scripts ou a versão R2 do ADAM do LDP. A partir desta redação, não é possível usar o ACL UI Editor para atribuir essas permissões.

O processo de marcar um atributo Confidential e adicionar os usuários que precisam visualizar o atributo tem 3 etapas

1. Determinar qual atributo marcar como Confidencial ou adicionar um atributo para marcar Confidencial.

2. Marcando como confidencial

3. Conceder aos usuários corretos o Control_Access para que eles possam ver o atributo.

Para mais detalhes e instruções passo a passo, consulte o seguinte artigo:

922836 Como marcar um atributo como confidencial no Windows Server 2003 Service Pack 1

link

    

Answer 2

Você sempre pode estender o Active Directory com um novo campo para essa finalidade.

Este é um documento que inclui instruções sobre como adicionar um novo atributo e limitar as permissões no atributo.

    

Answer 3

This value should be considered similar to a password, where even administrators shouldn't have access (if possible), just like the current AD Password.

Isso não está correto, não está errado. A senha não está armazenada. O hash é armazenado e os administradores de domínio podem acessá-lo. Na verdade, você pode até configurar o AD para armazenar a senha em uma criptografia reversível, se quiser.

Não há nada em que você possa manter os administradores de domínio no AD. Se você remover direitos ou mesmo Negar, um administrador de domínio poderá se apropriar e se incluir novamente. Isso está em contraste com o NDS da Novell, em que um administrador de uma unidade organizacional pode bloquear de forma irrevogável administradores de nível superior.

O melhor que você pode fazer é usar um atributo novo ou existente e restringir o acesso. Você pode manter os administradores fora dele, e você pode ativar a auditoria no atributo para que qualquer alteração de acesso ou permissões seja registrada.