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

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

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

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

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

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

В самом первом приближении профиль пользователя - это содержимое директории C:\Users\Name , где Name - имя пользователя, там мы увидим привычные всем папки Рабочий стол, Документы, Загрузки, Музыка и т.д., а также скрытую папку AppData .

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

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

Папка AppData предназначена для хранения настроек и пользовательских данных установленных программ и в свою очередь содержит еще три папки: Local, LocalLow и Roaming .

Рассмотрим их подробнее:

• Roaming - это "легкая" и, как следует из названия, перемещаемая часть профиля. Она содержит все основные настройки программ и рабочей среды пользователя, если в сети используются перемещаемые профили, то ее содержимое копируется на общий ресурс, а затем подгружается на любую рабочую станцию, куда выполнил вход пользователь.
• Local - "тяжелая" часть профиля, содержит кеш, временные файлы и иные, применимые только к текущему ПК настройки. Может достигать значительных размеров, по сети не перемещается.
• LocalLow - локальные данные с низкой целостностью. В данном случае мы снова имеем неудачный перевод термина low integrity level , на самом деле уровни целостности - это еще один механизм обеспечения безопасности. Не вдаваясь в подробности можно сказать, что высокой целостностью обладают данные и процессы системы, стандартной - пользователя, низкой - потенциально опасные. Если заглянуть в данную папку, то мы увидим там данные связанные с браузерами, флеш-плеером и т.п. Логика здесь проста - в случае какой-либо нештатной ситуации или атаки процессы запущенные из этой папки не будут иметь доступа к данным пользователя.

А теперь самое время подумать, повреждение каких из указанных данных может привести к проблемам с загрузкой профиля? Пожалуй, что никаких. Следовательно в профиле должно быть что-то еще. Конечно оно есть, и если внимательно посмотреть на скриншот профиля пользователя выше, то мы увидим там файл NTUSER.DAT . Если включить отображение защищенных системных файлов , то мы увидим целый набор файлов с аналогичными именами.

Вот мы и подобрались к сути. В файле NTUSER.DAT находится ветвь реестра HKEY_ CURRENT_USER для каждого пользователя. И именно повреждение ветви реестра делает невозможным загрузку профиля пользователя. Но не все так плохо, как может показаться на первый взгляд. Реестр достаточно хорошо защищен от возможных сбоев.

Файлы ntuser.dat.LOG содержат журнал изменений реестра с момента последней удачной загрузки, что делает возможным откатиться назад в случае возникновения каких-либо проблем. Файлы с расширением regtrans-ms являются журналом транзакций, что позволяет поддерживать ветку реестра в непротиворечивом виде в случае внезапного прекращения работы во время внесения изменений в реестр. В этом случае все незавершенные транзакции будут автоматически откачены.

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

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

Способ 1. Устранение проблемы в профиле пользователя

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

Chkdsk c: /f

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

Слева увидим некоторое количество разделов с именем типа S-1-5 и длинным "хвостом", которые соответствуют профилям пользователей. Для того чтобы определить какой профиль принадлежит какому пользователю обратите внимание на ключ ProfileImagePath справа:

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

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

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

Затем находим в новом основном профиле два ключа RefCount и State и устанавливаем значения обоих в нуль.

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

Способ 2. Создание нового профиля и копирование туда пользовательских данных

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

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

и удаляем все ветви, относящиеся к вашему профилю. Перезагружаемся.

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

Для дальнейших действий вам понадобится еще одна учетная запись с правами администратора, создадим ее, в нашем случае - это учетная запись temp .

После чего выходим из нашей основной учетной записи (или перезагружаемся) и входим во вспомогательный аккаунт. Наша задача - скопировать все содержимое старой папки профиля, кроме файлов NTUSER, в новую папку. Для этих целей лучше использовать файловый менеджер (Total Commander, Far и т.д.) запущенный с правами администратора.

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

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

• Теги:

Please enable JavaScript to view the

Повреждение учетной записи пользователя является общей проблемой Windows. Проблема возникает, когда вводите пароль или пин-код на экране блокировки и при нажатии enter будет выводиться ошибка "служба профилей пользователей не удалось войти в систему. Невозможно загрузить профиль пользователя" в windows 10 или Служба профилей пользователей препятствует входу в систему в Windows 7. .

