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

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

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

Voici un début de liste d’attributs activés par défaut sur un domaine Windows 2008R2 + Exchange 2010.

Mise à jour :

Quelqu’un connaît-il un attribut Octet String qui n’expose pas les permissions de « lecture » à tous les utilisateurs du domaine par défaut ? Je ne veux pas stocker mon hash publiquement et permettre à quelqu’un de construire une table arc-en-ciel basée sur les hashes.

Le problème que rencontrent la plupart des gens lorsqu’ils stockent des données dans AD est :

L’extension du schéma (qui a souvent des implications politiques au sein de l’entreprise)

L’utilisation d’un attribut existant et la modification des permissions (ce qui entraîne un gonflement AD/ACL qui augmente votre DIT et la taille de réplication subséquente)

Il existe une alternative… le meilleur choix selon moi est d’utiliser cette fonctionnalité peu connue d’AD pour prendre un attribut existant et le marquer comme Confidentiel.

Voici les détails du processus :

Les permissions par défaut dans Active Directory sont telles que les utilisateurs authentifiés ont un accès en lecture global à 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 de 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 » comme common-name). Vous pouvez déterminer si un objet est un objet de schéma de base en utilisant LDP pour visualiser l’objet et vérifier l’attribut systemFlags de l’objet. Si le 10e bit est défini, c’est un objet de schéma de base.

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

Par défaut, seuls les administrateurs ont l’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 DSACLs, par script, ou avec la version R2 ADAM de LDP. Au moment de la rédaction, il n’est pas possible d’utiliser l’éditeur d’interface utilisateur ACL pour attribuer ces permissions.

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

Déterminer quel attribut marquer comme confidentiel, ou ajouter un attribut à marquer comme confidentiel.

Le marquer comme confidentiel.

Accorder aux utilisateurs appropriés le droit Control_Access pour qu’ils puissent visualiser l’attribut.

Pour plus de détails et des instructions étape par étape, veuillez vous référer à 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