[Check_mk (english)] Windows host, ignore Winlogon CRIT

Andy isalexandru at gmail.com
Tue Feb 3 15:07:22 CET 2015


/opt/omd/sites/prod_mon/etc/check_mk/main.mk

# Put your host names here
# all_hosts = [ 'localhost' ]
all_hosts = [ ]

logwatch_patterns = {
    'Security': [

    # reclassify only on host WIN-edge-001
    ( ["WIN-edge-001"], 'I', 'winlogon' ),

    # this is for all hosts again
    ( 'I', 'test.*failed' )
    ]
}

Message:
"CRIT - 41 CRIT messages (Last worst: "Feb 03 14:08:10 0.4625
Microsoft-Windows-Security-Auditing An account failed to log on. Subject:
Security ID: S-1-5-18 Account Name: IP-0A4980D6$ Account Domain: WORKGROUP
Logon ID: 0x3e7 Logon Type: 10 Account For Which Logon Failed: Security ID:
S-1-0-0 Account Name: Administrator Account Domain: IP-0A4980D6 Failure
Information: Failure Reason: %%2313 Status: 0xc000006d Sub Status:
0xc000006a Process Information: Caller Process ID: 0x1764 Caller Process
Name: C:\Windows\System32\winlogon.exe Network Information: Workstation
Name: IP-0A4980D6 Source Network Address: 58.20.36.144 Source Port: 50467
Detailed Authentication Information: Logon Process: User32 Authentication
Package: Negotiate 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.")"


---Permission to forward and reprint is given.---
*Don't confuse my personality with my attitude. My personality is who I am.
My attitude depends on who you are.*

On Tue, Feb 3, 2015 at 2:02 PM, Marcel Schulte <schulte.marcel at gmail.com>
wrote:

> But the shown message does not match any of your rules. At least not the
> ones provided.
>
> Could you please provide all your logwatchpattern rules as-is and a
> message that should be handled by these rules (or you think it should) but
> isn't.
>
> Regards,
> Marcel
>
> Andy <isalexandru at gmail.com> schrieb am Tue Feb 03 2015 at 14:52:20:
>
> Marcel, thanks for the reply.
>> I did that already. On the Windows machine AND check_mk.
>>
>> I still receive:
>>
>> CRIT - 7 CRIT messages (Last worst: "Feb 03 13:43:07 0.4625
>> Microsoft-Windows-Security-Auditing An account failed to log on. Subject:
>> Security ID: S-1-5-18 Account Name: IP-xxxxxxxxx Account Domain: WORKGROUP
>> Logon ID: 0x3e7 Logon Type: 10 Account For Which Logon Failed: Security ID:
>> S-1-0-0 Account Name: administrator Account Domain: IP-xxxxxxx Failure
>> Information: Failure Reason: %%2313 Status: 0xc000006d Sub Status:
>> 0xc000006a Process Information: Caller Process ID: 0x1468 Caller Process
>> Name: C:\Windows\System32\winlogon.exe Network Information: Workstation
>> Name: IP-xxxxxxx Source Network Address: xxx.xxx.xxx.xxx Source Port: 58233
>> Detailed Authentication Information: Logon Process: User32 Authentication
>> Package: Negotiate 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"....
>>
>> Even after clearing the logs, the new ones are not ignored.
>>
>> Thanks,
>>
>> ---Permission to forward and reprint is given.---
>> *Don't confuse my personality with my attitude. My personality is who I
>> am. My attitude depends on who you are.*
>>
>> On Tue, Feb 3, 2015 at 1:47 PM, Marcel Schulte <schulte.marcel at gmail.com>
>> wrote:
>>
>>> Hi Andy,
>>>
>>> changes in logwatch patterns are only valid for NEW messages, they don't
>>> reclassify existing ones.
>>>
>>> ...so you first have to purge the affected Logwatch messages in check_mk.
>>>
>>> HTH,
>>> Marcel
>>>
>>> Andy <isalexandru at gmail.com> schrieb am Tue Feb 03 2015 at 13:37:12:
>>>
>>>> HI,
>>>>
>>>> I'm using check_mk with OMD on a Linux host.
>>>> So far I added 24 agents there...3 of them running Windows Server.
>>>>
>>>> Since I add the agents, I get CRIT/WARN from them. I want to solve the
>>>> problem that I currently have before going further.
>>>>
>>>> Basically:
>>>>
>>>> LOG-Security
>>>>
>>>> "CRIT - 302 CRIT messages (Last worst: "Feb 03 12:22:57 0.4625
>>>> Microsoft-Windows-Security-Auditing An account failed to log on.
>>>> Subject:
>>>> Security ID: S-1-5-18 Account Name: IP-0A4980D6$ Account Domain:
>>>> WORKGROUP
>>>> Logon ID: 0x3e7 Logon Type: 10 Account For Which Logon Failed: Security
>>>> ID:
>>>> S-1-0-0 Account Name: administrator Account Domain: IP-0A4980D6 Failure
>>>> Information: Failure Reason: ...."
>>>>
>>>> "CRIT - 325 CRIT, 2 WARN messages (Last worst: "Feb 03 10:58:24 0.0
>>>> sshd The
>>>> operation completed successfully.")
>>>>
>>>> Now, from what I understand, reading
>>>> http://mathias-kettner.de/checkmk_windows.html , I added the following
>>>> under
>>>>
>>>> /opt/omd/sites/edge_monitor/etc/check_mk/main.mk
>>>>
>>>> logwatch_patterns = {
>>>>     'Security': [
>>>>
>>>>     # reclassify only on host WIN-edge-001
>>>>     ( ["WIN-edge-001"], 'I', 'sshd.*successfully' ),
>>>>
>>>>     # this is for all hosts again
>>>>     ( 'I', 'test.*failed' )
>>>>     ]
>>>> }
>>>>
>>>> Then perform an
>>>> omd restart edge_monitor
>>>>
>>>> However, the messages are still on the webpage. Rescheduling a check is
>>>> not
>>>> changing the CRIT status.
>>>>
>>>> Any advice is appreciated.
>>>> Thanks,
>>>>
>>>>
>>>> _______________________________________________
>>>> checkmk-en mailing list
>>>> checkmk-en at lists.mathias-kettner.de
>>>> http://lists.mathias-kettner.de/mailman/listinfo/checkmk-en
>>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mathias-kettner.de/pipermail/checkmk-en/attachments/20150203/559a588e/attachment-0001.html>


More information about the checkmk-en mailing list