Решаем проблему "Служба профилей пользователей не удалось войти в систему" с помощью редактора реестра

Вариант 1. Исправить профиль учетной записи пользователя

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

Шаг 1 . Нажмите сочетание клавиш "windows + R " для вызова команды "выполнить" и введите команду regedit для входа в реестр.

Шаг 2 . В открывшимся окне перейдите по пути:

Шаг 3 . В параметре у вас будет несколько ключей s-1-5 . Вам нужно будет выбрать самый длинный ключ с длинным массивом чисел и вашей учетной записью, на которой ошибка "Служба профилей пользователей не удалось войти в систему". Убедиться, что путь правильный нажмите на длинный ключ и с право в колонке должно быть имя , если не нашли, то листайте все длинные ключи пока не наткнетесь в правой колонке на с вашим сломанным профилем, в моем случае учетная запись .

Шаг 4 . Если вы неправильно переименовали папку профиля пользователя C:\User\сайт пострадавшей учетной записи, то откройте проводник по пути C:\User\сайт и нажмите на сломанном профиле правой кнопкой мыши, выберите переименовать и введите вручную правильное имя профиля (сайт). После переименовки заходим обратно в реестре в папку и смотрим, чтобы имя было написано, как на картинке (шаг 3) C:\User\сайт.

Смотрите два варианта шаг 6 и шаг 7 в зависимости у кого как

Шаг 5 . Теперь сделаем два варианта, если у нас один длинный ключ S-1-5-21-19949....-1001.bak (в конце расширение.bak) и со вторым без .bak т.е. просто S-1-5-21-19949....-1001. В зависимости у кого как выстроились профили два или один.

Шаг 6 . Есть только один ключ в конце с.bak (S-1-5-21-19949....-1001.bak).

• А) Если у вас есть только один ключ в конце с .bak (S-1-5-21-19949....-1001.bak), нажмите на нем правой кнопкой мыши и нажмите переименовать. (смотрите рисунок ниже).

• Б) Удалите само слово с точкой .bak , чтобы получились просто цифры . Следуйте дальше шагу 8. (смотрите рисунок ниже)

Шаг 7 . Если у вас есть два одинаковых ключа, один без.bak, второй с.bak. (S-1-5-21-19949....-1001 и S-1-5-21-19949....-1001.bak) .

• А) В левой панели реестра, щелкните правой кнопкой мыши на ключе без .bak и допишите точка, две буквы .bk (см. рисунок ниже).

• Б) Теперь нажмите правой клавишей мыши на ключ с .bak , выберите переименовать и удалите .bak с точкой. (см. рисунок ниже).

• В) Теперь вернитесь и переименуйте первый ключ с .bk в .bak . Нажмите enter и следуйте дальше шагу 8.

Шаг 8 . Выделите ключ который переименовали без .bak и с право в столбце нажмите два раза, чтобы открыть настройки параметра , и присвойте значение 0. Если у вас нет такого параметра , то нажмите с право на пустом поле правой кнопкой мыши и создайте параметр DWORD (32-bit), переименуйте его в RefCount и задайте значение 0.

Шаг 9 . В правом поле выберите ключ без .bak и в параметре State задайте значение 0. Если нет такого параметра, то кликните на пустом поле с право и нажмите создать DWORD (32-bit), переименуйте его в State и задайте значение 0.

Шаг 10 . Перезапустите ваш комп и ошибка "служба профилей пользователей не удалось войти в систему" и "невозможно загрузить профиль пользователя" в windows 10 должна исчезнуть.

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

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

Шаг 1 . Если есть другая учетная запись администратора, на которой нет ошибки, выйдите из текущей учетной записи (например: сайт) и войдите в запись администратора.

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

• А). Загрузитесь в безопасном режиме, включите встроенный Администратор, выйдите из системы и войдите в систему Administrator.
• Б). Откройте окно командной строки при загрузке, включите встроенный администратор, перезагрузите компьютер и войдите в систему Administrator.

Шаг 2 . Сделайте резервную копию всего, что вы не хотите потерять в папке профиля C: \ Users \ (имя пользователя) (например: сайт) соответствующей учетной записи пользователя в другое место. Когда закончите, удалите папку C: \ Users \ (имя пользователя).

