As technology has advanced, it has grown to a place where employees are able to stay connected to their work, even after clocking out for the day. Employees can use their laptops, phones, and tablets to continue working or to respond to emails. This is a great aspect for better communication and increasing productivity; however, the security of these devices can get overlooked.

CoNetrix Security is excited to announce the launch of its new framework for conducting IT and cyber security audits. The updated IT Audit and Vulnerability Assessment ensures CoNetrix Security stays innovative in changing times. It provides financial institutions with a more comprehensive audit of cybersecurity controls while delivering the exceptional, actionable recommendations CoNetrix is known for.The goals in this complete redesign of our audit framework include:

I ran across an issue where I was trying to delete a file and kept getting several errors while attempting to delete said file. 1. Permissions issue --- Received an error that I needed permission from File owner to be able to delete. I made myself the owner of the file and attempted to delete the file. That introduced error #2 listed below.2. Directory is not Empty --- After resolving the permissions issue I began to receive an error that indicated the folder was not empty "Cannot Delete folder: The directory is not empty". So I went into make sure 'view hidden files' was checked in file explorer and it already was, yet the file in question still showed to be empty when opening it. Did some research and discovered that you can change the search options to include all subfolders and also to allow searching for files that are 'Empty' see screenshot below. After searching in this manner I was able to view a ton of subfolders that were sometimes 4 or 5 levels deep, and inside of those deeper folders, there would be data, which introduced error #3 to follow.

During my first attempt at installing the Office suite through O365, I began running into issues with the 'Invalid Security Certificate' warning popping up every few minutes after setting up the associates Outlook profile. This customer already had the proper GPO in place set to disable SCP look up, exclude httpautodiscoverdomain, etc, which had been effective at stopping this from occurring in the past with your standard Office install. After updating the ADMX files (which include a number of new Autodiscover policies) to the latest set in hopes of resolving the issue, the issue with the certificate warning continued to surface every few minutes. After doing some reading, I discovered there are two registry hives that can manage Autodiscover:Computer\HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutodiscoverComputer\HKEY_CURRENT_USER\Software\Policies\Microsoft\office\16.0\outlook\autodiscoverThe latter Policies hive is where the key changes take place when managing via GPO, which was not performing the intended way with this O365 setup. I manually tested adding the Excludehttpautodiscoverdomain key to the first hive, and the security warnings stopped immediately. I tested disabling and enabling keys in both hives, and was able to confirm the finding. I have not had an opportunity to see if this issue exists for any other workstation/customer, but hopefully someone might find this useful if they do. I wound up just adding this key in via the registry via GPO and had no further issues after it was applied.

One of our customers is hosting their servers with a hosting provider who also provides some other servers, like backups and patching. The hosting provider was unable to patch some of the servers for this customer. After investigating with the hosting provider, it was determined that they could patch all of the servers except for the domain controllers. The service account they were using was a Domain Admin so it should have been able to patch any server. I logged into another server as the service account and tried to access the admin$ share on one of the domain controllers, but was unable to do so.

In most of our Exchange environments, we'll have port 443 open to the outside for ActiveSync and Outlook Anywhere. When you do that, you'll also open up OWA and ECP to the outside. If you'd like to keep access for ActiveSync and Outlook Anywhere open but would like to block OWA and ECP you can follow the steps below.There are a few ways to block OWA and ECP to external addresses, but the best method is probably to use the IP and Domain Restrictions feature in IIS. This feature isn't available by default, so you'll have to install it.To install it, open Server Manager, select Add Roles and Features. In the Add Roles and Features Wizard, under Server Roles, expand Web Server (IIS), then expand Web Server, and then expand Security. Then click the checkbox for IP and Domain Restrictions.

