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

Cached Credentials: вход в Windows под сохраненными учетными данными при недоступности домена

16.02.2022

itpro

Active Directory, Групповые политики

комментариев 15

Когда доменный пользователь входит в Windows, по умолчанию его учетные данные (Cached Credentials: имя пользователя и хэш пароля) сохраняются на локальном компьютере. Благодаря этому, пользователь сможет войти на локальный компьютер, даже если контроллеры домена AD недоступны, выключены или на компьютере отключен сетевой кабель. Функционал кэширования учетных данных доменных аккаунтов удобен для пользователей ноутбуков, которые могут получить доступ к своим локальным данным на компьютере, когда нет доступа к корпоративной сети.

Сохраненный кэш доменной учетной записи в Windows

Вход на компьютер под кэшированными данными для пользователя доступен, если он ранее хотя бы один раз авторизовался на этом компьютере, и пароль в домене не был сменен с момента входа. Пароль пользователя в cashed credentials никогда не истекает. Если доменная политика паролей вынудит пользователя изменить пароль, сохраненный пароль пользователя в локальном кэше компьютера не изменится, пока пользователь не войдет на компьютер под новым паролем. Т.е. если пароль пользователя в AD был изменен после последнего входа на компьютер, и компьютер находился все время в офлайн режиме без доступа в сеть, то пользователь сможет войти на этот компьютер под старым паролем.

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

Сохраненные пароли хранятся в ветке реестра HKEY_LOCAL_MACHINE\Security\Cache (файл %systemroot%\System32\config\SECURITY). Каждый сохранённый хэш содержится в Reg_Binary параметре NL$x (где x – индекс кэшированных данных). По умолчанию даже у администратора нет прав на просмотр содержимого этой ветки реестра, но при желании их можно легко получить.

В реестр сохраняет хэш пароля, модифицированный с помощь salt, созданной на основе имени пользователя.

Очистка значения параметра NL$x приведет к удалению кэшированных данных.

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

There are currently no logon servers available to service the logon request.

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

Настройка Cached Credentials с помощью групповых политик

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

По-умолчанию в Windows 10 /Windows Server 2016 сохраняются учетные данные для 10 пользователей. Чтобы изменить это количество, используется параметр GPO Interactive logon: Number of previous logons to cache (in case domain controller is not available) (Интерактивный вход в систему: количество предыдущих подключений к кэшу в случае отсутствия доступа к контроллеру домена), который находится в разделе Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options. Можно задать значение от 0 до 50.

Если задать 0, это запретит Windows кэшировать учетные данные пользователей. В этом случае при недоступности домена, при входе пользователя появится ошибка “There are currently no logon servers available to service the logon request”.

Этот параметр также можно настроить с помощью REG_SZ параметра реестра CashedLogonsCount из ветки HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon

При входе под сохраненными данными, пользователь не видит, что контроллер домена не доступен. С помощью GPO можно вывести уведомление о входе под кэшированными данными. Для этого нужно включить политику Report when logon server was not available during user logon (Сообщать, когда сервер входа недоступен при входе пользователя) в разделе Compute configuration -> Policies -> Administrative templates -> Windows Components -> Windows Logon Options.

В этом случае при входе пользователя в трее будет появляться уведомление:

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

A domain controller for your domain could not be contacted. You have been logged on using cached account information. Changes to your profile since you last logged on might not be available.

Эту настройку можно включить через реестр:
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows NT/Current Version/Winlogon

• ValueName: ReportControllerMissing
• Data Type: REG_SZ
• Values: TRUE

Безопасность кэшированных учетных данных в Windows

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

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

Для доменов с функциональным уровнем Windows Server 2012 R2 или выше можно добавить учетные записи администраторов домена в группу Protected Users. Для таких пользователей запрещено локальное сохранение кэшированных данных для входа.

Можно создать в домене отдельные политики по использованию кэшированных учетных данных для разных устройств и категорий пользователей (например, с помощью GPO Security filters, WMI фильтров, или распространению настроек параметра реестра CashedLogonsCount через GPP Item level targeting).

Для мобильных пользователей – CashedLogonsCount = 1
Для обычных компьютеров – CashedLogonsCount = 0

Такие политики снизят вероятность получения хэша привелигированных пользователей с персональных компьютеров.

Предыдущая статья Следующая статья

Процедуры с учетными данными в проверке подлинности Windows

В этом справочном разделе ИТ-специалистов описывается, как проверка подлинности Windows обрабатывает учетные данные.

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

По умолчанию учетные данные Windows проверяются в базе данных диспетчера учетных записей безопасности (SAM) на локальном компьютере или active Directory на присоединенном к домену компьютере с помощью службы Winlogon. Учетные данные собираются с помощью входных данных пользователя в пользовательский интерфейс входа или программным способом с помощью интерфейса программирования приложения (API), который будет представлен целевому объекту проверки подлинности.

Сведения о локальной безопасности хранятся в реестре в разделе HKEY_LOCAL_MACHINE\SECURITY. Хранимая информация включает параметры политики, значения безопасности по умолчанию и сведения об учетной записи, такие как кэшированные учетные данные для входа. Копия базы данных SAM также хранится здесь, хотя она защищена записью.

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

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

Компоненты проверки подлинности для всех систем

