Поделиться через

Где создать точку Подключение ion службы

  • Статья

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

Помните, что клиентские приложения находят scPs, выполнив поиск в каталоге ключевое слово в SCP. Атрибут ключевое слово SCP входит в глобальный каталог. Клиенты могут искать глобальный каталог, чтобы найти scPs в лесу. По этой причине клиент не влияет на публикацию scPs.

Минимизация трафика репликации

Чтобы свести к минимуму трафик реплика tion, создайте scPs в разделе домена домена хост-компьютера службы. Например, можно создать SCPs в качестве дочерних объектов объекта компьютера, на котором установлена служба. Раздел домена служб домен Active Directory, иногда называемый контекстом именования домена, содержит объекты, относящиеся к домену, такие как объекты для пользователей и компьютеров домена. Полный реплика всех объектов в секции домена реплика для каждого контроллера домена, но он не реплика для других доменов.

Не создавайте scPs в разделе конфигурации, также называемом контекстом именования конфигурации, так как изменения в секции конфигурации реплика для каждого контроллера домена в лесу. Как отмечалось выше, клиенты по всему лесу могут запрашивать глобальный каталог, чтобы найти scPs в любом месте леса, поэтому создание SCPs в разделе конфигурации не делает их более видимыми для клиентов; Он создает только больше реплика трафика.

Простота Администратор istration

Рассмотрим следующие рекомендации по администрированию объектов:

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

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

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

На следующей схеме показана часть иерархии контейнеров по умолчанию для секции домена.

default domain partition container hierarchy

На схеме показана иерархия доменов по умолчанию, включенная в службы домен Active Directory. Однако многие предприятия создают иерархию контейнеров подразделения для группирования классов объектов, таких как пользователи и компьютеры, вместе для администрирования. Администратор istratorы затем могут применять политику и наследуемые записи управления доступом (ACEs) к подразделению, чтобы делегировать административные полномочия для объектов в подразделении. Это позволяет администраторам эффективно управлять предприятием, но это имеет несколько последствий для программистов служб:

  • Объект компьютера для узла службы может не находиться в контейнере "Компьютеры", как показано на схеме. Дополнительные сведения о том, как найти объект компьютера для локального компьютера, см. в разделе "Публикация под объектом компьютера".
  • Администратор istrator может перемещать объекты по мере изменения потребностей организации. Это означает, что вы не можете зависеть от объектов, оставшихся в фиксированном расположении; То есть служба не может зависеть от различающегося имени объекта, оставшегося неизменным. Вместо этого используйте атрибут objectGUID объекта, который не изменяется, если объект перемещен или переименован. Дополнительные сведения и пример кода, создающий SCP, сохраняет объект OBJECTGUID и затем извлекает объектGUID для привязки к SCP, см. в статье "Создание и обслуживание точки Подключение ion Point".
  • Все классы объектов, связанные со службой, а также все подклассы этих классов, являются допустимыми дочерними элементами классов компьютера и организацииUnit . Если вы расширяете схему, чтобы определить собственный класс для конкретной службы, убедитесь, что классы компьютеров и организацииUnit включены в возможные превосходства.
  • Установщик службы определяет расположение по умолчанию для создания SCPs. Может потребоваться разрешить администратору установить службу, чтобы указать альтернативный путь установки.

Объекты, относящиеся к службе, не должны создаваться в следующих областях:

  • Службы не должны публиковать объекты непосредственно в контейнерах "Пользователи" или "Компьютеры" секции домена, а также не создавать новые контейнеры в этих контейнерах. Однако службы могут публиковать объекты как дочерние объекты объекта компьютера, независимо от того, хранится ли объект компьютера в контейнере "Компьютеры".
  • Службы, использующие регистрацию и разрешение сокетов Windows (RnR) или API службы имен RPC (RpcNs) для объявления себя, создайте соответствующие объекты в контейнерах WinsockServices и RpcServices под системным контейнером секции домена. Не создавайте объекты в этих контейнерах явным образом. Это не причиняет прямого вреда, но может быть запутано для администраторов.