Доменная учетная запись: Локальные и доменные учетные записи

Локальные и доменные учетные записи

При работе в компьютерной сети существуют два типа учетных записей. Локальные учетные записи создаются на данном компьютере. Информация о них хранится локально (в локальной базе безопасности компьютера) и локально же выполняется аутентификация такой учетной записи (пользователя).

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

Чтобы пользователи домена могли иметь доступ к ресурсам локальной системы, при включении компьютера в состав домена Windows производится добавление группы пользователей домена в группу локальных пользователей, а группы администраторов домена — в группу локальных администраторов компьютера. Таким образом, пользователь, аутентифицированный контроллером домена, приобретает права пользователя локального компьютера. А администратор домена получает права локального администратора.

Необходимо четко понимать, что одноименные учетные записи различных компьютеров — это совершенно различные пользователи. Например, учетная запись, созданная на локальном компьютере с именем входа Иванов, и доменная учетная запись Иванов — это два пользователя. И если установить, что файл доступен для чтения «локальному Иванову», то «доменный Иванов» не сможет получить к нему доступ. Точнее, доменный Иванов сможет прочесть файл, если его пароль совпадает с паролем локального Иванова. Поэтому если на компьютерах одноранговой сети завести одноименных пользователей с одинаковыми паролями, то они смогут получить доступ к совместно используемым ресурсам автономных систем. Но после изменения одного из паролей такой доступ прекратится.

Рис. 4.8. Дополнительные параметры учетной записи После установки пакета Account Lockout and Management Tools в свойствах учетной записи отображается вкладка, на которой администратор может увидеть в том числе и количество неудачных попыток входа в систему (Bad Password Count) (рис.

4.8). Данную информацию можно получить и выполнив непосредственный запрос к службе каталогов. В качестве фильтра можно указать следующую строку:

(&(objectclass=user)(!(objectclass =computer))(!(badPwdCount=0)) (badPwdCount=*))

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

⇐Понятие учетной записи | Самоучитель системного администратора | Группы пользователей⇒

Учетная запись ArcGIS Server—ArcGIS Enterprise

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

Когда используется учетная запись ArcGIS Server?

Учетная запись ArcGIS Server используется для следующих целей:

• Запуск и остановка процессов, поддерживающих ArcGIS Server и сервисы.
• Чтение ГИС-данных за сервисами, когда зарегистрированная база данных использует аутентификацию операционной системы.
• Чтение и запись файлов в директориях ArcGIS Server; например, при создании кэша карты учетная запись ArcGIS Server записывает листы кэша в директорию кэша сервера.
• Чтение и запись файлов в хранилище конфигурации.
• Чтение и запись файлов в папку установки ArcGIS Server и системную директорию temp; например, учетная запись записывает файлы журнала, которые можно использовать для диагностики сервера.
• Чтение и запись сообщений журнала в папке журналов.

Какую учетную запись сделать учетной записью ArcGIS Server?

По умолчанию имя учетной записи ArcGIS Server – arcgis. Принятие данных значений по умолчанию является достаточным для большинства непроизводственных развертываний; для производственных систем рекомендуется перед установкой ArcGIS Server создать домен или учетную запись Active Directory. Если ваша политика безопасности требует применения паролей со сроком действия, то вам необходимо будет запустить утилиту настройки учетной записи Configure ArcGIS for Server для обновления пароля с истекшим сроком действия.

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

Доменная учетная запись

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

При задании учетной записи домена, используйте формат DOMAIN\username. Если вы не указываете домен, мастер установки ArcGIS Server создаёт локальную учётную запись с указанным вами именем пользователя. Если указать несуществующую доменную учетную запись, программа установки сообщит об ошибке.

Если настройки входа запрещают вход с машины, на которой установлен ArcGIS Server, вы получите во время установки сообщение об ошибке. Настраивать для пользователя ArcGIS Server параметр групповой политики Локальный вход (Log on locally) необязательно. Более подробно см. Дополнительные вопросы использования доменных учетных записей.

Локальная учётная запись

Если вы выбрали локальную учетную запись, она должна существовать на каждой установке ArcGIS Server с одинаковым именем и паролем. Вы можете создать локальную учётную запись с одинаковыми паролями на всех машинах перед установкой ArcGIS Server, или позволить мастеру установки ArcGIS Server создать локальную учётную запись; проверьте только чтобы на всех машинах сайта использовались одинаковые имя пользователя и пароль.

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

Групповая управляемая учетная запись сервиса

Групповая управляемая учетная запись сервиса (gMSA) это специальная учетная запись домена Active Directory, которая обеспечивает автоматическое управление паролями. Учетная запись не может быть использована для входа в интерактивном режиме и ограничена использованием только на подготовленной группе серверов.

Использование gMSA особенно удобно, когда служебная учетная запись управляет ПО на нескольких компьютерах, например, при использовании сайта ArcGIS Server на нескольких компьютерах. Поскольку gMSA работает на уровне домена, имеется возможность регулярной смены пароля служебной учетной записи на каждом компьютере без вмешательства вручную.

Начиная с версии 10.8, утилита командной строки ServerConfigurationUtility, описываемая ниже, может использоваться для настройки сервиса ArcGIS Server для запуска под gMSA. Для параметра имени пользователя, групповая управляемая учетная запись сервиса может быть задана с и без символа $ в конце. Параметр пароля не требуется. Параметры readconfig и writeconfig с групповой управляемой учетной записью сервиса работают одинаково.

Пример команды для настройки gMSA в качестве учетной записи ArcGIS Server:

ServerConfigurationUtility.exe /username mydomain\enterprise-gmsa$ /writeconfig c:\temp\domainaccountconfig.xml

Могу ли я использовать из Windows родную учётную запись Local System для запуска сервиса ArcGIS Server?

Да; но это не рекомендуется по следующим причинам:

• У учётной записи Windows LocalSystem очень много прав, это может плохо повлиять на безопасность. Подробные сведения см. в Учетная запись LocalSystem в Microsoft Development Center.
• Учетная запись LocalSystem не предназначена для доступа к сетевым папкам. Для доступа к сервису и данным сайта вам надо хранить данные локально.
• Вы не можете использовать LocalSystem в качестве учетной записи ArcGIS Server на сайте с несколькими машинами.

Какие права доступа необходимо предоставить учетной записи ArcGIS Server?

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

• <ArcGIS Server директория установки>\framework
• <ArcGIS Server директория установки>\usr
• <ArcGIS Server директория установки>\bin
• <ArcGIS Server директория установки>\XMLSchema
• <ArcGIS Server директория установки> \DatabaseSupport

Перед созданием сайта учетной записи ArcGIS Server необходимо предоставить следующие права:

• Полный доступ к местоположению, где создаются серверные директории. Помните, что вам необходимо предоставить учетной записи ArcGIS Server права для чтения и записи в любые новые серверные директории, которые вы создали после настройки сайта.
• Полный доступ к местоположению, где создается хранилище конфигурации.
• Полный доступ к директории, где хранятся журналы ArcGIS Server и право создания этой папки, если она еще не создана вручную. По умолчанию используется директория C:\arcgisserver\logs.
• Права чтения директорий, содержащих файлы подключения к базе данных, которые вы зарегистрируете при помощи сайта ArcGIS Server перед публикацией веб-сервисов. Если вы используете систему проверки подлинности Windows вместо проверки подлинности базы данных, то вам также потребуется выдать для учетной записи права доступа к учётной записи ArcGIS Server.
• Права доступа чтения для папок ГИС-данных, которые вы зарегистрируете при помощи сайта ArcGIS Server перед публикацией веб-сервисов. Если разрешить процессу публикации копировать данные на сервер (см. раздел Автоматическое копирование данных на сервер при публикации), то данные размещаются в серверных директориях, для которых учетной записи ArcGIS Server уже были назначены права при создании сайта. Применять дополнительные права доступа к исходным серверным директориям необязательно.
• Права с полным управлением к папке Python27. По умолчанию, эта директория находится в C:\Python27, если вы устанавливали ArcGIS Server на диск C:.

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

Учетной записи ArcGIS Server не нужно быть в группе Администраторы Windows на какой-либо из машин вашего сайта.

Изменение учетной записи ArcGIS Server

Вам не нужно повторно запускать установку ArcGIS Server для изменения учетной записи ArcGIS Server. После установки вы можете изменить учетную запись, запустив утилиту Configure ArcGIS Server Account utility, которая входит в комплект программного обеспечения. Это можно сделать и в ответ на изменение политики безопасности или при устранении неполадок сервера.

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

Чтобы изменить учетную запись ArcGIS Server с помощью утилиты, выполните следующие действия:

1. На одной машине сайта ArcGIS Server откройте утилиту Configure ArcGIS Server Account.
2. Введите имя пользователя и пароль для учетной записи, которую вы желаете назначить для учетной записи ArcGIS Server. Щелкните Далее.
3. Дополнительно укажите корневой каталог сервера и местоположения хранилища конфигурации, используемого вашим сайтом ArcGIS Server. Пример
   • Если корневой каталог вашего сайта и хранилище конфигурации доступны через локальные пути с именами диска и вы указали эти директории в утилите, то она автоматически выдаст права доступа чтения и записи новой учетной записи для директорий.
   • Если корневой каталог вашего сайта и хранилище конфигурации используют сетевые пути (UNC), оставьте эти поля пустыми и выдайте права доступа чтения и записи новой учетной записи для директорий вручную после завершения работы утилиты.
4. При необходимости укажите положение директории журналов. Если вы ввели местоположение, то утилита автоматически предоставит новой учетной записи права для чтения и записи для данной директории. Если вы оставите данное поле пустым, то вам потребуется выдать вручную права доступа чтения и записи новой учетной записи для директорий каждой машины вашего сайта ArcGIS Server в вашем развертывании вручную после завершения работы утилиты.

   Директория журналов не имеет отношения к местоположению директорий сервера или хранилища конфигураций. Если вы изменили местоположение директории журналов, постарайтесь сохранить местоположение на корневом уровне вашего сайта ArcGIS Server. Нельзя задать сетевую директорию в качестве местоположения журналов. Дополнительная информация приведена в разделе О журналах сервера.