We're working on testing and rolling out features of Microsoft Teams internally that will eventually allow us to migrate to Teams as our Enterprise Voice. During the process, one of my goals was to get the Calendar tab working inside the Teams client so that we could see and schedule meetings on our Outlook calendar from Teams. After a lot of reading and researching, it became apparent that the only way to get this working would be to enable Hybrid Exchange so that Teams (sitting in the O365 cloud) could talk to my mailbox (sitting on-prem).I configured our Exchange server for hybrid connection and let it sit overnight (thanks to Microsoft replication delays). The next morning, as I started looking into this again, I got a message from a coworker about how nice and helpful the Calendar tab was. I hadn't received it, yet, but was excited that it had started rolling out. Several hours later, the tab still wasn't present for me, but for everyone else that I spot-checked, the tab had appeared.Looking through the logs from my Teams client, the error message kept saying that my mailbox could not be found. Surely this couldn't be the case because my account was set up the same as everyone else. The only thing I could think of at the time was that it had to absolutely be a permissions issue.Continuing research over the next day or two, I discovered that the error message actually was accurate. I had attempted to migrate my mailbox to Exchange Online on a whim, but when I licensed my account in O365 for Exchange Online, it started building a new mailbox automatically. Normally, Exchange Online is aware of synced accounts that have on-premise mailboxes and will not create a new mailbox in that instance. So somewhere in the syncing process, my Azure AD account and on-prem AD account were not completely talking to each other (which didn't make complete sense, because the password hash sync was still working fine).I discovered that the sourceAnchor (ImmutableID / ms-DS-ConsistencyGuid) between the two accounts was different. Since it's impossible to update an ImmutableID attribute, I decided to update the ms-DS-ConsistencyGuid instead. Converting the ImmutableID from Base64 to Hex, you can then easily update the ms-DS-ConsistencyGuid on the source side.However, before doing that, I needed to clean up Exchange in Azure. You see, even if you unlicensed a user for Exchange Online, Azure will only disconnect the mailbox and tombstone it for 30 days. I needed to purge the Exchange attributes on my AzureAD account so that I didn't have to wait 30 days.https://techcommunity.microsoft.com/t5/exchange-team-blog/permanently-clear-previous-mailbox-info/ba-p/607619The solution is simple: Connect to the MSOL service in Powershell (Connect-MSOL), run "Set-User <upn> -PermanentlyClearPreviousMailboxInfo"It will then give you a warning that this is irreversible. Acknowledging that will fully purge the Exchange attributes and let you start over.I then updated the ms-DS-ConsistencyGuid to be correct, forced a sync via AzureAD Connect, wait for replication, and then enabled my account for Exchange. No new mailbox was created, as expected, and after a few hours the calendar tab showed up in my Teams client!

With the rise of COVID-19, we find ourselves in unprecedented circumstances. As we work through this unique time in our history, we want to provide assurance to our customers by communicating CoNetrix's response to the COVID-19 crisis.

CoNetrix was nominated in the 2020 Cybersecurity Excellence Awards recognizing companies, products, and individuals that demonstrate excellence, innovation, and leadership in the information security industry. The awards are produced by Cybersecurity Insiders in partnership with the Information Security Community on LinkedIn, tapping into the vast experience of over 400,000+ cybersecurity professionals to honor the world's best cybersecurity products, professionals and organizations.

As more and more offerings are moved into the cloud under subscription-based licensing, it's both becoming easier for people to take advantage of software that previously may not have been as readily available, and more challenging to find a solution that doesn't involve storing your data one someone else's hardware.Office 365 is a great example of this as it really does seem like the writing is on the wall for non-subscription licensing of the Office Suite for on-prem installation of much of the server software platform. Granted, Microsoft does make it remarkably easy to just switch over to their platform and to use all the pieces of the software suite that have been designed to seamlessly work together, but there is always a concern (even if it's tiny) that your data is in someone else's hands.Let's look at cloud hosting from a data availability vantage point instead. The cloud makes it incredibly simple to access the platform from practically anywhere in the world – provided thie service is online. In early February 2020, there was a global outage of the Microsoft Teams platform which brought a lot of this to light. If you were already logged in prior to the outage, you were good to go. Anyone else trying to connect up after the fact was in trouble.The cause of the outage? https://twitter.com/MSFT365Status/status/1224351597624537088

I had upgraded an older ESX 5.5 host for a customer to version 6.7. That night, when Veeam backup tried to run, it stated that the remote certificate was invalid.The easy fix was to go to the Backup Infrastructure in Veeam and find the ESX host. Open the properties of the ESX host and "next" your way through the name and credentials pages. You will eventually get a pop-up about the untrusted certificate and asked if you "want to connect anyway". After accepting, the backups worked again.

CoNetrix holds a company meeting and dinner annually in February, bringing in all employees, both local and remote, to gather in fellowship and share in success. In choosing a location for our company dinner, Marvin Crossnoe, CEO of CoNetrix, shared "We look for an event venue that inspires our group to feel pride in our location here in Lubbock, and also provides an uplifting experience that we can share together as a single group." Crossnoe went on to say, "Our company is very diversified and it's important from a cultural standpoint that we provide times to get together to bond as a group."