¿Dónde guardo datos confidenciales en Active Directory?

Básicamente, estoy almacenando una clave privada (Hash) en cualquiera de los atributos de OctetString dentro de Active Directory.

Mi pregunta es, ¿qué atributo es seguro de forma predeterminada y tiene sentido mantener allí los datos privados? Este valor debe considerarse similar a una contraseña, donde incluso los administradores no deberían tener acceso (si es posible), al igual que la contraseña de AD actual.

Aquí hay un comienzo de una lista de atributos que están habilitados de manera predeterminada en un dominio de Windows 2008R2 + Exchange 2010.

Actualizar:

¿Alguien sabe de un atributo de cadena de octeto que no expone los permisos de "lectura" a todos los usuarios en el dominio de forma predeterminada? No quiero almacenar mi hash públicamente y permitir que alguien construya una tabla de arco iris basada en los hash.

El problema al que se enfrentan la mayoría de las personas al almacenar datos en AD es

• Ampliación del esquema (que a menudo tiene implicaciones políticas para la empresa)

• Usar un atributo existente y editar los permisos (lo que da como resultado una hinchazón AD / ACL que aumenta su DIT y el tamaño de replicación posterior)

Hay una alternativa ... la mejor opción en mi mente es usar esta característica menos conocida de AD para tomar un atributo existente y marcarlo como Confidencial.

Aquí hay detalles sobre el proceso

Los permisos predeterminados en Active Directory son tales que los usuarios autenticados tienen acceso de lectura general a todos los atributos. Esto dificulta la introducción de un nuevo atributo que debería estar protegido para que nadie lo lea.

Para mitigar esto, Windows 2003 SP1 presenta una forma de marcar un atributo como CONFIDENCIAL. Esta característica se logra modificando el valor de searchFlags en el atributo en el esquema. SearchFlags contiene múltiples bits que representan varias propiedades de un atributo. Por ejemplo, el bit 1 significa que el atributo está indexado. El nuevo bit 128 (séptimo bit) designa el atributo como confidencial.

Nota: no puede establecer este indicador en los atributos del esquema base (los derivados de "top", como el nombre común). Puede determinar si un objeto es un objeto de esquema base utilizando LDP para ver el objeto y verificar el atributo systemFlags del objeto. Si se establece el décimo bit, es un objeto de esquema base.

Cuando el servicio de directorio realiza una verificación de acceso de lectura, busca atributos confidenciales. Si lo hay, además del acceso READ_PROPERTY, el servicio de directorio también requerirá acceso CONTROL_ACCESS en el atributo o su conjunto de propiedades.

De forma predeterminada, solo los administradores tienen acceso CONTROL_ACCESS a todos los objetos. Por lo tanto, solo los administradores podrán leer atributos confidenciales. Los usuarios son libres de delegar este derecho a cualquier grupo específico que deseen. Esto se puede hacer con la herramienta DSACL, los scripts o la versión R2 ADAM de LDP. A partir de este escrito, no es posible utilizar el Editor de UI de ACL para asignar estos permisos.

El proceso de marcar un atributo como Confidencial y agregar los usuarios que necesitan ver el atributo tiene 3 Pasos

1. Determinar qué atributo marcar como confidencial o agregar un atributo para marcar como confidencial.

2. Marcarlo como confidencial

3. Otorgar a los usuarios correctos el derecho Control_Access para que puedan ver el atributo.

Para obtener más detalles e instrucciones paso a paso, consulte el siguiente artículo:

922836 Cómo marcar un atributo como confidencial en Windows Server 2003 Service Pack 1

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

Siempre puede extender Active Directory con un nuevo campo para este propósito.

Aquí hay un documento que incluye instrucciones sobre cómo agregar un nuevo atributo y limitar los permisos sobre el atributo.

Este valor debe considerarse similar a una contraseña, donde incluso los administradores no deberían tener acceso (si es posible), al igual que la contraseña de AD actual.

Esto no es correcto, ni siquiera está mal. La contraseña no está almacenada. El hash se almacena y los administradores de dominio pueden acceder a eso. De hecho, incluso puede configurar AD para almacenar la contraseña en un cifrado reversible si lo desea.

No hay nada de lo que pueda mantener a los administradores de dominio fuera, en AD. Si elimina derechos o incluso Denega, un administrador de dominio puede tomar posesión y agregarse nuevamente. Esto contrasta con el NDS de Novell, donde un administrador de una unidad organizativa podría bloquear irrevocablemente a los administradores de nivel superior.

Lo mejor que puede hacer es usar un atributo existente o nuevo y restringir el acceso. Puede mantener a los administradores fuera de él y puede habilitar la auditoría del atributo para que se registre cualquier cambio de acceso o permisos.