Коли ми помічаємо галочкою згаданий вище чекбокс, насправді в
дозволах на змінюваний / створюваний об'єкт AD виставляються дозволу Deny Delete Deny Delete Subtree для групи Everyone. Тепер неможливо випадково видалити об'єкт. Так що там випадково, навіть для того, щоб видалити його цілеспрямовано, доведеться попітніти:1) якщо у Вас стоїть RSAT, то потрібно буде включити в ADUC «Advanced Features», потім відкрити властивості об'єкта і зняти галочку, після чого його можна буде видалити
2) якщо RSAT немає, то доведеться так само знаходити обридлий нам об'єкт і правити дозволу на вкладці Security
За замовчуванням, коли створення об'єкта відбувається в новій консолі, ця опція включена, що добре. Однак для старих об'єктів, створених в старій консолі ADUC цього не відбувається, тому або потрібно бути обережним або просто пройтися скриптом по дереву і позначити всю цю справу, як "захищене від випадкового видалення";)
Доброго дня. Виявив невизначений термін: встановлена галка на цій опції в учетке з правами domain admins через 15-20 хв злітає. З «звичайними» обліковими записами в цьому плані норм.
Що це на Ваш погляд - баг; пов'язане з якимось функціоналом; або проблема в конкретному домені?
Облікові записи, що входять в групу Domain Admins.
У повідомленні з поступовим зниженням Вами посиланню, наскільки зрозумів, говориться про облікові записи, які входили в цю групу ( «сліди» цього перебування adminCount = 1, заборона на спадкування дозволів від батьківського об'єкта в домені).
Т.ч. виходить, що для всіх облікових записів, які прямо або побічно належать до захищених AdminSDHolder групам, неможливо включити опцію «Захисту об'єкта від випадкового видалення», SDProp раз на годину все одно це буде відключати.
Ну не те щоб неможливо, можна поміняти дозволу, що застосовуються SDProp. Питання, чи так це необхідно?
Вірно, з дозволами об'єкта AdminSDHolder можна погратися, але можна і «догратися».
Шкурка вичинки не варта (с)