Я доверяю не политике - она просто запускает скрипт. Я доверяю скрипту, который пишет лог.
Про ивент состояние не думал, но очевидно, чтобы его было удобно отслеживать и как-то им оперировать - логи должны централизовано собираться и храниться. Хотя вариант - потенциально интересный.
Отслеживание выполнения - по логам в шаре. Или их отсутствию.
Наиболее точный ответ на вопрос, почему я не реализовал концепцию, которую вы описали: потому что она не пришла мне в голову :)
Не уверен, что до конца её понял, но меня смущает как минимум следующее: для каждого компа нужно создавать отдельную политику, которая будет закидывать группу PCname-admins на конкретный комп через таргетинг. Даже если это делается не руками, то открывая оснастку gpmc.msc - я не хочу видеть сотню однотипных политик.
В остальном, не готов вникать в детали вашей концепции и обсуждать её достоинства и недостатки. Допускаю, что она вполне рабочая.
Пробежался быстро по документу, на который вы дали ссылку. Честно говоря, не понял в каком месте написано, что администрировать рабочие станции через группу Domain Admins плохая практика. А как лучше?
Насколько я знаю, бест практикс от Microsoft = группа Domain Admins остается, но операции, требующие повышенных привелегий, запускаются техподдержкой через LAPS.
На счет отключения \ удаления шедулера ответил выше - решается в значительной степени не постоянным шедулером, а мгновенным. Хотя риски и уязвимости в этой схеме, безусловно - остаются. Но тут, кажется, ничего не поделать. Выдая пользователю права админа - можно лишь принять эти риски и смести их к минимуму)
Вы правы, что если используется "постоянный" шедулер, то пользователь с правами админа - может его отключить \ удалить.
Поэтому у нас используется мгновенный шедулер (Immediate Task). Его отличие от постоянного в том, что он не висит в списке планировщика постоянно. В момент обновления GPO (фоновый режим), политика создает задачу, запускает её и сразу после выполнения - удаляет. Это занимает секунды, если не доли. Таким образом, у пользователя нет особо возможности что-то сделать с ней.
LAPS нам приглянулся и мы его используем - просто не в этом сценарии)
Есть операции, которые должны выполнять разработчики на корпоративных ноутбуках, которые мы выдаем и которые требуют админских прав. Не буду вдаваться в детали зачем - просто примем это как факт.
Наша развилка: 1. Они будут делать под своей доменной учеткой, которой мы выдадим админские права 2. Мы будем как-то делегировать им возможность смотреть пароль встроенной учетки админа через LAPS
Оба сценария дают больше прав, чем мы бы хотели и создают какие-то риски (запустить что-то от имени SYSTEM через шедулер, вывести ноут из домена и т.д.), но вариант 1 - проще в эксплуатации. От рисков совсем не уйти и для их минимизации - нужны дополнительные инструменты.
Мы просто в какой-то момент приняли решение, что некоторым сотрудникам права админа выдаем и дальше надо систематизировать этот процесс.
Let's Encrypt действительно, дает помимо конечного, ещё рутовый + мидл в отдельном файле. Но с коммерческими не так, насколько я мог заметить. По крайней мере нам, сертификат выпущенный через Global Sign - приходит без полной цепочки
Да, видел новость, что их отключают, но ещё буквально несколько дней назад - мне удавалось получить описанным выше способом полную цепочку сертификата, выпущенного через Let's Encrypt
Я доверяю не политике - она просто запускает скрипт. Я доверяю скрипту, который пишет лог.
Про ивент состояние не думал, но очевидно, чтобы его было удобно отслеживать и как-то им оперировать - логи должны централизовано собираться и храниться. Хотя вариант - потенциально интересный.
Отслеживание выполнения - по логам в шаре. Или их отсутствию.
Наиболее точный ответ на вопрос, почему я не реализовал концепцию, которую вы описали: потому что она не пришла мне в голову :)
Не уверен, что до конца её понял, но меня смущает как минимум следующее: для каждого компа нужно создавать отдельную политику, которая будет закидывать группу PCname-admins на конкретный комп через таргетинг. Даже если это делается не руками, то открывая оснастку gpmc.msc - я не хочу видеть сотню однотипных политик.
В остальном, не готов вникать в детали вашей концепции и обсуждать её достоинства и недостатки. Допускаю, что она вполне рабочая.
Разработчики штатные. Доменные админы - не логинились.
Возможно, в обозримом будущем) Пока что - как есть)
Да, тут нагляднее - спасибо)
Суть сводится к созданию отдельных групп администрирования для каждого тира \ яруса (DC \ Server \ Workstation).
Надо сказать, никогда не сталкивался с подобным разделением даже в очень крупных enterprice - средах. Но в любом случае - задуматься стоит, да.
Вы поняли правильно.
Пробежался быстро по документу, на который вы дали ссылку. Честно говоря, не понял в каком месте написано, что администрировать рабочие станции через группу Domain Admins плохая практика. А как лучше?
Насколько я знаю, бест практикс от Microsoft = группа Domain Admins остается, но операции, требующие повышенных привелегий, запускаются техподдержкой через LAPS.
На счет отключения \ удаления шедулера ответил выше - решается в значительной степени не постоянным шедулером, а мгновенным. Хотя риски и уязвимости в этой схеме, безусловно - остаются. Но тут, кажется, ничего не поделать. Выдая пользователю права админа - можно лишь принять эти риски и смести их к минимуму)
Вы правы, что если используется "постоянный" шедулер, то пользователь с правами админа - может его отключить \ удалить.
Поэтому у нас используется мгновенный шедулер (Immediate Task). Его отличие от постоянного в том, что он не висит в списке планировщика постоянно. В момент обновления GPO (фоновый режим), политика создает задачу, запускает её и сразу после выполнения - удаляет. Это занимает секунды, если не доли. Таким образом, у пользователя нет особо возможности что-то сделать с ней.
LAPS нам приглянулся и мы его используем - просто не в этом сценарии)
Есть операции, которые должны выполнять разработчики на корпоративных ноутбуках, которые мы выдаем и которые требуют админских прав. Не буду вдаваться в детали зачем - просто примем это как факт.
Наша развилка:
1. Они будут делать под своей доменной учеткой, которой мы выдадим админские права
2. Мы будем как-то делегировать им возможность смотреть пароль встроенной учетки админа через LAPS
Оба сценария дают больше прав, чем мы бы хотели и создают какие-то риски (запустить что-то от имени SYSTEM через шедулер, вывести ноут из домена и т.д.), но вариант 1 - проще в эксплуатации.
От рисков совсем не уйти и для их минимизации - нужны дополнительные инструменты.
Мы просто в какой-то момент приняли решение, что некоторым сотрудникам права админа выдаем и дальше надо систематизировать этот процесс.
Let's Encrypt действительно, дает помимо конечного, ещё рутовый + мидл в отдельном файле. Но с коммерческими не так, насколько я мог заметить. По крайней мере нам, сертификат выпущенный через Global Sign - приходит без полной цепочки
Да, видел новость, что их отключают, но ещё буквально несколько дней назад - мне удавалось получить описанным выше способом полную цепочку сертификата, выпущенного через Let's Encrypt