Как отличить скрытую учётную запись службы от обычной?

[Dragokas]

Здравствуйте!

Бывают такие учётные записи, создаваемые службами, например, UpdatusUser (от NVIDIA), всякие MSSQL, MsDtsServer, Acronis Agent User.
Они по умолчанию скрыты, т.е. в них нельзя войти через меню выбора пользователей.

Как с помощью реестра идентифицировать такие учётки, понять какие из них созданы сторонними службами?

 

[Кирилл]

Как с помощью реестра идентифицировать такие учётки, понять какие из них созданы сторонними службами?

@Dragokas, надо уточнить все имеющиеся учетные записи и вычленить из них те, что принадлежат юзерам, или задача изначально просто получить перечень реальных учетных записей пользователей?

 

[Кирилл]

В общем.
На Windows 8-10 есть раздел

HKEY_USERS\.DEFAULT\Software\Microsoft\IdentityCRL\StoredIdentities

Там перечень аккаунтов MS - то есть их электронная почта.

Так же на всех системах (на ХР не знаю, надо проверить) есть раздел

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

Где есть перечень профилей учетных записей.
Здесь, на мой взгляд, можно ориентироваться на несколько параметров:
1) Учетная запись пользователя будет расположена в каталоге %userprofile% , а профили служб, обычно, в других местах. (параметр ProfileImagePath )
2) Учетная запись пользователя имеет sid параметр, а профиль службы нет - он не нужен ей. (параметр sid )

Это только мои мысли, которые легко проверить, если есть вышеперечисленные службы.

 

[Dragokas]

Где есть перечень профилей учетных записей.
Здесь, на мой взгляд, можно ориентироваться на несколько параметров:
1) Учетная запись пользователя будет расположена в каталоге %userprofile% , а профили служб, обычно, в других местах. (параметр ProfileImagePath )
2) Учетная запись пользователя имеет sid параметр, а профиль службы нет - он не нужен ей. (параметр sid )

При чём здесь это. Мне не учётку Microsoft нужно вычленить, а специальные учётки, создаваемые и используемыми службами, как Акронис. А у таких учёток есть всё, и SID, и ProfilePath, и соответственно путь в C:\users\XXX

 

[Кирилл]

При чём здесь это. Мне не учётку Microsoft нужно вычленить, а специальные учётки, создаваемые и используемыми службами, как Акронис. А у таких учёток есть всё, и SID, и ProfilePath, и соответственно путь в C:\users\XXX

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

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

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

 

[Dragokas]

У меня нет на чём тестировать.

 

[regist]

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

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

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

Так в этом и состоял вопрос заданный в первом посте. Какие есть у них особенности и как их отличить обычных учётных записей (можно читать и наоборот как обычные отличить от них). Из написанного выше ответа на этот вопрос никак не следует.

 

[regist]

Вот ещё пример такой "виртуальной" учётки UpdatusUser

 

[Lunik]

В реестре по пути

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

По параметру Guid может можно определить.
У меня у пользователей типа
MSSQL$MICROSOFT
Classic .NET AppPool
USR1CV8

Данного параметра нет.

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

Нет сорри, данный паарметр относится только к доменным пользователям.

Есть отличие что у локального пользователя что у доменного появляется параметр
RunLogonScriptSync

У этих пользователь его нет, так как вход не выполнялся соответствнно

MSSQL$MICROSOFT
Classic .NET AppPool
USR1CV8

 

[Кирилл]

@Lunik верно понял мою мысль.
+ добавлю, что та же логика должна работать и для каталогов пользователей.
То есть можно проверять наличие вложенных каталогов, характерных для "настоящего" пользователя.
Например, по этапам:

1) Перебираем раздел реестра ProfileList
2) Если есть вложенный раздел с параметром ProfileImagePath, там указан соответствующий адрес расположения
3) Там проверяем наличие атрибутов полноценной учетной записи - например, каталог Searches, Рабочий стол, файл Ntuser.dat ...

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

 

[Dragokas]

Есть отличие что у локального пользователя что у доменного появляется параметр
RunLogonScriptSync

Это не причина сокрытия учётки. Как результат - ненадёжный способ.

3) Там проверяем наличие атрибутов полноценной учетной записи - например, каталог Searches, Рабочий стол, файл Ntuser.dat ...

Это всё слишком косвенные признаки. Есть там конечно же Ntuser.dat, ведь у этого юзера всё как положено, и SID, соответственно и свой раздел в HKU. Ты наверное снова путаешь с учёткой от Майкрософт.

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

Вообщем, предположительно нашел ответ:
Acronis Agent User | Acronis Forum
Log on as a service (Windows 10)
User Rights Assignment (Windows 10)

У этой учётки должна присутствовать привилегия SeServiceLogonRight (Log on as a service).
Это не совсем признак сокрытия, но хотя бы явное разрешение использовать учётку для входа службой.

Поставил Акронис, но юзера "Acronis Agent User" я не нашел. Наверное, не та версия.
@Lunik, можешь, пожалуйста, проверить есть ли у тебя на компе, где MSSQL, упоминание этой учётной записи в пункте:
gpedit.msc:

Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment => Log on as a service

или

Конфигурация компьютера\Конфигурация Windows\Параметры безопасности\Локальные политики\Назначение прав пользователя => Вход в качестве службы

?

 

[Dragokas]

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

Запретить локальный вход

В этом случае учётка пропадает из окна входа пользователей.

 

[Lunik]

@Lunik, можешь, пожалуйста, проверить есть ли у тебя на компе, где MSSQL, упоминание этой учётной записи в пункте:
gpedit.msc:

Да они там присутствуют в пункте > Вход в качестве службы

Так же есть Пункт Запретить локальный вход, там их нет кроме USRV82

 

