Où puis-je stocker des données sensibles dans Active Directory?

Je stocke essentiellement une clé privée (Hash) dans l'un des attributs OctetString dans Active Directory.

Ma question est, quel attribut est sécurisé par défaut et est-il logique de conserver les données privées là-bas? Cette valeur doit être considérée comme similaire à un mot de passe, où même les administrateurs ne devraient pas avoir accès (si possible), tout comme le mot de passe AD actuel.

Voici le début d'une liste d'attributs qui sont activés par défaut sur un domaine Windows 2008R2 + Exchange 2010.

Mettre à jour:

Quelqu'un connaît-il un attribut de chaîne d'octets qui n'expose pas les autorisations de «lecture» à tous les utilisateurs du domaine par défaut? Je ne veux pas stocker mon hachage publiquement et permettre à quelqu'un de construire une table arc-en-ciel basée sur les hachages.

Le problème auquel la plupart des gens sont confrontés lors du stockage de données dans AD est

• Extension du schéma (qui a souvent des implications politiques pour l'entreprise)

• Utilisation d'un attribut existant et modification des autorisations (ce qui entraîne un gonflement AD / ACL qui augmente votre DIT et la taille de réplication ultérieure)

Il existe une alternative ... le meilleur choix dans mon esprit est d'utiliser cette fonctionnalité moins connue d'AD pour prendre un attribut existant et le marquer comme confidentiel.

Voici les détails du processus

Les autorisations par défaut dans Active Directory sont telles que les utilisateurs authentifiés ont un accès en lecture générale à tous les attributs. Cela rend difficile l'introduction d'un nouvel attribut qui devrait être protégé contre la lecture par tout le monde.

Pour atténuer cela, Windows 2003 SP1 introduit un moyen de marquer un attribut comme CONFIDENTIEL. Cette fonctionnalité est obtenue en modifiant la valeur searchFlags sur l'attribut dans le schéma. SearchFlags contient plusieurs bits représentant diverses propriétés d'un attribut. Par exemple, le bit 1 signifie que l'attribut est indexé. Le nouveau bit 128 (7e bit) désigne l'attribut comme confidentiel.

Remarque: vous ne pouvez pas définir cet indicateur sur les attributs de schéma de base (ceux dérivés de "top" tels que le nom commun). Vous pouvez déterminer si un objet est un objet de schéma de base en utilisant LDP pour afficher l'objet et en vérifiant l'attribut systemFlags de l'objet. Si le 10e bit est défini, il s'agit d'un objet de schéma de base.

Lorsque le service d'annuaire effectue une vérification d'accès en lecture, il recherche les attributs confidentiels. S'il y en a, en plus de l'accès READ_PROPERTY, le service d'annuaire aura également besoin d'un accès CONTROL_ACCESS sur l'attribut ou son ensemble de propriétés.

Par défaut, seuls les administrateurs ont un accès CONTROL_ACCESS à tous les objets. Ainsi, seuls les administrateurs pourront lire les attributs confidentiels. Les utilisateurs sont libres de déléguer ce droit à tout groupe spécifique de leur choix. Cela peut être fait avec l'outil DSACL, les scripts ou la version R2 ADAM de LDP. À ce jour, il n'est pas possible d'utiliser ACL UI Editor pour attribuer ces autorisations.

Le processus de marquage d'un attribut comme confidentiel et d'ajout des utilisateurs qui doivent afficher l'attribut comporte 3 étapes

1. Déterminer quel attribut marquer comme confidentiel ou ajouter un attribut pour marquer confidentiel.

2. Marquage confidentiel

3. Accorder aux utilisateurs appropriés le droit Control_Access afin qu'ils puissent afficher l'attribut.

Pour plus de détails et des instructions pas à pas, reportez-vous à l'article suivant:

922836 comment marquer un attribut comme confidentiel dans Windows Server 2003 Service Pack 1

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

Vous pouvez toujours étendre Active Directory avec un nouveau champ à cet effet.

Voici un document qui comprend des instructions sur l'ajout d'un nouvel attribut et la limitation des autorisations sur l'attribut.

Cette valeur doit être considérée comme similaire à un mot de passe, où même les administrateurs ne devraient pas avoir accès (si possible), tout comme le mot de passe AD actuel.

Ce n'est pas correct, ce n'est même pas faux. Le mot de passe n'est pas enregistré. Le hachage est stocké et les administrateurs de domaine peuvent y accéder. En fait, vous pouvez même configurer AD pour stocker le mot de passe dans un cryptage réversible si vous le souhaitez.

Il n'y a rien que vous puissiez empêcher les administrateurs de domaine, dans AD. Si vous supprimez des droits ou même refusez, un administrateur de domaine peut s'approprier et se rajouter. Ceci est en contraste avec le NDS de Novell, où un administrateur d'une unité d'organisation pourrait verrouiller irrévocablement les administrateurs de niveau supérieur.

Le mieux que vous puissiez faire est d'utiliser un attribut existant ou nouveau et de restreindre l'accès. Vous pouvez empêcher les administrateurs d'y accéder et vous pouvez activer l'audit sur l'attribut afin que toute modification d'accès ou d'autorisations soit enregistrée.