Onde armazeno dados confidenciais no Active Directory?

Essencialmente, estou 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, na qual 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 habilitados por padrão em um domínio do Windows 2008R2 + Exchange 2010.

Atualizar:

Alguém conhece um atributo Octet String que não expõe permissões de "leitura" a todos os usuários no domínio por padrão? Não quero armazenar meu hash publicamente e permitir que alguém construa uma tabela arco-íris com base nos hashes.

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 inchaço AD / ACL que aumenta a DIT e o tamanho da replicação subsequente)

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

Aqui estão os detalhes sobre o processo

As permissões padrão no Active Directory são tais que 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 contra leitura por todos.

Para atenuar isso, o Windows 2003 SP1 apresenta uma maneira de marcar um atributo como CONFIDENCIAL. Esse recurso foi conseguido modificando o valor searchFlags no atributo no esquema. SearchFlags contém vários bits que representam várias propriedades de um atributo. Por exemplo, o 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 nome comum). Você pode determinar se um objeto é um objeto de esquema base usando o LDP para visualizar o objeto e verificando o atributo systemFlags do objeto. Se o décimo bit estiver definido, é um objeto de esquema base.

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

Por padrão, apenas os Administradores têm acesso CONTROL_ACCESS a todos os objetos. Assim, apenas os administradores poderão ler atributos confidenciais. Os usuários podem delegar esse direito a qualquer grupo específico que desejarem. Isso pode ser feito com a ferramenta DSACLs, com scripts ou com a versão R2 ADAM do LDP. No momento da redação deste texto, não é possível usar o Editor da interface do usuário da ACL para atribuir essas permissões.

O processo de marcar um atributo como Confidencial e adicionar os usuários que precisam visualizar o atributo possui 3 etapas

1. Determinando qual atributo marcar Confidencial ou adicionando um atributo para marcar Confidencial.

2. Como confidencial

3. Concedendo aos usuários corretos o Control_Access certo para que eles possam visualizar 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

http://support.microsoft.com/default.aspx?scid=kb;EN-US;922836

Você sempre pode estender o Active Directory com um novo campo para esse fim.

Aqui está um documento que inclui instruções sobre como adicionar um novo atributo e limitar as permissões no atributo.

Esse valor deve ser considerado semelhante a uma senha, na qual mesmo os administradores não devem ter acesso (se possível), assim como a senha atual do AD.

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

Não há nada que você possa manter os administradores de domínio fora do AD. Se você remover direitos ou até Negar, um administrador de domínio poderá se apropriar e se recompor. Isso contrasta com o NDS da Novell, onde um administrador de uma UO pode irrevogavelmente bloquear administradores de nível superior.

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