Kaseya Community

TIL - LANCACHE has security design flaws in default configuration, undocumented behaviours, questionable if suitable for enterprise environment.

  • Today I learned...
    Note: this is posted in the patching section as I believe most users will use Lancache for patching and think nothing more of it.

    By default, the Lanchache server creates a local account that is setup and administered by the kaseya system.  This is documented and sounds perfectly fine.  What is not documented is that the lancache client also has an identical local administrator account created so that it can use 'pass-through' authentication.  Pass-through authentication is the old trick that if two machines have the same account with same password configured they will 'magically' authenticate with each other and communicate.  This is acceptable in a small/simple workgroup setup, which is what the functionality was originally designed for.  But this is simply not acceptable in an enterprise environment.

    If the Lancache client happens to be a domain controller, a domain admin account is created.  Secretly.  Without telling you anything.

    I was alerted to this behaviour by a savvy enterprise client asking "what do we have these accounts everywhere in our domain?"  I couldnt answer him, it made no sense.  After a long painful support process I was referred to the functionality where you can setup this domain account up manually.  This is a solution of sorts but its not pretty.  its also pretty far removed from the way you intuitively think the Lancache is really behaving.

    I have always defended Kaseya over the years.  Sure it has problems but these have tended to have been things that were broken, not design flaws.  This is a design flaw.  Pass through authentication is wrong, especially in the enterprise.

    If Kaseya want to be taken seriously in the enterprise environment this kind of issue needs to be fixed.  Its poor design.  Doesnt work well with servers and breaks pretty much any enterprise security policy when setup by default settings  The worst part of this is that this is poorly documented and the support path also seems to not understand the security implications or its workarounds.

    Kaseya.  listen up.  This is the exact documented moment when my long term support for the product faltered.  I cannot stare my colleagues in the face and tell them this is acceptable.  I can no longer blindly suggest Kaseya is a good patching product that my colleagues and other professionals should investigate.  I can no longer say "don't worry about that glitch or weird behaviour, the product is sound under the hood" -  There are just too many holes.  This is the worst one.

    [edited by: jamiev at 5:47 PM (GMT -7) on Jul 1, 2014]
  • Thanks for the heads-up jamiev!

  • Here is the link  to the documentation:


    It clearly states that LAN Cache “Automatically creates a local administrator or domain administrator account, or allows you to manually specify the credential for an existing domain administrator” on teh LAN Cache machine.

    The documentation also elaborates the step for credential setup:

    “Select the type of LAN Cache administrator credentials to use

    • Use auto-generated administrator credentials - If selected, an administrator credential is created for you when the LAN Cache is created. A local administrator credential is created unless the machine is a domain controller. If the machine is a domain controller, a domain administrator credential is created.

    • Use an existing domain administrator credential - If selected, enter the domain, username and password of an existing domain credential. The domain credential will not be created for you.”

    “ System > Default Setting > LAN Cache - Use auto-generated administrator credentials option is set to yes.”

    So I am not sure what is your disconnect with the documentation.

    I have also sent you an email regarding this. If you can provide more details on the disconnect that you see, I may be able to pull in rights folks to chime in.

  • In addition to the documentation in the help file, we also display a unique notice for any agents you intend to designate as a LAN cache that are domain controllers.

    While using a domain credential for the LAN Cache may not be in-line with the security practices at your organization, if you know of specific scenarios where this presents an immediate security vulnerability please share that directly with Varun, myself, or our Kaseya support team.

    [edited by: Ben at 7:41 AM (GMT -7) on Jul 2, 2014]
  • Hi Guys,

    Thanks for your reply.  I have no issues with the creation of a LANcache server.  You reference the help for this and its fairly well documented.  

    However, you do not reference the help for the Lancache client (Assign Lancache) - http://help.kaseya.com/WebHelp/EN/VSA/6050000/index.asp#9329.htm
    This help page is very basic indeed. it makes not mention of creating accounts on both the local machine and/or a domain if the machine happens to be a DC. Kaseya will secretly do either of these on all machines in the environment that you assign a lancache to (not create one on) and not tell anyone. This is the part that is wrong.  It leads the administrator to think that the assigning of a machine to a lancache is a benign event that does not effect the machine or the environment in any way.  You intuitively think it uses a client-server security mechanism when the account only exists on the server.

    My post is to make clear to other administrators that using Lancache in its default settings will change their environment in unexpected ways that may or may not break their companies/clients security policies. 

    Please re-read my initial post.


    PS: Note that I have also done a 3 day instructor led course for Kaseya.  Lancache was of course covered.  This behaviour was not.


  • The documentation mentions that the default setting creates admin accounts automatically as well as the selection option where one may nor may  not opt for using existing user credentials.

    It does not say that it is applicable only to the server and not to the LAN Cache clients.

    But I see your point that this information is not repeated on the page where we talk about assigning machines to a LAN Cache. And this can lead to the misunderstanding that this user account creation is not applicable to the LAN Cache clients.

    Thanks for bringing this to our attention.

    I will take this feedback to our product managers to have the documentation updated.

  • I have a question that relates to this topic.

    Why does the LAN Cache not use the existing agent credentials by default?

  • So if I point a DC at a LAN cache on a regular machine, a domain admin account is created on the DC just to talk to the share on that regular machine?

    Hopefully I'm just misunderstanding this, as I fail to see why that'd be remotely necessary - the agent is already running as LocalSystem so doesn't need any additional rights to install the patches; a domain admin account just to copy files across a network is hugely excessive.

    Does anyone know what the password complexity on these accounts is?

  • Sam, For starters, the LocalSystem account doesn't have NETWORK access - that's why it's called LOCALSystem after all ;)

    Consider all the issues with creating a share at the server end, and connecting to that share at the client end; the best solution is for Kaseya to create a service account to do so, in the same way you'd create a service account for, say, your network copier to send scans and save FAX's to a server.

    The next issue becomes - what to do if the client and server aren't in the same realm e.g. no active directory on the server, or non-domain guest, BYOD device, etc? This is where the passthru authentication comes in.

    As soon as you start to look at all these scenarios (and remember, it has to work for all kaseya users, not just you) you start to realize that Kaseya's solution is the best way to solve the issues.

    n.b. on my server (which is a DC and also a lancache client [to itself]), the kaseya account FS***** is a member of "builtin\administrators" - NOT "Domain admins". builtin\administrators does not grant enterprise wide domain admIn rights, as you suggest?

  • Hi Craig,

    > Sam, For starters, the LocalSystem account doesn't have NETWORK access - that's why it's called LOCALSystem after all ;)

    I'm curious, how does your Kaseya agent talk to your server? ;)

    LocalService doesn't have any network access, but LocalSystem does - however it "has whatever network access is granted to the computer account", and so would have problems talking to any shares needing user accounts to authenticate (although is fine making, for example, TCP connections to a Kaseya server) - hence I suspect the perceived need for a service account to transfer files from an authenticated share.

    However, as these patches are freely available on the web, I don't really see the need to require authentication for a local cache - why not just provide read-only anonymous access from the lan cache share?  Or even better, leverage Kaseya's own writeFileFromAgent() facility for transferring files between agents and bypass the shares entirely.

    It's comforting to hear that your environment doesn't seem to be affected by this though - like I say, hopefully I've just misunderstood the OP, as creating a domain admin account for the purposes of network file transfer seems a bit nuts :)