0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Как синхронизировать рабочие станции домена по контроллеру домена

Как синхронизировать рабочие станции домена по контроллеру домена

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

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

Рис. 6.1. Доверительные отношения между доменами

Доверяющий домен — trusting — предоставляет доступ к своим ресурсам пользователям из другого домена — доверяемого или trusted. Иногда доверяющий домен называют ресурсным, так как в нем находятся серверы, к ресурсам которых получают доступ пользователи, учетная информация которых находится в SAM контроллеров доверяемого домена, который называют поэтому учетным.

Доверительные отношения не являются транзитивными. Например, если домен А доверяет домену В, а В доверяет С, то это не значит, что А автоматически доверяет С.

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

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

6.2. Транзитная аутентификация в многодоменной сети

Пользователи могут входить в сеть из рабочих станций не только того домена, где хранится их учетная информация, но и из рабочих станций доменов, которые доверяют этому домену.

При входе в учетный домен с компьютера ресурсного домена также выполняется транзитная аутентификация. Пользователь в многодоменной сети полностью идентифицируется в сети составным именем в форме имя_доменаимя_пользователя.

  • при начальном логическом входе в учетный домен с рабочей станции,
  • при использовании ресурсов доверяющего домена.
  1. Компьютер Windows NT при старте выполняет сервис Netlogon, с помощью которого обнаруживает контроллер своего домена (например, домена 2) на основе Windows NT Server.
  2. Пользователь (например, пользователь 2) логически входит в компьютер домена 2, имея учетную информацию в домене 1. Он делает это изменяя имя домена в окне From с имени «домен 2» на имя «домен 1».
  3. Контроллер домена 2 не может произвести аутентификацию пользователя, поскольку в запросе указано, что учетная информация пользователя находится в домене 1.
  4. Аутентификационный запрос передается по доверительной связи в контроллер домена 1. Этот контроллер проверяет базу данных учетной информации домена 1 на наличие там данных о пользователе 2 и корректность введенного пароля.
  5. Контроллер домена 1 аутентифицирует пользователя 2 и передает его идентификатор и идентификатор его группы контроллеру домена 2. Затем контроллер домена 2 передает эту информацию компьютеру Windows NT, через который осуществлял вход пользователь 2.
6.3. Синхронизация контроллеров в сети Windows NT

Существует только один основной контроллер домена (PDC). Он управляет главной копией учетной базы данных домена, которая автоматически реплицируется на резервные контроллеры домена (BDC). Иногда может возникнуть потребность в повышении статуса резервного контроллера домена до основного, например, при проведении профилактических работ на первичном контроллере домена. Если PDC находится в рабочем состоянии, то он может поменяться ролями с BDC. Повышение статуса BDC до PDC приведет к тому, что статус PDC автоматически понизится до BDC.

Если же PDC отключен, то BDC также можно повысить до статуса PDC, но все последние изменения в его базе будут утеряны.

  • Если выбирается один из BDC, то с PDC синхронизируется только его база данных.
  • Если выбирается PDC, то база данных PDC будет синхронизироваться со всеми BDC домена.

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

Полная синхронизация учетной базы данных не является необходимой, если PDC и BDC работают на основе Windows NT Server. Это происходит потому, что PDC отслеживает уровень синхронизации для каждого BDC, что позволяет PDC управлять интенсивностью процесса частичной синхронизации. PDC посылает сообщение об изменении своей базы данных только тому BDC, который нуждается в изменениях, вместо того, чтобы синхронизировать все BDC. В каждом цикле репликации сообщения посылаются некоторому подмножеству BDC домена, что предотвращает одновременные ответы сразу от всех BDC. Это уменьшает пиковые значения сетевого трафика и загрузки PDC.

Читайте так же:
Синхронизация наручных часов с мобильным

Параметры репликации: период репликации (по умолчанию — 5 минут), количество одновременно реплицируемых BDC (по умолчанию — 20), максимальное значение периода репликации и некоторые другие параметры. Все они хранятся в базе Registry.

6.4. Четыре базовые модели организации доменов

Механизм доменов можно использовать на предприятии различными способами. В зависимости от специфики предприятия можно объединить ресурсы и пользователей в различное количество доменов, а также по-разному установить между ними доверительные отношения.

  1. Модель с одним доменом
  2. Модель с главным доменом
  3. Модель с несколькими главными доменами
  4. Модель с полными доверительными отношениями