[Dragokas]

Спасибо. Удалось воспроизвести с помощью Download Microsoft® SQL Server® 2014 Express from Official Microsoft Download Center

Осталось выяснить как программно получить доступ к этим данным.

Вообщем, тема ещё не решена.

На мойм стенде, "Вход в качестве службы" указан в том числе основной пользователь "Alex",
а в пункте "Запретить локальный вход" указан только "Гость",
но при этом в списке пользователей экрана входа и оснастки lusrmgr.msc отсутствует "MSSQL$SQLEXPRESS",
хотя этот юзер имеет и SID, и папку в C:\Users.

В ключе ProfileList есть различия в параметрах:
1. RunLogonScriptSync - у учётки службы его нет (но это плохой критерий)
2. State - у обычной учётки (администратора) он = 0x100, а у учётки службы он = 0.

Нашел описания перечисления State, но числа 0 среди них, к сожалению нет:

RefCount in the Profilelist

According to our research, the path of the ProfileList key is “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\ “.Is the path corresponding with yours?

The main subkeys for each user are “Default”,“Flags”,“ProfileImagePath”,”ProfileLoadTimeHigh”,” ProfileLoadTimeLow”, ” RefCount ”,”Sid” and ”State”,” RunLogonScriptSync”.

Default: It's the value whose name is null.

Flags: enable you to control the installation and uninstallation of your registry entries.

ProfileImagePath: The User profiles` path.

ProfileLoadTimeHigh: Profile load time of user
ProfileLoadTimeLow: Profile load time low of user
RefCount: 0 value means the account has no active session, not `0`value means the account has an active session.

Sid:Security Identifier.

State: indicates the state of the local profile cache.

• 0001 Profile is mandatory.
• 0002 Update the locally cached profile.
• 0004 New local profile.
• 0008 New central profile.
• 0010 Update the central profile.
• 0020 Delete the cached profile.
• 0040 Upgrade the profile.
• 0080 Using Guest user profile.
• 0100 Using Administrator profile.
• 0200 Default net profile is available and ready.
• 0400 Slow network link identified.
• 0800 Temporary profile loaded.

RunLogonScriptSync : Determines whether the system waits for the logon script to finish running before it starts Windows Explorer and creates the desktop.

• 0 The logon script and Windows Explorer can run simultaneously.
• 1 Windows Explorer does not start until the logon script has finished running.

P.S. Попробовал создать новую учётку, присвоить ей State = 0 и перезагрузиться, но новая учётка не скрылась.

 

[Hunter]

Интересно.....

 

[Lunik]

2. State - у обычной учётки (администратора) он = 0x100, а у учётки службы он = 0.

У учетки пользователя домена тоже 0


У учеток ввида
Classic .NET AppPool = 204

MSSQL$MICROSOFT = 0 (RefCon =1)

USR1CV8 = 0

 

[«G~Lí†çh»]

Так ведь не только службы скрыты! SID и "своя папка" есть у таких "пользователей", как:
«система» (0x00000012 | "SY" | SYSTEM);
«Локальная служба» (0x00000013 | "LS" | LOCAL SERVICE);
«Сетевая служба» (0x00000014 | "NS" | NETWORK SERVICE).
SeInteractiveLogonRight (Локальный интерактивный вход в систему) имеют группы «Администраторы», «Гости», «Операторы архива» и «Пользователи», а что насчёт "Все" — относится ли к ним "система" и остальные "службы"?
Входила ли та служба в группу ИНТЕРАКТИВНЫЕ (0x00000004 | "IU" | INTERACTIVE) — оно-то скрыто в оснатке, чтоб не думать, как запустить whoami /groups от имени службы, проверить упоминание S-1-5-4 в реестре:

[HKEY_USERS\S-1-80-%…SID пользователя/службы%\Software\Microsoft\Windows\CurrentVersion\Group Policy\GroupMembership]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy] содержит ключ с именем S-1-5-%…SID пользователя/службы%, у которго есть "Подключ" GroupMembership, и там точно такой же список…


P.S. Почему в secpol/lusrmgr/везде где встречается "вкладка Безопасность" (GUI настройки разрешений) невозможно выбрать таких "пользователей", как ОГРАНИЧЕННЫЕ (0x0000000C | "RC" | RESTRICTED CODE | *S-1-5-12), ЗАПИСЬ ОГРАНИЧЕНА (0x00000021 | "WR" | WRITE RESTRICTED | *S-1-5-33), «Никто» (NULL SID | *S-1-0-0), ЛОКАЛЬНЫЕ (LOCAL | *S-1-2-0), «ВСТРОЕННЫЕ» (BUILTIN\BUILTIN | *S-1-5-32), «Операторы печати» (0x00000226 | "PO" | PRINTER OPERATORS | *S-1-5-32-550), «Операторы сервера» (0x00000225 | "SO" и SERVER OPERATORS, *S-1-5-32-549) и ACCOUNT_OPERATORS (0x00000224 | "AO" | *S-1-5-32-448)?? А то ведь как попадутся в некоторых оснатках, и они оттуда легко удаляются, а вот вернуть обратно быстро уже невозможно – ни одной даже командной утилиты для этого не предусмторено… А возиться с PowerShell`ом ради банального исправления… пф, уж проще и быстрее восстановление системы сделать… Для NTFS и реестра — calcs + icacls пойдёт, но вот в .MSC оснатках…

 

[regist]

@«G~Lí†çh» просьба используйте теги CODE, а то читать ваше сообщение очень сложно.

 

[Dragokas]

Для проверки / изучения:

Service Accounts

Windows Server standalone and group-managed service accounts in Active Directory

learn.microsoft.com

+
WinAPI: NetIsServiceAccount