5. Нажмите Далее.
6. В диалоговом окне Экспорт файла конфигурации сервера рассмотрите следующие возможности:
   • Если в вашем развертывании имеется несколько сайтов ArcGIS Server, выполните экспорт файла конфигурации. Это обезопасит вас от необходимости ввода информации в утилиту для оставшихся компьютеров вашего сайта. Таким образом, вы можете гарантировать, что учетная запись ArcGIS Server настроена одинаково на всех компьютерах вашего сайта. Укажите безопасное местоположение для файла конфигурации и нажмите Далее.
   • Вы можете экспортировать и сохранить файл конфигурации, если у вас есть одна машина в сайте ArcGIS Server, файл конфигурации можно сохранить опционно. Убедитесь, что файл сохранен в безопасном местоположении, и щёлкните Далее.
7. На итоговой панели просмотрите свойства учетной записи и нажмите Настроить. Ваша новая учетная запись будет настроена как учетная запись ArcGIS Server. Закройте утилиту.
8. Запустите утилиту на каждом из оставшихся компьютеров вашего сайта. Вы можете указать утилите файл конфигурации, созданный ранее, или ввести информацию, которую вы предоставили выше.
9. Выдайте новой учетной записи права чтения директорий, содержащих файлы данных и файлы подключения к базе данных, которые вы зарегистрировали на сайте ArcGIS Server. Если вы используете аутентификацию Windows вместо аутентификации средствами базы данных, то вам также потребуется выдать для учетной записи права доступа записи для файлов подключения.

Изменение учетной записи ArcGIS Server из командной строки

Чтобы не запускать мастер утилиты Configure ArcGIS Server Account, вы можете запустить исполняемый файл из командной строки. Утилита командной строки ServerConfigurationUtility.exe устанавливается в <ArcGIS Server installation location>\bin. Вы можете собрать в скрипт обновления на учётной записи ArcGIS Server после применения обновлений в политике безопасности вашей организации.

Доступны следующие параметры:

ServerConfigurationUtility [/readconfig] | [/writeconfig] | [/username] | [/password] | [/rsdir] | [/csdir] | [/logsdir]

• <readconfig> – Необязательный путь к файлу конфигурации, сохраненный при предыдущем выполнении утилиты.
• <writeconfig> – Необязательный путь к папке, где будет сохранен файл конфигурации, чтобы можно было применить те же свойства при последующих запусках утилиты.
• <username> – имя учетной записи ArcGIS Server.
• <Password> – пароль учётной записи ArcGIS Server.
• <rsdir> – Путь к корневому каталогу сервера. Это необязательный параметр, но если вы его не укажете, вам придется вручную предоставить учетной записи ArcGIS Server права чтения и записи в корневом каталоге сервера.
• <csdir> – Каталог хранилища конфигурации. Это необязательный параметр, но если вы его не укажете, вам придется вручную предоставить учетной записи ArcGIS Server права чтения и записи в хранилище конфигурации.
• <logsdir> – Путь к каталогу журналов ArcGIS Server. Это необязательный параметр, но если вы его не укажете, вам придется вручную предоставить учетной записи ArcGIS Server права чтения и записи в директории журналирования.

Пример: ServerConfigurationUtility /writeconfig c:\temp\myconfig.xml /username arcgisnew /password secret /rsdir c:\arcgisserver\directories /csdir c:\arcgisserver\config-store /logsdir c:\arcgisserver\logs

Определение региональных настроек учетной записи ArcGIS Server

Локаль учетной записи ArcGIS Server выбирается согласно локали учетной записи Windows, заданной в процессе установки. Если учетная запись не указана и используется учетная запись по умолчанию (arcgis), ее локаль определяется настройками ОС. Локаль имеет важное значение, поскольку все сообщения, генерируемые ArcGIS Server, такие как журналы, отображаются на языке учетной записи ArcGIS Server. Чтобы сообщения отображались на другом языке или с другим форматом, вам надо изменить язык отображения для учётной записи ArcGIS Server на каждой машине вашего сайта ArcGIS Server. См. документацию Microsoft по определённым инструкциям для используемой вами версии операционной системы.

azure-docs.ru-ru/reference-connect-accounts-permissions.md at master · MicrosoftDocs/azure-docs.ru-ru · GitHub

title	description	services	documentationcenter	author	manager	editor	ms.reviewer	ms.assetid	ms.service	ms.workload	ms.tgt_pltfrm	ms.devlang	ms.topic	ms.date	ms.subservice	ms.author	ms.collection	ms.openlocfilehash	ms.sourcegitcommit	ms.translationtype	ms.contentlocale	ms.lasthandoff	ms.locfileid
Azure AD Connect выполняет следующие функции: учетные записи и разрешения | Документация Майкрософт	В этом разделе описаны используемые и созданные учетные записи, а также необходимые разрешения.	active-directory		billmath	daveba		cychua	b93e595b-354a-479d-85ec-a95553dd9cc2	active-directory	identity	na	na	reference	01/04/2021	hybrid	billmath	M365-identity-device-management	1f7466931537745fb188a3bdb05646bff19912e8	772eb9c6684dd4864e0ba507945a83e48b8c16f0	MT	ru-RU	03/20/2021	103466258

Учетные записи, используемые для Azure AD Connect

Azure AD Connect использует 3 учетные записи, чтобы синхронизировать данные из локальной среды или Windows Server Active Directory с Azure Active Directory. Эти учетные записи приведены ниже.

• Учетная запись соединителя AD DS: используется для чтения и записи информации в Windows Server Active Directory.

• Учетная запись службы ADSync: используется для запуска службы синхронизации и доступа к базе данных SQL.

• Учетная запись соединителя Azure AD: используется для записи сведений в Azure AD.

Помимо этих трех учетных записей, используемых для запуска Azure AD Connect, для установки Azure AD Connect потребуются также следующие учетные записи. а именно:

• Локальная учетная запись администратора: администратор, который устанавливает Azure AD Connect и имеет права локального администратора на компьютере.

• Учетная запись администратора предприятия AD DS: используется, если нужно создать учетную запись соединителя Azure AD, описанную выше.

• Учетная запись глобального администратора Azure AD: используется для создания учетной записи соединителя Azure AD и настройки Azure AD. Учетные записи глобального администратора можно просмотреть в портал Azure. См. раздел список назначений ролей Azure AD.

• Учетная запись SQL SA (необязательная): используется для создания базы данных ADSync при использовании полной версии SQL Server. Этот сервер SQL Server может быть локальным или удаленным для установки Azure AD Connect. Этой учетной записью может быть учетная запись администратора предприятия. Внешнюю подготовку базы данных может выполнять администратор SQL, а установку — администратор Azure AD Connect с правами владельца базы данных. Дополнительные сведения см. в статье Установка Azure AD Connect с использованием делегированных разрешений администратора SQL.

[!IMPORTANT] Начиная со сборки 1.4.###.#, учетные записи администратора предприятия и администратора домена больше не поддерживаются как учетные записи соединителя AD DS. Если вы попытаетесь ввести учетную запись администратора предприятия или администратора домена при задании параметра Использовать существующую учетную запись, появится сообщение об ошибке.

[!NOTE] Поддерживается управление административными учетными записями, которые используются в Azure AD Connect, из административного леса ЕСАЕ (иногда называется «Красный лес»). Выделенные административные леса позволяют организациям размещать административные учетные записи, рабочие станции и группы в среде с более надежными элементами управления безопасностью, чем в обычной рабочей среде. Дополнительные сведения о выделенных административных лесах см. в разделе Подход к архитектуре административного леса ESAE.

[!NOTE] После начальной установки роль глобального администратора уже не нужна, и можно сохранить только учетную запись с ролью Учетные записи синхронизации каталогов. Это не означает, что вам нужно удалить учетную запись с ролью глобального администратора. Лучше заменить ее на роль с меньшим уровнем привилегий, так как полное удаление этой учетной записи принесет вам трудности, если когда-либо придется повторно запустить мастер. Уменьшив привилегии этой роли, вы всегда сможете вернуть их обратно, чтобы применить мастер Azure AD Connect снова.

Установка Azure AD Connect

Мастер установки Azure AD Connect предлагает два разных варианта.

• Для варианта «Стандартные параметры» мастеру требуются дополнительные привилегии. Это нужно для того, чтобы мастер мог настроить конфигурацию автоматически и вам не пришлось создавать пользователей или настраивать разрешения.
• В случае с вариантом «Настраиваемые параметры» мастер предлагает вам самостоятельно выбрать различные параметры. Однако в некоторых ситуациях вы должны убедиться, что у вас есть необходимые разрешения.

Установка со стандартными параметрами

В режиме «Стандартные параметры» мастер установки запрашивает следующее:

• учетные данные администратора предприятия AD DS;
• учетные данные глобального администратора Azure AD.

Учетные данные администратора предприятия AD DS

Учетная запись администратора предприятия AD DS используется для настройки локальной среды Active Directory. Эти учетные данные используются только во время установки и не используются после ее завершения. Именно учетные данные администратора предприятия, а не администратора домена, должны использоваться для настройки разрешений в Active Directory во всех доменах.

Если вы выполняете обновление из DirSync, учетные данные администратора предприятия в AD DS применяются для сброса пароля учетной записи, используемой средством DirSync. Кроме того, вам требуются учетные данные глобального администратора в Azure AD.

Учетные данные глобального администратора Azure AD

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

Разрешения учетной записи соединителя AD DS, необходимые для режима «Стандартные параметры»

