Honeywell Download Server
Tommie
Tanium simplifies and accelerates patch management and compliance with automated patching across the enterprise. This helps Honeywell lessen the burden on its operational staff by carrying out patching tasks and monitoring patch status across its mix of Linux and Windows server endpoints.
Honeywell has also automated its patching. By integrating Tanium with its ServiceNow CMDB, the company was able to automate patching functions that had previously been done manually by the operations team.
To maintain accurate patching, Honeywell has also created a table that compares configuration item (CI) data with Tanium endpoint data. Once a match is found, the tags are compared. In addition, the setup can show whether a server that is supposed to be managed by Tanium in fact is being managed that way.
Honeywell immediately launched an investigation upon learning of the vulnerability in Progress MOVEit Transfer, a third-party web transfer application used by many companies, public institutions and governments. The investigation detected unauthorized access on a single MOVEit server. Our cybersecurity defenses limited the impact to this server and we fully patched and upgraded the Progress MOVEit app as soon as the patches were made available from the provider before restoring service. We are in contact with certain law enforcement and regulatory authorities.
As part of our investigation, we have found data, including certain personally identifiable information, that has been accessed through the MOVEit app by an unauthorized third party. We are contacting affected individuals, customers, and partners as appropriate.
All of our systems are fully online, and this has had no impact on company operations. At this time, we do not expect that the unauthorized access on the MOVEit server we used will have a material impact on our business operations. Security is a top priority at Honeywell, and we are committed to taking all appropriate measures to ensure the highest integrity of our systems.
We are aware that certain Honeywell suppliers have been impacted by the same Progress MOVEit vulnerability and that our data might have been impacted as a result. We will assess and respond to any impacts as part of our investigation as we receive notification from suppliers that our data has been compromised.
This contains certain statements that may be deemed "forward-looking statements" within the meaning of Section 21E of the Securities Exchange Act of 1934. Forward-looking statements are those that address activities, events or developments that management intends, expects, projects, believes or anticipates will or may occur in the future. They are based on management's assumptions and assessments in light of past experience and trends, current economic and industry conditions, expected future developments and other relevant factors. They are not guarantees of future performance, and actual results, developments and business decisions may differ significantly from those envisaged by our forward-looking statements. We do not undertake to update or revise any of our forward-looking statements, except as required by applicable securities law. Our forward-looking statements are also subject to risks and uncertainties, including the impact of the ongoing investigation into the unauthorized access to our server and any unauthorized access to our suppliers' servers, each of which that can affect our performance in both the near- and long-term. In addition, no assurance can be given that any plan, initiative, projection, goal commitment, expectation, or prospect set forth in this release can or will be achieved. Any forward-looking plans described herein are not final and may be modified or abandoned at any time. We identify the principal risks and uncertainties that affect our performance in our Form 10-K and other filings with the Securities and Exchange Commission.
During recent IT network updates on campus, a particular section has been experiencing issues with door access control. Specifically, badge-based access to doors becomes non-functional even after reinitializing the control panels. I have verified the power supplies, battery backups, and configuration settings for proper door functionality. Although a hard reset of the control panels was suggested as a solution, the problem persists. Ideally, control panels should maintain functionality despite losing server connection. I am seeking insight on potential causes for this ongoing issue.
I am converting from a Cisco based WLC to a Meraki infrastructure. I am running into an issue with my Honeywell 99ex handheld scanners not being able to connect. The SSID is using wpa2-enterprise, AES, PEAP-MSchapv2. The SSIDs are about as exact as they can be with respect to securities and authentication servers.
Did a packet capture and the Meraki "auth-exchange" shows the username field is blank, so that's why it's causing errors on RADIUS. Kind of stuck between vendors here. Honeywell says it works (like it does with Cisco WLC) plus using their latest firmware and Meraki of course does not see a username being transmitted and of course other devices can connect to the SSID just fine.
Turns out the application analyst had what they thought was an updated version of code but did not take in account any service pack releases. They reported 26.7 but did not include the latest service pack. Anyways... long story short. They upgraded to this release below with updated WLAN driver dated 3/12/2019. Thanks for the sounding board and feedback.
PEAP is a tunnel, and the actual username used for authentication is send inside of the PEAP tunnel. There is a username field on the outside, but it is only used for tracking, and it is fine for this to be blank.
Because PEAP is a tunnel, the AP/WLC infrastructure does not see the authentication happening within it. The AP/WLC simply passes it onto the RADIUS server. The RADIUS server rips everything out of the tunnel, checks the credentials, and sends back an ACCEPT or REJECT. The AP/WLC infrastructure then allows/blocks access based on this.
The RADIUS only refuses connections with this client so not a shared key issue. I can also get other clients to use the same SSID on the Meraki infrastructure. So the back end radius seems fine. **Added APs IP ranges and verified keys.
I'm sad and embarrassed to report that 10 handhelds are using the same username and password (we are fixing that!!) but in this case it helps because the ones still on Cisco WLCs using the same uname and password are working. So prolly no lockout.
yeah we tried with a lesser security - OPEN guest (and it does connect) but we do not have any PSK ssids at this location. I'd have to spin one up to see if that can make a difference. But kind of trying to stay away from PSKs for now so if it works I can use it for tshooting but would rather not like to share with the user.
Really appreciate the feedback @Nash and @PhilipDAth Helps immensely. As for the securities, they are as shown below. No policies or splash pages or anything too terribly different from what I can tell. Add yes all other devices can connect from the Cisco APs to the Merak APs. Just seems like a interpretation between Mr52s and the supplicant on the handheld.
Which does bring to mind. Does Meraki have a testing lab or department like their big brother Cisco WBU to look at different device types for compatibility? One that we can submit this model and code to have them run it thru their tests to see if the engineers see the same thing?
I'm right there with ya. I have tried to change that already - no luck. Might take a packet capture from a Cisco AP that works and a Meraki AP to find the real root cause. Might try and offload that task to Meraki support if they have the labs to get that done. My sites are remote and I don't have an over the air packet sniffer handy for them to use locally.
@Charlie I would advise against using the 26.3 Beta firmware with the MR52. Now that staff is starting to return (school district) I discovered a bug where devices on the 2.4ghz band (printer in this case) would Disassociate:Reason Unknown after a minute or two of connection and would not reconnect unless the WAP was reset and then it would just repeat the issue a minute or two later.
Assuming this can be verified with different devices (maybe just make a 2.4GHz only SSID to test). Is this just you testing on your own or did you have Support verify and open up a case? Curious to know if they have any fix for this as well please and thank you.
@NolanHerring This was just me testing on my own. I've run into a bug that I worked with support on previously which pertained to the MR34 and WPA2 DHCP rejection. I had to roll back to 25.13 because teachers are starting to report and I have quite a few Brother wireless printers at the site that has the MR52s. Zero connection issue with the 25.13 firmware.
Basically, I reset the network interface on the printer and started fresh. It connected and would accept a print job. I could see it on the WAP in the dashboard. Then it would drop from the WAP with a Reason Unknown message, but the printer itself would have a solid wi-fi light. I could reset the WAP, watch the printer connect to the WAP next door, and then repeat the process of dropping with Reason Unknown. The printer has the latest firmware from Brother and is less than a year old. It's a model I have a few of at multiple sites and haven't had an issue with it previously.
c80f0f1006