Forum Discussion

etb's avatar
etb
Active Contributor
4 months ago

Host Version 15512 - New "Keystrokes" Permission Defaults to Disabled?

I have 1 user who reported today that they could no longer log in to their computer through LMI.  They could still hit the control-alt-delete button to log in, but after doing that, they were unable to type anything through LMI.  But everything worked perfectly fine for me to remote control their computer using my user account.

 

This is not unlike something that had happened ~8 months ago, so I went about debugging along similar lines as what had worked back then.  But then I realized that new version 15512 was released today (link), and it comes with new permissions for Black Screen, Keystrokes, and Ctrl-Alt-Del.  I found that the host computer for this 1 affected user had updated already, and theirs is the only 1 of our host computers to get the update so far.  And I checked the new permissions for this affected use, and the new permissions all seemingly defaulted to being disabled.

 

The way that the permission descriptions are written (link), it's actually not clear to me whether checking the checkbox of these new permissions enables or disables the ability to use these functions.  For example the description for the new Keystrokes permission says "Disable all keystrokes from the client sent to the remote host during remote control".  So if I check that checkbox, am I enabling or disabling the user to send keystrokes?  When I examine a user that has "full control", these checkboxes are all checked, so for example that makes it seem like checking the checkbox allows the user to send keystrokes.

 

I only really just discovered this a bit ago, so I haven't fully tested yet.  But, if these new permissions could effectively default to locking out all non-admin users from using LMI, that might constitute a semi-emergency that should be raised sooner than later.  That said, apologies if this winds up being a false alarm.

  • GlennD's avatar
    GlennD
    4 months ago

    Hi etb, I apologize for the frustration. We have paused the deployment of 15512 earlier today due to this issue.

     

  • DBedford's avatar
    DBedford
    New Contributor
    3 months ago

    Same issue here today and yesterday. Two LogMeIn Central hosts had updated themselves, and the default permissions for BUILTIN\Users do not allow Keystrokes which means users cannot type when they connect via LogMeIn, nor Blank Screen because that's also been added.

     

    Since we don't also pay for the Automations add-in, there is no way for me to remotely update every PC so I may have to visit them all and update each. 

     

    Whilst I'm grateful for the new permissions, the fact they prohibit existing established behaviour (and with no warning) doesn't fill me with confidence for LogMeIn's ability to test updates.

    • etb's avatar
      etb
      Active Contributor
      3 months ago

      Hey DBedford ,

       

      May I ask for my own purposes if your affected users are on host version 15512 or 15530?

       

      Per Glenn's post above, hosts should have stopped getting updated to 15512 as of June 21st.  But I checked the release notes again today, and I see that new version 15530 was released June 27th (today), and it is indicated for 15530 that this issue should be fixed.  None of my hosts have been automatically updated to 15530 yet, so I don't know, but I'm just looking to plan accordingly as needed.

       

      For your purposes, please don't take my word for it because I'm just a random guy, but maybe a workable solution could be to force the affected hosts to update to 15530?  We can trigger hosts to update from the Central admin control web interface.

      • DBedford's avatar
        DBedford
        New Contributor
        3 months ago

        Happy to confirm!

         

        Most of our hosts are running 15460. 

        The two hosts that updated and broke are running 15512.

        I've updated a machine today and it's updated to 15530 and does not have the new permission options, so presumably works fine (haven't tested it yet). 

         

        A solution I had in the works was to export the registry key from the BUILTIN\Users group that had the permissions for Blank Screen and Keystrokes granted, then to deploy that via group policy to affected machines. 

        The registry key is in Computer\HKEY_LOCAL_MACHINE\SOFTWARE\LogMeIn\V5\Permissions and it's called AccessMask. One subkey is created for each user being granted permission, so as long as I was targeting a group all users were in, it should apply fine. 

  • kbar's avatar
    kbar
    Active Contributor
    3 months ago

    I had a somewhat of disaster of a morning because of this update. Many of my users were able to connect, but not type after connecting. After a fairly long tech support call the solution they offered was to give the users "full control" permissions which fixes the problem. 

     

    Not ideal, but it works. It seems like the update was rushed for "pro" (read expensive) SaaS software.

     

    Big miss on LogMeIn. 

  • etb's avatar
    etb
    Active Contributor
    4 months ago

    Okay, I chanced getting locked out of this computer in question, and I tested these new permissions by checking/unchecking them for my own user account.

     

    If I uncheck the "Keystrokes" permission, I am no longer able to type through LMI.  (Although I can still access the on-screen keyboard.)  Once I re-check the permission, I can type again.

     

    If I uncheck the "Ctrl-Alt-Del" permission, the ctrl-alt-del button no longer functions.  Once I re-check the permission, it works again.

     

    I actually didn't bother testing the "blank screen" permission, because it seems straightforward.

     

    I have not yet been able to ask my originally affected user to try again, so I can't be 100% certain that this was the cause of their issue, but it seems like it probably is.  

     

    So...yeah.  Unless my experience is somehow unique, you probably won't want 15512 until maybe these new permissions can default to being enabled for users who already have remote control permissions.

     

    Sorry for the uninvited "at", but since this seems kind of urgent...KateG ?

    • GlennD's avatar
      GlennD
      GoTo Manager
      4 months ago

      Hi etb, I apologize for the frustration. We have paused the deployment of 15512 earlier today due to this issue.

       

      • NotYourSysAdmin's avatar
        NotYourSysAdmin
        New Member
        4 months ago

        Good to know that the rollout has been paused!  This new option is easily overlooked and also caused me a bit of frustration today until I'd noticed the version difference.  If I've already granted a user remote desktop access, maybe the default keystroke option should be enabled in this instance?