Active Directory内の機密データはどこに保存しますか？
私は基本的に、Active Directory内のOctetString属性のいずれかに秘密キー（ハッシュ）を格納しています。
私の質問は、どの属性がデフォルトで安全であり、そこにプライベートデータを保持するのが理にかなっているのですか？この値は、現在のADパスワードと同様に、管理者でさえも（可能であれば）アクセスできないようにするパスワードと同様に考える必要があります。
以下は、Windows 2008R2 + Exchange 2010ドメインでデフォルトで有効になっている属性のリストの始まりです。
更新：
デフォルトでドメイン内のすべてのユーザーに「読み取り」権限を公開しないオクテット文字列属性を知っている人はいますか？私はハッシュを公開しないで、ハッシュに基づいて誰かがRainbowテーブルを作成できるようにしたくありません。
ADにデータを保存するときにほとんどの人が直面する問題は
スキーマの拡張（これは多くの場合、会社の政治に影響を与えます）
既存の属性を使用してアクセス許可を編集する（これにより、DITとその後のレプリケーションサイズが増加するAD/ACLの膨張が発生します）
代替案があります...私の心の中での最良の選択は、ADのこのあまり知られていない機能を使用して既存の属性を取得し、それを機密としてフラグを立てることです。
ここにプロセスの詳細があります
Active Directoryのデフォルトのアクセス許可では、認証されたユーザーがすべての属性への一括読み取りアクセス権を持っています。これは、誰もが読まないように保護する必要がある新しい属性を導入することを困難にします。
これを軽減するために、Windows 2003 SP1では、属性を機密としてマークする方法が導入されています。この機能は、スキーマの属性のsearchFlags値を変更することによって実現されました。 SearchFlagsには、属性のさまざまなプロパティを表す複数のビットが含まれています。例えば。ビット1は、属性にインデックスが付けられていることを意味します。新しいビット128（7番目のビット）は、属性を機密として指定します。
注：このフラグは、base-schema属性（common-nameなどの「top」から派生したもの）には設定できません。 LDPを使用してオブジェクトを表示し、オブジェクトのsystemFlags属性を確認することで、オブジェクトが基本スキーマオブジェクトであるかどうかを確認できます。 10番目のビットが設定されている場合、それは基本スキーマオブジェクトです。
ディレクトリサービスは、読み取りアクセスチェックを実行するときに、機密属性をチェックします。存在する場合、READ_PROPERTYアクセスに加えて、ディレクトリサービスは属性またはそのプロパティセットに対するCONTROL_ACCESSアクセスも必要とします。
デフォルトでは、管理者のみがすべてのオブジェクトへのCONTROL_ACCESSアクセス権を持っています。したがって、管理者だけが機密属性を読み取ることができます。ユーザーは、この権利を任意の特定のグループに自由に委任できます。これは、DSACLツール、スクリプト、またはLDPのR2 ADAMバージョンで実行できます。これを書いている時点では、ACL UIエディターを使用してこれらの権限を割り当てることはできません。
属性を機密としてマークし、属性を表示する必要があるユーザーを追加するプロセスには、3つのステップがあります。
機密としてマークする属性の決定、または機密としてマークする属性の追加。
機密としてマークする
適切なユーザーにControl_Access権限を付与して、属性を表示できるようにします。
詳細と手順については、次の記事を参照してください。
922836 Windows Server 2003 Service Pack 1で属性を機密としてマークする方法
http://support.Microsoft.com/default.aspx?scid=kb;EN-US;922836
この目的のために、常に新しいフィールドでActive Directoryを拡張できます。
これは document で、新しい属性の追加と属性へのアクセス許可の制限に関する指示が含まれています。
この値は、現在のADパスワードと同様に、管理者でさえも（可能であれば）アクセスできないようにするパスワードと同様に考える必要があります。
これは正しくありません、それも間違っていません。パスワードは保存されません。ハッシュは保存され、ドメイン管理者はそれにアクセスできます。実際、必要に応じて、パスワードを可逆暗号化で保存するようにADを構成することもできます。
ADでは、ドメイン管理者を除外することはできません。権限を削除するか、さらには拒否すると、ドメイン管理者が所有権を取得して自分自身を追加し直すことができます。これは、OUの管理者が上位レベルの管理者を完全にロックアウトできるNovellのNDSとは対照的です。
最善の方法は、既存の属性または新しい属性を使用して、アクセスを制限することです。管理者を除外し、属性の監査を有効にして、アクセスや権限の変更がログに記録されるようにすることができます。