Шаг 3 . Нажмите кнопки windows + R, чтобы открыть диалоговое окно «Выполнить», введите regedit и нажмите кнопку OK.

Шаг 4 . В редакторе реестра перейдите к указанному ниже расположению.

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

Шаг 5 . На левой панели в списке ProfileList нажмите на длинный ключ на котором ошибка учетной записи. Справа в виден профиль.

Шаг 6 . Удалите профили с ошибкой с.bak и без.bak. К примеру (S-1-5-21-19949....-1001 и S-1-5-21-19949....-1001.bak )-удалить.

Шаг 7 . Закройте редактор реестра и перезагрузите компьютер, после чего он автоматически воссоздаст нового пользователя.

Решим проблему "Невозможно загрузить профиль пользователя" простым способом

Способ 1 . Данный способ работает не у всех, но многим он помог. Постарайтесь скопировать свои документы в папке (C:\Users\) в другое место, чтобы создать резервную копию на всякий случай. Обычно проблема возникает из-за повреждения файла "NTUSER.DAT", расположенного в папке "C:\Users\Default". Чтобы решить эту проблему вам нужно заменить файл "NTUSER.DAT" с другого профиля. .

1. Зайдите в систему в безопасном режиме с учетной записью профиля который работает.
2. Найдите файл (C:\Users\Default) "NTUSER.DAT" и переименуйте расширение.DAT на.OLD. Должно быть (NTUSER.OLD).
3. Найдите файл "NTUSER.DAT" в рабочем профиле таких как "Гость","Общие". Пример (C:\Users\Guest\NTUSER.DAT).
4. Скопируйте его и вставьте в папку по умолчанию C:\Users\Default.
5. Перезагрузить компьютер.

Можете скопировать этот файл с другого компьютера с такой же версией windows и вставить его к себе по пути C:\Users\Default.

Способ 2 . Можно попробовать заменить целиком папку "C:\Users\" с другого компьютера.

• Возьмите флешку в формате FAT32 и запишите на нее с другого компа папку C:\Users\и закиньте к себе на комп.

Если кто знает, как еще исправить ошибку, "Служба профилей пользователей препятствует входу в систему" еще каким методом, то пишите в форме "сообщить об ошибке".

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

Первые существенные изменения в механизмах защиты служб появились в Windows XP Service Pack 2. Сейчас уже сложно себе это представить, но до выхода SP2 все службы самой операционной системы запускались в контексте встроенной учетной записи Local System, обладающей на компьютере максимально полными административными правами. SP2 добавил еще две записи: Local Service и Network Service. Принципиальные отличия трех перечисленных записей можно найти в табл. 1.

Таблица 1

Соответственно, начиная с Windows XP SP2, администратор мог настраивать запуск службы в контексте одной из встроенных учетных записей, локальной или доменной учетной записи. Тем не менее, большая часть служб самой Windows по-прежнему запускается в контексте Local System. Но даже если абстрагироваться от этого, ситуация, когда несколько служб запускаются в контексте одной и той же учетной записи, приводит к тому, что успешный взлом одной службы, пусть даже без административных привилегий, потенциально открывает для атакующего любые другие ресурсы, к которым имеет доступ учетная запись взломанной службы.

В Windows Vista появилось несколько механизмов, повышающих изоляцию служб. Я остановлюсь на двух.
Первый механизм – это уникальный идентификатор безопасности службы (Service SID). Данный SID генерируется для каждой службы путем хеширования имени службы с помощью алгоритма SHA-1. К результату добавляется префикс S-1-5-80-. Просмотреть SID службы можно с помощью команды sc showsid, указав в качестве параметра имя службы (см. рис. 1).
Рис. 1

Вы можете поэкспериментировать, например, со службой W32Time. Для любой папки на NTFS в настройках разрешений (permissions) нужно лишь ввести имя пользователя в формате NT SERVICE\<имя службы>, в нашем случае NT SERVICE\w32time (см. рис 2).

Рис. 2

Нажимаете Check Names, затем ОК и видите пользователя (см. рис. 3), которому можно назначать права.

