
Active directory, GPO, CA
Active directory, GPO, CA
Безопасность сервера каталогов можно существенно повысить, если настроить его на отклонение привязок SASL (согласование, Kerberos, NTLM или выборка), которые не запрашивают подписи (проверки целостности) и простых привязок LDAP, которые выполняются для подключения LDAP с открытым (не зашифрованным SSL/TLS) текстом. Даже если никто из клиентов такие привязки не использует, настройка сервера на их отклонение улучшает безопасность сервера.

Active directory, GPO, CA
Как вы все знаете в локальных сетях построенных на использовании контроллеров домена Active Directory, они несут самую наиважнейшую роль, так как без их нормальной работы, можно забыть про стабильность данной конструкции. В первоочередные обязанности системного администратора, входит проверка наличия ошибок на DC и их устранение. Для меня наиболее удобным вариантом оказался простейший пакетный файл, который состоит всего из пары строк:

Active directory, GPO, CA
Добрый день уважаемые читатели, в большой сети у системного администратора часто возникает задача быстрой синхронизации всех контроллеров домена. Статья предлагает простое решение, позволяющее этого достигнуть в считанные минуты. Проблема Active Directory автоматически синхронизирует изменения, но… делает это не сразу, а с задержками в несколько минут. Эти задержки становятся весьма ощутимы, когда системный администратор вносит изменения в Active Directory, а потом тут же пытается увидеть эти изменения в клиентском приложении или в какой-нибудь утилите. Примеры практических ситуаций, в которых задержка в синхронизации контроллеров домена мешает быстро выполнить задачу: создана новая учетная запись пользователя или сервиса и нужно войти в домен с ее помощью, причем неизвестно, какой из контроллеров домена будет обрабатывать запрос; изменены свойства учетной записи и приложению, работающему с глобальным каталогом, нужно увидеть эти изменения;

Active directory, GPO, CA
Имя журнала: System Источник: Microsoft-Windows-WinRM Дата: 08.09.2012 17:56:46 Код события: 10154 Категория задачи:Отсутствует Уровень: Предупреждение Ключевые слова:Классический Пользователь: Н/Д Компьютер: Dcsrv1.nwtraders.msft Описание: Службе WinRM не удалось создать следующие имена участников-служб: WSMAN/Dcsrv1.nwtraders.msft, WSMAN/Dcsrv1. Дополнительные данные Была получена ошибка "8344": %%8344. Действия пользователя Имена участников-служб можно создать под учетной записью администратора с помощью служебной программы setspn.exe. Xml события: <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="Microsoft-Windows-WinRM" Guid="{A7975C8F-AC13-49F1-87DA-5A984A4AB417}" EventSourceName="WinRM" /> <EventID Qualifiers="7">10154</EventID> <Version>0</Version> <Level>3</Level> <Task>0</Task> <Opcode>0</Opcode> <Keywords>0x80000000000000</Keywords> <TimeCreated SystemTime="2012-09-08T13:56:46.000000000Z" /> <EventRecordID>4643</EventRecordID> <Correlation /> <Execution ProcessID="0" ThreadID="0" /> <Channel>System</Channel> <Computer>Dcsrv1.nwtraders.msft</Computer> <Security /> </System> <EventData> <Data Name="spn1">WSMAN/Dcsrv1.nwtraders.msft</Data> <Data Name="spn2">WSMAN/Dcsrv1</Data> <Data Name="error">8344</Data> </EventData>
Active directory, GPO, CA
В любой серьезной ИТ-инфраструктуре и проектах, связанных с её созданием и модернизацией, присутствуют соглашения об именовании объектов. Однако, собранных в одном месте лучших практик по этой теме я не нашел ни в русских интернетах, ни в заграничных. В этой статье я попытаюсь восполнить сей пробел и изложу своё видение и подход к проектированию схем именования: учетных записей пользователей и групп, компьютеров, сетевых устройств и других объектов в Active Directory. Предложенные варианты схем основаны на личном проектном опыте и в результате анализа достоинств и недостатков в ИТ-инфраструктурах, которые приходилось встречать. Я приведу аргументы практически для каждого решения, принятого при проектировании предлагаемых ниже схем. Буду рад увидеть альтернативные мнения в комментариях.

Active directory, GPO, CA
Добрый день! Уважаемые читатели и гости блога pyatilistnik.org. Если вы еще не превратились в Шерлока Холмса в вашем домене, то теперь самое время. Ежеминутно в системах происходят тысячи изменений, которые требуется отследить и запротоколировать. Чем больше размер и сложность структуры, тем выше вероятность появления ошибок в администрировании и раскрытия данных. Без постоянного анализа изменений (удачных или неудачных) нельзя построить действительно безопасную среду. Системный администратор всегда должен ответить, кто, когда и что изменил, кому делегированы права, что произошло в случае изменений (удачных или неудачных), каковы значения старых и новых параметров, кто смог или не смог зайти в систему или получить доступ к ресурсу, кто удалил данные и так далее.

Active directory, GPO, CA
На сайте я уже писал про корзину AD но для windows server 2012R2, и решил таки перенести сюда мою старую статью про 2008R2. Active Directory — одна из самых важных служб для сетей Windows, любые сбои в ее работе сказываются на всех пользователях сети. При неполадках в Active Directory очень важно иметь отработанные сценарии аварийного восстановления. Одна из наиболее распространенных причин сбоя службы — случайное удаление объектов, поэтому предлагаю вам познакомиться с некоторыми способами восстановления удаленных объектов в Active Directory. Итак, что делать, если вы случайно удалили из Active Directory нужного пользователя (компьютер, группу, контейнер и т.п. )? Отвечу на вопрос, который сразу возникает в подобной ситуации - создать новый объект гораздо проще, чем пытаться восстановить старый, и в некоторых ситуация это допустимо. Но давайте представим, что произойдет при создании, скажем, нового пользователя взамен удаленного. Да, мы можем дать ему точно такое же имя, и он даже сможет зайти под ним в сеть, но и все! Попытавшись получить доступ к ресурсам, на которые у него раньше были права, он получит отказ.
Active directory, GPO, CA
Надеюсь, после прочтения этой статьи многие поймут, что контроллеры домена обязательно либо делать Read-Only, либо шифровать (например Bitlocker). Бывает, что в организации злые администраторы перед уходом поменяли все пароли и перед вами стоит задача взлома пароля для администратора домена. Сразу скажу, что если у вас есть физический доступ к серверу, неважно виртуальный он или физический, то у вас есть все шансы сделать себя администратором домена, главное иметь под рукой нужные утилиты и немного базовых навыков.