Update 05.12.2009: выпилена часть про смену пароля как не совсем правильную (см.каменты). Судя по логике смены паролей компьютерами в домене, можно реализовать Offline CA в доменной среде с большим сроком бездействия. Но это всё равно не отменяет того факта, что такое решение будет не совсем правильным.
Сегодня хочу немного обсудить несколько (все не получится :-() вопросов планирования ирерархий Certification Authority (CA), как это делается в реальном мире. Как таковых бест-практисов на эту тему не существует, равно как и бест-практисов по планированию лесов Active Directory. Есть только несколько стандартных классических схем и рекомендаций на основании которых можно выбирать. Этот вопрос очень серьёзный, поскольку иерархии PKI и AD очень редко меняются в силу сложности и дороговизны процесса. И с тем вариантом, который вы выбрали на этапе планирования, скорее всего вы будете жить очень долго.
В реальной жизни домены и PKI в основном развёртываются по одному из трёх сценариев:
Не всем посчастливилось устроиться работать в компанию последней группы и чаще всего приходится работать в первых двух. С первым вариантом даже обсуждать нечего, потому что с такими администраторами говорить вовсе не о чем, разве что смаковать последние новости с ЛОРа, секлаба и двача. Я всё-таки надеюсь, что этот пост будет полезен администраторам второй группы.
Перед принятием решения о развёртывании PKI необходимо понять, что детский сад уже заканчивается и начинается взрослая половая жизнь к которой нужно относиться весьма серьёзно. Это будет означать, что PKI будет достаточно критичным моментом в инфраструктуре и любые фейлы потенциально (в реальности так и происходит) могут очень негативно отразиться на бизнесе, поэтому саму архитектуру нужно спланировать так, чтобы возможность эпик-фейла была как можно минимальной, а расширение было безболезненным. Самое основное, что должен знать администратор — это роли CA их назначение. Всего этих ролей 3:
В условиях малого и среднего бизнеса не всегда можно набрать компетентный в этих вопросах персонал, поэтому админстраторы обычно делают всё попроще — ставят 1 или 2 Enterprise Issuing CA и радуются жизни. В таких ситуациях один единственный CA выполняет все 3 роли — он и корневой, и Policy и издающий CA. Чем это плохо? Учитывая тот факт, что сервер CA находится постоянно в сети и его настройки безопасности могут содержать брешь, через которую CA можно легко скомпрометировать. Это, например, совмещение роли CA с другими ролями, как контроллер домена, сервер терминалов, файл-сервер и т.д. В данных случаях получить доступ к закрытому ключу CA будет проще, чем в остальных сценариях.
Если выделить отдельный сервер, член домена, под роль CA, то риск снижается, но незачительно, поскольку любой член групп Domain/Enterprise Admins, операторы бэкапа, etc. могут получить доступ к ключу CA. Это весьма неиллюзорная угроза, поскольку обидевшийся админ может поломать вам единственный корневой CA и даже использовать его ключ в корыстных целях — выпускать «липовые» сертификаты. Учитывая, что не существует идеальной ОС и в любой из них обнаруживаются те или иные уязвимости, при помощи которых злоумышленник может положить ваш CA не слезая с подругидивана просто запустив эксплоит (я надеюсь, что случай с конфикером/кидо напоминать не надо?). Другая проблема заключается в том, что ваш корневой CA будет жить ровно столько, сколько живёт сам домен/лес, поскольку мигрировать в другой домен/лес может быть весьма проблематично. И если вы решили переименовать домен или мигрировать в другой лес, то неиллюзорный секс с миграцией PKI вас ожидает, особенно, если всё делалось простым Next-Next. Это означает, что даже в условиях сети на 20 человек, держать корневой CA постоянно в сети — не самая лучшая идея. Хотя, если у вас есть HSM (Hardware Security Module), то опасность компрометации такого CA снижается, но не на столько, чтобы оправдать наличие корневого CA в доменной сети. Да и цена таких девайсов явно не по карману компаниям малого и среднего бизнеса. Лично мне с HSM поработать не довелось.
Следовательно, чтобы избежать всех этих проблем путь есть только один — вынос корневого CA из домена на отдельный сервер рабочей группы. При этом вы можете не покупать Enterprise редакции Windows Server, поскольку в рабочей группе хватает Standard Edition (а с выходом Winows Server 2008 R2, Standard тянет даже на Enterprise CA). Какие преимущества вы получите от такого CA?
С учётом выской популярности и доступности систем виртуализации, даже если у вас нет лишнего железа для сервера CA (а CA к ресурсам крайне нетребователен и может спокойно работать на железе уровня Pentium III), то вы с лёгкостью можете развернуть корневой CA на виртуальной машине с минимальной затратой средств. При этом виртуальную машину лучше хранить на съёмном жёстком диске, который можно прятать в сейф.
Это достаточно большой и очень теоретический вопрос. В действительности Policy CA от остальных отличает только активная кнопка Issuer Statement:
К сожалению очень многие компании забивают на такую мелочь. Подумаешь, есть кнопка или нет её. Но в действительности Policy CA очень нужен, поскольку кнопка Issuer Statement ведёт на CPS данной ветки иерарахии CA. Как я уже говорил, CPS документально описывает порядок работы служб сертификации и сопутствующих механизмов. В RFC 3647 вы можете более подробно ознакомиться с содержимым CPS или просто почитать CPS коммерческих CA, например, VeriSign — http://www.verisign.com/repository/cps. И это не просто бумажка какая-то, а уже юридический документ, за нарушение условий которого можно получить конфет пизденцовнанести сильный ущерб доверию компании со стороны самих сотрудников и внешних партнёров. Поскольку компания может вырасти или могут поменяться условия работы, не рекомендуется совмещать роль Policy CA с ролью корневого CA, потому что корень у вас только один, а политик сертификации может быть несколько. Все последующие CA (если есть) будут подчиняться политике самого первого Policy CA в цепочке. Поэтому каждый CA второго уровня (следом за корнем) будет представлять своё дерево политик сертификации со своим CPS.
Если Policy CA не рекомендуется совмещать с корнем, то совмещать его с Issuing CA вполне можно, если у вас планируется только один Issuing CA. Если же их будет больше одного, то Policy CA следует выносить отдельно и предусмотреть для него такие же правила размещения, как и для Offline Root CA (об этом я рассказывал чуть выше). Почему не рекомендуется совмещать Policy CA и Issuing CA, если издающих будет больше одного? Дело в том, что у вас не должно быть больше одного уровня издающих CA. Т.е. вот такой схемы:
Поскольку в этом во-первых нет необходимости и вы почём зря удлиняете цепочку сертификации. В принципе, иерархии состоящие из более, чем 4-х уровней нежизнеспособны, поскольку CCE (Certificate Chaining Engine) каждый раз будет тратить очень много времени на построение и проверки цепочек сертификатов и из-за таймаутов может давать битые цепочки. Конечно же, за такое вас никто бить по лицу ногами не будет, но таких схем лучше избегать за исключением очень сложных схем, когда используется 2 уровня Policy CA (что подразумевает несколько различных политик сертификаций) и 2 уровня издающих CA. Такое возможно только в больших компаниях и их я не затрагиваю в данном материале. В случае если вам необходимо иметь несколько издающих CA под одним Policy CA, то схему лучше строить вот так, в зависимости от количеста издающих CA:
В первом случае у нас будет простая иерархия с единственным издающим CA, который так же выполняет роль Policy CA и ниже по иерархии ничего нет. Если ВНЕЗАПНО появятся потребности в ещё одном издающем CA, то это решается достаточно путём миграции ко второй схеме. Я не уверен, что Microsoft поддерживает миграцию с Online Enterprise CA на Offline Standalone CA, но я сам такие миграции делал и особых проблем это не вызывало. Просто при миграции нужно учитывать несколько нюансов и всё. Поэтому с учётом перспективы целесообразно делать такую схему изначально. По большому счёту это наиболее распространённые схемы иерархий PKI.
И ещё один момент, который хочу посмотреть — какой срок действия должен быть у сертификата CA? Вопрос достаточно риторический и зачастую зависит от требования к сроку действия конечных сертификатов. Но обычно используется простая схема:
Т.е. если у вас 2-х уровневая иерархия PKI, то Issuing CA будет на 5 лет, а Root CA на 10 лет. Для 3-х уровневой иерархии Issuing CA на 5 лет, Policy CA на 10 лет и Root CA на 15 лет. Но основной отправной точкой будет требования к сроку действия конечных сертификатов.
Как бы и всё. Данный материал в основном опирается на общие рекомендации и моё личное восприятие этого мира, поэтому готов обсудить альтернативные варианты.
> Сделать его offline не получится, потому что компьютерам в домене каждые 30 дней необходимо менять свои пароли. Это совершенно не Верно! Во-первых - необходимо менять не означает, что через 31 день компьютер этого сделать не сможет. Тут всё точно так же как и с пользователями - если пароль истёк, то при входе в систему его попросят изменить и совершенно неважно как давно он истёк - будь то месяц или год;). Грабли со сменой паролей и отключением сервера от сети можно словить только в случае контроллеров домена. Во-вторых - данный момент настраивается групповой политикой вплоть до отключения изменения пароля вообще, что лично я часто применяю для тестовых виртуальных машин при использовании Snapshot'ов. > Другая проблема заключается в том, что ваш корневой CA будет жить ровно столько, сколько живёт сам домен/лес > В рабочей группе вы никак не привязаны к имени домена/леса. Что позволяет сохранять корень доверия даже при смене лесов > Я не уверен, что Microsoft поддерживает миграцию с Online Enterprise CA на Offline Standalone CA, но я сам такие миграции делал и особых проблем это не вызывало. Враньё и противоречие! Во-первых - смерть леса не означает смерть корня, ибо мы можем взять его закрытый ключ и перенести его хоть на Standalone CA о чём ты сам же и говоришь;). Во-вторых - уж если говорить о привязке к имени домена, то у самого корневого сертификата её, в общем-то, нет.
> Во-первых - необходимо менять не означает, что через 31 день компьютер этого сделать не сможет вопрос: а в чём профит такой схемы? Что у тебя будет по сути мёртвая машина. И, как я говорил корень лучше вообще к сети не подключать, ибо нефиг. > Во-вторых - данный момент настраивается групповой политикой вплоть до отключения изменения пароля вообще, что лично я часто применяю для тестовых виртуальных машин при использовании Snapshot'ов. ну в своих виртуалках ты можешь делать что угодно! :) > Враньё и противоречие! :) > Во-первых - смерть леса не означает смерть корня по дефолту это что-то близкое к этому. Потому что по тому же дефолту первые ссылки ведут на LDAP, из-за чего как минимум на данном этапе будет теряться 20 секунд времени (по 10 секунд на CDP и AIA). Если есть ещё один уровень CA с LDAP ссылками, то и там приплюсуй по 20 секунд таймаутов. Для http уже остаётся 5 секунд. Если клиент будет сильно слоупочить, то цепочки будут рваться. Кстати, это одна из причин почему я и не использую LDAP в CDP и AIA. С HTTP тоже могут быть трудности. Сменили домен/лес, но для этого придётся где-то создавать домен с таким именем и прописывать в DNS новые записи. Если для внутренних клиентов это просто — в DNS создал зону и набил нужные адреса, то для внешних клиентов имя домена придётся поддерживать и дальше (чтобы http ссылки не бились). И за это придётся платить. Вобщем, не каждый случай Enterprise Root CA можно спокойно мигрировать в Standalone Root CA, иногда будет проще всё грохнуть и сделать с нуля. > ибо мы можем взять его закрытый ключ и перенести его хоть на Standalone CA о чём ты сам же и говоришь одного ключа может не хватить. Всё-таки лучше переносить весь PFX файл, т.е. вместе с самим сертификатом. > Во-вторых - уж если говорить о привязке к имени домена, то у самого корневого сертификата её, в общем-то, нет. ну вобщем-то есть, потому что по дефолту когда ты поднимаешь Enterprise CA, то его Subject будет содержать DN домена. Принципиальной разницы в этом нет, просто нелогично будет, что у тебя новый домен/лес adatum.com, а Subject сертификата будет выдан на litware.com (старое имя). Это ещё один повод, почему при поднятии CA поле Subject нужно заполнять так, чтобы оно отражало принадлежность к компании, а не к имени домена или леса. Тогда вне зависимости от домена компании ни у кого никаких подозрений не будет. Т.е. тут играют роль не только технические моменты, но и психологические (если их так можно назвать) тоже.
> вопрос: а в чём профит такой схемы? Тут дело в том, что идёт явный обман читателя, ибо цитирую: "Сделать его offline не получится". В общем, призываю отличать "нужно" от "можно";). > Потому что по тому же дефолту первые ссылки ведут на LDAP Вадя, вот не нужно сейчас уворачиваться, как уж на сковороде;)! Если поискать мои комментарии к соответствующему посту, то вспомнишь что по тому же умолчанию в корневом сертификате прописывается усключительно CDP и то такое поведение было лишь в 2003, в 2008 в корне нет ни AIA ни CDP. Но если, опять же, вспомнить, ты сам учил, что CDP в корне быть не должно;)! > Если есть ещё один уровень CA с LDAP ссылками О каком "ещё одном уровне" мы говорим при переезде, тем более в случае разворачивания PKI говноадминами? Мы можем просто сохранить лишь корень, а дальше создать новые подчинённые центры сертификации и соответственно прописывать в них новые CDP и AIA;)... > Сменили домен/лес, но для этого придётся где-то создавать домен с таким именем и прописывать в DNS новые записи А вот это потребуется только в случае сохранения всей старой инфраструктуры PKI - подчинённые центры и конечные потребители. > то для внешних клиентов имя домена придётся поддерживать и дальше (чтобы http ссылки не бились). И за это придётся платить Ну это вообще смешно! Продление жизни домена стоит 450 рублей в год;)! Да и нужен он будет лишь до тех пор, пока срок жизни старых подчинённых центров не истечёт. > Вобщем, не каждый случай Enterprise Root CA можно спокойно мигрировать в Standalone Root CA Думаю, при грамотном подходе, неразрешимых проблем возникнуть не должно. > Всё-таки лучше переносить весь PFX файл, т.е. вместе с самим сертификатом. Вадя, ну понятное дело, что я говорил о криптопаре, а не только о закрытом ключе;). > ну вобщем-то есть, потому что по дефолту когда ты поднимаешь Enterprise CA, то его Subject будет содержать DN домена Именно поэтому я и сказал "в общем-то, нет". > Принципиальной разницы в этом нет, просто нелогично будет Вот именно! Нелогично != привязка. То есть, технически это ни как не повлияет на работу PKI.
> Тут дело в том, что идёт явный обман читателя, ибо цитирую: "Сделать его offline не получится". В общем, призываю отличать "нужно" от "можно";). Можно, но не всегда. Почему — я уже писал. > Вадя, вот не нужно сейчас уворачиваться, как уж на сковороде;)! Если поискать мои комментарии к соответствующему посту, то вспомнишь что по тому же умолчанию в корневом сертификате прописывается усключительно CDP и то такое поведение было лишь в 2003, в 2008 в корне нет ни AIA ни CDP. Но если, опять же, вспомнить, ты сам учил, что CDP в корне быть не должно;)! а при чём тут корень? Я говорю про конечные сертификаты. Или ты будешь утверждать, что по дефолту там не LDAP? Во всяком случае, сколько я видел PKI (не верисайна!), везде простой дефолтный next-next. Вот с дефолтом переезжать не очень интересно. Я не думаю, что кто-то будет заморачиваться поднимать какой-нибудь LDS только для поддержки LDAP ссылок. > О каком "ещё одном уровне" который будет выполнять Offline Policy CA. Он не всегда будет, но желательно иметь такой CA. > А вот это потребуется только в случае сохранения всей старой инфраструктуры PKI - подчинённые центры и конечные потребители. безусловно. Если старая инфраструктура не нужна, то там вообще никаких проблем нет. Всё грохнул и начинай жить заново. > Ну это вообще смешно! Продление жизни домена стоит 450 рублей в год;)! Да и нужен он будет лишь до тех пор, пока срок жизни старых подчинённых центров не истечёт. смешно-не смешно, зато правда. Это просто ещё один лишний хвост. Даже по 450 рублей + расходы на содержании зоны. И так лет на 10. И об этом тоже нужно думать. > Думаю, при грамотном подходе, неразрешимых проблем возникнуть не должно. вот ты можешь дать определение "грамотного подхода"? Это изначально правильное планирование или что? Если так, то миграция Enterprise -> Standalone как бы не подразумевается, потому что оно уже есть изначально. Или что ещё ты подразумеваешь в этом слове? > Вот именно! Нелогично != привязка. То есть, технически это ни как не повлияет на работу PKI знаешь, технически вообще есть только одна привязка - имя CA. Остальное всё относительно. Ну и ещё ссылки в CDP/AIA. Но тем не менее всякие нетехнические детали тоже имеют значение.
> Можно, но не всегда. Почему — я уже писал. Вадя, ты меня опять не понял! Любой компьютер, кроме контроллера домена, можно выключить на любой срок и это не вызовет никаких проблем. Пароль компьютер изменит при следующем включении... > а при чём тут корень? А при том, что всё доверие строется на нём! > Я говорю про конечные сертификаты. Или ты будешь утверждать, что по дефолту там не LDAP? В таком случае, о каких внешних пользователях тут говорить;)? Устранить это можно только одним способом - правильно настроить ссылки и перевыпустить сертификаты. > Во всяком случае, сколько я видел PKI (не верисайна!), везде простой дефолтный next-next. Можно подумать, ты их видел миллион;)! > Я не думаю, что кто-то будет заморачиваться поднимать какой-нибудь LDS только для поддержки LDAP ссылок. It Depends. Если сертификатов огромное количество и их перевыпуск выльется в копеечку, можно и подумать. Но если у кого-то такой PKI, то наверняка и сертификатов там немного, так что будет гораздо проще их просто переиздать с правильными ссылками. > который будет выполнять Offline Policy CA. У "говноадминов" его не будет точно;)! > + расходы на содержании зоны Это ещё более смешно, чем стоимость домена:)! Это копейки! Даже, если взять, что дополнительные расходы обойдутся нам в 10000 рублей за год (а в действительности эта сумма не накапает даже за 10 лет), то получается, организации нужно выкладывать по 27 рублей в день. Неужели ты думаешь, что даже самая быдло-контора не справится с такими платежами и необходимо заранее планировать такие мега-расходы? > вот ты можешь дать определение "грамотного подхода"? Я говорил о грамотном подходе при миграции;). > Ну и ещё ссылки в CDP/AIA В корне нет AIA, а CDP в нём нет (по умолчанию), начиная с 2008.
> Вадя, ты меня опять не понял! Любой компьютер, кроме контроллера домена, можно выключить на любой срок и это не вызовет никаких проблем. Пароль компьютер изменит при следующем включении... читай шапку поста. > А при том, что всё доверие строется на нём! Ты вообще о чём? > Можно подумать, ты их видел миллион;)! не миллион, но вообще общее представление построить можно. Редко у кого сделано как положено. > В таком случае, о каких внешних пользователях тут говорить ну хотя бы сотрудников компании, которые из дома заходят на OWA за почтой. В данном случае проблему будут испытывать только внешние пользователи. А с переездом в новый лес — и внутренние тоже. С этим уже определились, что LDAP в CDP и AIA по большому счёту нах не нужен. > It Depends. Если сертификатов огромное количество и их перевыпуск выльется в копеечку, можно и подумать. угу. > Это ещё более смешно, чем стоимость домена:)! Это копейки! Даже, если взять, что дополнительные расходы обойдутся нам в 10000 рублей за год (а в действительности эта сумма не накапает даже за 10 лет), то получается, организации нужно выкладывать по 27 рублей в день. тут дело даже не в деньгах. Просто эта мелочь на себя будет отвлекать внимание. > В корне нет AIA, а CDP в нём нет (по умолчанию), начиная с 2008 я про сам корневой сертификат вообще ничего не говорил. Я говорил про CDP/AIA всех остальных сертификатов. > Я говорил о грамотном подходе при миграции;). вот можешь рассказать про граммотный подход при миграции? Если всё изначально сделано так, что PKI не зависит от лесов, то переезд Enterprise CA в другой лес не вызовет вообще никаких проблем. При этом количество переносимых CA снижается до количества Enterprise CA.
Здравствуйте! "Мне поручено и я пытаюсь..." Пытаюсь "всё сделать правильно". Подскажите, пожалуйста, если у нас есть родительская компания и у нее есть RootCA, то видимо нам не имеет смысла делать свой RootCA, а сделать только PolicyCA и IssuingCA, чтоб не удлиннять излишне цепочку? Заранее прошу прощения, если мой вопрос глупый. Принципиально вроде бы уже решено (на нашем уровне), что у нас не будет своего RootCA, а будет только PolicyCA м IssuingCA, но что-то меня сомнения одолели. PS система Windows 2003 server Заранее благодарю за ответ.
А в чём сомнения? По возможности следует избегать создания новых корней, если иерархию можно подвязать под один корень.
Да, пожалуй, всё же еще одно звено будет лишним. Я просто рассматриваю возможность, что нам может понадобиться два PolicyCA и вроде бы не нахожу такой необходимости. А сомнения как всегда смутные - не доводилось мне пока проектировать иерархию СА...
Ничего страшного не случится. Просто подумайте, может, есть возможность разместить 2 PolicyCA на одном уровне. В любом случае, до 4-х CA в цепочке — допустимая длина (хоть и предельная).
Если размещать два PolicyCA на одном уровне, то придется же два сертификата у головной компании запрашивать? И ведь надо еще им объяснить, зачем. А я и сама не знаю - зачем... Пусть пока будет один Policy и два Issuing (для внешних и внутренних пользователей отдельно)...
извините, но я тоже не знаю, зачем вам два Policy CA.
Если PolicyCA будет offline, то как же пользователи смогут получить у него сертификаты (те, которые уже выпущены) - для построения цепочки сертификатов (с помощью CCE)? Или они тоже на веб-сервере публикуются?
Прошу прощения, радикально ступила. В сертификате есть поле AIA, в котором указывается, откуда качать сертификат вышестоящено CA.
Не совсем понятно, насколько хорошей будет схема с 1 Offline Standalone Root CA и 2-мя Online Enterprise Policy/Issuing CA, выносить в таком случае Offline Standalone Policy CA как-то не очень хочется ибо это обслуживание, лицензии и т.д., а практического смысла не вижу никакого. PS: Спасибо за статьи, в вопросе PKI как лучик света ... толково и по существу.
Нашёл сам. В другой статье http://www.sysadmins.lv/PermaLink,guid,5ee5feb6-bcb0-4a1f-adfc-de989556785a.aspx описана данная конфигурация.
вот, почитайте подробнее по вопросу PolicyCA: http://www.sysadmins.lv/PermaLink,guid,a421d4c0-e56b-43e0-abbe-1704a7946eba.aspx т.е. это нормально иметь один Offline Root и 2 Online Subordinate (если они не подвязаны к разным политикам).
Владимир, добрый день, возможно у вас это было описанно, но я пока не нашел. Меня интересует схема, когда система pki предприятия встраивается так сказать, в общемировую. И сертификат корневого ЦС не является самоподписанным. Т.е. корневой ЦС предприятия будет иметь подтверждаемый verisign сертификат, и ЦС предприятия далее выдает и управляет сертификатами для своих клиентов. Можно это в двух словах описать?
http://social.technet.microsoft.com/wiki/contents/articles/certification-authority-root-signing.aspx
Может вопрос будет немного странный. В модели офлайн Root CA и офлайн Policy CA возможна ли установка этих 2х ролей на 1 физический хост? И в этой-же модели возможна первоначальная установка 1 а не 2х Issuing CA. Смысл такой модели таков. Общая сеть компании более 200 хостов, но сейчас речь идет об 1 основном офисе 50+ хостов. В будущем будет еще подключено 3 офиса по 20-25 хостов. Офисы распределенны по территории.
Нет, на одну ОС можно установить только один инстанс Certification Authority.
кое-что из прочитанного всё равно ставляет вопросы: на примере 2х уровневой структуры 1 - надо ли юзерам и компам устанавливать серты корневого и выпускающего или только выпускающего? 2 - если скомпрометируют выпускающий то придётся перевыпустить все серты которые он выпустил и его собственный серт тоже - так?
1) корневой надо устанавливать обязательно. Издающие сами устанавливаются на клиенты. 2) в принципе, достаточно отозвать только сертификат издающего CA, тогда все сертификаты, которые он выпустил автоматически будут считаться отозванными тоже.
Не хочу показаться говноодмином из метро за 15 минут на коленке next-next ok profit маке бизнес пошел ежже, но чёт я всё равно не понимаю в чём смысл 2-х уровневой структуры кроме политик и возможности миграции в другой лес? Какие ещё плюсы? Если поломали выпускающий то одинх все серты перевыпускать, то же самое что и с одноуровневой иерархией - переустановить и ехать дальше если порвут или не так? Что может сделать кидо\конфикер с СА? А если в локальные админы добавить только доверенное лицо которое распишеться за ответственность, настроить файрволл, все обновления накатить, комерческий резидентный антивирус и не совмещать с другими ролями неужели одноуровневая иерархия всё равно будет только для говноадминов? Никак не могу определиться: 2-х уровневою или всё же говноадмина включить. В моём случае првда полюбому совмещать роли придёцца и ставить корневой либо выпускающий на контроллер, на сколько это будет хреново?
Comments: