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

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

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

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

Потерян пароль от учетной записи в Windows
Доброго времени суток. Очень нужна ваша помощь. потерял пароль от учетной записи Администратора в.

Как заснифать пароль учетной записи?
добрый вечер уважаемые!))) у меня такой вопрос как я смогу снифать пароль учетной записи.

Учетные записи домена хранятся в базе данных Active Directory. Обычно база данных AD располагается в файле %Windows%/ntds/NTDS.DIT и является сердцем Active Directory.

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

Сообщение от Dywar
Сообщение от Dywar

Нет, я достал файлы SAM и SYSTEM загрузившись из под линукса и скопировал их на другой компьютер, где пробовал их открывать в следующих программах:
Удалено

Все выше перечиленные проги не видели доменных учетных записей, а некоторые даже других учетных записей не видели. Последняя прога единственная, которая помогла сбросить пароль к локальной учетной записи мгновенно без всяких там брут форсов переборов. Но опять же, она доменных учетных записей не видела
Помогите! Где найти пароль от доменной учетной записи?

Добавлено через 5 минут
Учетная запись, пароль от которой я хочу достать, моя. Я забыл пароль и не могу вспомнить. Имею полный доступ к компьютеру и могу в другие админские учетки заходить, а вот в свою родную доменную учетную запись никак не получается разблокировать. Истратил уже 2 дня на это

Раз она ваша, скажите админу сбросить пароль. Или дату на компьютере передвиньте на 1 год вперед, и будет новый пасс запрошен (если в групповых политиках такое требование).

Авторизуйтесь в домене, перехватив трафик.

Сообщение от Dywar

Такое требование есть. Собственно из-за него я теперь и мучаюсь с забытым паролем. В пятницу после входа в учетку попросило поменять пароль. Ну я поменял, и будь проклят тот момент, когда я понадеялся на свою память и нигде не записал новый пароль! Через час когда нужно было разлочить свою учетку, вспомнить своего пароля я уже не мог. Точнее, пароль то я помню, но почему оно не входит. То ли я два раза подряд ввел где-то неправильный символ на клавиатуре при создании нового пароля, то ли чего.
Теперь ВСЕГДА буду записывать свои пароли.

Сообщение от Dywar

У меня новый пасс запрашивается где-то раз в 3 месяца, и при том только после того, как я ввойду в свою учетную запись под текущим паролем. Как же у меня оно запросит новый пасс, если я текущего пароля не помню??

Сообщение от Dywar

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

Сообщение от Dywar

Можете подробнее рассказать, как это сделать?

Сообщение от Dywar
Сообщение от Tolias28

Потому что я когда-то пробовал вытягивать сетевой кабель и логиниться под сетевой учеткой, вводя свой пароль. Без доступа к сети я вошел в сетевую учетку без доступа к инету. Значит хеш этого пароля на компьютере хранится где-то локально. И если файла %Windows%/ntds/NTDS.DIT на моем компьютере нету, значит пароль хранится где-то в другом месте.

—
С меня модератор Persk прикалывается что ли. Просит написать в личку об выяснении его действий, когда она у него закрыта. Пишу ему здесь в теме, что она у него закрыта, а он мне снова в личку пишет, что открыта, так как другие ему без проблем пишут. Не знаю, для кого у вас личка там открыта, что вам могут писать, но я вот пару секунд назад снова попробовал отослать вам ЛС и получил в ответ вот такое:
[QUOTE]Вы не можете отправить сообщение Persk, поскольку он(а) не разрешил(а) принимать личные сообщения, либо ему(ей) не разрешено это делать.

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 – индекс кэшированных данных). По умолчанию даже у администратора нет прав на просмотр содержимого этой ветки реестра, но при желании их можно легко получить.

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

Настройка 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.

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

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

• 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 в рамках домена, то вам может быть интересно, где хранятся пароли и настройки учетных записей пользователей. В данной статье мы рассмотрим этот вопрос более подробно и дадим полезные советы.

Где хранятся пароли пользователей домена

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

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

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

Где хранятся пароли учетных записей Windows

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

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

Где хранится пароль от учетной записи Windows

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

Полезные советы и выводы

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

Настройки учетных записей и пароли пользователей домена Windows хранятся в базе данных безопасности, известной как SAM. Эта база данных находится в реестре на всех членах домена и рабочих станциях. База данных SAM содержит информацию обо всех учетных записях пользователей, в том числе хэши их паролей. Хэш — это зашифрованное представление пароля, чтобы он не мог быть просмотрен в открытом виде. Хэши паролей используются для проверки подлинности пользователя при входе в систему. Кроме того, база данных SAM также содержит информацию о разрешениях, предоставленных пользователю, и ограничениях, наложенных на его доступ к ресурсам и приложениям в сети домена. Для обеспечения безопасности данных учетных записей, база данных SAM защищена от несанкционированного доступа и контролируется службой безопасности Windows.

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

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

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

Политика паролей домена конфигурируется объектом GPO- Default Domain Policy, которая применяется для всех компьютеров домена. Для того что бы посмотреть или внести изменения в политику паролей, необходимо запустить оснастку «Управление групповой политикой», найти Default Domain Policy, нажать на ней правой кнопкой мыши и выбрать «Изменить«.

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