6.4.1. Модель с одним доменом

Эта модель подходит для организации, в которой имеется не очень много пользователей, и нет необходимости разделять ресурсы сети по организационным подразделениям. Главный ограничитель для этой модели — производительность, которая падает, с увеличением числа серверов в сети.

Централизованное управление пользовательской учетной информацией.

Нет нужды в управлении доверительными отношениями.

Использование только одного домена также означает, что один сетевой администратор должен администрировать всю сеть. Разделение сети на несколько доменов позволяет назначать несколько администраторов, каждый из которых может администрировать отдельные серверы, входящие в разные домены.

6.4.2. Модель с главным доменом

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

Рис. 6.2. Модель с главным доменом

Главный домен удобно рассматривать как чисто учетный домен, основное назначение которого — хранение и обработка пользовательских учетных данных. Остальные домены в сети — это домены ресурсов, они не хранят и не обрабатывают пользовательскую учетную информацию, а поставляют ресурсы (такие как разделяемые файлы и принтеры) для всей сети. В этой модели пользовательскую учетную информацию хранят только основной и резервный контроллеры главного домена.

Учетная информация может централизованно управляться.

Ресурсы логически группируются.

Домены отделов могут иметь своих администраторов, которые управляют ресурсами отдела.

6.4.3. Модель с несколькими главными доменами

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

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

Каждый главный домен доверяет всем остальным главным доменам. Каждый домен отдела доверяет всем главным доменам, но доменам отделов нет необходимости доверять друг другу.

Рис. 6.3. Модель с несколькими главными доменами

Так как все ресурсные домены доверяют всем главным, то данные о любом пользователе могут использоваться в любом отделе предприятия.

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

Чтобы упростить решение этой проблемы, целесообразно распределять пользователей по главным доменам по организационному принципу, а не по какому-либо иному, например, по алфавитному.

Ресурсы логически группируются.

Необходимо управлять большим количеством доверительных отношений.

6.4.4. Модель с полными доверительными отношениями

Эта модель обеспечивает распределенное администрирование пользователей и доменов. В этой модели каждый домен доверяет каждому. Каждый отдел может управлять своим доменом, определяя своих пользователей и глобальные группы пользователей, и они могут использоваться во всех доменах предприятия.

Рис. 6.4. Модель с полными доверительными отношениями

Из-за резкого увеличения числа доверительных отношений эта модель не подходит для больших предприятий. Для n доменов нужно установить n(n-1) доверительных отношений.

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

Хорошо масштабируется в отношении количества пользователей.

Каждый отдел имеет полное управление над своими пользователями и ресурсами.

Нужно управлять очень большим количеством доверительных отношений.

Читайте так же:
Синхронизировать несколько камер premiere
6.5. Практические занятия

6.5.1. Установление доверительных отношений между доменами

  • Перед началом выполнения данной лабораторной работы учебная сеть состоит из 5, не связанных между собой доменов DOM1, DOM2, DOM3, DOM4, DOM5.
  • Домен DOM1 требуется сделать доверяющим (ресурсным) по отношению к домену DOM2.
  • Dомены DOM3 и DOM4 должны стать доверяющими (ресурсными) по отношению к домену DOM5.
  • к ресурсам компьютеров и пользователям своего домена
  • к ресурсам компьютеров и пользователей чужого домена

При проверке пользователь должен просматривать имеющиеся разделяемые ресурсы (компьютеры и share) и иметь возможность к ним подключаться.

Администратор должен проверить свои возможности по созданию новых пользователей, а также созданию новых разделяемых каталогов и контролю за их использованием.

Упражнение 2 . Установить доверительные отношения между доменами:

    Выполнить действия на PDC домена B, чтобы этот домен занес домен A в список доменов, которым разрешено доверять данному домену.

  • запустить User Manager for Domains;
  • в меню Policies выбрать пункт Trust Relationships;
  • в появившемся окне диалога в поле Trusting Domain выбрать нажать Add;
  • в появившемся окне в поле Domain Trusting набрать имя домена A и в полях Initial Password и Confirm Password задать пароль, который будет использован в следующей процедуре администратором домена А. ОК. Close.
  • Запустить User Manager for Domains;
  • меню Policies выбрать пункт Trust Relationships;
  • появившемся окне диалога в поле Trusted Domains нажать кнопку Add;
  • поле Domain набрать имя домена B, а в поле Password ввести пароль и нажать кнопку OK;
  • Если после этого доверительные отношения установятся успешно, то появится соответствующее сообщение.

