Довольно часто встречаются ситуации, когда контроллер домена оказывается удален без понижения роли, это может быть связано как с ошибками при понижении, так и с физическим выходом из строя, после чего в структуре Active Directiry остается информация (метаданные) несуществующего контроллера, что может приводить к различным ошибкам. Поэтому, если у вас произошла такая ситуация, следует обязательно выполнить очистку связанных с удаленным контроллером метаданных в базе Active Directory.

Как известно - все контроллеры домена в Active Directory равнозначны, но у некоторых из них есть особые функции, которые должны быть уникальны в пределах домена или леса. Это хозяева операций или FSMO-роли, которые отвечают за ряд критически важных операций, но при этом практически не участвуют в повседневной жизни службы каталогов. Для управления хозяевами предусмотрены различные инструменты, начиная от оснасток MMC и заканчивая инструментами PowerShell, о которых сегодня и поговорим.

Синхронизация времени - важный и во многом достаточно критичный аспект работы Active Directory, особенно сегодня, когда широко используется взаимодействие с внешними системами и работа с сотрудниками, которые могут находиться в различных часовых поясах. Применение систем виртуализации вносит дополнительные особенности, которые также следует учитывать. Поэтому данный вопрос может оказаться не столь простым, как кажется, а синхронизация с внешним источником точного времени становится одной из актуальных задач.

Довольно часто коллеги и читатели обращаются к нам с просьбой создать руководство по быстрому практическому развертыванию минимально работоспособной конфигурации Active Directory и сопутствующих служб. Хотя у нас на сайте уже есть цикл по развертыванию AD, вполне актуальный, несмотря на дату написания, он рассчитан прежде всего на пошаговое изучение вопроса как в теоретической, так и практической областях. Поэтому создание именно руководства нацеленного на быстрое получение результата имеет смысл и дает хороший повод еще раз обобщить и обновить информацию по этому вопросу.

В прошлой части нашего цикла мы рассмотрели работу протоколов семейства NTLM, отметив ряд их существенных недостатков, которые невозможно решить в рамках протокола. Поэтому вместе с Active Directory на смену им пришел более совершенный протокол Kerberos, который продолжает успешно применяться до сих пор. В данном материале мы рассмотрим общие принципы функционирования данного протокола, что позволит получить начальные знания в этой области самым широким массам читателей.

В прошлых частях нашего цикла мы рассмотрели, как настроить Squid для аутентификации пользователей через ActiveDirectory, однако просто проверять подлинность пользователя в большинстве случаев недостаточно. Требуется гибко управлять доступом пользователей к сети интернет основываясь на их членстве в группах безопасности AD, такая схема позволит администраторам использовать привычную и понятную модель управления, в тоже время задействовав все возможности прокси-сервера Sqiud.

Продолжаем цикл статей об интеграции прокси-сервера Squid и Active Directory. Одним из наиболее важных вопросов является прозрачная аутентификация пользователей домена на прокси-сервере. В этой части мы расскажем, как настроить аутентификацию по протоколу Kerberos, которая позволит использовать единую точку входа, когда пользователь вводит логин и пароль один раз - при входе в систему.

Материалы о построении роутера на базе Squid - одни из самых популярных на нашем сайте. Такое решение позволяет с минимальными затратами (прежде всего на программную часть) организовать и упорядочить доступ к сети интернет на предприятии. Но рассматриваемые нами варианты предназначались преимущественно для работы в составе рабочей группы. Отсутствие интеграции с Active Directory резко снижало удобство применения такого роутера в доменных сетях, поэтому мы решили исправить это упущение.

Работая в среде Windows каждый системный администратор так или иначе сталкивается с системами аутентификации. Но для многих этот механизм представляет собой черный ящик, когда суть происходящих процессов остается неясна. В тоже время от правильной настройки аутентификации напрямую зависит безопасность сети, поэтому важно не только знать способы и протоколы, но и представлять их работу, хотя бы на общем уровне.

С ошибкой "Не удалось установить доверительные отношения между этой рабочей станцией и основным доменом" время от времени приходится сталкиваться каждому системному администратору. Но не каждый понимает причины и механизмы процессов, приводящие к ее возникновению. Потому что без понимания смысла происходящих событий невозможно осмысленное администрирование, которое подменяется бездумным выполнением инструкций.

Управление ролями FSMO при помощи стандартных оснасток MMC не совсем удобный процесс, так как для доступа к разным ролям приходится использовать различные оснастки, а к некоторым из них еще и не так просто добраться. Кроме того оснастки MMC не позволяют производить операции захвата ролей в случае выхода из строя контроллера домена на котором они были расположены. Гораздо удобнее для этих целей использовать утилиту ntdsutil, о чем и пойдет речь в данной статье.

Как известно - ничего вечного нет, все меняется, особенно в такой отрасли как IT. Развернутая один раз инфраструктура постоянно развивается, расширяется, совершенствуется и наступает момент когда в вашу Active Directory требуется ввести контроллер домена под управлением более поздней версии операционной системы.

Установка самоподписанных сертификатов весьма частая задача для системного администратора. Обычно это делается вручную, но если машин не один десяток? И как быть при переустановке системы или покупке нового ПК, ведь сертификат может быть и не один. Писать шпаргалки-напоминалки? Зачем, когда есть гораздо более простой и удобный способ - групповые политики ActiveDirectory. Один раз настроив политику можно больше не беспокоится о наличии у пользователей необходимых сертификатов.

В прошлых материалах мы рассказали как правильно развернуть и настроить инфраструктуру Active Directory, сегодня мы поговорим о том, как правильно ввести в структуру AD уже существующие рабочие станции и учетные записи пользователей. Следуя нашим рекомендациям вы сможете избежать ряда потенциальных проблем и осуществить переход к AD наиболее безболезненно.

В прошлой статье мы подробно рассмотрели процесс создания контроллеров домена для вашей структуры AD. Сегодня мы хотим поговорить о правильной настройке службы DHCP, которой обычно не придают особого внимания. А зря, от правильной работы этой службы во многом зависит бесперебойная работа вашей локальной сети.

В прошлой части нашей статьи мы разобрали тот минимум теоретического материала, который необходимо знать перед развертыванием доменных служб Active Directory. Сегодня мы начнем практическую часть цикла, в которой подробно рассмотрим создание и переход к доменной структуре сети. Начнем, как всегда, сначала - в данной статье мы расскажем как правильно развернуть контроллеры домена.

В наших прошлых материалах мы разобрали общие вопросы касающиеся служб каталогов и Active Directory. Теперь пришла пора переходить к практике. Но не спешите бежать к серверу, перед развертыванием доменной структуры в вашей сети необходимо ее спланировать и иметь четкое представление о назначении отдельных серверов и процессах взаимодействия между ними.

Active Directory, пожалуй, самая распространенная и популярная на сегодня служба каталогов. Мы решили немного отступить от обычного формата изложения материала об AD и простым, понятным языком рассказать о довольно сложных вещах, намеренно упростив некоторые моменты. На начальном этапе гораздо важнее иметь цельное представление о предмете и на этом фундаменте углублять свои знания, чем пытаться разобраться в каше из малопонятных вещей.

В прошлой статье мы разобрались, что такое служба каталогов и какие преимущества можно получить от ее использования. Сегодня мы расскажем о существующих реализациях служб каталогов, их достоинствах и недостатках, чтобы вы могли осознанно сделать выбрать решение, которое наиболее полно удовлетворит ваши запросы.