Учетная запись соединителя AD DS со стандартными параметрами, созданная для чтения и записи в данных в Windows Server AD, имеет следующие разрешения:

Разрешение	Используется для
Репликация изменений каталога Репликация всех изменений каталога	Синхронизация хэша паролей
Чтение и запись всех свойств для пользователя	Гибридный импорт и обмен
Чтение и запись всех свойств для iNetOrgPerson	Гибридный импорт и обмен
Чтение и запись всех свойств для группы	Гибридный импорт и обмен
Чтение и запись всех свойств для контакта	Гибридный импорт и обмен
Сброс пароля	Подготовка к включению компонента обратной записи паролей

Сводка мастера экспресс-установки

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

Страница мастера	Собираемые учетные данные	Необходимые разрешения	Область использования
Недоступно	Пользователь, запускающий мастер установки	Администратор локального сервера	Создание учетной записи службы ADSync, используемой для запуска службы синхронизации.
Подключение к Azure AD	Учетные данные каталога Azure AD	Роль глобального администратора в Azure AD	Включение синхронизации в каталоге Azure AD. Создание учетной записи соединителя Azure Active Directory, которая используется для выполнения текущих операций синхронизации в Azure Active Directory.
Подключение к AD DS	Учетные данные локальной службы Active Directory	Член группы администраторов предприятия в Active Directory	Создание учетной записи соединителя AD DS в доменных службах Active Directory и назначение ей разрешений. Эта созданная учетная запись используется для чтения и записи данных каталога во время синхронизации.

Параметры выборочной установки

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

Сводка мастера выборочной установки

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

Страница мастера	Собираемые учетные данные	Необходимые разрешения	Область использования
Недоступно	Пользователь, запускающий мастер установки	Администратор локального сервера При использовании полной версии SQL Server пользователь должен быть системным администратором (SA) в SQL	По умолчанию создает локальную учетную запись, которая используется в качестве учетной записи службы модуля синхронизации. Эта учетная запись создается только в том случае, если администратор не указывает определенную учетную запись.
Установка служб синхронизации (параметр «Учетная запись службы»)	Учетные данные AD или локального пользователя	Разрешения пользователя предоставляет мастер установки.	Если администратор указал учетную запись, она будет использоваться в качестве учетной записи службы синхронизации.
Подключение к Azure AD	Учетные данные каталога Azure AD	Роль глобального администратора в Azure AD	Включение синхронизации в каталоге Azure AD. Создание учетной записи соединителя Azure Active Directory, которая используется для выполнения текущих операций синхронизации в Azure Active Directory.
Подключение к каталогам	Учетные данные локальной службы Active Directory для каждого леса, подключенного к Azure AD.	Разрешения зависят от включенных вами функций. Дополнительные сведения см. в разделе «Создание учетной записи Azure AD DS».	Эта учетная запись используется для чтения и записи данных каталога во время синхронизации.
Серверы AD FS	Мастер собирает учетные данные для каждого сервера в списке, если учетных данных пользователя, работающего с мастером, недостаточно для подключения.	Администратор домена	Установка и настройка роли сервера AD FS.
Прокси-серверы веб-приложений	Мастер собирает учетные данные для каждого сервера в списке, если учетных данных пользователя, работающего с мастером, недостаточно для подключения.	Локальный администратор на целевом компьютере	Установка и настройка роли сервера WAP.
Учетные данные доверия прокси-сервера	Учетные данные доверия службам федерации (учетные данные, которые прокси-сервер использует для получения сертификата доверия из служб федерации)	Учетная запись домена, принадлежащая локальному администратору сервера AD FS	Начальная регистрация сертификата доверия FS-WAP.
Учетная запись службы AD FS (параметр «Использовать учетную запись пользователя домена»)	Учетные данные пользователя AD	Пользователь домена	Указанная учетная запись пользователя Azure AD используется для входа в службу AD FS.

Создание учетной записи соединителя AD DS

[!IMPORTANT] Новый модуль PowerShell с именем ADSyncConfig.psm1 был представлен в сборке 1.1.880.0 (выпущенной в августе 2018 года). Эта сборка включает в себя коллекцию командлетов, которые помогут вам настроить правильные разрешения Active Directory для учетной записи соединителя Azure AD DS.

Дополнительные сведения см. в статье Azure AD Connect выполняет следующие функции: Настройка разрешений учетной записи соединителя AD DS

Учетная запись, которая указывается на странице Подключить каталоги, на момент установки должна уже существовать в Active Directory. В Azure AD Connect начиная с версии 1.1.524.0 есть возможность разрешить мастеру Azure AD Connect создать учетную запись соединителя AD DS, используемую для подключения к Active Directory.

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

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

Обновление

При обновлении с одной версии Azure AD Connect до нового выпуска требуются следующие разрешения:

[!IMPORTANT] Начиная со сборки 1.1.484 в Azure AD Connect появилась регрессионная ошибка, из-за которой требуются разрешения администратора для обновления базы данных SQL. Эта ошибка будет устранена в сборке 1. 1.647. При обновлении до этой сборки вам потребуются разрешения системного администратора. Разрешений владельца базы данных недостаточно. Если вы попытаетесь обновить Azure AD Connect без разрешений системного администратора, обновление завершится ошибкой, а Azure AD Connect будет работать неправильно. Корпорация Майкрософт знает о наличии этой ошибки и работает над ее устранением.

Основной	Необходимые разрешения	Используется для
Пользователь, запускающий мастер установки	Администратор локального сервера	Обновление двоичных файлов.
Пользователь, запускающий мастер установки	Член ADSyncAdmins	Внесение изменений в правила синхронизации и другие настройки.
Пользователь, запускающий мастер установки	При использовании полной версии SQL Server: разрешения DBO (или схожие) базы данных модуля синхронизации	Внесение изменений на уровне базы данных, например обновление таблицы с помощью новых столбцов.

Дополнительные сведения о созданных учетных записях

Учетная запись соединителя AD DS

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

Если вы используете настраиваемые параметры, то перед началом установки вам понадобится создать учетную запись. Ознакомьтесь с разделом «Создание учетной записи соединителя AD DS».

Учетная запись службы ADSync

Служба синхронизации может работать от имени разных учетных записей. Она может быть запущена от имени учетной записи виртуальной службы (VSA), групповой управляемой учетной записи службы (gMSA/sMSA) или учетной записи обычного пользователя. Поддерживаемые параметры изменены в сборках Connect начиная с апреля 2017 г. при выполнении новой установки. При обновлении с более ранней версии Azure AD Connect эти дополнительные параметры недоступны.

Тип учетной записи	Вариант установки	Описание
Учетная запись виртуальной службы	быстрая и настраиваемая установки, апрель 2017 г. и более поздние версии	Это параметр, используемый для всех быстрых установок, за исключением установки на контроллер домена. При настраиваемой установке этот тип учетной записи используется по умолчанию, если не указано иное.
Групповая управляемая учетная запись службы	Настраиваемая, сборка за апрель 2017 г. и более поздние версии	Если используется удаленный сервер SQL, то рекомендуется использовать групповую управляемую учетную запись службы.
Учетная запись пользователя	быстрая и настраиваемая установки, апрель 2017 г. и более поздние версии	Учетная запись пользователя с префиксом AAD_ создается только во время установки при установке на Windows Server 2008 и при установке на контроллере домена.
Учетная запись пользователя	быстрая и настраиваемая установки, март 2017 г. и более ранние версии	Локальная учетная запись с префиксом AAD_ создается во время установки. При пользовательской установке можно указать другую учетную запись.

При использовании Connect сборки за март 2017 года или более ранней не следует сбрасывать пароль учетной записи службы, так как после этого Windows удалит ключи шифрования из соображений безопасности. Не удается изменить учетную запись на любую другую учетную запись без повторной установки Azure AD Connect. Если происходит обновление до апрельской сборки 2017 г. или более поздней версии, то в ней поддерживается изменение пароля для учетной записи службы, но в то же время нельзя изменить используемую учетную запись.

[!Important] Учетную запись службы можно задать только при первой установке. Изменение учетной записи службы после завершения установки не поддерживается.

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

Условные обозначения

• Жирным показаны параметры по умолчанию, и в большинстве случаев это рекомендуемые параметры.
• Курсивом обозначены рекомендуемые параметры, которые не являются параметрами по умолчанию.
• 2008 — параметр по умолчанию при установке на Windows Server 2008
• Не жирный — поддерживаемый параметр
• Локальная учетная запись — учетная запись локального пользователя на сервере
• Доменная учетная запись — учетная запись пользователя домена
• sMSA — автономная управляемая учетная запись службы
• gMSA — групповая управляемая учетная запись службы

	LocalDB Express	LocalDB или LocalSQL Другой	Удаленная SQL Другой
компьютер, присоединенный к домену	VSA Локальная учетная запись (2008)	VSA Локальная учетная запись (2008) Локальная учетная запись Доменная учетная запись. sMSA,gMSA	gMSA Доменная учетная запись.
Контроллер домена	Доменная учетная запись	gMSA Доменная учетная запись sMSA	gMSA Доменная учетная запись

Учетная запись виртуальной службы

Учетная запись виртуальной службы — особый тип учетной записи, которая не имеет пароля и управляется ОС Windows.

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

Для этой функции требуется Windows Server 2008 R2 или более поздней версии. Если установить Azure AD Connect на Windows Server 2008, то установка будет осуществляться с помощью учетной записи пользователя.

Групповая управляемая учетная запись службы

Если используется удаленный сервер SQL Server, мы рекомендуем использовать групповую управляемую учетную запись службы. Дополнительные сведения о том, как подготовить каталог Active Directory к использованию групповой управляемой учетной записи службы, см. в разделе Обзор групповых управляемых учетных записей служб.

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

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