В результате установлены односторонние доверительные отношения, в которых домен А является доверяющим (ресурсным), а домен В — доверяемым (учетным).

6.5.2. Тестирование возможностей пользователей в сети с доверительными отношениями

Как подружить Linux с доменом Active Directory

Windows или Linux? Наверное, нет ни одного системного администратора, который не задумывался бы над этим вопросом. О плюсах и минусах операционных систем Open Source и продуктов Microsoft написаны гигабайты текстов, ожесточенные споры не утихают уже много лет. Наблюдая за этими баталиями, хочется лишь одного – гармонии.

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

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

Статья представляет собой пошаговое руководство, как «подружить» рабочие станции Linux с доменом Active Directory.

Домен Active Directory под управлением одного или более контроллеров домена на базе Windows Server 2003; в качестве Linux-десктопа используется Kubuntu 7.10

  • Обеспечить единую аутентификацию пользователей.
  • Обеспечить авторизацию пользователей в домене Active Directory.
  • Обеспечить прозрачную и сквозную авторизацию на ресурсах сети (SSO – Single Sign-On).
  • Обеспечить хранение пользовательских данных на сервере.

Про последний пункт хотелось бы сказать следующее: в данном примере в качестве файлового сервера используется Windows-сервер. Поэтому речь идет только о хранении данных пользователей. Сохранять профиль UNIX-пользователя на сервере не представляется возможным, так как в качестве Linux-десктопа используется Kubuntu 7.10 со встроенным экранным менеджером KDE. В процессе создания профиля пользователя KDE создает символьные ссылки (symlink), которые необходимы для корректной работы. Естественно, что создать symlink в файловой системе NTFS на Windows Server 2003 не получится.

  • domain.ru – полное имя домена Active Directory;
  • dc.domain.ru – полное имя контроллера домена;
  • fileserver.domain.ru – полное имя файлового сервера.

Условно всю работу можно разделить на следующие этапы:

  • Модернизация схемы Active Directory.
  • Настройка атрибутов будущих UNIX-пользователей и групп.
  • Настройка рабочей станции с Kubuntu.
  • Настройка ресурсов сети (веб-серверов, службы ssh и т. д.) для обеспечения прозрачной и сквозной авторизации пользователей.

Модернизация схемы Active Directory

В классической схеме AD невозможно хранить атрибуты UNIX-пользователей, такие как UID, GID, Login Shell, Home Directory. Поэтому схему необходимо расширить, добавив в нее возможность хранения нужных нам сведений. Для этого существует два варианта: первый – это бесплатный пакет Microsoft под названием Windows Services for UNIX 3.5 (SFU), второй – это использование последней версии семейства серверов 2003 – Windows Server 2003 R2. Мы будем использовать второй вариант. Если ваши контроллеры домена и файловые серверы уже работают под релизом R2, можно смело пропустить несколько абзацев, касающихся обновления стандартного Windows Server 2003 до R2.

Читайте так же:
Где синхронизировать контакты самсунг

Windows Server 2003 R2 – версия Windows Server 2003, имеющая встроенные компоненты Windows Services for UNIX (SFU), необходимые нам при создании гетерогенной среды для хранения атрибутов UNIX-пользователей в схеме Active Directory. Релиз R2 включает в себя два важных компонента:

  • Subsystem for UNIX-based Applications (SUA);
  • Identity Management for UNIX (IMU).

SUA помогает UNIX-приложениям работать под Windows так, как будто они работают в Linux или UNIX. Это выходит за рамки нашей статьи, поэтому мы сфокусируем внимание на компоненте IMU, которая содержит нужные в дальнейшем службы – Administration Components, Password Synchronization, Server for NIS, их установку мы сейчас и рассмотрим.

Необходимо отметить, что возможно два сценария обновления, в зависимости от того, установлен у вас пакет SFU или нет. Мы будем рассматривать вариант, при котором SFU не установлен. В противном случае рекомендую посетить англоязычный ресурс http://www.winlinanswers.com/book/resources.php?id=5, где вы найдете полное описание варианта обновления до R2 с установленным SFU.