Политика	Краткое пояснение	Возможные значения
Вести журнал паролей/ Enforce password history	Определяет число новых уникальных паролей	0-24
Максимальный срок действия пароля/ Maximum password age	Определяет период времени (в днях), в течении которого можно использовать пароль, пока система не потребует сменить его.	1-999
Минимальная длина пароля / Minimum password lenght	Параметр определяет минимальное количество знаков, которое должно содержаться в пароле
Минимальный срок действия пароля/ Minimum password age	Параметр определяет период времени (в днях)?в течении которого пользователь должен использовать пароль, прежде чем его можно будет изменить.	0-998
Пароль должен отвечать требованиям сложности / Password must meet complexity requirements

Параметр определяет должен ли пароль отвечать сложности:

-не содержать имени учетной записи

— длина не менее 6 знаков

— содержать заглавные буквы (F, G,R)

— содержать строчные буквы (f,y,x)

— содержать спец знаки (#,@,$)

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

Трудности возникают, если у вас в домене должны быть исключение, т.е. пользователь или группа пользователей для которых необходимы иные условия политики пароля. Для этих целей необходимо использовать гранулированную политику пароля. Эти политики представляют отдельный класс объектов AD, который поддерживает параметры гранулированной политики паролей: объект параметров политики PSO (Password Settings Object). Гранулированные политики пароля не реализованы как часть групповой политики и не применяются объектами GPO их можно применить отдельно к пользователю или глобальной группе.

Для того, что бы настроить PSO необходимо запустить adsiedit.msc, для этого нажимаете кнопку «Пуск», в окне «Выполнить», введите «adsiedit.msc» и нажмите кнопку «Enter».

В оснастке «Редактор ADSI» щелкните правой кнопкой мыши Редактор ADSI и выберите команду Подключение к...

Нажмите на кнопку «OK«, чтобы выбрать настройки по умолчанию в диалоговом окне «Параметры подключения» или в поле Имя введите полное доменное имя для того домена, в котором требуется создать объект параметров паролей, а затем нажмите кнопку «ОК».

Далее зайдите по пути «DC= «- «CN=System»- «CN=Password Setings Container».

Щелкните правой кнопкой пункт «CN=Password Setings Container«, выберите команду «Создать», а затем пункт «Объект».

В диалоговом окне Создание объекта в разделе Выберите класс щелкните атрибут msDS-PasswordSettings (выбора как такого у вас не будет, поскольку атрибут будет один), затем нажмите кнопку «Далее».

После этого мастер поможет создать объект настроек для пароля Password Settings Object. Необходимо будет указать значение для каждого из следующих 10 атрибутов. Ниже представлена таблица с кратким описанием и возможными значениями атрибутов.

После того как создана PSO, необходимо добавить в него пользователя или группу пользователей, к которым будет применяться указанные настройки пароля. Для этого нажимаем правой кнопкой мыши на PSO и выбираем «Свойства«.

В редакторе атрибутов находим и выбираем атрибут msDS-PSOAppliesTo и нажимаем кнопку «Изменить«.

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

Если все указано верно настройку политик паролей PSO можно считать успешно завершенной.

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

Когда доменный пользователь входит в 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 – индекс кэшированных данных). По умолчанию даже у администратора нет прав на просмотр содержимого этой ветки реестра, но при желании их можно легко получить.

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

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

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

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

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

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

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

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

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

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

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

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

Архив номеров / 2007 / Выпуск №4 (53) / Администрирование учетных записей в домене Active Directory

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

Одна из важнейших задач администратора – управление локальными и доменными учетными записями: аудит, квотирование и разграничение прав пользователей в зависимости от их потребностей и политики компании. Что может предложить в этом плане Active Directory?

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

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

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

Знакомство с Active Directory – Users and Computers

После того как вы установили свой первый контроллер в домене (тем самым вы собственно и организовали домен), в разделе «Администрирование» появляется пять новых элементов (см. рис. 1).

Рисунок 1. Новые элементы для администрирования домена

Для управления объектами AD используется Active Directory – Пользователи и компьютеры (ADUC – AD Users and Computers, см. рис. 2), которая также может быть вызвана через меню «Выполнить» посредством DSA.MSC.

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

Существует также возможность для управления объектами AD без обращения к серверу напрямую. Ее обеспечивает пакет ADMINPAK.MSI, расположенный в директории «%SYSTEM_DRIVE%\Windows\system32». Развернув его на своей машине и наделив себя правами администратора домена (если таковых не было), вы сможете администрировать домен.

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

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

Вводим компьютер в домен

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

Создаем пользователя домена

Пусть мы создали пользователя Иван Иванов в контейнере Users (User Logon Name: ivanov@HQ.local). Если в системах NT 4 это имя играло лишь роль украшения, то в AD оно является частью имени в формате LDAP, которое целиком выглядит так:

Здесь cn – container name, dc – domain component. Описания объектов в формате LDAP используются для выполнения сценариев WSH (Windows Script Hosts) либо для программ, использующих протокол LDAP для связи с Active Directory.

Для входа в домен Иван Иванов должен будет использовать имя в формате UPN (Universal Principal Name): ivanov@hq.local. Также в доменах AD будет понятно написание имени в старом формате NT 4 (пред Win2000), в нашем случае HQ\Ivanov.

При создании учетной записи пользователя ей автоматически присваивается идентификатор защиты (SID, Security Identifier) – уникальный номер, по которому система и определяет пользователей. Это очень важно понимать, так как при удалении учетной записи удаляется и ее SID и никогда не используется повторно. А каждая новая учетная запись будет иметь свой новый SID, именно поэтому она не сможет получить права и привилегии старой.

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

Рабочая среда пользователя

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

Рассмотрим основные составляющие профиля пользователя:

Если пользователь впервые входит в систему, происходит следующее:

В конечном итоге рабочее окружение пользователя – это объединение его рабочего профиля и профиля All Users, в котором находятся общие для всех пользователей данной машины настройки.

Теперь несколько слов о создании профиля по умолчанию для домена. Создайте фиктивный профиль на своей машине, настройте его в соответствии с вашими нуждами либо с требованиями корпоративной политики. Затем выйдите из системы и снова зайдите как администратор домена. На общем ресурсе NETLOGON-сервера создайте папку Default User. Далее при помощи вкладки User Profiles в апплете System (см. рис. 3) скопируйте ваш профиль в эту папку и предоставьте права на ее использование группе Domain Users или какой-либо другой подходящей группе безопасности. Все, профиль по умолчанию для вашего домена создан.

Рисунок 3. Вкладка «User Profiles» апплета System

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

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

Перемещаемые профили хранятся на сервере. Путь к ним указывается в настройках пользователя домена (см. рис. 4).

Рисунок 4. Здесь указывается путь к перемещаемому профилю

При желании можно указать перемещаемые профили для нескольких пользователей одновременно, выделив нескольких пользователей, и в свойствах во вкладке «Профиль» указать %USERNAME% вместо папки с именем пользователя (см. рис. 5).

Рисунок 5. Путь к перемещаемым профилям нескольких пользователей

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

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

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

Технология IntelliMirror в системах Windows последних версий позволяет осуществлять перенаправление определенных папок пользователей, таких как «Мои документы», «Мои рисунки» и др., на сетевой ресурс.

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

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

В первом случае нужно кликнуть на иконке «Мои документы» на рабочем столе либо в меню «Пуск» правой кнопкой мыши и выбрать свойства. Дальше все предельно просто.

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

Рисунок 6. Настройка перенаправления папок при помощи групповых политик

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

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

К недостаткам перемещаемых профилей можно отнести следующее:

Введение уже существующего пользователя в домен

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

Создайте на общем сетевом ресурсе (например, Profiles) на сервере папку с именем пользователя и задайте для нее разрешения на запись для группы Everyone. Пусть она называется HQUser, а полный путь к ней выглядит так: \\Server\Profiles\HQUser.

Создайте пользователя домена, который будет соответствовать пользователю вашей локальной сети, и в качестве пути к профилю укажите \\Server\Profiles\HQUser.

На компьютере, содержащем локальный профиль нашего пользователя, нужно войти под учетной записью администратора и при помощи вкладки User Profiles апплета System скопировать его в папку \\Server\Profiles\HQUser.

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

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

Для включения механизма квотирования и его настройки нужно зайти в свойства локального тома и открыть вкладку «Квота» (Quota) (см. рис. 7).

Рисунок 7. Включение дисковых квот

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

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

Рисунок 8. Управление дисковыми квотами для отдельных пользователей домена

Группы пользователей в AD

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

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

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

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

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

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

Чтобы понять описанное выше и основные принципы вложенности групп, рассмотрим пример. Пусть у нас есть лес, содержащий два домена HQ.local и SD.local (какой из них корневой в данном случае, не важно). Каждый из доменов содержит ресурсы, к которым нужно предоставить доступ, и пользователей (см. рис. 9).

Рисунок 9. Предоставление доступа на основе групп

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

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

Каталогом Distrib будут иметь право пользоваться как члены домена HQ.local, так и члены домена SD.local (оранжевые линии на рис. 9). Поэтому пользователей Manager и Salary мы можем добавить в глобальную группу домена HQ.local, а затем эту группу добавить в локальную группу домена SD.local вместе с пользователем IT. Затем этой локальной группе и предоставить доступ к ресурсу Distrib.

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

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

На каком-то ресурсе в Интернете, посвященном сертификационным экзаменам Microsoft, я увидел упоминание о такой формуле – AGUDLP, что значит: учетные записи (Account) помещаются в глобальные группы (Global), которые помещаются в универсальные (Universal), которые помещаются в локальные доменные группы (Domain Local), к которым и применяются разрешения (Permissions). Эта формула в полной мере описывает возможность вложенности. Следует добавить, что все эти виды могут быть вложены в локальные группы отдельно взятой машины (локальные доменные исключительно в рамках своего домена).