Компонент	Description
Вход пользователя в систему	Winlogon.exe — это исполняемый файл, ответственный за управление безопасным взаимодействием с пользователем. Служба Winlogon инициирует процесс входа в операционные системы Windows, передав учетные данные, собранные действием пользователя на защищенном рабочем столе (пользовательский интерфейс входа) в локальный центр безопасности (LSA) через Secure32.dll.
Вход в приложение	Для входа в приложение или службу, для которых не требуется интерактивный вход. Большинство процессов, инициируемых пользователем в пользовательском режиме с помощью Secur32.dll, а процессы, инициированные при запуске, такие как службы, выполняются в режиме ядра с помощью Ksecdd.sys.

Этот раздел состоит из следующих подразделов.

• Входные данные учетных данных для входа пользователя
• Вход учетных данных для входа в систему приложений и служб
• Локальный центр безопасности
• Кэшированные учетные данные и проверка
• Хранилище учетных данных и проверка
• База данных диспетчера учетных записей безопасности
• Локальные домены и доверенные домены
• Сертификаты в проверка подлинности Windows

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

В Windows Server 2008 и Windows Vista архитектура графической идентификации и проверки подлинности (GINA) была заменена моделью поставщика учетных данных, что позволило перечислить различные типы входа с помощью плиток входа. Обе модели описаны ниже.

Архитектура графической идентификации и проверки подлинности

Архитектура графической идентификации и проверки подлинности (GINA) применяется к операционным системам Windows Server 2003, Microsoft Windows 2000 Server, Windows XP и Windows 2000 Профессиональный. В этих системах каждый интерактивный сеанс входа создает отдельный экземпляр службы Winlogon. Архитектура GINA загружается в пространство процесса, используемое Winlogon, получает и обрабатывает учетные данные, а также вызывает интерфейсы проверки подлинности через LSALogonUser.

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

На следующей схеме показан процесс учетных данных для Windows Server 2003, Microsoft Windows 2000 Server, Windows XP и Microsoft Windows 2000 Professional.

Архитектура поставщика учетных данных

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

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

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

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

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

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

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

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

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

