We really only need customers to answer one question: Can they access the admin share (Admin$) on the endpoints to be scanned? The admin share is enabled by default on Windows Servers for administrative purposes, even if they are in a workgroup (it’s only enabled on Windows workstations IF they are part of a domain). This share cannot simply be removed, but access to it can be blocked using a firewall. Almost all organizations keep this share open using firewall exceptions. Now if this share is not available then Movere will attempt to access c$ (this is primarily for legacy reasons e.g. Windows 2000/2003). This is why we really only need to know if they can access the admin$ share. Microsoft has pre-configured exceptions for this in the Windows firewall and this exception is referred to as the File and Printer Sharing exception. This exception opens ports 135-139 and 445.
So what if the admin share is blocked? Does that mean Movere can’t be used? Absolutely not. Organizations need to be able to get files to their servers in an automated manner, which is why the admin share is almost always left open because this can only be accessed by administrators. If access is blocked then a separate technology must be used to automate the distribution of binaries. This was another reason why we switched to Bots back in 2011, because we had customers who wanted to utilize their own existing distribution platforms.
The next and far more common issue is access. We could have one administrator run a test to confirm that the admin share is accessible, but we need to make sure that they run the test to leverage the credentials that will ultimately be given to Movere, which isn’t always as easy as it sounds. This is why Movere has a Credential Mapper. We needed to both simplify the entry and the encryption of credentials AND make sure that ONLY those credentials are use in the domain(s) to which they relate. For projects like this, customers often leverage existing service accounts, but these accounts won’t permit logon locally or via RDS, so they logon using their own admin account, run a successful test, then switch to Movere and access is denied. To further complicate matters, Windows enforces rights based upon the order in which they are granted. If a service account is created that denies log on, but is then granted admin rights, it will fail. But if this is done in the reverse order it will be successful.
So ultimately, if the customer can access the admin share then Movere will work. This works because Movere has multiple ways of returning the data it collects to the cloud. One is a direct cloud upload via port 445. Most customers focus on blocking inbound traffic NOT outbound, and port 445 outbound is typically left open. Even if the customer has a proxy in place, if the endpoint can reach the Internet then direct cloud upload should work. Having said that, not all devices can reach the Internet, but Movere has that covered as well. If the Movere bot can’t reach the cloud then the payload can be routed to the Internet via the device the customer is running the Movere Console on over ANY port they like. Movere defaults to port 80, but this can be altered in the config. Now you might say, what if the customer uses a product like SCCM to deploy the bots, do they lose this as an option? Once again the answer is no. The Movere upload listener can be installed on any Windows device. The name of this device, and the desired port number can be specified in the command that instructs the bot to start.
The final item we should consider is the subnets utilized by the customer. A device on one subnet may not be accessible from a device on another subnet even if it is in the same domain, or the customer may want to minimize WAN traffic. This is another reason why we built Movere the way we did - no installation required. A customer can scan all devices from one location, but if there are subnet or WAN concerns, then the Movere Console can simply be copied to an alternative device and run from there. Large global organizations often use multiple Movere Consoles to minimize WAN traffic, while for Linux devices, multiple Movere Consoles are used when Linux admins set the ssh_config to only accept ssh connections from devices on approved subnets. If multiple subnets exist then once again the Movere Console can be run from multiple devices on different subnets.
Start by confirming if the admin share is accessible. If you don’t know then run a command like this from Windows PowerShell: get-WmiObject -class Win32_Share -computer server1.domain.com
This was just run on one of our jump servers and here’s what came back. As you can see, the ADMIN share is listed:
Now if I run this command against a server in another domain with a regular user account I get an access denied error:
Now if I open PowerShell using my domain admin account I get this:
If a customer runs Movere and everything works perfectly out of the box then we’re good to go, but if some devices can’t be reached, then the service log should give us the information we need to figure out what is blocking Movere, and in most cases is simply the account being used. To scan a Windows device you need local admin permission, and this is why customers use service accounts that are denied logon rights. As long as the account is granted local admin rights FIRST then denied logon rights second, Movere will be able to leverage this account to access each targeted endpoint assuming of course that the device can be reached (i.e. it’s powered on, and connected to the network).
We would also recommend that the customer target specific groups of devices first, if they don’t want to target all devices, just to confirm that the scans will work out of the box. When you ask the customer to target a handful of devices, Movere will echo back two key messages:
‘Launching bot’ is just the release of the bots, but ‘Service success’ means the admin share is accessible AND the user/service account being leveraged by Movere has local admin rights. The last message ‘Local scan started’ will only appear IF the targeted endpoint can speak back to the device the Movere Console is being run on over the port specified, which is port 80 by default, but this can be changed to any other open port.
If the customer targets a Windows server and sees these three lines then Movere will work!