Вставив CD#2 с дистрибутивом Windows Server 2003 R2 и согласившись на продолжение установки, вы увидите сообщение об ошибке с описанием, что установка не может быть продолжена, поскольку версия схемы данного домена не совместима с R2. Поэтому сначала необходимо выполнить следующую команду:

где X – буква, соответствующая CD с дистрибутивом. После чего можно начать установку компонентов R2, выполнив файл R2auto.exe из корневой директории CD.

После установки компонентов R2 нужно в панели управления в разделе установки и удаления программ выбрать пункт «Windows Components», затем найти строчку «Active Directory Services» и в детализации выбрать установку «Identity Management for UNIX».

После завершения установки необходимо будет перезагрузить сервер.

Настройка атрибутов будущих UNIX-пользователей и групп

Откройте оснастку Active Directory User and Computers и вызовите свойства любого пользователя. Появилась новая закладка UNIX Attributes, в которой возможно назначить свойства UNIX-пользователя (см. рисунок). Для начала нам нужно создать несколько UNIX-групп, которые пригодятся нам в дальнейшем.

Свойства UNIX-пользователя — UNIX attributes

Создайте группу UNIXusers – это будет группа по умолчанию для всех UNIX-пользователей. Для этого создайте обычным способом группу нужного вам вида (Domain Local или Global), затем откройте свойства данной группы и перейдите на вкладку «UNIX Attributes». В строке «NIS Domain» выберите ваш домен, после чего группе автоматически будет присвоен GID. Если он не устраивает вас по какой-то причине, можете прописать новый идентификатор вручную. При создании следующих групп GID будет автоматически увеличиваться на единицу.

Аналогичным способом создайте группу UNIXadmins, которая затем будет указана в настройках конфигурационного файла /etc/sudoers как группа, членам которой разрешено выполнять sudo на рабочих станциях с Kubuntu.

Создайте еще одну группу и назовите ее audio, присвоив ей вручную GID 29. Дело в том, что в Linux есть одна особенность – файлы аудиоустройств, как правило, имеют общую группу таким образом, что возможность работы с аудио доступна только владельцам файлов и членам этой группы. В эту группу потом добавим всех пользователей, чтобы у них была возможность использовать наушники и микрофон.

Теперь выберите одного из тех пользователей вашего домена, которому вы хотите присвоить UNIX-атрибуты. В свойствах откройте вкладку «UNIX Attributes», так же как и для группы, выберите имя вашего домена в строке «NIS Domain», и в строке «Primary group name/GID» выберите группу по умолчанию UNIXusers.

Если необходимо по каким-то причинам изменить параметры Login Shell и Home Directory, можно это сделать. UID присвоится автоматически, но при желании можно прописать его вручную.

После присвоения UNIX-атрибутов всем нуждающимся в них пользователям вернемся к группам. Открыв свойства группы UNIXusers, на вкладке «UNIX Attributes» нажмите кнопку «Add» и добавьте туда всех пользователей.

Аналогично поступим с группой audio, а в группу UNIXadmins внесем только тех пользователей, кому разрешено выполнение sudo на рабочих станциях.

Теперь остается только создать нового пользователя, например unixldap, и присвоить ему соответствующие атрибуты. Учетная запись этого пользователя будет использоваться при регистрации и поиске в LDAP с Linux-десктопа, поэтому её необходимо максимально ограничить в правах, допустим, явно запретив доступ ко всем ресурсам файлового сервера и т. д.

На этом работы с оснасткой «Active Directory User and Computers» закончены.

Немного о настройке файлового сервера для работы с UNIX-клиентами

В данном примере монтирование домашних каталогов пользователей осуществляется с использованием CIFS (Common Internet File System).

Если для каких-нибудь задач вам потребуется работа с NFS (Network File System), то для обеспечения доступа к файловым ресурсам вашего Windows-сервера с Linux-десктопов необходимо будет установить на сервер пакет Microsoft Services for NFS. Привожу краткое руководство, как это сделать.

Читайте так же:
Хускварна 240 регулировка подачи масла