Для этой функции требуется Windows Server 2012 R2 или более поздней версии. Если необходимо использовать более старую операционную систему и удаленный сервер SQL, то следует использовать учетную запись пользователя.

Учетная запись пользователя

Локальная учетная запись службы создается мастером установки (если только вы не укажете нужную учетную запись в пользовательских параметрах). Эта учетная запись имеет префикс AAD_ и используется для запуска от имени фактической службы синхронизации. Если Azure AD Connect устанавливается на контроллере домена, учетная запись создается в этом домене. Учетная запись службы AAD_ должна быть размещена в домене, если:

• используется удаленный сервер под управлением SQL Server;
• используется прокси-сервер, требующий проверки подлинности.

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

Эта учетная запись используется для безопасного хранения паролей других учетных записей. Эти пароли хранятся в зашифрованном виде в базе данных. Закрытые ключи защищены службами шифрования с закрытым ключом с использованием API защиты данных Windows (DPAPI).

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

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

Учетная запись соединителя Azure AD

Создается учетная запись в Azure AD для использования службой синхронизации. Эту учетную запись можно определить по ее отображаемому имени.

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

При создании этой учетной записи используется длинный сложный пароль, который имеет неограниченный срок действия. Учетной записи назначается специальная роль Учетная запись синхронизации каталогов , которая имеет разрешения только на выполнение задач синхронизации каталогов. Эту встроенную роль можно назначить только в мастере Azure AD Connect. На портале Azure такая учетная запись отображается с ролью Пользователь.

Число учетных записей службы синхронизации в Azure AD не должно превышать 20. Чтобы получить список существующих учетных записей службы Azure AD в Azure AD, выполните следующий командлет Azure AD PowerShell: Get-AzureADDirectoryRole | where {$_.DisplayName -eq "Directory Synchronization Accounts"} | Get-AzureADDirectoryRoleMember

Чтобы удалить неиспользуемые учетные записи службы Azure AD, выполните следующий командлет Azure AD PowerShell: Remove-AzureADUser -ObjectId <ObjectId-of-the-account-you-wish-to-remove>

[!NOTE] Прежде чем использовать приведенные выше команды PowerShell, необходимо установить модуль Azure Active Directory PowerShell для Graph и установить подключение к экземпляру Azure AD с помощью Connect-AzureAD.

Дополнительные сведения о сбросе пароля для учетной записи Azure AD Connect и управлении им см. в статье Изменение пароля учетной записи Azure AD Connect.

Дополнительная документация

Если вы еще не ознакомились с документацией по интеграции локальных удостоверений с Azure Active Directory, см. разделы, на которые ведут ссылки в таблице ниже.

Дальнейшие действия

Узнайте больше об интеграции локальных удостоверений с Azure Active Directory.

Мониторинг

Мониторинг Active Directory

Мониторинг Active Directory и создание/обновление учетных записей MDaemon

Включите эту опцию, чтобы создавать и обновлять учетные записи MDaemon синхронно с Active Directory.

Выполнять мониторинг Active Directory и обновлять адресные книги

Включите эту опцию, чтобы поддерживать в актуальном состоянии публичные записи контактов MDaemon. Стандартные поля публичной записи контакта, такие как почтовый адрес, номера телефонов, контактная информация и т. п., обновляются при изменении соответствующих данных в Active Directory. Таким образом будут отслеживаться многочисленные поля записей контактов. Полный список полей публичной записи контакта, которые можно сопоставить с атрибутами Active Directory, приводится в комментариях в файлеActiveDS.dat. См. также:Обновление публичных адресных книг.

Использовать доменные имена Active Directory при создании учетных записей

Включите эту опцию, чтобы добавлять новые учетные записи, созданные в результате мониторинга Active Directory, в домен, указанный в атрибуте «UserPrincipalName» учетной записи Active Directory. При использовании этой опции, если для учетной записи требуется домен, который в MDaemon еще не создан, новый домен будет создан автоматически. Когда эта опция отключена, MDaemon создает учетные записи вдомене по умолчанию.

Запрашивать новые данные от Active Directory каждые [XX] секунд

Это временной интервал, с которым MDaemon будет осуществлять мониторинг Active Directory на предмет изменений.

Домен Windows для AD-авторизации

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

При удалении учетных записей в Active Directory…

Опции ниже определяют, что будет с учетной записью MDaemon при удалении связанной с ней учетной записи Active Directory.

…ничего не делать

Выберите эту опцию, чтобы не вносить изменений в учетную запись MDaemon при удалении связанной с ней учетная записи Active Directory.

…удалять их также из MDaemon

При выборе этой опции учетная запись MDaemon будет удаляться при удалении связанной с ней учетной записи Active Directory.

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

…отключить учетную запись

Когда выбрана эта опция, учетная запись MDaemon отключается при удалении связанной с ней учетной записи Active Directory. Учетная запись MDaemon по-прежнему будет присутствовать на сервере, но не сможет отправлять или получать почту.

…заморозить учетную запись

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

Замораживать учетные записи MDaemon при отключении связанных записей в Active Directory

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

Когда учетные записи удаляются в AD, они удаляются из общедоступной адресной книги

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

Учетные записи, удаленные вне AD, мониторингом AD не восстанавливаются

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

 

Выполнить полное сканирование Active Directory немедленно

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

См. также:

Active Directory

Active Directory » Авторизация

 

Учетные записи для установки и работы программы

Учетные записи для установки и работы программы

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

Для запуска Консоли Сервера интеграции вы можете использовать следующие учетные записи:

• Если компьютер, на котором установлена Консоль администрирования Kaspersky Security Center, входит в домен Microsoft Windows, для запуска Консоли Сервера интеграции вы можете использовать учетную запись, которая входит в локальную или доменную группу KLAdmins, или учетную запись, которая входит в группу локальных администраторов. Также вы можете использовать учетную запись администратора Сервера интеграции, созданную автоматически при установке Сервера интеграции.
• Если компьютер, на котором установлена Консоль администрирования Kaspersky Security Center, не входит в домен Microsoft Windows или ваша учетная запись не входит в локальную или доменную группу KLAdmins или в группу локальных администраторов, для запуска Консоли Сервера интеграции вы можете использовать только учетную запись администратора Сервера интеграции, созданную автоматически при установке Сервера интеграции.

Гипервизор VMware ESXi

Для установки и работы программы на гипервизоре VMware ESXi требуются следующие учетные записи:

• Для развертывания, удаления и изменения конфигурации SVM требуется учетная запись администратора со следующими правами:
  • Datastore.Allocate space
  • Datastore.Low level file operations
  • Datastore.Remove file
  • Global.Cancel task
  • Global.Licenses
  • Host.Config.Virtual machine autostart configuration
  • Host.Inventory.Modify cluster
  • Network.Assign network
  • Tasks.Create task
  • vApp.Import
  • Virtual machine.Configuration.Add new disk
  • Virtual machine.Configuration.Add or remove device
  • Virtual machine.Configuration.Memory
  • Virtual machine.Interaction.Power Off
  • Virtual machine.Interaction.Power On
  • Virtual machine.Provisioning.Customize
  • Virtual machine.Inventory.Create new (только для VMware vCenter Server 6.0 и VMware vCenter Server 6.5)
  • Virtual machine.Inventory.Remove (только для VMware vCenter Server 6.0 и VMware vCenter Server 6.5)
  • System.Anonymous (только для VMware vCenter Server 6.0)
  • System.Read (только для VMware vCenter Server 6.0)
  • System.View (только для VMware vCenter Server 6.0)
• Для подключения Сервера интеграции к VMware vCenter Server рекомендуется использовать учетную запись, которой назначена предустановленная системная роль ReadOnly.
• Для подключения Сервера интеграции к VMware NSX Manager требуется учетная запись VMware NSX Manager, которой назначена роль Enterprise Administrator.

Права должны быть назначены учетным записям на верхнем уровне иерархии объектов управления VMware – на уровне VMware vCenter Server.

Гипервизор Microsoft Windows Server (Hyper-V)

Для развертывания, удаления и изменения конфигурации SVM на гипервизоре Microsoft Windows Server (Hyper-V) требуется встроенная учетная запись локального администратора или доменная учетная запись, входящая в группу Администраторы Hyper-V. В случае доменной учетной записи вам также требуется выдать права на удаленное подключение и использование следующих пространств имен WMI:

• root\cimv2;
• root\MSCluster;
• root\virtualization;
• root\virtualization\v2 (для версий операционных систем Microsoft Windows для серверов, начиная с версии Windows Server 2012 R2).

Для подключения Сервера интеграции к гипервизору Microsoft Windows Server (Hyper-V) также используется встроенная учетная запись локального администратора или доменная учетная запись, входящая в группу Администраторы Hyper-V, которой предоставлены указанные выше права.

Гипервизор Citrix Hypervisor (Citrix XenServer)

Для установки и работы программы на гипервизоре Citrix Hypervisor (Citrix XenServer) требуются следующие учетные записи:

• Для развертывания, удаления и изменения конфигурации SVM требуется учетная запись с правами Pool Admin.
• Для подключения Сервера интеграции к гипервизору Citrix Hypervisor (Citrix XenServer) рекомендуется использовать учетную запись с ролью Read Only.

Гипервизор KVM

Для установки и работы программы на гипервизоре KVM требуются следующие учетные записи:

• Для развертывания, удаления и изменения конфигурации SVM требуется учетная запись root или учетная запись, которая имеет право выполнять действия от имени учетной записи root.
• Для подключения Сервера интеграции к гипервизору KVM рекомендуется использовать учетную запись непривилегированного пользователя, которой разрешен доступ к Unix-сокету «только для чтения» (libvirt-sock-ro) службы libvirtd (libvirtd daemon).

Гипервизор Proxmox VE

Для установки и работы программы на гипервизоре Proxmox VE требуются следующие учетные записи:

