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

Andy isalexandru at gmail.com
Tue Feb 3 15:30:49 CET 2015


On WIN-edge-001, as specified on main.mk

I'm trying to make the rule work for at leas this host.
Once is tested, I can add it to the rest of the windows machines.

---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:17 PM, Marcel Schulte <schulte.marcel at gmail.com>
wrote:

> Sorry, found it. On which host do you see this message?
>
> Marcel Schulte <schulte.marcel at gmail.com> schrieb am Di., 3. Feb. 2015
> 15:16:
>
> Uh, too long to read on my phone...
>>
>> But a first look does not show "winlogon" in the message so it does not
>> match your rule - but maybe I just don't see it.
>>
>> Marcel
>>
>> Andy <isalexandru at gmail.com> schrieb am Di., 3. Feb. 2015 15:07:
>>
>> /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/b4708ef4/attachment.html>


More information about the checkmk-en mailing list