Зайдите в панель управления, затем в разделе установки и удаления программ выберите пункт «Windows Components», там войдите в «Other Network File and Print Services» и в детализации выберите установку «Microsoft Services for NFS». Из данного пакета необязательными к установке являются два последние пункта: Server for NFS Authentication и User Name Mapping. После установки данных служб пользователи с рабочих станций под управлением Linux получат доступ к файловым ресурсам данного сервера, используя NFS.

Настройка рабочей станции с Kubuntu

Теперь приступим к самой большой части работы – настройке Kubuntu. Сначала выполните установку Kubuntu 7.10 на рабочую станцию, после чего установите все необходимые обновления, например, используя встроенный в KDE менеджер обновлений Adept Updater.

Также рекомендуется изменить параметры входа в систему для KDE (в других экранных менеджерах могут быть отличия) – открываем меню «System Settings», переходим на закладку «Advanced», там выбираем «Менеджер входа в систему», и, войдя в административный режим, отключаем опцию «Показывать список» на вкладке «Пользователи». Если этого не сделать, система при входе будет отображать всех UNIX-пользователей вашего домена, что совершенно ни к чему.

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

Поэтому первым пунктом настроим синхронизацию времени. Для этого в файле /etc/default/ntpdate внесем следующие изменения:

При следующей перезагрузке ПК будет синхронизировать время с контроллером домена, а пока проведем синхронизацию вручную, выполнив следующую команду:

$sudo ntpdate -s dc.domain.ru

Указываем FQDN для настраиваемой рабочей станции в файле /etc/hosts:

127.0.0.1 workstation.domain.ru localhost workstation

Проверьте доступность машины по FQDN командой:

ping workstation.domain.ru –с 4

Теперь необходимо установить и настроить поддержку Kerberos. Устанавливаем нужные пакеты:

$sudo apt-get install krb5-user libpam-krb5 krb5-config libkrb53 krb5-doc

Если система выдала ошибку :

dpkg was interrupted, you must manually run dpkg –-configure –a to correct this problem

последуйте совету подсказки, наберите:

$sudo dpkg –-configure –a

В процессе вас попросят принять решение о замене файла /etc/qt3/qt_plugins_3.3rc – согласитесь с вариантом по умолчанию, оставьте текущую версию без изменений. Данная ошибка иногда проявляется в версии 7.10 после первой установки обновлений.

Как синхронизировать рабочие станции домена по контроллеру домена

Интеграция и синхронизация с Active Directory и доменами

Для настройки режимов интеграции с Active Directory и синхронизации данных пользователей Active Directory с пользователями системы SecureTower, в окне вкладки Пользователи и привилегии выберите вкладку Интеграция с Active Directory и доменами .

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

Интеграция с Active Directory

Вы можете выбрать объекты AD (домены, субдомены или организационные единицы), с которыми требуется проводить синхронизацию системы SecureTower. Рекомендуется настроить интеграцию для снижения нагрузки на контроллеры доменов и повышения скорости реагирования системы на изменения в AD при работе в сетях со сложной структурой (большим количеством доменов и групп) .

Для настройки интеграции следуйте рекомендациям параграфа Настройка режимов интеграции с Active Directory.

Синхронизация пользователей

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

Для настройки параметров синхронизации системы с Active Directory следуйте рекомендациям параграфа Настройка синхронизации с Active Directory.

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

Интеграция с контроллерами доменов для распознавания IP-адресов

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

Информация об авторизации пользователей на рабочих станциях в сети организации, получаемая от контроллера домена, будет добавляться в карточки пользователей SecureTower в автоматическом режиме. Выполнение интеграции с контроллерами доменов позволяет обеспечивать корректную привязку пользователей к IP-адресам для точного соответствия информации, перехваченной с рабочих станций, определенному пользователю.

Читайте так же:
Радиаторы для дома с регулировкой температуры

Для настройки интеграции с контроллерами домена следуйте рекомендациям параграфа Настройка интеграции с контроллерами домена.

Как синхронизировать рабочие станции домена по контроллеру домена

Есть 2 DC. PDC и резервный контроллер домена(виртуальная машина Hyper-V).

Оговорюсь сразу синхронизация с хостовой машиной отключена.

На PDC настроил синхронизацию с внешним источником.

Клиенты в том числе и резервный контроллер не синхронизируют время с PDC.

