Hassas verileri Active Directory'de nerede saklayabilirim?

Aslında Active Directory içindeki OctetString özniteliklerinden herhangi birinde özel bir anahtar (Hash) saklıyorum.

Benim sorum, hangi özellik varsayılan olarak güvenlidir ve özel verileri orada tutmak mantıklıdır? Bu değer, geçerli AD Şifresi gibi, yöneticilerin bile (mümkünse) erişime sahip olmaması gereken bir şifreye benzer olarak düşünülmelidir.

Windows 2008R2 + Exchange 2010 etki alanında varsayılan olarak etkinleştirilen öznitelikler listesinin başlangıcı aşağıdadır.

Güncelleme:

Herkes varsayılan olarak alan adındaki tüm kullanıcılara "okuma" izinlerini göstermeyen bir Octet String özniteliğini biliyor mu? Karmamı herkese açık olarak saklamak ve birinin karmalara dayalı bir gökkuşağı masası oluşturmasına izin vermek istemiyorum.

AD'de veri depolarken çoğu insanın karşılaştığı sorun

• Şemayı genişletmek (genellikle şirket-politik sonuçları vardır)

• Varolan bir özniteliği kullanma ve izinleri düzenleme (DIT'inizi ve sonraki çoğaltma boyutunu artıran AD / ACL şişmesi ile sonuçlanır)

Bir alternatif var ... aklımdaki en iyi seçenek, daha az bilinen AD özelliğini mevcut bir özelliği almak ve Gizli olarak işaretlemek için kullanmaktır.

İşte süreçle ilgili ayrıntılar

Active Directory'deki varsayılan izinler, Kimliği Doğrulanmış Kullanıcıların tüm özniteliklere battaniye okuma erişimine sahip olacağı şekildedir. Bu, herkes tarafından okunmaktan korunması gereken yeni bir özellik eklemeyi zorlaştırır.

Bunu azaltmak için, Windows 2003 SP1 bir özniteliği GİZLİ olarak işaretlemenin bir yolunu sunar. Bu özellik, şemadaki öznitelikte searchFlags değerini değiştirerek elde edilir. SearchFlags, bir özelliğin çeşitli özelliklerini temsil eden birden fazla bit içerir. Örneğin bit 1, özelliğin dizine eklendiği anlamına gelir. Yeni bit 128 (7. bit) özelliği gizli olarak tanımlar.

Not: bu bayrağı temel şema özniteliklerine ayarlayamazsınız (ortak ad gibi "üst" öğeden türetilenler). Nesneyi görüntülemek için LDP kullanarak ve nesnenin systemFlags özniteliğini denetleyerek bir nesnenin temel şema nesnesi olup olmadığını belirleyebilirsiniz. 10. bit ayarlanmışsa, temel şema nesnesidir.

Dizin Hizmeti bir okuma erişim denetimi gerçekleştirdiğinde, gizli öznitelikleri denetler. Varsa, READ_PROPERTY erişimine ek olarak, Dizin Hizmeti öznitelikte veya özellik kümesinde CONTROL_ACCESS erişimi de gerektirir.

Varsayılan olarak, yalnızca Yöneticilerin tüm nesnelere CONTROL_ACCESS erişimi vardır. Böylece, yalnızca Yöneticiler gizli özellikleri okuyabilecektir. Kullanıcılar bu hakkı istedikleri herhangi bir gruba devredebilir. Bu, DSACL aracı, komut dosyası oluşturma veya LDP'nin R2 ADAM sürümü ile yapılabilir. Bu yazı itibariyle, bu izinleri atamak için ACL UI Düzenleyicisi'ni kullanmak mümkün değildir.

Bir özelliği Gizli olarak işaretleme ve özelliği görüntülemesi gereken kullanıcıları ekleme işlemi 3 Adımdan oluşur

1. Hangi özelliği Gizli olarak işaretleyeceğinizi belirleme veya Gizli olarak işaretlemek için bir özellik ekleme.

2. Gizli olarak işaretleme

3. Özniteliği görüntüleyebilmeleri için doğru kullanıcılara Control_Access hakkı verme.

Daha fazla ayrıntı ve adım adım talimatlar için lütfen aşağıdaki makaleye bakın:

922836 Windows Server 2003 Service Pack 1'de bir özniteliği gizli olarak işaretleme

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

Bu amaçla Active Directory'yi her zaman yeni bir alanla genişletebilirsiniz.

Yeni bir özellik ekleme ve özellik üzerindeki izinleri sınırlama ile ilgili talimatları içeren bir doküman .

Bu değer, geçerli AD Şifresi gibi, yöneticilerin bile (mümkünse) erişime sahip olmaması gereken bir şifreye benzer olarak düşünülmelidir.

Bu doğru değil, yanlış bile değil. Parola kaydedilmez. Karma saklanır ve etki alanı yöneticileri buna erişebilir. Aslında, AD'yi isterseniz, şifreyi tersine çevrilebilir bir şifrelemede saklayacak şekilde yapılandırabilirsiniz.

AD'de alan adı yöneticilerini dışında tutabileceğiniz hiçbir şey yoktur. Hakları kaldırır veya hatta Reddet, bir etki alanı yöneticisi sahiplik yapabilir ve kendilerini tekrar ekleyebilir. Bu, bir OU'nun yöneticisinin geri dönülmez bir şekilde daha üst düzey yöneticileri kilitleyebileceği Novell'in NDS'sinin aksine.

Yapabileceğiniz en iyi şey mevcut veya yeni bir özelliği kullanmak ve erişimi kısıtlamaktır. Yöneticileri bundan uzak tutabilir ve herhangi bir erişim veya izin değişikliğinin günlüğe kaydedilmesi için öznitelikte denetimi etkinleştirebilirsiniz.