wmi issues, need a syntax change
Hi, I am guessing that wmi polling is not used very much but I do use it and find it handy. If you do use it, you are probably aware that your event logs are filling up with this error:
The server-side authentication level policy does not allow the user domain\wmiuser SID (S-1-5-21-99999-3660327915-2769000259-31856) from address 1.1.1.1 to activate DCOM server. Please raise the activation authentication level at least to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY in client application.
I am getting 4 eventlog errors every polling interval (5 minutes) on every windows server. This is due to Microsoft enhancing security on wmi. (KB5004442-Manage changes for Windows DCOM Server Security Feature Bypass (CVE-2021-26414) (microsoft.com)https://support.microsoft.com/en-us/topic/kb5004442-manage-changes-for-windows-dcom-server-security-feature-bypass-cve-2021-26414-f1400b52-c141-43d2-941e-37ed901c769c)
There is a solution to this, you need to call wmi with pkt integrity enabled (wmic RPC_C_AUTHN_LEVEL_PKT_INTEGRITY support · Issue #41 · greenbone/openvas-smb (github.com)https://github.com/greenbone/openvas-smb/issues/41). So, for example
wmic --user=domain.local\user --password= //server.domain.local "select * from Win32_ComputerSystem" - throws the error in the target servers event log...also, this will start failing next year.
However
wmic --user=domain.local\user --password= //ncacn_ip_tcp:server.domain.local[sign] "select * from Win32_ComputerSystem" will not throw the error wrapping the target server in ncacn_ip_tcp: and [sign] fixes the issue.
So, would it be possible for you to enhance Observium to make the wmi calls this way?
Thanks
Tony
Hi Tony,
You're right, it's not used a lot I think right now.
Would that impact older Windows versions when this change is made? Because of course that would present a problem...
Thanks, Tom
On 2022-04-11 22:34, Tony Guadagno via observium wrote:
Hi, I am guessing that wmi polling is not used very much but I do use it and find it handy. If you do use it, you are probably aware that your event logs are filling up with this error:
The server-side authentication level policy does not allow the user domain\wmiuser SID (S-1-5-21-99999-3660327915-2769000259-31856) from address 1.1.1.1 to activate DCOM server. Please raise the activation authentication level at least to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY in client application.
I am getting 4 eventlog errors every polling interval (5 minutes) on every windows server. This is due to Microsoft enhancing security on wmi. (KB5004442—Manage changes for Windows DCOM Server Security Feature Bypass (CVE-2021-26414) (microsoft.com) https://support.microsoft.com/en-us/topic/kb5004442-manage-changes-for-windows-dcom-server-security-feature-bypass-cve-2021-26414-f1400b52-c141-43d2-941e-37ed901c769c)
There is a solution to this, you need to call wmi with pkt integrity enabled (wmic RPC_C_AUTHN_LEVEL_PKT_INTEGRITY support · Issue #41 · greenbone/openvas-smb (github.com) https://github.com/greenbone/openvas-smb/issues/41).
So, for example
wmic --user=domain.local\user --password= //server.domain.local "select * from Win32_ComputerSystem" - throws the error in the target servers event log…also, this will start failing next year.
However
wmic --user=domain.local\user --password= //ncacn_ip_tcp:server.domain.local[sign] "select * from Win32_ComputerSystem" will not throw the error
wrapping the target server in ncacn_ip_tcp: and [sign] fixes the issue.
So, would it be possible for you to enhance Observium to make the wmi calls this way?
Thanks
Tony
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Tom, there is a couple of moving parts here. First, if you have a system that is still patchable, then this applies because this is pushed in patches. Now, if you are still using WinXP or Server 2003, then probably not. Whether the fix will break WMI monitoring on these old systems, I cannot say. This is my feeling, should we let newer systems break with WMI monitoring or older (unsupported) systems break? I think it does not make sense to break new systems in favor of old. I guess another option would be to make a config pram (WMI-signing?) if true, the new call is used?
But to be clear, right now, the WMI hardening results in error messages in the event log but the command succeeds….however…as of 2023, the command will fail and no info will be returned so doing nothing will break WMI.
Thanks for your time on this
From: observium observium-bounces@observium.org On Behalf Of Tom Laermans via observium Sent: Wednesday, April 13, 2022 7:26 AM To: observium@observium.org Cc: Tom Laermans tom.laermans@powersource.cx Subject: Re: [Observium] wmi issues, need a syntax change
Hi Tony,
You're right, it's not used a lot I think right now.
Would that impact older Windows versions when this change is made? Because of course that would present a problem...
Thanks, Tom
On 2022-04-11 22:34, Tony Guadagno via observium wrote: Hi, I am guessing that wmi polling is not used very much but I do use it and find it handy. If you do use it, you are probably aware that your event logs are filling up with this error:
The server-side authentication level policy does not allow the user domain\wmiuser SID (S-1-5-21-99999-3660327915-2769000259-31856) from address 1.1.1.1 to activate DCOM server. Please raise the activation authentication level at least to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY in client application.
I am getting 4 eventlog errors every polling interval (5 minutes) on every windows server. This is due to Microsoft enhancing security on wmi. (KB5004442—Manage changes for Windows DCOM Server Security Feature Bypass (CVE-2021-26414) (microsoft.com)https://support.microsoft.com/en-us/topic/kb5004442-manage-changes-for-windows-dcom-server-security-feature-bypass-cve-2021-26414-f1400b52-c141-43d2-941e-37ed901c769c)
There is a solution to this, you need to call wmi with pkt integrity enabled (wmic RPC_C_AUTHN_LEVEL_PKT_INTEGRITY support · Issue #41 · greenbone/openvas-smb (github.com)https://github.com/greenbone/openvas-smb/issues/41). So, for example
wmic --user=domain.local\user --password= //server.domain.local "select * from Win32_ComputerSystem" - throws the error in the target servers event log…also, this will start failing next year.
However
wmic --user=domain.local\user --password= //ncacn_ip_tcp:server.domain.local[sign] "select * from Win32_ComputerSystem" will not throw the error wrapping the target server in ncacn_ip_tcp: and [sign] fixes the issue.
So, would it be possible for you to enhance Observium to make the wmi calls this way?
Thanks
Tony
_______________________________________________
observium mailing list
observium@observium.orgmailto:observium@observium.org
http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Tony,
I don't disagree that it needs to work correctly on new systems, however the adage of Observium (for better or for worse...) usually is "don't break either", hence my question.
I guess we'll have to think a bit...
Microsoft also said they'd stop doing SNMP, and claimed they'd stop doing unsigned LDAP - for now neither has materialised ;-)
Tom
On 2022-04-13 16:22, Tony Guadagno wrote:
Tom, there is a couple of moving parts here. First, if you have a system that is still patchable, then this applies because this is pushed in patches. Now, if you are still using WinXP or Server 2003, then probably not. Whether the fix will break WMI monitoring on these old systems, I cannot say.
This is my feeling, should we let newer systems break with WMI monitoring or older (unsupported) systems break? I think it does not make sense to break new systems in favor of old.
I guess another option would be to make a config pram (WMI-signing?) if true, the new call is used?
But to be clear, right now, the WMI hardening results in error messages in the event log but the command succeeds….however…as of 2023, the command will fail and no info will be returned so doing nothing will break WMI.
Thanks for your time on this
*From:* observium observium-bounces@observium.org *On Behalf Of *Tom Laermans via observium *Sent:* Wednesday, April 13, 2022 7:26 AM *To:* observium@observium.org *Cc:* Tom Laermans tom.laermans@powersource.cx *Subject:* Re: [Observium] wmi issues, need a syntax change
Hi Tony,
You're right, it's not used a lot I think right now.
Would that impact older Windows versions when this change is made?
Because of course that would present a problem...
Thanks,
Tom
On 2022-04-11 22:34, Tony Guadagno via observium wrote:
Hi, I am guessing that wmi polling is not used very much but I do use it and find it handy. If you do use it, you are probably aware that your event logs are filling up with this error: The server-side authentication level policy does not allow the user domain\wmiuser SID (S-1-5-21-99999-3660327915-2769000259-31856) from address 1.1.1.1 to activate DCOM server. Please raise the activation authentication level at least to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY in client application. I am getting 4 eventlog errors every polling interval (5 minutes) on every windows server. This is due to Microsoft enhancing security on wmi. (KB5004442—Manage changes for Windows DCOM Server Security Feature Bypass (CVE-2021-26414) (microsoft.com) <https://support.microsoft.com/en-us/topic/kb5004442-manage-changes-for-windows-dcom-server-security-feature-bypass-cve-2021-26414-f1400b52-c141-43d2-941e-37ed901c769c>) There is a solution to this, you need to call wmi with pkt integrity enabled (wmic RPC_C_AUTHN_LEVEL_PKT_INTEGRITY support · Issue #41 · greenbone/openvas-smb (github.com) <https://github.com/greenbone/openvas-smb/issues/41>). So, for example wmic --user=domain.local\\user --password= //server.domain.local "select * from Win32_ComputerSystem" - throws the error in the target servers event log…also, this will start failing next year. However wmic --user=domain.local\\user --password= //ncacn_ip_tcp:server.domain.local[sign] "select * from Win32_ComputerSystem" will not throw the error wrapping the target server in ncacn_ip_tcp: and [sign] fixes the issue. So, would it be possible for you to enhance Observium to make the wmi calls this way? Thanks Tony _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Tom, yes, I agree this is not an emergency….sort of, I actually have turned off wmi polling because of all the errors generated in my event logs, so it is impacting us now. It would be nice to be able to use this again without the errors. I think the middle ground solution (adding a config variable to toggle the feature) seems like not a big lift?
Thanks for considering it
From: Tom Laermans tom.laermans@powersource.cx Sent: Wednesday, April 13, 2022 12:00 PM To: Tony Guadagno tonyg@guadagno.org; Observium observium@observium.org Subject: Re: [Observium] wmi issues, need a syntax change
Tony,
I don't disagree that it needs to work correctly on new systems, however the adage of Observium (for better or for worse...) usually is "don't break either", hence my question.
I guess we'll have to think a bit...
Microsoft also said they'd stop doing SNMP, and claimed they'd stop doing unsigned LDAP - for now neither has materialised ;-)
Tom
On 2022-04-13 16:22, Tony Guadagno wrote: Tom, there is a couple of moving parts here. First, if you have a system that is still patchable, then this applies because this is pushed in patches. Now, if you are still using WinXP or Server 2003, then probably not. Whether the fix will break WMI monitoring on these old systems, I cannot say. This is my feeling, should we let newer systems break with WMI monitoring or older (unsupported) systems break? I think it does not make sense to break new systems in favor of old. I guess another option would be to make a config pram (WMI-signing?) if true, the new call is used?
But to be clear, right now, the WMI hardening results in error messages in the event log but the command succeeds….however…as of 2023, the command will fail and no info will be returned so doing nothing will break WMI.
Thanks for your time on this
From: observium observium-bounces@observium.orgmailto:observium-bounces@observium.org On Behalf Of Tom Laermans via observium Sent: Wednesday, April 13, 2022 7:26 AM To: observium@observium.orgmailto:observium@observium.org Cc: Tom Laermans tom.laermans@powersource.cxmailto:tom.laermans@powersource.cx Subject: Re: [Observium] wmi issues, need a syntax change
Hi Tony,
You're right, it's not used a lot I think right now.
Would that impact older Windows versions when this change is made? Because of course that would present a problem...
Thanks, Tom
On 2022-04-11 22:34, Tony Guadagno via observium wrote: Hi, I am guessing that wmi polling is not used very much but I do use it and find it handy. If you do use it, you are probably aware that your event logs are filling up with this error:
The server-side authentication level policy does not allow the user domain\wmiuser SID (S-1-5-21-99999-3660327915-2769000259-31856) from address 1.1.1.1 to activate DCOM server. Please raise the activation authentication level at least to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY in client application.
I am getting 4 eventlog errors every polling interval (5 minutes) on every windows server. This is due to Microsoft enhancing security on wmi. (KB5004442—Manage changes for Windows DCOM Server Security Feature Bypass (CVE-2021-26414) (microsoft.com)https://support.microsoft.com/en-us/topic/kb5004442-manage-changes-for-windows-dcom-server-security-feature-bypass-cve-2021-26414-f1400b52-c141-43d2-941e-37ed901c769c)
There is a solution to this, you need to call wmi with pkt integrity enabled (wmic RPC_C_AUTHN_LEVEL_PKT_INTEGRITY support · Issue #41 · greenbone/openvas-smb (github.com)https://github.com/greenbone/openvas-smb/issues/41). So, for example
wmic --user=domain.local\user --password= //server.domain.local "select * from Win32_ComputerSystem" - throws the error in the target servers event log…also, this will start failing next year.
However
wmic --user=domain.local\user --password= //ncacn_ip_tcp:server.domain.local[sign] "select * from Win32_ComputerSystem" will not throw the error wrapping the target server in ncacn_ip_tcp: and [sign] fixes the issue.
So, would it be possible for you to enhance Observium to make the wmi calls this way?
Thanks
Tony
_______________________________________________
observium mailing list
observium@observium.orgmailto:observium@observium.org
http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Yeah, in general our policy is that our changes/defauts shouldn’t break things that already work.
Since you have to manually add WMI, I don’t think it’s a hardship to set this explicitly. It should just be a checkbox in the WMI tab.
The default should maintain current behaviour on existing devices, but can be the new behaviour on any future added devices. This is easier with a devices table field than it is with a device attribute, but possible either way.
I’m not sure how much device table sprawl matters, it’s not functionally possible to have enough rows in that table for it to matter, so this can probably be a devices table field.
Adam.
From: observium observium-bounces@observium.org On Behalf Of Tom Laermans via observium Sent: 13 April 2022 17:00 To: Tony Guadagno tonyg@guadagno.org; Observium observium@observium.org Cc: Tom Laermans tom.laermans@powersource.cx Subject: Re: [Observium] wmi issues, need a syntax change
Tony,
I don't disagree that it needs to work correctly on new systems, however the adage of Observium (for better or for worse...) usually is "don't break either", hence my question.
I guess we'll have to think a bit...
Microsoft also said they'd stop doing SNMP, and claimed they'd stop doing unsigned LDAP - for now neither has materialised ;-)
Tom
On 2022-04-13 16:22, Tony Guadagno wrote:
Tom, there is a couple of moving parts here. First, if you have a system that is still patchable, then this applies because this is pushed in patches. Now, if you are still using WinXP or Server 2003, then probably not. Whether the fix will break WMI monitoring on these old systems, I cannot say.
This is my feeling, should we let newer systems break with WMI monitoring or older (unsupported) systems break? I think it does not make sense to break new systems in favor of old.
I guess another option would be to make a config pram (WMI-signing?) if true, the new call is used?
But to be clear, right now, the WMI hardening results in error messages in the event log but the command succeeds….however…as of 2023, the command will fail and no info will be returned so doing nothing will break WMI.
Thanks for your time on this
From: observium mailto:observium-bounces@observium.org observium-bounces@observium.org On Behalf Of Tom Laermans via observium Sent: Wednesday, April 13, 2022 7:26 AM To: observium@observium.org mailto:observium@observium.org Cc: Tom Laermans mailto:tom.laermans@powersource.cx tom.laermans@powersource.cx Subject: Re: [Observium] wmi issues, need a syntax change
Hi Tony,
You're right, it's not used a lot I think right now.
Would that impact older Windows versions when this change is made?
Because of course that would present a problem...
Thanks,
Tom
On 2022-04-11 22:34, Tony Guadagno via observium wrote:
Hi, I am guessing that wmi polling is not used very much but I do use it and find it handy. If you do use it, you are probably aware that your event logs are filling up with this error:
The server-side authentication level policy does not allow the user domain\wmiuser SID (S-1-5-21-99999-3660327915-2769000259-31856) from address 1.1.1.1 to activate DCOM server. Please raise the activation authentication level at least to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY in client application.
I am getting 4 eventlog errors every polling interval (5 minutes) on every windows server. This is due to Microsoft enhancing security on wmi. (KB5004442—Manage changes for Windows DCOM Server Security Feature Bypass (CVE-2021-26414) (microsoft.com) https://support.microsoft.com/en-us/topic/kb5004442-manage-changes-for-windows-dcom-server-security-feature-bypass-cve-2021-26414-f1400b52-c141-43d2-941e-37ed901c769c )
There is a solution to this, you need to call wmi with pkt integrity enabled (wmic RPC_C_AUTHN_LEVEL_PKT_INTEGRITY support · Issue #41 · greenbone/openvas-smb (github.com) https://github.com/greenbone/openvas-smb/issues/41 ).
So, for example
wmic --user=domain.local\user --password= //server.domain.local "select * from Win32_ComputerSystem" - throws the error in the target servers event log…also, this will start failing next year.
However
wmic --user=domain.local\user --password= //ncacn_ip_tcp:server.domain.local[sign] "select * from Win32_ComputerSystem" will not throw the error
wrapping the target server in ncacn_ip_tcp: and [sign] fixes the issue.
So, would it be possible for you to enhance Observium to make the wmi calls this way?
Thanks
Tony
_______________________________________________ observium mailing list observium@observium.org mailto:observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Adam, thanks, I look forward to the change!
From: observium observium-bounces@observium.org On Behalf Of adama--- via observium Sent: Wednesday, April 13, 2022 12:21 PM To: 'Observium' observium@observium.org Cc: adama@observium.org Subject: Re: [Observium] wmi issues, need a syntax change
Yeah, in general our policy is that our changes/defauts shouldn’t break things that already work.
Since you have to manually add WMI, I don’t think it’s a hardship to set this explicitly. It should just be a checkbox in the WMI tab.
The default should maintain current behaviour on existing devices, but can be the new behaviour on any future added devices. This is easier with a devices table field than it is with a device attribute, but possible either way.
I’m not sure how much device table sprawl matters, it’s not functionally possible to have enough rows in that table for it to matter, so this can probably be a devices table field.
Adam.
From: observium <observium-bounces@observium.orgmailto:observium-bounces@observium.org> On Behalf Of Tom Laermans via observium Sent: 13 April 2022 17:00 To: Tony Guadagno <tonyg@guadagno.orgmailto:tonyg@guadagno.org>; Observium <observium@observium.orgmailto:observium@observium.org> Cc: Tom Laermans <tom.laermans@powersource.cxmailto:tom.laermans@powersource.cx> Subject: Re: [Observium] wmi issues, need a syntax change
Tony,
I don't disagree that it needs to work correctly on new systems, however the adage of Observium (for better or for worse...) usually is "don't break either", hence my question.
I guess we'll have to think a bit...
Microsoft also said they'd stop doing SNMP, and claimed they'd stop doing unsigned LDAP - for now neither has materialised ;-)
Tom
On 2022-04-13 16:22, Tony Guadagno wrote: Tom, there is a couple of moving parts here. First, if you have a system that is still patchable, then this applies because this is pushed in patches. Now, if you are still using WinXP or Server 2003, then probably not. Whether the fix will break WMI monitoring on these old systems, I cannot say. This is my feeling, should we let newer systems break with WMI monitoring or older (unsupported) systems break? I think it does not make sense to break new systems in favor of old. I guess another option would be to make a config pram (WMI-signing?) if true, the new call is used?
But to be clear, right now, the WMI hardening results in error messages in the event log but the command succeeds….however…as of 2023, the command will fail and no info will be returned so doing nothing will break WMI.
Thanks for your time on this
From: observium observium-bounces@observium.orgmailto:observium-bounces@observium.org On Behalf Of Tom Laermans via observium Sent: Wednesday, April 13, 2022 7:26 AM To: observium@observium.orgmailto:observium@observium.org Cc: Tom Laermans tom.laermans@powersource.cxmailto:tom.laermans@powersource.cx Subject: Re: [Observium] wmi issues, need a syntax change
Hi Tony,
You're right, it's not used a lot I think right now.
Would that impact older Windows versions when this change is made? Because of course that would present a problem...
Thanks, Tom
On 2022-04-11 22:34, Tony Guadagno via observium wrote: Hi, I am guessing that wmi polling is not used very much but I do use it and find it handy. If you do use it, you are probably aware that your event logs are filling up with this error:
The server-side authentication level policy does not allow the user domain\wmiuser SID (S-1-5-21-99999-3660327915-2769000259-31856) from address 1.1.1.1 to activate DCOM server. Please raise the activation authentication level at least to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY in client application.
I am getting 4 eventlog errors every polling interval (5 minutes) on every windows server. This is due to Microsoft enhancing security on wmi. (KB5004442—Manage changes for Windows DCOM Server Security Feature Bypass (CVE-2021-26414) (microsoft.com)https://support.microsoft.com/en-us/topic/kb5004442-manage-changes-for-windows-dcom-server-security-feature-bypass-cve-2021-26414-f1400b52-c141-43d2-941e-37ed901c769c)
There is a solution to this, you need to call wmi with pkt integrity enabled (wmic RPC_C_AUTHN_LEVEL_PKT_INTEGRITY support · Issue #41 · greenbone/openvas-smb (github.com)https://github.com/greenbone/openvas-smb/issues/41). So, for example
wmic --user=domain.local\user --password= //server.domain.local "select * from Win32_ComputerSystem" - throws the error in the target servers event log…also, this will start failing next year.
However
wmic --user=domain.local\user --password= //ncacn_ip_tcp:server.domain.local[sign] "select * from Win32_ComputerSystem" will not throw the error wrapping the target server in ncacn_ip_tcp: and [sign] fixes the issue.
So, would it be possible for you to enhance Observium to make the wmi calls this way?
Thanks
Tony
_______________________________________________
observium mailing list
observium@observium.orgmailto:observium@observium.org
http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Side question related to wmi polling...
Certain windows boxen that don't have an add-on SNMP software component installed (Dell Command Monitor, HPE CPQ agent) will return a hardware identifier of "Intel x64" and that is what populates the "Hardware" field for the Server/Workstation.
When the WMI module is enabled, one of the queries we make of the polled node is "SELECT Name FROM Win32_ComputerSystem".
My question is, could we also use that same (or similar) query to include "SELECT Model FROM Win32_ComputerSystem" and use that to populate the hardware field for the polled node? In the case of a baremetal device, it will return the actual hardware type, or in the case of a VM on an ESXI host, it will return "VMware Virtual Platform".
Examples: root@observium:/opt/observium# /bin/wmic --user=<redacted> --password=<redacted> --workgroup=<redacted> --delimiter='##' --namespace='root\CIMV2' //'10.50.52.XX' "SELECT Name,Model FROM Win32_ComputerSystem" CLASS: Win32_ComputerSystem Model##Name Precision Tower 5810##RJM-T5810
root@observium:/opt/observium# /bin/wmic --user=<redacted> --password=<redacted> --workgroup=<redacted> --delimiter='##' --namespace='root\CIMV2' //'10.1.9.XX' "SELECT Name,Model FROM Win32_ComputerSystem" CLASS: Win32_ComputerSystem Model##Name VMware Virtual Platform##DBSRV2K8
On the first one, I have the Dell SNMP agent installed, so hardware is being populated by the SNMP query made under the Dell-specific MIB queries. The second one is a VM, and since there's no specific SNMP agent, hardware is currently shown as "Intel x64"... which doesn't tell me if that is a VM or not.
Thus my question... if the WMI query could be updated to include the Model information, and then populate the hardware field appropriately.
Thanks, Ron
On 2022-04-13 10:21, adama--- via observium wrote:
Yeah, in general our policy is that our changes/defauts shouldn’t break things that already work.
Since you have to manually add WMI, I don’t think it’s a hardship to set this explicitly. It should just be a checkbox in the WMI tab.
The default should maintain current behaviour on existing devices, but can be the new behaviour on any future added devices. This is easier with a devices table field than it is with a device attribute, but possible either way.
I’m not sure how much device table sprawl matters, it’s not functionally possible to have enough rows in that table for it to matter, so this can probably be a devices table field.
Adam.
FROM: observium observium-bounces@observium.org ON BEHALF OF Tom Laermans via observium SENT: 13 April 2022 17:00 TO: Tony Guadagno tonyg@guadagno.org; Observium observium@observium.org CC: Tom Laermans tom.laermans@powersource.cx SUBJECT: Re: [Observium] wmi issues, need a syntax change
Tony,
I don't disagree that it needs to work correctly on new systems, however the adage of Observium (for better or for worse...) usually is "don't break either", hence my question.
I guess we'll have to think a bit...
Microsoft also said they'd stop doing SNMP, and claimed they'd stop doing unsigned LDAP - for now neither has materialised ;-)
Tom
On 2022-04-13 16:22, Tony Guadagno wrote:
Tom, there is a couple of moving parts here. First, if you have a system that is still patchable, then this applies because this is pushed in patches. Now, if you are still using WinXP or Server 2003, then probably not. Whether the fix will break WMI monitoring on these old systems, I cannot say.
This is my feeling, should we let newer systems break with WMI monitoring or older (unsupported) systems break? I think it does not make sense to break new systems in favor of old.
I guess another option would be to make a config pram (WMI-signing?) if true, the new call is used?
But to be clear, right now, the WMI hardening results in error messages in the event log but the command succeeds….however…as of 2023, the command will fail and no info will be returned so doing nothing will break WMI.
Thanks for your time on this
Probably, but the existing WMI code was contributed and abandoned by the original author a decade or so ago. It needs pretty much completely rewritten to be very useful.
At the moment the WMI code is all in one module, where it collects a bunch of data and either overwrites other modules, or stores data in arrays for later modules to pick up with hacks and special handling. It’s not easy to extend.
Adam.
-----Original Message----- From: observium observium-bounces@observium.org On Behalf Of Ron M. via observium Sent: 13 April 2022 19:14 To: Observium observium@observium.org Cc: ron@rjr-services.com Subject: Re: [Observium] wmi issues, need a syntax change
Side question related to wmi polling...
Certain windows boxen that don't have an add-on SNMP software component installed (Dell Command Monitor, HPE CPQ agent) will return a hardware identifier of "Intel x64" and that is what populates the "Hardware" field for the Server/Workstation.
When the WMI module is enabled, one of the queries we make of the polled node is "SELECT Name FROM Win32_ComputerSystem".
My question is, could we also use that same (or similar) query to include "SELECT Model FROM Win32_ComputerSystem" and use that to populate the hardware field for the polled node? In the case of a baremetal device, it will return the actual hardware type, or in the case of a VM on an ESXI host, it will return "VMware Virtual Platform".
Examples: root@observium:/opt/observium# /bin/wmic --user=<redacted> --password=<redacted> --workgroup=<redacted> --delimiter='##' --namespace='root\CIMV2' //'10.50.52.XX' "SELECT Name,Model FROM Win32_ComputerSystem" CLASS: Win32_ComputerSystem Model##Name Precision Tower 5810##RJM-T5810
root@observium:/opt/observium# /bin/wmic --user=<redacted> --password=<redacted> --workgroup=<redacted> --delimiter='##' --namespace='root\CIMV2' //'10.1.9.XX' "SELECT Name,Model FROM Win32_ComputerSystem" CLASS: Win32_ComputerSystem Model##Name VMware Virtual Platform##DBSRV2K8
On the first one, I have the Dell SNMP agent installed, so hardware is being populated by the SNMP query made under the Dell-specific MIB queries. The second one is a VM, and since there's no specific SNMP agent, hardware is currently shown as "Intel x64"... which doesn't tell me if that is a VM or not.
Thus my question... if the WMI query could be updated to include the Model information, and then populate the hardware field appropriately.
Thanks, Ron
On 2022-04-13 10:21, adama--- via observium wrote:
Yeah, in general our policy is that our changes/defauts shouldn’t break things that already work.
Since you have to manually add WMI, I don’t think it’s a hardship to set this explicitly. It should just be a checkbox in the WMI tab.
The default should maintain current behaviour on existing devices, but can be the new behaviour on any future added devices. This is easier with a devices table field than it is with a device attribute, but possible either way.
I’m not sure how much device table sprawl matters, it’s not functionally possible to have enough rows in that table for it to matter, so this can probably be a devices table field.
Adam.
FROM: observium observium-bounces@observium.org ON BEHALF OF Tom Laermans via observium SENT: 13 April 2022 17:00 TO: Tony Guadagno tonyg@guadagno.org; Observium observium@observium.org CC: Tom Laermans tom.laermans@powersource.cx SUBJECT: Re: [Observium] wmi issues, need a syntax change
Tony,
I don't disagree that it needs to work correctly on new systems, however the adage of Observium (for better or for worse...) usually is "don't break either", hence my question.
I guess we'll have to think a bit...
Microsoft also said they'd stop doing SNMP, and claimed they'd stop doing unsigned LDAP - for now neither has materialised ;-)
Tom
On 2022-04-13 16:22, Tony Guadagno wrote:
Tom, there is a couple of moving parts here. First, if you have a system that is still patchable, then this applies because this is pushed in patches. Now, if you are still using WinXP or Server 2003, then probably not. Whether the fix will break WMI monitoring on these old systems, I cannot say.
This is my feeling, should we let newer systems break with WMI monitoring or older (unsupported) systems break? I think it does not make sense to break new systems in favor of old.
I guess another option would be to make a config pram (WMI-signing?) if true, the new call is used?
But to be clear, right now, the WMI hardening results in error messages in the event log but the command succeeds….however…as of 2023, the command will fail and no info will be returned so doing nothing will break WMI.
Thanks for your time on this
_______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
participants (5)
-
Adam Armstrong -
adama＠observium.org
-
ron＠rjr-services.com -
Tom Laermans -
Tony Guadagno