Jump to content

sinistersnowgod

Members
  • Content Count

    20
  • Joined

  • Last visited

About sinistersnowgod

  • Rank
    New Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Ok... so I guess the best option for me at this time is going to be to adjust the XML file for the client which does work. I can only think of two ways of doing that relatively elegantly but maybe you have another option? I can either change the server config to the publicly resolvable name for as long as it takes to generate the installation package so that the package contains the XML file with the correct URL... or on my software deployment platform (SCCM) I can create a software deployment package that installs Malwarebytes and then goes back in and overwrites the XML file with one that has the correct URL. I guess my question is, is there any easy way in the console to adjust the URL that will be in the XML file when generating the XML package without having to jump through those hoops every time we have a need to generate a new installation package? Not the end of the world if we have to follow that process every time but just kind of messy. Thanks, Ian
  2. That's usefull information but I guess where I'm getting hung up is that I am using an FQDN... it's just not the FQDN of the local host as it is in the AD domain. The AD domain has it's own DNS name that isn't publicly resolvable... so the internal FQDN of the server is complicatedservername.addomain.local. The requisite ports for the clients are open to the server and a publicly resolvable DNS name is registered to the NAT address of the internal host IP. The publicly resolvable "friendly" FQDN is mwbytes.publicdomain.com. I'm using that FQDN in the configuration. That FQDN is resolvable by the server and the clients... so that's where I'm confused because I believe that should work?
  3. Hey Dyllon... any thoughts on the whole friendly name issue lingering here? As far as I can tell it's really just impacting the launch of the management console creating that error but I'd like to eliminate that error and be certain it's not going to cause me issues down the road when the clients are rolled out. Thanks!
  4. Yeah actually it was already set to update from the internet and by changing it to update from the MBMC the client was able to successfully update so it probably is a proxy issue for the client which is easy for me to resolve and switch back to internet updates or at least have the internet update fallback work. So that's cool... making progress... but I'm still stuck with the issue of the "friendly" name not working. When I change the server name to one that is publicly resolvable I get the "Registered server address cannot be found. Please go to the Admin pane to modify the server address." error when running the management console... and I also need the friendly name to work so that clients on the internet can resolve it and check in.
  5. PS I am now seeing the test clients I have check into the server and populate the DB with their information... I am however still getting the same error message when trying to "Check for Updates" from the clients themselves.
  6. Yeah I'm basically trying to set it up to be accessible from outside the network for roaming clients and let internal clients reach out to it using split DNS. The recommended model in the install guide is a violation of our n-tier security policy so I've decided to just put this thing on the internet and lose the AD integrated functionality and instead use SCCM to push and manage the client packages and have our internal clients reach out to the Malwarebytes server in the Internet Services zone rather than communicate with it internally, since if I put it internally I wouldn't be able to manage our external clients or have them connect back for updates. Usually products like this... whether it's Palo Alto Traps or AirWatch or whatever allow for kind of a split horizon... Traps for example has a listening service for roaming clients on a server facing the internet that writes to the same database as the internal management server but the installation guide for Malwarebytes doesn't seem to indicate that model is possible and suggests opening the firewall on 443 and 18457 to the internal server directly... which we would never do here and I would think that would not be an uncommon restriction.
  7. Ok... I found a way to get rid of the error however it is not a workable solution. I changed the Server Address in Server Address Settings to match the local hostname of the server.... however this is a complex name and not resolvable outside of that AD domain. It needs to be able to work with the "friendly" name I've registered in DNS... which is split between public and private. It is also the name for which I've issued the public certificate. So for example the server name is something like PMWBETPAV01.addomain.com. The "friendly" name is mwbytes.fqdn.com So now that I've updated the server address I can run the console without error, however I still get the error on the client which is configured to connect to the friendly name.
  8. I am attempting it from both the primary management server and a management workstation and getting the same result. I get the same result with 127.0.0.1 or localhost.
  9. I've recently installed Malwarebytes for business and when I launch the Management console from the server I get the following error message: "Registered server address cannot be found. Please go to the Admin pane to modify the server address." It will then successfully launch the console. When running the console on a desktop for management purposes I get the same result. When trying to "Check for updates from a client" I get the error message "An error has occured. Please report this issue to our support team (include the content of all error message(s) and code(s) in your submission). PROGRAM_ERROR_UPDATING (11001, 0, Host not found) No such host is known." I've validated that DNS is correct and name resolution for the server host works fine... as evidenced by the ability to run the management console from a client even though it throws this error. Please advise. Thanks, Ian
  10. I read that document and it is kind of unrelated... I'm running Windows Server 2016 DataCenter and there isn't any problem with the SQL connection... the problem was on the contacting of the Malwarebytes servers during the installation process, for which I had to downgrade the security on the server to support TLS 1.0... the server once installed may support TLS 1.1 and 1.2 and the SQL connection looks fine... but you can't actually install the product without TLS 1.0 being supported because the licensing mechanism during installation in the installation package itself didn't seem support TLS 1.1 or 1.2 even though the licensing servers themselves do when I checked them with Qualys. I think you're missing the TLS 1.1 and 1.2 support in the actual installation package but maybe not the product once installed... Thanks!
  11. Yeah in fact I just enabled TLS 1.0 on this server to test and was able to run through the installer... so you're licensing servers are trying to negotiate TLS 1.0 with the registering server and anyone who doesn't have TLS 1.0 negotiation enabled on their system will fail. I'm surprised I'm the first one to find this since TLS 1.0 has been a security issue for some time now. https://www.nist.gov/oism/tls-10-being-turned-wwwnistgov I'm going to have to turn this back off due to our policy here... but I got the product installed. I think you guys need to make sure TLS 1.1 or 1.2 is getting negotiated by those licensing servers in order to ensure licensing continues to work and so that other clients are able to register.
  12. Ok... found the log file... here's what looks like the pertinent part of it: "***MEEServer*** 2017-11-21 10:43:53.488: Testing Keystone connectivity MSI (s) (D0!8C) [10:43:53:488]: Closing MSIHANDLE (24) of type 790531 for thread 3212 MSI (s) (D0!8C) [10:43:53:816]: Creating MSIHANDLE (25) of type 790531 for thread 3212 ***MEEServer*** 2017-11-21 10:43:53.816: Exception thrown while testing Keystone connectivity: System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive. ---> System.ComponentModel.Win32Exception: The client and server cannot communicate, because they do not possess a common algorithm at System.Net.SSPIWrapper.AcquireCredentialsHandle(SSPIInterface SecModule, String package, CredentialUse intent, SecureCredential scc) at System.Net.Security.SecureChannel.AcquireCredentialsHandle(CredentialUse credUsage, SecureCredential& secureCredential) at System.Net.Security.SecureChannel.AcquireClientCredentials(Byte& thumbPrint) at System.Net.Security.SecureChannel.GenerateToken(Byte input, Int32 offset, Int32 count, Byte& output) at System.Net.Security.SecureChannel.NextMessage(Byte incoming, Int32 offset, Int32 count) at System.Net.Security.SslState.StartSendBlob(Byte incoming, Int32 count, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte buffer, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult) at System.Net.TlsStream.CallProcessAuthentication(Object state) at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result) at System.Net.TlsStream.Write(Byte buffer, Int32 offset, Int32 size) at System.Net.PooledStream.Write(Byte buffer, Int32 offset, Int32 size) at System.Net.ConnectStream.WriteHeaders(Boolean async) --- End of inner exception stack trace --- at System.Net.HttpWebRequest.GetResponse() at SC.Server.Setup.CustomAction.CustomActions.TestKeystone(Session session) MSI (s) (D0!8C) [10:43:53:816]: Closing MSIHANDLE (25) of type 790531 for thread 3212 MSI (s) (D0!8C) [10:43:53:816]: Creating MSIHANDLE (26) of type 790531 for thread 3212 ***MEEServer*** 2017-11-21 10:43:53.816: Done with Keystone test. Result: Failure" I would probably associate this with an SSL connection that is trying to negotiate an unsupported protocol or cipher. So for example TLS 1.0 which has been deprecated and we disable via Group Policy. Here are are the supported protocols and ciphers on the system this install is failing on... do you kno
  13. Ok... found the log file... here's what looks like the pertinent part of it: "***MEEServer*** 2017-11-21 10:43:53.488: Testing Keystone connectivity MSI (s) (D0!8C) [10:43:53:488]: Closing MSIHANDLE (24) of type 790531 for thread 3212 MSI (s) (D0!8C) [10:43:53:816]: Creating MSIHANDLE (25) of type 790531 for thread 3212 ***MEEServer*** 2017-11-21 10:43:53.816: Exception thrown while testing Keystone connectivity: System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive. ---> System.ComponentModel.Win32Exception: The client and server cannot communicate, because they do not possess a common algorithm at System.Net.SSPIWrapper.AcquireCredentialsHandle(SSPIInterface SecModule, String package, CredentialUse intent, SecureCredential scc) at System.Net.Security.SecureChannel.AcquireCredentialsHandle(CredentialUse credUsage, SecureCredential& secureCredential) at System.Net.Security.SecureChannel.AcquireClientCredentials(Byte& thumbPrint) at System.Net.Security.SecureChannel.GenerateToken(Byte input, Int32 offset, Int32 count, Byte& output) at System.Net.Security.SecureChannel.NextMessage(Byte incoming, Int32 offset, Int32 count) at System.Net.Security.SslState.StartSendBlob(Byte incoming, Int32 count, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte buffer, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult) at System.Net.TlsStream.CallProcessAuthentication(Object state) at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result) at System.Net.TlsStream.Write(Byte buffer, Int32 offset, Int32 size) at System.Net.PooledStream.Write(Byte buffer, Int32 offset, Int32 size) at System.Net.ConnectStream.WriteHeaders(Boolean async) --- End of inner exception stack trace --- at System.Net.HttpWebRequest.GetResponse() at SC.Server.Setup.CustomAction.CustomActions.TestKeystone(Session session) MSI (s) (D0!8C) [10:43:53:816]: Closing MSIHANDLE (25) of type 790531 for thread 3212 MSI (s) (D0!8C) [10:43:53:816]: Creating MSIHANDLE (26) of type 790531 for thread 3212 ***MEEServer*** 2017-11-21 10:43:53.816: Done with Keystone test. Result: Failure" I would normally associate this with an SSL connection that is trying to negotiate an unsupported protocol or cipher. So for example TLS 1.0 which has been deprecated and we disable via Group Policy. Here are are the supported protocols and ciphers on the system this install is failing on... but I also see that the licensing systems allow for our supported protocols and ciphers so not sure why this is failing just yet...
×
×
  • Create New...

Important Information

This site uses cookies - We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.