Резервный берет хардварные часы как источник и роздает на всю сеть. и даже если отключить виртуальную машину с основным контроллером клиенты не синхронизируют время.

Помогите пжст "оттраблшутить".

Ответы

  • Помечено в качестве ответа Petko Krushev Microsoft contingent staff, Moderator 5 декабря 2016 г. 8:04
  • Помечено в качестве ответа Petko Krushev Microsoft contingent staff, Moderator 5 декабря 2016 г. 8:04

Все ответы

А на эмуляторе pdc служба сервера ntp запущена? настраиваете правкой в реестре или через gpo?

Клиентам лучше настройки времени задать через групповую политику на уровне домена посредством NT5DS, тогда клиентские машины будут брать настройки времени с pdc. на самом pdc настройки службы ntp лучше сделать через групповую политику привязанную к ou в котором размещены контроллеры домена, но через wmi фильтр применить ее только для pdc.

И Вам, добрый вечер!

Правки делаю через w32tm + правка реестра.

Немного не понял, реализацию через груповые политики.(если можно разжевать в картинках).

А что касается настроек, то вроде как бы достаточно сделать(только правильно) как я пытаюсь.

И согласно доменной иерархии все должны сами знать где им брать время.

Если вас не затруднит объясните где неправ.

Правильная схема работы NTP сервера в доменной среде:

PDC берет время с внешнего источника, DC берет время с PDC, как реализовать:

w32tm /config /manualpeerlist:ntp1.stratum1.ru /syncfromflags:manual /reliable:yes /update

Net stop w32time && net start w32time

обязательно проверьте w32tm /query /source покажет текущий источник времени

W32tm /config /syncfromflags:manual /manualpeerlist:name of the pdc emulator/reliable:yes

Net stop w32time && net start w32time

Далее настройте через GPO чтобы все клиенты синхронизировались с временем с PDC.

  • Помечено в качестве ответа Petko Krushev Microsoft contingent staff, Moderator 5 декабря 2016 г. 8:04

Господа, доброго времени суток!

PDC — на момент моего вопроса на PDC все было настроено как вы и указали выше.

на втором DC время стояло локальное и как я не пытался настроить брать время с PDC нифига не работало,

т.е добровольно он его никак не хотел брать.

Дважды выполнил эту процедуру и перезапустил службу.

Но второй DC упорно не брал время с PDC.

В реестре ручками указал, что бери друг время с Главного контроллера и. получилось

Теперь схема работает так:

PDC берет время из мира

DC берет время с PDC

сеть клиентов берет время с DC. вроде бы и не плохо но что-то напрягает. Почитаю про GPO попробую сделать через них.

Может вы подскажете вариант чтобы обойтись без GPO.

Хотя теоретически время на домен контроллер по умолчанию отдает через какие-то политики(незнаю, но кажется я брежу)

Обратил внимание вот на что:

C:Windowssystem32>echo %logonserver%
\DC-02

Это имя резервного DC, может ли это быть причиной?

C:Windowssystem32>netdom query fsmo
Хозяин схемы DC-01
Хозяин именования доменов DC-01
PDC DC-01
Диспетчер пула RID DC-01
Хозяин инфраструктуры DC-01
Команда выполнена успешно.

  • Изменено realet 1 декабря 2016 г. 8:50
  • Помечено в качестве ответа Petko Krushev Microsoft contingent staff, Moderator 5 декабря 2016 г. 8:04

Да, пока ждал ответ на свой краний поста как раз вычитал про то, что тазикам пофик кто папа))

Благодарю отписавшихся за оказанную помощь.

Илья, если загляните еще сюда, просьба такого характера.

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

1. какие контроллеры разворачивать

2. сервисы какие на них необходимо поднять

3. какие групповые политики на них развернуть(я уже разного начитался, но суть прозрения не приходит, какие вы бы рекомедовали гпо разворачивать)

4. что в АД необходимо а главное как бекапить.

5. и самое главное (ведь собрать можно по массе хавтушек в сети) как эту кухню всю траблшутить.

если что можно и на мыло инструкцию кинуть, а то разрозненых знаний куча а как их в порядок привести а кто ж его знает))) povarsp4()жмель.com

голоса
Рейтинг статьи
Ссылка на основную публикацию
ВсеИнструменты
Adblock
detector