Рис. 3

Еще раз подчеркну, что w32time не является объектом-пользователем. Это – SID, но раз так, его можно использовать в списках ACL, причем как в графическом интерфейсе, так и в командной строке и программным путем. Более того, сервисные SID-ы можно использовать в настройках Windows Firewall, применяя те или иные правила к конкретной службе, точнее конкретному Service SID.

Второй изменение, появившееся в Vista, это идентификаторы безопасности нового типа – Write Restricted SID. Если служба помечена типом Write Restricted SID, то ее SID добавляется в ее же маркере доступа в специальный список – Restricted SID list. При попытке такой службы записать что-либо в какой-либо файл алгоритм проверки прав доступа несколько изменяется. А именно, служба сможет записать в файл только в том случае, если разрешение Write дано явным образом SID-у этой службы, либо группе Everyone.
Например, учетная запись ServiceAccount1 некоторой службы Service1 является членом группы Group1. Группа Group1 и только она имеет разрешение Write на папку Folder1. Что произойдет, если служба попытается что-то изменить в папке Folder1? В обычной ситуации ServiceAccount1 получит возможность записи в папку за счет членства в Group1. Но если служба Service1 помечена типом Write Restricted SID, то ее маркер доступа обрабатывается иначе, и она не сможет записать что-либо в папку, поскольку ей явным образом не дано разрешение Write, равно как не дано это право и Everyone.
Просмотреть тип идентификатора безопасности можно с помощью команды sc qsidtype (см. рис. 4).

Рис. 4

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

В Windows 7 и Windows Server 2008 R2 работа над изоляцией служб была продолжена. Появились виртуальные учетные записи (virtual accounts) и управляемые учетные записи служб (managed service accounts). А собственно в чем проблема? Нужно изолировать службы – давайте создадим нужное количество локальных (или доменных) учетных записей пользователей. Для каждой критически важной службы свой account. Да, это решение. Но для локальных служб, которым не нужен сетевой доступ к ресурсам, необходимо вручную задавать пароли, длинные и сложные. И также вручную их периодически обновлять. Ну, раз уж мы за безопасность. Для служб, которые должны по сети обращаться к ресурсам в контексте доменных учетных записей, плюс к этому еще нужно регистрировать Service Principal Name (SPN), свой для каждой службы. Это неудобно. Но неудобство становится реальной проблемой, когда служба из-за просроченного пароля не может стартовать. А админ просто забыл сменить для нее пароль.

Так вот для локальных служб вы можете использовать virtual accounts. Виртуальная учетная запись используется только для запуска конкретной службы, точнее для создания контекста безопасности конкретной службы. Вы не найдете эту запись среди пользователей в Computer Management. И, тем не менее, это – account, со своим уникальным SID-ом, со своим пользовательским профилем. А стало быть, вы можете назначать ему разрешения и, тем самым, разграничивать права доступа и четко их контролировать. Но также как и в случае с Local System, Local Service и Network Service операционная система берет на себя задачи управления паролями для virtual accounts. Мы изолируем нужные службы, и у нас не болит голова о паролях.

Чтобы создать виртуальную учетную запись, нужно в настройках службы указать в качестве учетной записи: NT SERVICE\<имя службы> (см. рис 5)

Рис. 5

После запуска службы virtual account отобразится в консоли Services (рис. 6), а в папке Users вы заметите появление нового пользовательского профиля.
Рис. 6

По формату это очень напоминает сервисный SID. Но подчеркну, это не просто дополнительный уникальный SID для службы как в Vista, это отдельная учетная запись и, соответственно, другой уровень изоляции. По умолчанию виртуальные учетные записи используются, например, для пулов приложений (application pool) в IIS 7.5 в Windows Server 2008 R2. Надо иметь в виду, что virtual accounts предназначены для локального использования. Если служба, запущенная в контексте virtual account, обращается по сети, то это обращение происходит от имени учетной записи компьютера, на котором служба запущена. Если же необходимо, чтобы служба, например SQL Server, работала по сети от имени доменной учетной записи, то здесь как раз помогут managed service accounts. С ними, однако, связано больше тонкостей, и их рассмотрение выходит за рамки данного поста. Более подробно с MSA можно познакомиться