• Для развертывания, удаления и изменения конфигурации SVM требуется учетная запись root или учетная запись, которая имеет право выполнять действия от имени учетной записи root.
• Для подключения Сервера интеграции к гипервизору Proxmox VE рекомендуется использовать учетную запись, которой предоставлен доступ с ролью PVEAuditor к корневой директории (/) и всем дочерним директориям.

Гипервизор Р-Виртуализация

Для установки и работы программы на гипервизоре Р-Виртуализация требуются следующие учетные записи:

• Для развертывания, удаления и изменения конфигурации SVM требуется учетная запись с ролью «Главный администратор».
• Для подключения Сервера интеграции к серверу управления виртуальной инфраструктурой Скала-Р Управление рекомендуется использовать учетную запись с ролью «Мониторинг инфраструктуры».

Гипервизор HUAWEI FusionCompute CNA

Для установки и работы программы на гипервизоре HUAWEI FusionCompute CNA требуются следующие учетные записи:

• Для развертывания, удаления и изменения конфигурации SVM требуется учетная запись с ролью VMManager.
• Для подключения Сервера интеграции к HUAWEI FusionCompute VRM рекомендуется использовать учетную запись с ролью Auditor.

Гипервизор Nutanix AHV

Защита виртуальной инфраструктуры на платформе Nutanix Acropolis поддерживается только в обновлениях 5.1.1, 5.1.2 и 5.1.3 программы Kaspersky Security.

Для установки и работы программы на гипервизоре Nutanix AHV требуются следующие учетные записи:

• Для развертывания, удаления и изменения конфигурации SVM требуется учетная запись с ролью Cluster Admin.
• Для подключения Сервера интеграции к Nutanix Prism рекомендуется использовать учетную запись с ролью Viewer.

В начало

Шаг 2. Подключение к Серверу интеграции

Шаг 2. Подключение к Серверу интеграции

На этом шаге выполняется подключение к Серверу интеграции для получения информации о виртуальной инфраструктуре VMware.

Если компьютер, на котором установлена Консоль администрирования Kaspersky Security Center, входит в домен и ваша доменная учетная запись входит в группу KLAdmins или в группу локальных администраторов на компьютере, где установлен Сервер интеграции, для подключения к Серверу интеграции по умолчанию используется ваша доменная учетная запись. Флажок Использовать доменную учетную запись установлен по умолчанию.

Если вы хотите использовать учетную запись администратора Сервера интеграции (admin), снимите флажок Использовать доменную учетную запись и введите пароль администратора в поле Пароль.

Если компьютер, на котором установлена Консоль администрирования Kaspersky Security Center, не входит в домен или компьютер входит в домен, но ваша доменная учетная запись не входит в группу KLAdmins или в группу локальных администраторов на компьютере, где установлен Сервер интеграции, для подключения к Серверу интеграции вы можете использовать только учетную запись администратора Сервера интеграции (admin). Введите пароль администратора в поле Пароль.

Если для подключения к Серверу интеграции вы используете учетную запись администратора Сервера интеграции (admin), вы можете сохранить пароль администратора. Для этого установите флажок Сохранить пароль. При следующем подключении к этому Серверу интеграции используется сохраненный пароль администратора. Если вы снимаете флажок, установленный при предыдущем подключении к Серверу интеграции, Kaspersky Security удаляет ранее сохраненный пароль администратора Сервера интеграции.

Флажок Сохранить пароль может быть недоступен, если на компьютере, на котором установлена Консоль администрирования Kaspersky Security Center, установлены обновления Windows KB 2992611 и / или KB 3000850. Чтобы восстановить возможность сохранения пароля администратора, вы можете удалить эти обновления Windows или внести изменения в реестр операционной системы, как описано в Базе знаний.

Перейдите к следующему шагу мастера создания задачи.

Мастер создания задачи проверяет SSL-сертификат, полученный от Сервера интеграции. Если полученный сертификат содержит ошибку, откроется окно Проверка сертификата с сообщением об ошибке. SSL-сертификат используется для установки защищенного соединения с Сервером интеграции. При возникновении проблем с SSL-сертификатом рекомендуется убедиться в безопасности используемого канала передачи данных. Чтобы посмотреть информацию о полученном сертификате, нажмите на кнопку Посмотреть полученный сертификат в окне с сообщением об ошибке. Вы можете установить полученный сертификат в качестве доверенного, чтобы при следующем подключении к Серверу интеграции не получать сообщение об ошибке сертификата. Для этого установите флажок Установить полученный сертификат и больше не показывать предупреждения для <адрес Сервера интеграции>.

Чтобы продолжить подключение, нажмите на кнопку Продолжить в окне Проверка сертификата. Если вы установили флажок Установить полученный сертификат и больше не показывать предупреждения для <адрес Сервера интеграции>, полученный сертификат сохраняется в реестре операционной системы на компьютере, где установлена Консоль администрирования Kaspersky Security Center. При этом выполняется проверка ранее установленного доверенного сертификата для этого Сервера интеграции. Если полученный сертификат не соответствует ранее установленному сертификату, откроется окно для подтверждения замены ранее установленного сертификата. Чтобы заменить ранее установленный сертификат на сертификат, полученный от Сервера интеграции, и продолжить подключение, нажмите на кнопку Да в этом окне.

После того, как подключение будет установлено, откроется окно Список серверов VMware vCenter. Выберите сервер VMware vCenter, соответствующий кластеру KSC, для SVM которого вы создаете задачу выборочной проверки, и нажмите на кнопку ОК.

В начало

Блокировка учетной записи пользователя Active Directory, анализ и решение

Добрый день! Уважаемые читатели и гости, крупного IT блога Pyatilistnik.org. В прошлый раз мы с вами рассматривали границы применения групп Active Directory, и надеюсь вы разобрались, где и какие следует использовать. Сегодня я хочу рассмотреть, очень частую и жизненную ситуацию, которая есть в любой доменной среде, а именно блокировка учетной записи Windows в Active Directory. Данную проблему вы легко встретите на предприятиях, где есть свои политики PSO и политики смены паролей. Так, что давайте прокачаем свои знания и научимся разбираться в данной ситуации.

Причина блокировки пользователя Active Directory

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

Вот так вот выглядит сообщение о блокировке:

Учетная запись пользователя заблокирована и не может быть использована для входа в сеть (The referenced account is currently locked out and may not be logged on to)

Как видите в моем примере, пользователь по имени Барбоскин Геннадий Викторович не может начать работать, так как залочен.

Если в оснастке Active Directory — Пользователи и компьютеры, посмотреть свойства заблокированной учетной записи на вкладке «Учетная запись», то вы обнаружите статус:

Разблокируйте учетную запись. Учетная запись на этом контроллере домена Active Directory на данный момент заблокирована (Unlock account. This account is currently locked out on this Active Directory Domain Controller).

Ставим галку и разблокируем учетную запись. После этого нужно выявлять причины.

Из основных причин блокировки я могу выделить:

• Идет подбор пароля, так называемый брутфорс, что в итоге приводит к блокировкам
• Бывают моменты, что человек пришел из отпуска и напрочь забыл свой пароль, ввел его несколько раз не правильно, чем вызвал блокирование
• После изменения пароля, у пользователя остались старые подключения WIFI на компьютере или телефоне со старыми учетными данными, которые пытаются автоматически подключиться к сервисам компании, это является основной причиной блокировки в Active Directory
• Как и в случае с WIFI, у пользователя после смены пароля, могут быть закэшированные, старые пароли в доступах к сетевым шарам, Outlook календарям и другим программам, которые однажды попросили ввести логин и пароль.
• Иногда бывают задания в планировщике Windows, которые запускались от имени пользователя, а не системы
• Забытые сессии на удаленном рабочем столе, был у меня случай когда у пользователя были права и он подключался по RDP к серверу. потом у него права забрали, а сессию разлогинить забыли, в итоге у него меняется пароль и его начинает каждый день по 5-10 раз блокировать, пака сессию не убили, проблема была актуальной.
• Сохраненные пароли в браузерах
• Службы работающие из под доменной учетной записи

Где настраивается политика блокировки учетных записей в домене

По рекомендациям компании Microsoft, политику блокировки учетной записи Windows настраивают на уровне домена, и чаще всего используют для этого уже имеющуюся политику «Default Domain Policy».  Открываем редактор групповой политики и щелкаем правым кликом мыши по политике «Default Domain Policy», из контекстного меню выберите пункт «Изменить».

Переходим с вами по пути: Конфигурация компьютера — Политики — Конфигурация Windows -> Параметры безопасности -> Политики учетных записей -> Политики блокировки учетных записей (Computer Configuration -> Windows Settings -> Security Settings -> Account Policy -> Account Lockout Policy)

Тут в политике будет три пункта:

• Время до сброса счетчика блокировки (Reset account lockout counter after) — в данном параметре задается, через какое количество времени система обнулит счетчик неудачных попыток авторизации. (Этот параметр безопасности определяет количество минут, которые должны пройти после неудачной попытки входа в систему до того, как счетчик неудачных попыток входа будет сброшен до 0. Допустимые значения: от 1 до 99999 минут. Если определено пороговое значение блокировки учетной записи, то время сброса должно быть меньше или равно длительности блокировки учетной записи. ). В моем примере я настроил политику «Время до сброса счетчика блокировки» на 10 минут, думаю больше не стоит.

• Пороговое значение блокировки (Account lockout threshold) — Тут вы задаете, сколько будет допустимых неправильных попыток ввода, после превышения которых учетная запись Windows будет заблокирована (Количество неудачных попыток входа в систему может составлять от 0 до 999. Если установить это значение равным 0, то учетная запись никогда не будет разблокирована.Неудачные попытки ввода паролей на рабочих станциях или серверах-членах домена, заблокированных с помощью клавиш CTRL+ALT+DELETE или с помощью защищенных паролем заставок, считаются неудачными попытками входа в систему).  Я в своей политике задал пороговое значение блокировки равным 5-ти, этого думаю хватит, чтобы правильно ввести свой пароль.