• Проверка подлинности сети и вход на компьютер обрабатываются различными поставщиками учетных данных. К этому сценарию относятся следующие варианты:
  • Пользователь может подключиться к сети, например подключиться к виртуальной частной сети (VPN), прежде чем входить на компьютер, но не требуется для этого подключения.
  • Для получения сведений, используемых во время интерактивной проверки подлинности на локальном компьютере, требуется проверка подлинности сети.
  • За несколькими сетевыми проверками подлинности следует один из других сценариев. Например, пользователь проходит проверку подлинности в поставщике услуг Интернета (ISP), выполняет проверку подлинности в VPN, а затем использует учетные данные учетной записи пользователя для локального входа.
  • Кэшированные учетные данные отключены, а для проверки подлинности пользователя требуется удаленное подключение службы Access через VPN.
  • У пользователя домена нет локальной учетной записи, настроенной на компьютере, присоединенном к домену, и необходимо установить удаленное подключение службы Access через VPN-подключение перед завершением интерактивного входа.

  Перечисление плитки входа

  Поставщик учетных данных перечисляет плитки входа в следующие экземпляры:

  • Для этих операционных систем, указанных в списке «Область применения» в начале этого раздела.
  • Поставщик учетных данных перечисляет плитки для входа на рабочую станцию. Поставщик учетных данных обычно сериализует учетные данные для проверки подлинности в локальном органе безопасности. В этом процессе отображаются плитки, относящиеся к каждому пользователю и относящиеся к целевым системам каждого пользователя.
  • Архитектура входа и проверки подлинности позволяет пользователю использовать плитки, перечисленные поставщиком учетных данных для разблокировки рабочей станции. Как правило, пользователь, вошедший в систему, является плиткой по умолчанию, но если несколько пользователей вошли в систему, отображаются многочисленные плитки.
  • Поставщик учетных данных перечисляет плитки в ответ на запрос пользователя, чтобы изменить пароль или другую частную информацию, например ПИН-код. Как правило, пользователь, вошедший в систему, является плиткой по умолчанию; Однако если в систему вошли несколько пользователей, отображаются многочисленные плитки.
  • Поставщик учетных данных перечисляет плитки на основе сериализованных учетных данных, которые будут использоваться для проверки подлинности на удаленных компьютерах. Пользовательский интерфейс учетных данных не использует тот же экземпляр поставщика, что и пользовательский интерфейс входа, разблокировка рабочей станции или изменение пароля. Таким образом, сведения о состоянии не могут храниться в поставщике между экземплярами пользовательского интерфейса учетных данных. Эта структура приводит к тому, что одна плитка для каждого удаленного компьютера входит в систему, если учетные данные были правильно сериализованы. Этот сценарий также используется в области контроля учетных записей пользователей (UAC), что может помочь предотвратить несанкционированные изменения на компьютере, запрашивая пользователю разрешение или пароль администратора, прежде чем разрешать действия, которые могут повлиять на операцию компьютера или изменить параметры, влияющие на других пользователей компьютера.

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

  

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

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

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

  При проверке подлинности подключения клиента или сервера:

  • Приложение на стороне клиента подключения отправляет учетные данные серверу с помощью функции InitializeSecurityContext (General) SSPI.
  • Приложение на стороне сервера подключения реагирует на функцию AcceptSecurityContext (General) SSPI.
  • Функции InitializeSecurityContext (General) SSPI и AcceptSecurityContext (General) повторяются до тех пор, пока все необходимые сообщения проверки подлинности не будут обменены на успешное или сбой проверки подлинности.
  • После проверки подлинности подключения LSA на сервере использует сведения от клиента для создания контекста безопасности, содержащего маркер доступа.
  • Затем сервер может вызвать функцию ImpersonateSecurityContext SSPI, чтобы подключить маркер доступа к потоку олицетворения для службы.

  Приложения и режим пользователя

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

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

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

  SSPI доступен через модуль Secur32.dll, который используется для получения интегрированных служб безопасности для проверки подлинности, целостности сообщений и конфиденциальности сообщений. Он предоставляет уровень абстракции между протоколами уровня приложения и протоколами безопасности. Так как для различных приложений требуются различные способы идентификации или проверки подлинности пользователей и различные способы шифрования данных по сети, SSPI предоставляет способ доступа к библиотекам динамического канала (DLL), содержащим различные функции проверки подлинности и криптографические функции. Эти библиотеки DLL называются поставщиками поддержки безопасности (SSPS).

  Управляемые учетные записи служб и виртуальные учетные записи были представлены в Windows Server 2008 R2 и Windows 7 для предоставления важных приложений, таких как Microsoft SQL Server и службы IIS (IIS), с изоляцией собственных учетных записей домена, устраняя необходимость администратора вручную администрировать имя субъекта-службы (SPN) и учетные данные для этих учетных записей. Дополнительные сведения об этих функциях и их роли в проверке подлинности см . в документации по управляемым учетным записям служб для Windows 7 и Windows Server 2008 R2 и групповых управляемых учетных записей служб.

  Службы и режим ядра

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

  Службы обычно выполняются в контекстах безопасности, известных как локальная система (SYSTEM), сетевая служба или локальная служба. Windows Server 2008 R2 представила службы, которые выполняются под управляемой учетной записью службы, которые являются субъектами домена.

  Перед запуском службы контроллер службы входит в систему с помощью учетной записи, назначенной для службы, а затем предоставляет учетные данные службы для проверки подлинности с помощью LSA. Служба Windows реализует программный интерфейс, который диспетчер контроллеров служб может использовать для управления службой. Служба Windows может запускаться автоматически при запуске системы или вручную с помощью программы управления службами. Например, когда клиентский компьютер Windows присоединяется к домену, служба messenger на компьютере подключается к контроллеру домена и открывает к нему безопасный канал. Чтобы получить прошедшее проверку подлинности подключение, служба должна иметь учетные данные, которыми доверяет локальный центр безопасности удаленного компьютера (LSA). При взаимодействии с другими компьютерами в сети LSA использует учетные данные для учетной записи домена локального компьютера, как и все остальные службы, работающие в контексте безопасности локальной системы и сетевой службы. Службы на локальном компьютере выполняются как SYSTEM, поэтому учетные данные не должны быть представлены В LSA.

  Файл Ksecdd.sys управляет и шифрует эти учетные данные и использует локальный вызов процедуры в LSA. Тип файла — DRV (driver) и называется поставщиком поддержки безопасности в режиме ядра (SSP), и в этих версиях, указанных в списке «Область применения» в начале этого раздела, соответствует FIPS 140-2 уровня 1.

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

  Локальная система безопасности

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

  LSA проверяет удостоверение пользователя на основе следующих двух сущностей, выданных учетной записью пользователя:

  • Локальный центр безопасности. LSA может проверить сведения о пользователе, проверка базу данных диспетчера учетных записей безопасности (SAM), расположенную на том же компьютере. Любые рабочие станции или сервер-члены могут хранить локальные учетные записи пользователей и сведения о локальных группах. Однако эти учетные записи можно использовать для доступа только к этой рабочей станции или компьютеру.
  • Центр безопасности для локального домена или доверенного домена. LSA обращается к сущности, которая выдала учетную запись и запрашивает проверку подлинности учетной записи и что запрос был получен от владельца учетной записи.

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

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

  • Зашифрованный обычный текст с возможностью дешифровки
  • Билеты Kerberos (билеты на предоставление билетов (TGTs), сервисные билеты)
  • NT-хэш
  • Хэш диспетчера локальной сети (LM)

  Если пользователь входит в Систему Windows с помощью смарт-карта, LSASS не сохраняет пароль обычного текста, но сохраняет соответствующее хэш-значение NT для учетной записи и пин-код открытого текста для смарт-карта. Если для смарт-карты, необходимой для интерактивного входа, включается атрибут учетной записи, то для соответствующего профиля происходит автоматическая генерация произвольного NT-хэша, который используется вместо изначального хэша пароля. Хэш пароля, автоматически сгенерированный при установке атрибута, не изменяется.

  Если пользователь входит на компьютер под управлением Windows с паролем, совместимым с хэшами LAN Manager (LM), этот средство проверки подлинности присутствует в памяти.

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

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

  • Вход в локальный сеанс или сеанс протокола удаленного рабочего стола (RDP) на компьютере
  • Запускает задание с помощью команды RunAs
  • Запускает на компьютере активную службу Windows
  • Запускает назначенное или пакетное задание
  • Запускает на локальном компьютере задание с помощью средства удаленного администрирования.

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

  • Пароль учетной записи для учетной записи домен Active Directory служб (AD DS) компьютера
  • Пароли учетных записей служб Windows, настроенных на компьютере
  • Пароли учетных записей настроенных назначенных заданий
  • Пароли учетных записей для пулов приложений IIS и веб-сайтов.
  • Пароли для учетных записей Майкрософт

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

  Дополнительные сведения об этих дополнительных защитах см. в разделе «Настройка дополнительной защиты LSA».

  Кэшированные учетные данные и проверка

  Механизмы проверки зависят от представления учетных данных во время входа. Однако, если компьютер отключен от контроллера домена, а пользователь представляет учетные данные домена, Windows использует процесс кэшированных учетных данных в механизме проверки.

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

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

  Хранилище учетных данных и проверка

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

  Процессы учетных данных удаленного входа

  Протокол удаленного рабочего стола (RDP) управляет учетными данными пользователя, который подключается к удаленному компьютеру с помощью клиента удаленного рабочего стола, который появился в Windows 8. Учетные данные в виде обычного текста отправляются на целевой узел, где узел пытается выполнить процесс проверки подлинности, а при успешном выполнении подключает пользователя к разрешенным ресурсам. RDP не сохраняет учетные данные на клиенте, но учетные данные домена пользователя хранятся в LSASS.

  В Windows Server 2012 R2 и Windows 8.1 режим ограниченного Администратор обеспечивает дополнительную безопасность для сценариев удаленного входа. Этот режим удаленного рабочего стола приводит к тому, что клиентское приложение будет выполнять вызов входа в сеть с помощью односторонней функции NT (NTOWF) или использовать билет службы Kerberos при проверке подлинности на удаленном узле. После проверки подлинности администратора администратор не имеет соответствующих учетных данных учетной записи в LSASS, так как они не были предоставлены удаленному узлу. Вместо этого администратор имеет учетные данные учетной записи компьютера для сеанса. учетные данные Администратор istrator не предоставляются удаленному узлу, поэтому действия выполняются в качестве учетной записи компьютера. Ресурсы также ограничены учетной записью компьютера, а администратор не может получить доступ к ресурсам с собственной учетной записью.

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

  При входе пользователя на устройство Windows 8.1 LSA сохраняет учетные данные пользователя в зашифрованной памяти, доступной только LSASS.exe. Когда Обновл. Windows инициирует автоматическую перезагрузку без присутствия пользователя, эти учетные данные используются для настройки автологона для пользователя.

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

  Дополнительные сведения об ARSO см. в статье Об автоматическом входе в Winlogon (ARSO).

  Сохраненные имена пользователей и пароли в Windows Vista и Windows XP

  В Windows Server 2008, Windows Server 2003, Windows Vista и Windows XP, сохраненные имена пользователей и пароли в панель управления упрощают управление и использование нескольких наборов учетных данных входа, включая сертификаты X.509, используемые с смарт-карта и учетными данными Windows Live (теперь называется учетной записью Майкрософт). Учетные данные — часть профиля пользователя — хранятся до тех пор, пока не потребуется. Это действие может повысить безопасность на основе каждого ресурса, гарантируя, что если один пароль скомпрометирован, он не компрометируют всю безопасность.

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

  Применяются следующие ограничения:

  • Если сохраненные имена пользователей и пароли содержат недопустимые или неверные учетные данные для определенного ресурса, доступ к ресурсу запрещен, а диалоговое окно «Сохраненные имена пользователей и пароли » не отображается.
  • Сохраненные имена пользователей и пароли хранят учетные данные только для протокола NTLM, протокола Kerberos, учетной записи Майкрософт (прежнее название — Windows Live ID) и проверки подлинности SSL. Некоторые версии Интернет-Обозреватель поддерживают собственный кэш для базовой проверки подлинности.

  Эти учетные данные становятся зашифрованной частью локального профиля пользователя в каталоге \Documents and Параметры\Username\Application Data\Microsoft\Credentials. В результате эти учетные данные могут перемещаться с пользователем, если политика сети пользователя поддерживает перемещаемые профили пользователей. Однако если пользователь имеет копии сохраненных имен пользователей и паролей на двух разных компьютерах и изменяет учетные данные, связанные с ресурсом на одном из этих компьютеров, изменение не распространяется на сохраненные имена пользователей и пароли на втором компьютере.

  Windows Vault и Диспетчер учетных данных

  Диспетчер учетных данных появился в Windows Server 2008 R2 и Windows 7 в качестве функции панель управления для хранения имен пользователей и паролей и управления ими. Диспетчер учетных данных позволяет пользователям хранить учетные данные, относящиеся к другим системам и веб-сайтам в защищенном хранилище Windows. Некоторые версии Интернет-Обозреватель использовать эту функцию для проверки подлинности на веб-сайтах.

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

  Когда веб-сайт, приложение или другой компьютер запрашивает проверку подлинности с помощью протокола NTLM или Kerberos, появится диалоговое окно, в котором выбрано поле «Обновить учетные данные по умолчанию» или «Сохранить пароль» проверка. Это диалоговое окно, позволяющее пользователю сохранять учетные данные локально, создается приложением, поддерживающим API диспетчера учетных данных. Если пользователь выбирает поле «Сохранить пароль» проверка, диспетчер учетных данных отслеживает имя пользователя, пароль и связанные сведения для используемой службы проверки подлинности.

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

  База данных диспетчера учетных записей безопасности

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

  Например, клиентские компьютеры под управлением операционной системы Windows участвуют в сетевом домене, взаимодействуя с контроллером домена, даже если пользователь не вошел в систему. Чтобы инициировать обмен данными, компьютер должен иметь активную учетную запись в домене. Прежде чем принимать обмен данными с компьютера, LSA на контроллере домена проверяет подлинность удостоверения компьютера, а затем создает контекст безопасности компьютера так же, как и для субъекта безопасности человека. Этот контекст безопасности определяет удостоверение и возможности пользователя или службы на определенном компьютере или пользователе, службе или компьютере в сети. Например, маркер доступа, содержащийся в контексте безопасности, определяет ресурсы (например, общую папку или принтер), к которым можно получить доступ, а также действия (например, чтение, запись или изменение), которые могут выполняться этим субъектом — пользователем, компьютером или службой на этом ресурсе.

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

  Локальные домены и доверенные домены

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

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

  Сведения о отношениях доверия между доменами и лесом относительно проверки подлинности см. в разделе «Делегированная проверка подлинности и отношения доверия».

  Сертификаты в проверка подлинности Windows

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

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

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

  Удаленные узлы устанавливают свою надежность путем получения сертификата из центра сертификации (ЦС). ЦС, в свою очередь, может иметь сертификацию от высшего органа, который создает цепочку доверия. Чтобы определить, является ли сертификат надежным, приложение должно определить удостоверение корневого ЦС, а затем определить, является ли он надежным.

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

  Чтобы создать сертификат, данные проверки подлинности передаются через хэш-алгоритмы, такие как безопасный хэш-алгоритм 1 (SHA1), для создания дайджеста сообщений. Затем дайджест сообщения подписывается с помощью закрытого ключа отправителя, чтобы доказать, что дайджест сообщения был создан отправителем.

  SHA1 — это значение по умолчанию в Windows 7 и Windows Vista, но было изменено на SHA2 в Windows 8.

  Проверка подлинности смарт-карта

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

  Сведения о проверке подлинности смарт-карта см. в техническом справочнике по Windows Smart Card.

  Технология виртуальной интеллектуальной карта появилась в Windows 8. Он хранит сертификат смарт-карта на компьютере, а затем защищает его с помощью микросхемы безопасности доверенного платформенного модуля (TPM). Таким образом, компьютер фактически становится смарт-карта, который должен получать ПИН-код пользователя для проверки подлинности.

  Удаленная и беспроводная проверка подлинности

  Удаленная и беспроводная проверка подлинности сети — это другая технология, которая использует сертификаты для проверки подлинности. Служба проверки подлинности Интернета (IAS) и серверы виртуальной частной сети используют расширяемую проверку подлинности протокол-транспорт безопасности (EAP-TLS), защищенный расширяемый протокол проверки подлинности (PEAP) или безопасность протокола Интернета (IPsec) для выполнения проверки подлинности на основе сертификатов для многих типов сетевого доступа, включая виртуальную частную сеть (VPN) и беспроводные подключения.

  Сведения о проверке подлинности на основе сертификатов в сети см. в разделе «Проверка подлинности и сертификаты доступа к сети».

  Удобный поиск компьютера пользователя в домене Windows

  Привет всем!
  Работаю в компании. 1500+ активных пользователей.
  Организован ХелпДеск, сотрудники регистрируют тикеты в системе, но, как-то так получается, что часть из юзеров забывают указывать имя пк, за которым они находятся.

  Для выяснения этой информации (по телефону/email/экстрасенсорные способности) девочки из поддержки тратят драгоценное время, которое они могли бы уделить свежей чашке кофе или разговорам о новом платье (шутка). Наши сотрудники постоянно заняты своей непосредственной работой.

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

  

  Что у нас есть?

  Windows среда (ХР/7/2003/2008), учетные записи хранятся в AD, все устройства работаю в локальной сети в качестве СУБД используем MSSQL 2005/2008R2.

  Что мы хотим?

  Поиск информации через веб интерфейс:

  1. Где логинился сотрудник с фамилией, например, «Иванов«;
  2. Кто логинился на устройстве, например, «PC34«;
  3. Где были совершены логоны под учетной записью, например, «hr.ivanov«.

  Должна отображаться информация:

  • имя пк;
  • login;
  • фио;
  • ip адрес;
  • дата логона.

  Название?

  Так как «решением» будут пользоваться несколько человек (от 5 до 35 человек), надо как-то его обозвать для удобства. Нарекли мы его «SuperVisor».

  Приступим к реализации

  Как будем писать в БД?

  Первое, что пришло в голову — это создать bat файл с sqlcmd, но для каждой версии Windows нужна своя версия утилиты sqlcmd. Неудобно, и мы не стали копать глубже.

  Вторым решением было создать небольшой exe клиент, который при запуске будет собирать данные об имени доменной учетной записи, имени пк, ip адресе пк и после получения этой информации будет выполняться вставка данных в БД. Программу размещаем, например, в папке NETLOGON на контроллере домена и групповыми политиками распространяем на ПК/Сервера в локальной сети компании.

  Программа на Delphi

  unit Unit1; interface uses Windows,SysUtils, Variants, Classes, Forms,WinSock, Dialogs, DB, ADODB,StdCtrls,Messages, ExtCtrls; type TForm1 = class(TForm) boston: TADOConnection; qryinsert: TADOQuery; timer: TTimer; procedure FormCreate(Sender: TObject); procedure timerTimer(Sender: TObject); private < Private declarations >public < Public declarations >end; var Form1: TForm1; implementation // версия 0.0.4 // дата 27-02-2014 function GetCurrentUserName: string; const cnMaxUserNameLen = 254; var sUserName: string; dwUserNameLen: DWORD; begin dwUserNameLen := cnMaxUserNameLen - 1; SetLength(sUserName, cnMaxUserNameLen); GetUserName(PChar(sUserName), dwUserNameLen); SetLength(sUserName, dwUserNameLen); Result := string(sUserName); end; function GetCurrentComputerName: string; const cnMaxComputerNameLen = 254; var sComputerName: string; dwComputerNameLen: DWORD; begin dwComputerNameLen := cnMaxComputerNameLen - 1; SetLength(sComputerName, cnMaxComputerNameLen); GetComputerName(PChar(sComputerName), dwComputerNameLen); SetLength(sComputerName, dwComputerNameLen); Result := string(sComputerName); end; function GetLocalIP: String; const WSVer = $101; var wsaData: TWSAData; P: PHostEnt; Buf: array [0..127] of Char; begin Result := ''; if WSAStartup(WSVer, wsaData) = 0 then begin if GetHostName(@Buf, 128) = 0 then begin P := GetHostByName(@Buf); if P <> nil then Result := iNet_ntoa(PInAddr(p^.h_addr_list^)^); end; WSACleanup; end; end; procedure TForm1.FormCreate(Sender: TObject); begin try qryinsert.SQL.Text := 'begin TRANSACTION insertdata' +#13#10 + 'insert into [supervisor].[user].[info_host](host,login,last_ip) values (:host,:login,:ip)'+#13#10 + 'COMMIT TRANSACTION insertdata'; qryinsert.Parameters.ParamByname('login').Value:= GetCurrentUserName ; qryinsert.Parameters.ParamByname('host').Value:= GetCurrentComputerName ; qryinsert.Parameters.ParamByname('ip').Value:= GetLocalIP ; qryinsert.ExecSQL; timer.Enabled:=True; form1.timer.Interval:=1500; except Application.Terminate; end end; procedure TForm1.timerTimer(Sender: TObject); begin ExitProcess(0); end; end. 

  Дальше алгоритм такой:

  1. Пользователь логинится за пк;
  2. Скрытно запускается SuperVisor.exe;
  3. Делается попытка INSERT в указанную бд, если успешно, то программа завершает свою работу;
  4. Если выполнить INSERT не получается (ноутбук не в локальной сети, сервер бд недоступен и т.д), таймаут 15 секунд и процесс «убивается», не пугая пользователя страшными сообщениями и окнами.

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

  /* Главная таблица, в которую пишутся логоны ----------------------------------------------------------- host - имя пк login - имя доменной учетной записи last_ip - ip адрес пк createdate - дата создания записи createdate_unix - unix время, дата создания записи ------------------------------------------------------------ */ CREATE TABLE [user].[info_host]( [id] [int] IDENTITY(1,1) NOT NULL, [host] [nvarchar](128) NULL, [login] [nvarchar](128) NULL, [createdate] [datetime] NOT NULL, [createdate_unix] [int] NOT NULL, [last_ip] [nvarchar](20) NULL ) ON [supervisor] GO ALTER TABLE [user].[info_host] ADD DEFAULT (getdate()) FOR [createdate] GO ALTER TABLE [user].[info_host] ADD DEFAULT (datediff(second,'1970-01-01 00:00:00',getutcdate())) FOR [createdate_unix] 

   /* Таблица справочник с ФИО учетных записей, наполняется из АД. Синхронизация происходит один раз в сутки ------------------------------------------------------------ login - имя доменной учетной записи displayName - поле displayname из АД для учетной записи createdate - дата создания записи createdate_unix - unix время, дата создания записи ------------------------------------------------------------ */ CREATE TABLE [user].[info_login_card]( [id] [int] IDENTITY(1,1) NOT NULL, [login] [nvarchar](128) NULL, [createdate] [datetime] NOT NULL, [createdate_unix] [int] NOT NULL, [displayName] [nvarchar](256) NULL ) ON [supervisor] GO ALTER TABLE [user].[info_login_card] ADD DEFAULT (getdate()) FOR [createdate] GO ALTER TABLE [user].[info_login_card] ADD DEFAULT (datediff(second,'1970-01-01 00:00:00',getutcdate())) FOR [createdate_unix] GO 

  Таблицы созданы и наполняются данными. Забыл написать, что сервер БД у нас виртуальный и работает под Windows Server 2003R2, СУБД MSSQL 2008R2. Сервер приложения виртуальный, Windows 2003R2, Apache 2.2 + PHP 5.2

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

  

  В строку поиска можно ввести фамилию сотрудника/учетную запись(логин) или имя компьютера:

  

  Причем, не обязательно вводить полностью фамилию и имя сотрудника/логин/имя пк, поиск совпадений в БД осуществляется с помощью оператора LIKE ( пример . LIKE ‘ива%’), запросы выполняются асинхронно, результат поиска обновляется перед глазами сотрудника без перезагрузки страницы после ввода нового символа в строку поиска.

  запрос к бд для поиска по ФИО

   set rowcount $limit SELECT a.[id] ,a.[host] ,a.[login] ,a.[createdate] ,a.[createdate_unix] ,a.[last_ip] ,b.[displayName] FROM [user].[info_host] a left join [user].[info_login_card] b on a.login = b.login where b.displayName like ('$ihostlogin') order by a.[createdate_unix] desc set rowcount 0 

  запрос к бд для поиска по имени пк

   set rowcount $limit SELECT a.[id] ,a.[host] ,a.[login] ,a.[createdate] ,a.[createdate_unix] ,a.[last_ip] ,b.[displayName] FROM [user].[info_host] a left join [user].[info_login_card] b on a.login = b.login where a.host like ('$hostlogin') order by a.[createdate_unix] desc set rowcount 0 

  поиск по логину

  set rowcount $limit SELECT a.[id] ,a.[host] ,a.[login] ,a.[createdate] ,a.[createdate_unix] ,a.[last_ip] ,b.[displayName] FROM [user].[info_host] a left join [user].[info_login_card] b on a.login = b.login where a.login like ('$hostlogin') order by a.[createdate_unix] desc set rowcount 0 

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

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

  Служба каталогов Active Directory

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

  В среде Windows 2003 Active Directory существует 3 главных типа пользовательских учетных записей:

  • Локальные учетные записи пользователей. Эти учетные записи существуют в локальной базе данных SAM ( Security Accounts Manager ) на каждой системе, работающей под управлением Windows 2003. Эти учетные записи создаются с использованием инструмента Local Users and Groups ( Локальные пользователи и группы ) консоли Computer Management ( Управление компьютером ). Заметим, что для входа в систему по локальной учетной записи, эта учетная запись обязательно должна присутствовать в базе данных SAM на системе, в которую вы пытаетесь войти. Это делает локальные учетные записи непрактичными для больших сетей, вследствие больших накладных расходов по их администрированию.
  • Учетные записи пользователей домена. Эти учетные записи хранятся в Active Directory и могут использоваться для входа в систему и доступа к ресурсам по всему лесу AD. Учетные записи этого типа создаются централизованно при помощи консоли » Active Directory Users and Computers » (» Active Directory – пользователи и компьютеры «).
  • Встроенные учетные записи. Эти учетные записи создаются самой системой и не могут быть удалены. По умолчанию любая система, будь то изолированная (отдельно стоящая) или входящая в домен, создает две учетные записи – Administrator ( Администратор ) и Guest ( Гость ). По умолчанию учетная запись Гость отключена.

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

  Существуют различные форматы, в которых могут быть представлены имена для входа пользователей в систему, потому что они могут отличаться для целей совместимости с клиентами, работающими под управлением более ранних версий Windows (такими как 95, 98, NT). Два основных вида имен входа — это с использованием суффикса User Principal Name ( основного имени пользователя ) и имя входа пользователя в системах пред-Windows 2000.

  Основное имя пользователя ( UPN, User Principle Name ) имеет такой же формат, как и электронный адрес. Он включает в себя имя входа пользователя, затем значок » @ » и имя домена. По умолчанию доменное имя корневого домена выделено в выпадающем окне меню, независимо от того, в каком домене учетная запись была создана (выпадающий список будет также содержать имя домена, в котором вы создали эту учетную запись).

  Также можно создавать дополнительные доменные суффиксы (та часть имени, которая стоит после знака @ ), которые будут появляться в выпадающем списке и могут быть использованы при образовании UPN, если вы их выберете (это делается при помощи консоли » Active Directory – домены и доверие » (» Active Directory Domain and Trusts «).

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

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

  Каждый компьютер с операционными системами Windows NT/2000/XP/2003 (если это не сервер, являющийся контроллером домена) имеет локальную базу данных учетных записей, называемую базой данных SAM. Эти БД обсуждались при описании модели безопасности «Рабочая группа». Локальные пользователи и особенно группы используются при назначении прав доступа к ресурсам конкретного компьютера даже в доменной модели безопасности. Общие правила использования локальных и доменных групп для управления доступом будут описаны ниже.

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

  Доменные учетные записи пользователей (а также компьютеров и групп) хранятся в специальных контейнерах AD. Это могут быть либо стандартные контейнеры Users для пользователей и Computers для компьютеров, либо созданное администратором Организационное подразделение (ОП). Исключение составляют учетные записи контроллеров домена, они всегда хранятся в ОП с названием Domain Controllers.

  Рассмотрим на примерах процесс создания учетных записей пользователей в БД Active Directory и разберем основные свойства доменных учетных записей. Учетные записи для компьютеров создаются в процессе включения компьютера в домен.

  Создание доменной учетной записи

  1. Откроем административную консоль » Active Directory – пользователи и компьютеры «.
  2. Щелкнем правой кнопкой мыши на контейнере, в котором будем создавать учетную запись, выберем в меню команду » Создать » и далее — » Пользователь «.
  3. Заполним поля » Имя «, » Фамилия «, например, » Иван » и » Иванов » (в английской версии — First Name, Last Name ), поле » Полное имя » ( Full Name ) заполнится само.
  4. Введем » Имя входа пользователя » ( User logon name ), например, User1. К этому имени автоматически приписывается часть вида » @ «, в нашем примере — » @world.ru » (полученное имя должно быть уникальным в масштабах леса).
  5. В процессе формирования имени входа автоматически заполняется » Имя входа пользователя (пред-Windows 2000) » ( User logon name (pre- Windows 2000) ), создаваемое для совместимости с прежними версиями Windows (данное имя должно быть уникально в масштабе домена). В каждой организации должны быть разработаны схемы именования пользователей (по имени, фамилии, инициалам, должности, подразделению и т.д.) В нашем примере получится имя » WORLD\User1 «. Нажмем кнопку » Далее » (рис. 6.43):

  Рис. 6.43.

  • Требовать смену пароля при следующем входе в систему (полезно в случае, когда администратор назначает пользователю начальный пароль, а затем пользователь сам выбирает пароль, известный только ему);
  • Запретить смену пароля пользователем (полезно и даже необходимо для учетных записей различных системных служб);
  • Срок действия пароля не ограничен (тоже используется для паролей учетных записей служб, чтобы политики домена не повлияли на функционирование этих служб, данный параметр имеет более высокий приоритет по сравнению с политиками безопасности);
  • Отключить учетную запись.

  Нажмем кнопку » Далее » (рис. 6.44):

  Рис. 6.44.

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

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

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

  Правила выбора символов для создания пароля:

  • длина пароля — не менее 7 символов;
  • пароль не должен совпадать с именем пользователя для входа в систему, а также с его обычным именем, фамилией, именами его родственников, друзей и т.д.;
  • пароль не должен состоять из какого-либо слова (чтобы исключить возможность подбора пароля по словарю);
  • пароль не должен совпадать с номером телефона пользователя (обычного или мобильного), номером его автомобиля, паспорта, водительского удостоверения или другого документа;
  • пароль должен быть комбинацией букв в верхнем и нижнем регистрах, цифр и спецсимволов (типа @#$%^*&()_+ и т.д.).

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

  Обзор свойств учетных записей пользователей

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

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

  Откроем консоль » Active Directory – пользователи и компьютеры » и посмотрим свойства только что созданного нами пользователя.

  Закладка » Общие «. На данной закладке содержатся в основном справочные данные, которые могут быть очень полезны при поиске пользователей в лесу AD. Наиболее интересные из них:

  • » Имя «
  • » Фамилия «
  • » Выводимое имя «
  • » Описание «
  • » Номер телефона «
  • » Электронная почта «

  Закладка » Адрес » — справочная информация для поиска в AD.

  Закладка » Учетная запись » — очень важный набор параметров (параметры » Имя входа пользователя » и » Имя входа пользователя (пред-Windows 2000) » обсуждались выше при создании пользователя):

  • кнопка » Время входа » — дни и часы, когда пользователь может войти в домен;
  • кнопка » Вход на… » — список компьютеров, с которых пользователь может входить в систему (регистрироваться в домене);
  • Поле типа чек-бокс » Заблокировать учетную запись » — этот параметр недоступен, пока учетная запись не заблокируется после определенного политиками некоторого количества неудачных попыток входа в систему (попытки с неверным паролем), служит для защиты от взлома пароля чужой учетной записи методом перебора вариантов; если будет сделано определенное количество неудачных попыток, то учетная запись пользователя автоматически заблокируется, поле станет доступным и в нем будет установлена галочка, снять которую администратор может вручную, либо она снимется автоматически после интервала, заданного политиками паролей;
  • » Параметры учетной записи » (первые три параметра обсуждались выше):
    • » Требовать смену пароля при следующем входе в систему «
    • » Запретить смену пароля пользователем «
    • » Срок действия пароля не ограничен «
    • » Отключить учетную запись » — принудительное отключение учетной записи (пользователь не сможет войти в домен);
    • » Для интерактивного входа в сеть нужна смарт-карта » — вход в домен будет осуществляться не при помощи пароля, а при помощи смарт-карты (для этого на компьютере пользователя должно быть устройство для считывания смарт-карт, смарт-карты должны содержать сертификаты, созданные Центром выдачи сертификатов);

    Закладки » Телефоны «, » Организация » — справочная информация о пользователе для поиска в AD.

    Закладка » Профиль «

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

    • локальные — хранятся в папке » Documents and Settings » на том разделе диска, где установлена операционная система;
    • перемещаемые (сетевые, или roaming ) — хранятся на сервере в папке общего доступа, загружаются в сеанс пользователя на любом компьютере, с которого пользователь вошел (зарегистрировался) в домен, давая возможность пользователю иметь одинаковую рабочую среду на любом компьютере (путь к папке с профилем указывается на данной закладке в виде адреса \\server\share\%username% , где server — имя сервера, share — имя папки общего доступа, %username% — имя папки с профилем; использование переменной среды системы Windows с названием %username% позволяет задавать имя папки с профилем, совпадающее с именем пользователя);
    • обязательные ( mandatory ) — настройки данного типа профиля пользователь может изменить только в текущем сеансе работы в Windows, при выходе из системы изменения не сохраняются.

    Параметр «Сценарий входа» определяет исполняемый файл, который при входе пользователя в систему загружается на компьютер и исполняется. Исполняемым файлом может быть пакетный файл ( .bat , .cmd ), исполняемая программа (.exe, .com), файл сценария (.vbs, js).

    Закладка » Член групп » — позволяет управлять списком групп, в которые входит данный пользователь.

    Закладка » Входящие звонки «.

    Управление доступом пользователя в корпоративную систему через средства удаленного доступа системы Windows Server (например, через модем или VPN-соединение). В смешанном режиме домена Windows доступны только варианты » Разрешить доступ » и » Запретить доступ «, а также параметры обратного дозвона (» Ответный вызов сервера «). В режимах » Windows 2000 основной » и » Windows 2003 » доступом можно управлять с помощью политик сервера удаленного доступа (не надо путать с групповыми политиками). Подробнее данный вопрос обсуждается в разделе, посвященном средствам удаленного доступа.

    Закладки » Профиль служб терминалов «, » Среда «, » Сеансы «, » Удаленное управление » — данные закладки управляют параметрами работы пользователя на сервере терминалов:

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

    1. Intel processor diagnostic tool что это
    2. Загрузчик скриншотов steam как отключить
    3. Индукционная плита bosch ошибка e что это
    4. Как поменять ориентацию одной страницы в ворде