У трьох окремих системах на сервері контролера домену багато разів реєструється така подія (від 30 до 4000 разів на день залежно від системи):
An account failed to log on.
Subject:
Security ID: SYSTEM
Account Name: %domainControllerHostname%$
Account Domain: %NetBIOSDomainName%
Logon ID: 0x3E7
Logon Type: 3
Account For Which Logon Failed:
Security ID: NULL SID
Account Name:
Account Domain:
Failure Information:
Failure Reason: Unknown user name or bad password.
Status: 0xc000006d
Sub Status: 0xc0000064
Process Information:
Caller Process ID: 0x1ec
Caller Process Name: C:\Windows\System32\lsass.exe
Network Information:
Workstation Name: %domainControllerHostname%
Source Network Address: -
Source Port: -
Detailed Authentication Information:
Logon Process: Schannel
Authentication Package: Kerberos
Transited Services: -
Package Name (NTLM only): -
Key Length: 0
This event is generated when a logon request fails. It is generated on the computer where access was attempted.
The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.
The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).
The Process Information fields indicate which account and process on the system requested the logon.
The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.
The authentication information fields provide detailed information about this specific logon request.
- Transited services indicate which intermediate services have participated in this logon request.
- Package name indicates which sub-protocol was used among the NTLM protocols.
- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.
Ця подія трохи відрізняється від усіх інших, які я виявив під час досліджень, але я визначив наступне:
Event ID: 4625
. "Не вдалося ввійти в обліковий запис" .Logon Type: 3
. "Мережа (тобто підключення до спільної папки на цьому комп'ютері з інших місць в мережі)" .Security ID: NULL SID
. "Дійсний обліковий запис не ідентифіковано" .Sub Status: 0xC0000064
. Msgstr "Ім'я користувача не існує" .Caller Process Name: C:\Windows\System32\lsass.exe
. Служба підсистеми місцевого управління безпеки (LSASS) - це процес в операційних системах Microsoft Windows, який відповідає за впровадження політики безпеки в системі. Він перевіряє вхід користувачів на комп'ютер або сервер Windows, обробляє зміни пароля та створює маркери доступу. Він також пише в Журнал безпеки Windows.Workstation Name: SERVERNAME
. Запит на аутентифікацію подається або через сам контролер домену.
Подібність постраждалих систем:
- Операційна система сервера: Windows Small Business Server 2011 або Windows Server 2012 R2 Essentials
- Настільна операційна система: Windows 7 Professional (як правило)
Відмінності уражених систем:
- Антивірус
- Інтегрована Інтернет-фільтрація з Active Directory
- Настільні кешовані логотипи
- Ролі (обмін, резервне копіювання тощо)
Деякі цікаві речі, які я помітив у найбільш сильно постраждалій системі:
- Нещодавно ми почали синхронізувати паролі облікових записів користувачів Active Directory та Office 365 через інтеграцію Windows Server 2012 R2 Essentials 'Office 365. Для інтеграції потрібен пароль адміністратора Office 365 та політика безпеки. Синхронізація вимагає присвоєння кожному обліковому запису користувача відповідному обліковому запису Microsoft, що вимагає змінити пароль наступного входу. Ми також додали їх основний домен електронної пошти як суфікс UPN в Active Directory Domains and Trusts та змінили UPN всіх облікових записів користувачів на свій домен електронної пошти. Це фактично дозволило їм увійти до домену та Office 365 за допомогою своєї електронної адреси та пароля. Однак з цього моменту кількість зареєстрованих подій за день зросла з ~ 900 до ~ 3900. Примітка:
- Більшість подій, схоже, реєструються через рівні проміжки часу кожні 30 або 60 хвилин, за винятком ~ 09:00, коли користувачі приходять на роботу: 2015/07/02 18:55
2015/07/02 19:25
2015 / 07/02 19:54
2015/07/02 20:25
2015/07/02 20:54
2015/07/02 21:25
2015/07/02 22:24
2015/07/02 23:25
2015/07 / 03 00:25
2015/07/03 01:24
2015/07/03 01:55
2015/07/03 02:24
2015/07/03 02:55
2015/07/03 03:55
2015/07/03 04:55
2015/07/03 05:54
2015/07/03 06:25
2015/07/03 07:25
2015/07/03 08:24
2015/07/03 08:27
2015/07/03 08: 49
2015/07/03 08:52
2015/07/03 08:54
2015/07/03 08:56
2015/07/03 08:57
2015/07/03 09:00
2015/07/03 09:01
2015/07/03 09:03
2015/07/03 09:06
2015 / 07/03 09:08
2015/07/03 09:10
2015/07/03 09:12
2015/07/03 09:13
2015/07/03 09:17
2015/07/03 09:13 2015/07
/ 03 09:25
2015/07/03 10:24
2015/07/03 11:25 Наступна подія реєструється на сервері терміналу / віддаленого сервісу настільних ПК, хоча ніде так багато разів:
An account failed to log on. Subject: Security ID: NULL SID Account Name: - Account Domain: - Logon ID: 0x0 Logon Type: 3 Account For Which Logon Failed: Security ID: NULL SID Account Name: %terminalServerHostname% Account Domain: %NetBIOSDomainName% Failure Information: Failure Reason: Unknown user name or bad password. Status: 0xC000006D Sub Status: 0xC0000064 Process Information: Caller Process ID: 0x0 Caller Process Name: - Network Information: Workstation Name: %terminalServerHostname% Source Network Address: %terminalServerIPv6Address% Source Port: %randomHighNumber% Detailed Authentication Information: Logon Process: NtLmSsp Authentication Package: NTLM Transited Services: - Package Name (NTLM only): - Key Length: 0 This event is generated when a logon request fails. It is generated on the computer where access was attempted. The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe. The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network). The Process Information fields indicate which account and process on the system requested the logon. The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases. The authentication information fields provide detailed information about this specific logon request. - Transited services indicate which intermediate services have participated in this logon request. - Package name indicates which sub-protocol was used among the NTLM protocols. - Key length indicates the length of the generated session key. This will be 0 if no session key was requested.
Отже, підсумовуючи, це, очевидно, пов'язане з доступом до мережі з настільних комп'ютерів за допомогою облікових записів користувачів персоналу, але я не можу зрозуміти, як це зробити.
Оновлення 25.08.2015 08:48:
У найбільш сильно постраждалій системі я зробив наступне, щоб виокремити проблему і після кожного скасування зміни:
- Вимкніть сервер сервісів терміналів / віддалених настільних ПК, і загальні невдалі входи в систему не продовжуються.
- Відключений сервер контролера домену з мережі і загальних невдалих входів в систему було продовжувати.
- Перезавантажив сервер у безпечному режимі без мереж, і загальні невдалі логотипи не продовжувались.
- Зупинився і відключити всі «зайві» послуги (агент моніторингу, резервного копіювання, мережевий фільтрації інтеграції, TeamViewer, антивірус і т.д.) і загальні невдалі входи в систему було продовжувати.
- Зупинився і відключені служби Windows Server Основи (
WseComputerBackupSvc
,WseEmailSvc
,WseHealthSvc
,WseMediaSvc
,WseMgmtSvc
, іWseNtfSvc
) і загальні невдалі входи в систему НЕ продовжувати. - Врешті-решт зупинили та відключили службу управління Windows Server Essentials (
WseMgmtSvc
), і загальні невдалі входи в систему не продовжувались.
Я ще раз перевірив, що служба управління WseMgmtSvc
сервісом Windows Essentials ( ) відповідає за ці загальні невдалі логотипи, вимкнувши їх на кілька днів, а загальних невдалих логотипів та включення їх не було протягом декількох днів, а тисячі загальних невдалих логотипів не було .
Оновлення 2015/10/08 09:06:
10.10.2015 о 16:42 я знайшов таке заплановане завдання:
- Назва: "Оцінки сповіщення"
- Розташування: "\ Microsoft \ Windows \ Windows Server Essentials"
- Автор: "Корпорація Майкрософт"
- Опис: "Це завдання періодично оцінює стан здоров'я комп'ютера."
- Рахунок: "СИСТЕМА"
- Тригери: "О 08:54 28.10.2014 - Після спрацьовування повторюйте кожні 30 хвилин на невизначений час"
- Дії: "Запустіть програму: C: \ Windows \ System32 \ Essentials \ RunTask.exe /asm:"C:\Windows\Microsoft.Net\assembly\GAC_MSIL\AlertFramework\v4.0_6.3.0.0__31bf3856ad364e35\AlertFramework.dll" /class:Microsoft.WindowsServerSolutions.NetworkHealth.AlertFramework.HealthScheduledTask / method: EvaluateAlertsTaskAction / task: "Оповіщення оцінки" "
Цей часовий інтервал майже точно відповідає поведінці, зазначеній вище, тому я відключив його, щоб побачити, чи впливає це на проблему.
08.08.2015 о 08:57 я виявив, що лише 47 з цих загальних невдалих логотипів були зареєстровані з тих пір з нерегулярними інтервалами.
Отже, я ще більше звузив його.