• Продолжительность блокировки учетной записи (Account lockout duration) — ну тут все просто, собственно время блокировки учетной записи Windows в Active Directory. Допустимые значения: от 0 до 99999 минут. Если продолжительность блокировки учетной записи равна 0, то учетная запись будет заблокирована до тех пор, пока администратор не разблокирует ее. Если определено пороговое значение блокировки учетной записи, то длительность блокировки учетной записи должна быть больше или равна времени сброса.

Как выяснить причину блокировки учетной записи

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

Про аудит Active Directory я подробно рассказывал, можете посмотреть по ссылке, тут я приведу легкую его выдержку, для полноты статьи. Нам нужно включить политику аудита входа, на уровне домена. (Так же вы можете подробно почитать про расширенный аудит, дающий более тонкие настройки https://technet.microsoft.com/ru-ru/library/mt431761%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396)

Включение политики аудита входа

Открываем редактор групповой политики и находим в нем дефолтную политику «Default Domain Policy», открываем ее и переходим по такому пути.

Конфигурация компьютера — Политики — Конфигурация Windows -> Параметры безопасности -> Локальные политики -> Политики аудита

Тут будут такие политики:

1. Аудит входа в систему
2. Аудит доступа к объектам
3. Аудит доступа к службе каталогов
4. Аудит изменений политики
5. Аудит использования привилегий
6. Аудит отслеживания процессов
7. Аудит системных событий
8. Аудит событий входа в систему
9. Аудит управления учетными записями

Нас будет интересовать включение аудита входа в систему, именно данный вид будет генерировать события 4771 и 4624. Открываем ее и ставим галки «Успех и отказ»

Так же советую задать политику аудита событий входа в систему, так же установите «Успех и отказ»

Ну и настроим еще таким же способом «Аудит управления учетными записями«, чтобы мы видели события с кодом 4740.

Когда политика настроена, то вы можете ее принудительно обновить или дождаться автоматического обновления в течении 90-120 минут.

Какие события отслеживать в журнале безопасность

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

• 4771 — Это событие возникает каждый раз, когда не удается центром распространения ключей для выдачи Kerberos билетов предоставить билета (TGT). Это может произойти, когда контроллер домена не установлен сертификат для проверки подлинности смарт-карты (например, с помощью «Контроллера домена» или «Проверка подлинности контроллера домена» шаблона), истек срок действия пароля пользователя или неправильный пароль был предоставленные. 4771 на контроллере домена указывает на неудачную попытку войти через Kerberos на рабочей станции с доменной учетной записью. (Подробнее про 4771 https://docs.microsoft.com/ru-ru/windows/security/threat-protection/auditing/event-4771)

• 4776 — Событие 681/4776 на контроллере домена указывает на неудачную попытку входа в систему через NTLM с доменной учетной записью. Код ошибки указывает, почему именно аутентификация была неудачной. Если происходит сбой попытки проверки учетных данных, вы увидите, что событие отказов с значение параметра Код ошибки не равно «0x0» (Подробнее про событие 4476 https://docs.microsoft.com/ru-ru/windows/security/threat-protection/auditing/event-4776)

• 4740 — Учетная запись указанного пользователя была заблокирована после нескольких попыток входа (Подробнее про событие 4740 https://docs. microsoft.com/ru-ru/windows/security/threat-protection/auditing/event-4740)
• 4662 — Это событие создается только в том случае, если соответствующие SACL настроен для объекта Active Directory и выполнить операцию не удалось (Подробнее https://docs.microsoft.com/ru-ru/windows/security/threat-protection/auditing/event-4662).

Как удобно отслеживать события блокировки

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

Я вам рассказывал про набор утилит от компании Microsoft под названием Active Directory ALTools. Там была утилита LockoutStatus.exe. В задачи которой и входило определение статуса пользовательской учетной записи, заблокирована она или нет, и если до, то на каком контроллере домена. Скачайте ее и запустите. Нажимаете пункт меню «File — Select Target», для того чтобы выбрать логин нужной учетной записи.

В поле «Target User Name» вы указываете логин пользователя, кто подвергся блокировке в Active Directory.

На выходе вы получите отчет по всем контроллерам в домене, о статусе вашей учетной записи. Как видите, мой Барбоскин Геннадий Викторович заблокирован и имеет статус «Locked», видно количество попыток неправильного ввода пароля (Bad Pwd Count) и на каких контроллерах домена, на них мы и будем искать нужные нам события, о которых я говорил выше.

Открываем просмотр событий на нужном контроллере домена. Переходим в журнал «Безопасность (Security)» именно в нем кроется причина блокировки учетной записи Барбоскина Геннадия. Так как событий огромное количество, то нам нужно отфильтровать наш журнал событий. Для этого есть кнопка «Filter Current Log (Фильтр текущего журнала)», она позволит нам выбрать только те события, которые нам нужны.

В поле «Logged (Дата)» указываем за какой срок нужны данные, я укажу 12 часов, и в поле все события, укажем номер ID 4740 и нажимаем «Ок»

Видим нашлось 50 событий, но может быть и больше и чтобы ускорить поиск нужного события, мы воспользуемся поисков, для этого нажмите кнопку «Find (Поиск)»

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

В итоге у меня нашлось событие с кодом 4740, из которого видна причина блокировки учетной записи. В данном случае это рабочая станция с именем SVTTSETMAIN01, это тестовая виртуальная машина, как видите тут статус «A user account was locked out», можно переходить на эту машину и смотреть в чем там дело.

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

В моей компании используются сервисы Google, такие как G-Sute и общие файловые диски, и вот при смене пароля пользователем, в данных утилитах могут остаться старые данные, в результате чего вы будите видеть в логах в компьютере блокировки имя WORKSTATION. Думаю с событием 4740 все понятно, но оно не всегда показывает подробный источник блокировки, поэтому нужно смотреть событие 4771.

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

Более подробную причину блокировки учетной записи Windows на покажет событие 4771. Сделаем так же фильтрацию и по нему. Основное сообщение тут «Kerberos pre-authentication failed», обратите внимание тут есть IP-адрес, что уже хорошо, это дополнительная информация, показывающая территориальный источник. В ошибка есть код отказа Kerberos, таблица была представлена выше.

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

Кстати получив IP-адрес вы можете посмотреть его mac адрес на DHCP сервере или же на сетевом оборудовании, например, Cisco, я показывал как там узнать mac-адрес.

Далее с помощью специальных сервисов можно определить, что за производитель у данного mac-адреса, сайтов в интернете полно, которые вам помогу, например, https://2ip.ua/ru/services/information-service/mac-find. Будет полезно с мобильными устройствами.

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

Как видите утилита от компании Mirosoft отлично работает, но можно посмотреть, что-то более удобное, мне нравится утилита Account Lockout Examiner от Netwrix, она бесплатная и позволяет создавать портал для технической поддержки, где они могут видеть кто заблокирован и разблокировать его, а так же причину и она умеет посылать оповещения по электронной почте.

Утилита Account Lockout Examiner проста в установке и потребует от вас две вещи:

1. Указание имени домена для поиска событий блокировки учетных записей Windows
2. Учетные данные от имени которых будет обращение к контроллерам домена

Через некоторое время вы получите табличку со всем пользователями у кого наблюдаются проблемы с блокировкой учеток. Тут вы увидите столбец «Workstation» в котом вы увидите адрес устройства блокировки, есть поле Bad Pwd Count показывающее количество попыток неправильно введенного пароля и дата последнего ввода. В самом конце вы увидите статусы пользователей Not locked или Locked.

Тут же вы можете через правый клик разблокировать пользователя.

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

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

Поиск компьютера блокирующего пользователя через PowerShell

PowerShell, очень мощное средство позволяющее сделать очень многое, вот пример поиска устройства из-за которого блокируется учетная запись. Открываем PowerShell ISE и вводим код:

$Username = ‘username1’
$Pdce = (Get-AdDomain).PDCEmulator
$GweParams = @{
‘Computername’ = $Pdce
‘LogName’ = ‘Security’
‘FilterXPath’ = «*[System[EventID=4740] and EventData[Data[@Name=’TargetUserName’]=’$Username’]]»
}
$Events = Get-WinEvent @GweParams
$Events | foreach {$_.Properties[1].value + ‘ ‘ + $_.TimeCreated}

Единственное не забудьте поменять в $Username = ‘username1’ на своего пользователя, можете скачать уже готовый скрипт у меня. На выходе вы получаете имя компьютера.

Аналогичным образом можно опросить из PowerShell все контроллеры домена в Active Directory:

$Username = ‘username1’
Get-ADDomainController -fi * | select -exp hostname | % {
$GweParams = @{
‘Computername’ = $_
‘LogName’ = ‘Security’
‘FilterXPath’ = "*[System[EventID=4740] and EventData[Data[@Name='TargetUserName']='$Username']]"
}
$Events = Get-WinEvent @GweParams
$Events | foreach {$_.Computer + " " +$_.Properties[1].value + ' ' + $_.TimeCreated}
}

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

Блокировка учетной записи не в домене Active Directory

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

Как разблокировать учетную запись в Windows 10 имея вторую учетку

Если у вас блокировка учетной записи windows 10 уже свершилась, и есть в наличии вторая учетная запись, например у папы своя у мамы своя, то сделайте следующее. Чтобы снять блокировку активируйте учетную запись, откройте окно выполнить, через сочетание клавиш WIN и R и введите название оснастки lusrmgr.msc

Открываем контейнер «Пользователи» и находим нужного нам, переходим в его свойства

Снимаем у нее галку «Заблокировать учётную запись» и нажимаем применить, все учетная запись теперь будет в рабочем состоянии.

Как разблокировать свою учётную запись Windows, если нет административного доступа

Чтобы обойти блокировку учетной записи, можно пойти двумя путями, легким и посложнее. Самый простой способ разблокировать учетную запись не имя административных прав, это воспользоваться загрузочным диском SonyaPE. Когда вы сделаете из него загрузочную флешку и загрузитесь с нее, то получите рабочий стол Windows 7. Там есть утилита Active@ Password Changer Professional 3.8, которая позволит вам включить и сбросить пароль от встроенной учетной записи Администратор, которая есть в любой операционной системе Windows, далее зайдя под ней вы разблокируете нужную нам учетную запись, как я описывал выше.

Как видите этот метод позволяет обойти блокировку учетной записи, но он не единственный, допустим у вас под рукой нет такого диска, как SonyaPE, что делать. Можно воспользоваться встроенными средствами восстановления Windows или же ими, но на любом установочном диске с Windows вашей редакции. В заметке «Как вернуть предыдущую версию виндоус 10» я показал метод попадания в дополнительные инструменты Windows 10.

Либо вы можете попасть в эти утилиты, через инструменты восстановления системы, о которых шла речь в заметке про восстановление загрузчика Windows 10.

В том и в другом случае, вам необходимо открыть командную строку.

В командной строке введите regedit

Выбираем раздел HKEY_LOCAL_MACHINE, после чего в меню «Файл» выберите пункт «Загрузить куст».

 

У вас откроется проводник Windows. В моем компьютере, перейдите по пути Windows\System32\Config. В этой папке лежит файл локальной базы данных пользователей, по имени SAM. Выбираем его и открываем.

Задаем имя новому кусту, для примера это будет 777.

Внутри раздела реестра HKEY_LOCAL_MACHINE теперь наблюдаем новую ветвь 777. Переходим в ней по пути: 777 – SAM – Domains – Account – Users – Names. Тут вам необходимо идентифицировать вашу учетную запись, которая находится в блокировке. В моем примере, это Василий. Выбрав Васю, посмотрите, что по умолчанию он имеет значение 0x3f8

Выбираем теперь куст 00003f8. В правой панели реестра ищем параметр «F» и двойным кликом раскрываем его.

В окошке параметра нам нужна строка 0038. Её первые два значения (у нас это 10 и 00) заменяем.

Двойным кликом щёлкаем по очереди на каждом из двух значений, и когда те выделятся синим, вписываем другие значения. А эти другие значения должны быть 10 и 02 соответственно.

Теперь в окне реестра кликаем на загруженный и отредактированный куст, у нас это 777. И выгружаем его: жмём «Файл», далее «Выгрузить куст». Все необходимые изменения внесены.

Перезагружаем ваш компьютер и пробуем войти под вашей учетной записью, она уже не должна быть заблокирована. На этом все, с вами был Семин Иван, автор и создатель IT блога Pyatilistnik.org.

локальных пользователей и пользователей домена в Windows

Локальные пользователи

В Windows локальный пользователь — это тот, чье имя пользователя и зашифрованный пароль хранятся на самом компьютере. Когда вы входите в систему как локальный пользователь, компьютер проверяет свой собственный список пользователей и свой собственный файл паролей, чтобы узнать, разрешено ли вам войти в систему. Затем сам компьютер применяет все разрешения (например, «может использовать компакт-диск», «можно устанавливать программы») и ограничения (например, «не может устанавливать программы»), назначенные вам для этого компьютера.

Пользователи домена

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

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

Важные соображения

Когда вы входите в свой компьютер в Университете Индианы, если в поле «Вход в:» указано ADS, то вы входите в систему как пользователь домена. Важно помнить, что если вы в конечном итоге удалите свой компьютер из домена, вы не сможете войти в систему, потому что компьютер не сможет получить доступ к контроллеру домена. Если вы планируете удалить свой компьютер из домена (например, переместить компьютер за пределы кампуса), вы должны создать локального пользователя. Дополнительные сведения см. В разделе «Отключение сетевых настроек Windows ADS после выхода из сети IU».

Использование учетной записи пользователя домена в качестве учетной записи для входа в службу — приложения Win32

• 31.05.2018
• 2 минуты на чтение

В этой статье

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

Примечание

Следующая документация предназначена для разработчиков. Если вы — конечный пользователь, ищущий информацию о сообщении об ошибке, связанном с учетными записями пользователей домена, посетите форумы сообщества Microsoft. Для получения информации об управлении учетными записями пользователей домена см. TechNet.

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

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

Экземпляр службы, использующий учетную запись пользователя домена, требует периодических административных действий для поддержания пароля учетной записи. Диспетчер управления службами (SCM) на главном компьютере экземпляра службы кэширует пароль учетной записи для использования при входе в службу.При изменении пароля учетной записи необходимо также обновить кэшированный пароль на главном компьютере, на котором установлена ​​служба. Дополнительные сведения и пример кода см. В разделе «Изменение пароля учетной записи пользователя службы». Вы можете избежать регулярного обслуживания, оставив пароль неизменным, но это повысит вероятность атаки пароля на учетную запись службы. Имейте в виду, что даже несмотря на то, что SCM хранит пароль в защищенной части реестра, он, тем не менее, подвержен атаке.

Учетная запись пользователя домена имеет два формата имени: отличительное имя объекта пользователя в каталоге и формат «\», используемый локальным диспетчером управления службами. Дополнительные сведения и пример кода, который преобразует один формат в другой, см. В разделе «Преобразование форматов имен доменных учетных записей».

Окна

— есть ли разница между DOMAIN \ username и [email protected]?

Предполагая, что у вас есть среда Active Directory:

Я полагаю, что формат обратной косой черты DOMAIN \ USERNAME будет искать в домене DOMAIN объект пользователя, имя учетной записи SAM которого — USERNAME.

В формате UPN имя пользователя @ домен будет искать в лесу объект пользователя, имя принципа пользователя которого — имя пользователя @ домен.

Теперь обычно учетная запись пользователя с именем учетной записи SAM USERNAME имеет UPN USERNAME @ DOMAIN, поэтому в любом формате должна быть указана одна и та же учетная запись, по крайней мере, при условии, что AD полностью работает. Если есть проблемы с репликацией или вы не можете получить доступ к глобальному каталогу, формат обратной косой черты может работать в тех случаях, когда формат UPN не работает. Также могут быть (ненормальные) условия, при которых применяется обратное — например, если контроллеры домена не могут быть достигнуты для целевого домена.

Однако: вы также можете явно настроить учетную запись пользователя на UPN, компонент имени пользователя которого отличается от имени учетной записи SAM, а компонент домена отличается от имени домена.

На вкладке «Учетная запись» в Active Directory «Пользователи и компьютеры» отображается UPN под заголовком «Имя пользователя для входа в систему» ​​и имя учетной записи SAM под заголовком «Имя пользователя для входа в систему (до Windows 2000)». Поэтому, если у вас возникли проблемы с конкретными пользователями, я бы проверил, нет ли расхождений между этими двумя значениями.

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

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

windows server 2008 — путаница с локальными учетными записями пользователей и учетными записями пользователей домена

На имя пользователя всегда можно ссылаться в формате [NetBIOS domain] \ [username]. Для учетной записи локального пользователя доменом всегда является имя компьютера, то есть WS01 \ frank. Для учетной записи пользователя Active Directory это будет NetBIOS-имя домена, то есть WIDGETCO \ frank.

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

Профиль пользователя создается при первом входе учетной записи пользователя на рабочую станцию. Если на этой рабочей станции нет папки профиля с именем пользователя, папка будет создана с именем, содержащим только имя пользователя (т.е.е., C: \ Users \ frank). Если папка профиля с таким именем уже существует, она добавит NetBIOS-имя учетной записи пользователя в новую папку профиля (например, C: \ Users \ frank.WS01 или C: \ Users \ frank.WIDGETCO). Если папка с добавленной доменной частью уже существует, Windows добавит трехзначное число, начинающееся с 000 (т. Е. C: \ Users \ frank.WIDGETCO.000, frank.WIDGETCO.001 и т. Д.).

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

Путь к профилю пользователя хранится в реестре в HKLM \ Software \ Microsoft \ Windows NT \ CurrentVersion \ ProfileList. Вы можете переназначить имя входа пользователя в уже существующую папку профиля, изменив значение ProfileImagePath в подразделе для SID пользователя. Обратите внимание, что у пользователя должны быть соответствующие разрешения на доступ к файлам и кусту реестра, хранящимся в этом профиле.

локальных и доменных учетных записей пользователей

Введение

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

Первоначальный вход в систему

При первоначальном входе в систему пользователю предоставляется возможность войти в систему с локальной или доменной учетной записью! Графический интерфейс не на 100% ясен в этом факте, но это именно то, что происходит.Переход с Windows XP на Windows 7 — еще один шаг, который усложняет эту концепцию. При входе на компьютер с Windows XP пользователь может выбрать домен (или один из многих доверенных доменов) или локальный компьютер, как показано на рисунке 1.

Рисунок 1: Первоначальный вход в Windows XP позволяет пользователям выбрать локальную или доменную учетную запись.

Для Windows 7 изменился вход в систему и параметры стали еще более сложными. На рис. 2 показан компьютер с Windows 7, присоединенный к домену, и параметры, доступные пользователю при входе в систему.

Рисунок 2: Первоначальный вход в Windows 7

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

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

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

• Компьютер может быть членом только одного домена в любое время
• Контроллер домена может быть связан только с одним доменом одновременно
• Должно быть минимум (2), но обычно больше контроллеров домена на домен
• Учетная запись пользователя может быть указана в домене только один раз
• Учетная запись пользователя может быть указана во всех доменах, но только один раз
• Доверенный домен не должен дублировать учетные записи пользователей из одного домена в другой; это доверительные отношения, которые позволяют пользователю входить в систему с компьютера, присоединенного к одному домену, у которого есть доверие с другим доменом.Дублирование аккаунтов сводит на нет точку доверия.

Локальные учетные записи по умолчанию

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

• Администратор
• Гость (по умолчанию отключено)
• <настроенный администратор>

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

Область локальной учетной записи

Когда пользователь входит в систему с локальной учетной записью, объем и доступ, к которым у пользователя есть доступ, значительно сокращаются. Учетные записи локальных пользователей имеют доступ только к ресурсам на локальном компьютере и ни к чему другому. Учетную запись локального пользователя нельзя поместить в список управления доступом (ACL) или поместить в группу домена.Таким образом, доступ в корпоративной среде настолько ограничен, что конфигурация становится нежелательной.

Учетные записи домена по умолчанию

При установке Active Directory существует множество учетных записей домена по умолчанию. Для недавно установленного контроллера домена Windows Server 2008 или 2008 R2 для нового домена список учетных записей пользователей включает:

• Администратор
• Гость (по умолчанию отключено)
• Krbtgt (учетная запись службы Kerberos)
• <настроенный администратор>

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

Область действия учетной записи домена

Область действия учетной записи домена — это то место, где в игру вступает мощь домена Windows Active Directory. Учетные записи пользователей домена можно настроить на следующие параметры:

• Членство в группе домена
• Находится в ACL для ЛЮБОГО ресурса на любом компьютере, который также присоединился к домену
• Находится в локальной группе ЛЮБОГО компьютера, который присоединился к домену
• Право пользователя на ЛЮБОЙ компьютер, который присоединился к домену
• Для получения централизованных настроек групповой политики для настройки безопасности, профиля, рабочего стола и т. Д.информация

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

Сводка

Понятие «домен или учетная запись локального пользователя» не вызывает особых споров. Для любой организации я настоятельно рекомендую удалить все локальные учетные записи пользователей и разрешить только те, которые действительно необходимы.Сюда могут входить учетные записи служб, тестовые учетные записи разработчиков, учетные записи типов приложений и т. Д. Разрешение пользователю входа в систему на локальном компьютере обеспечивает небольшой контроль. Наихудший случай — разрешить пользователю входить в систему с правами локального администратора, что невозможно контролировать. Это также создает ситуацию, когда пользователь может атаковать сеть с компьютера, который является частью домена. Это никогда не бывает хорошо. Удаление всех учетных записей локальных пользователей заставляет пользователя войти в систему с учетной записью пользователя домена.Это немедленно дает преимущества для всего предприятия, и сетевые администраторы могут контролировать весь доступ и все функции учетной записи пользователя в этом сценарии.

Просмотры сообщений: 26 317

---

Вход в систему и домены Microsoft Windows

В этой статье рассматривается только Windows 7 и более ранние версии.

Щелкните здесь, чтобы прочитать статью о входе в Microsoft Windows 8 и доменах.

Введение

В бизнес-сети на базе Microsoft Windows набор компьютеров, общих папок, общих принтеров, а также список авторизованных пользователей и политик безопасности, которые все управляются вместе, в совокупности называют доменом Windows, доменом Active Directory или, как правило, , просто домен.

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

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

В любом случае, на компьютере, который является членом домена, Windows показывает то, что мы будем называть контекстом входа в систему, на начальном экране входа в систему. Это указывает, где находится учетная запись пользователя, с которой вы собираетесь войти в систему. Таким образом, он покажет либо имя домена Windows, либо имя вашего компьютера (что будет означать локальные учетные записи пользователей). Если вы вводите свое имя пользователя и пароль, но указан неправильный контекст, Windows просто сообщит вам, что ваше имя пользователя или пароль неверны.Windows проверяет только указанный контекст, чтобы увидеть, есть ли ваша учетная запись пользователя, и проверить ваш пароль. Таким образом, единственный способ успешно войти в систему — убедиться в правильности указанного контекста входа.

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

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

Выбор контекста входа в Windows XP

Если у вас установлена ​​Windows XP в корпоративной сети (или вы все еще используете Windows 2000), ваш экран входа в систему будет выглядеть примерно так, как показано на рисунке ниже. По умолчанию контекст входа в систему скрыт, пока вы не нажмете кнопку «Параметры».

Когда вы нажмете «Параметры», вы увидите следующее:

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

Ниже приведен пример компьютера с именем WORKSTATION4, который находится в сети с двумя доменами с именами JDFOXMICRO и LAB.

По умолчанию Windows 2000 и Windows XP будут настроены на контекст входа в систему последнего пользователя, который вошел в систему. Поэтому, если несколько пользователей имеют учетные записи в разных доменах и совместно используют один компьютер, каждый пользователь должен будет вручную выбрать правильный домен в поле «Вход в систему».

В приведенном выше примере, если у пользователя kgibson есть учетная запись только в домене LAB, ему нужно будет выбрать ее в поле «Войти в», чтобы иметь возможность войти в систему.

Последнее замечание об этой версии Windows: когда вы впервые щелкаете раскрывающийся список, чтобы увидеть список доменов, вы можете получить сообщение с надписью «Подождите, пока список доменов будет создан». Когда это появляется, ваш компьютер начинает общаться в сети, чтобы определить, какие домены доступны.Это займет всего несколько секунд. Однако есть странность, когда сообщение не исчезает, когда оно закончено, и вы можете сидеть и смотреть в свой компьютер, вечно ожидая, пока он скажет, что готово. Чтобы сообщение исчезло, нажмите Ctrl + Alt + Delete. Если создание списка доменов действительно завершено, сообщение исчезнет, ​​и вы сможете снова щелкнуть раскрывающийся список и сразу увидеть доступные домены.

Выбор контекста входа в Windows Vista и Windows 7

Windows Vista и Windows 7 изменили способ указания доменов.Выпадающего списка больше нет! Причины сложны, но по сути Microsoft внесла это изменение в название безопасности.

В этих более новых версиях Windows, если вам нужно указать домен, отличный от домена по умолчанию, вы должны теперь вручную ввести имя домена со своим именем пользователя, используя следующий синтаксис: DOMAIN \ USERNAME. Обратите внимание на использование обратной косой черты, которая обычно находится над клавишей Enter на клавиатуре. Если элемент «Вход в систему» ​​присутствует и уже показывает правильное доменное имя, вы можете просто ввести свое имя пользователя.

Итак, взгляните на наиболее распространенный экран, который вы увидите, когда хотите войти в систему, который показывает пользователя, который последний раз входил в систему, и запрашивает пароль:

Обратите внимание, что здесь четко указан домен JDFOXMICRO, но вы не можете редактировать домен или имя пользователя, просто щелкнув по нему. Вы должны нажать «Сменить пользователя», а затем «Другой пользователь», как если бы вы использовали другую учетную запись даже в сети с одним доменом.

Только сейчас вы заметите, что в приглашении к входу в систему под полем пароля указан домен, где написано «Вход в систему».На этом экране Windows Vista и Windows 7 всегда по умолчанию используют домен, членом которого является сам компьютер, независимо от того, кто вошел в систему последним. В этом случае компьютер является членом домена JDFOXMICRO, поэтому этот домен все еще отображается здесь.

Если вам нужно войти в систему с учетной записью в другом домене, введите имя домена в поле Имя пользователя, затем обратную косую черту, а затем ваше имя пользователя в этом домене, как показано ниже. Как только вы нажмете клавишу обратной косой черты, Windows узнает, что вы указываете доменное имя, и элемент «Вход в систему» ​​ниже изменится, чтобы показать, что вы ввели.

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

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

Вы заметите ссылку «Как мне войти в другой домен?» на экране выше.Если вы щелкните по нему, вы увидите это окно, в котором указано, что имя этого компьютера — WORKSTATION2.

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

Чтобы войти на этот компьютер с использованием учетной записи из домена, отличного от домена по умолчанию, включите имя домена в поле имени пользователя, используя следующий синтаксис: домен \ имя пользователя.

Чтобы войти на этот компьютер с использованием локальной учетной записи пользователя, поставьте перед локальным именем пользователя точку и обратную косую черту, например:.\имя пользователя.

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

Дополнительные рекомендации при использовании учетных записей домена — Документация (10.

3 и 10.3.1)

В этом разделе

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

При использовании учетной записи домена в качестве учетной записи ArcGIS Server

Если ваши настройки входа запрещают права входа на компьютер, на котором установлен ArcGIS Server, вы столкнетесь с ошибкой во время установки. Нет необходимости предоставлять настройки групповой политики «Локальный вход» учетной записи ArcGIS Server; требуются только следующие шаги:

1. Войдите в систему на компьютере, на котором размещена Windows Active Directory.
2. Щелкните Пуск> Администрирование> Пользователи и компьютеры Active Directory.
3. Найдите организационную единицу, содержащую учетную запись ArcGIS Server.
4. Щелкните правой кнопкой мыши учетную запись ArcGIS Server и выберите Свойства.
5. Щелкните вкладку «Учетная запись» и нажмите «Войти в систему».
6. В поле ниже Параметр «Следующие компьютеры» введите имя хоста компьютера, на котором размещен ArcGIS Server.
7. Нажмите «Добавить».
8. Нажмите Применить.

Для получения дополнительной информации об учетной записи ArcGIS Server см. Учетная запись ArcGIS Server.

При использовании Active Directory в качестве хранилища безопасности

Если ваши настройки входа запрещают права входа на компьютер, на котором размещен Active Directory, вы столкнетесь с ошибкой при настройке безопасности для использования Windows в качестве хранилища идентификаторов.Нет необходимости предоставлять пользователю параметры групповой политики «Локальный вход»; требуются только следующие шаги:

1. Настройте Windows в качестве хранилища удостоверений, следуя инструкциям в руководстве.