Forum Discussion

Chris42's avatar
Chris42
Active Contributor
3 years ago

Windows Defender Firewall issue

Hello,

Remote users are getting a Windows Defender Firewall prompt about the Rescue applet when I start a connection.  Hoping you can guide me to a fix.

 

Here are the details...

Users have an AD-joined local account with no admin permissions.  They download and run the applet with the 6 digit pin as normal.  I'm putting in the local admin password at the Rescue connect screen and elevating the session.

When that connects, the user gets this pop-up,

The path is c:\users\[username]\appdata\local\logmein rescue applet\lmir0f138001.tmp\lmi_rescue_srv.exe   So it's actually a different temp folder path for the applet every time.

I want to allow both public and private networks - they're working remote and I have no idea what type of connection they are on.

I can actually get connected to their screen, but the pop-up is generating questions from the users, and if they hit Allow it goes to their local machine's UAC which I can't see and it disrupts my connecting.

 

So question 1 is what are the firewall rules I want to create?

Question 2 is do you have any advice on deploying such rules through InTune in this case where the applet folder is particular to the user?  I've had troubles in the past establishing those types of rules because InTune only wants to manage rules for known paths like Program Files and doesn't seem to have a way to vary the path with a local user account.  %appdata% resolves to the InTune admin user, not each local user.  (If this part is outside this scope I'll take it to a Windows InTune forum once I know the details of the rule I want.)

 

Thanks

 

Problem
  • Chris42's avatar
    Chris42
    3 years ago

    OK, so then the firewalls I create in Endpoint should have distinct names, in case I deploy different CC builds to the same machine.

    And that probably should be distinct profiles, too, with all the rules for one CC instance per policy, not combining all the firewall variants in one big profile.

     

    So that's the setup, to sum up for other users:

    1, Create the CC, wrap it in an intunewin package, configure its deployment.

    2, Create a configuration profile for Endpoint Protection that sets a firewall rule for the particular CC install location.

    3, attach both to the user group that gets this CC.

    All done, nice and easy.

  • Elian1's avatar
    Elian1
    New Contributor
    3 years ago

    I was having same issue and still finding the solution please share the answer if you got thanks in advance.

    • AshC's avatar
      AshC
      Retired GoTo Contributor
      3 years ago

      When a Rescue7 administrator generates a Calling Card installer for a channel by the Admin Center, the CC is assigned a Referral ID, like "ejwsyp". This is a unique ID in Rescue7 and the install path will contain the referral ID every time the CC is installed or deployed by a Tech. The referral ID is used to differentiate company's Calling Cards from each other, it is stored in the current Windows user's registry, together with the company ID, and the channel ID.


      The binaries may be the same in folders with paths of different referral ID-s.  The Windows pop-up with the security prompt every time a CC first runs under a user on each PC -- even for lower admin users.

      • Chris42's avatar
        Chris42
        Active Contributor
        3 years ago

        OK, so then the firewalls I create in Endpoint should have distinct names, in case I deploy different CC builds to the same machine.

        And that probably should be distinct profiles, too, with all the rules for one CC instance per policy, not combining all the firewall variants in one big profile.

         

        So that's the setup, to sum up for other users:

        1, Create the CC, wrap it in an intunewin package, configure its deployment.

        2, Create a configuration profile for Endpoint Protection that sets a firewall rule for the particular CC install location.

        3, attach both to the user group that gets this CC.

        All done, nice and easy.

  • AshC's avatar
    AshC
    Retired GoTo Contributor
    3 years ago

    Hi Chris42 

    In some cases clicking the cancel button there will still all you to remotely access the desktop.

    A couple other ideas you may consider: 

    • Attempt launching the applet as a system service before you start a remote control session, which should avoid the warning if that’s possible.
    • Use the Calling Card instead, because it has a static folder it launches from so the firewall can be more easily configured to allow its P2P connection.

    It's also important to cross reference the allowlisting data :   https://support.logmeinrescue.com/rescue/help/allowlisting-and-rescue 

     

    I'm sorry we don't have any specific documentation around applying through InTune yet. 

     

     

    • Chris42's avatar
      Chris42
      Active Contributor
      3 years ago

      Hello.  Sorry for the delay, holidays and such and I thought I had this fixed but... well...

      So I downloaded Calling Card as you suggested, and deployed it thru InTune.   Calling Card does indeed look like the right plan here.

       

      Users are now getting a firewall error from that.  Note the different program folder than the earlier screenshot.

       

      This is occurring after they click Connect on the calling card and I accept the session on my side.

      What's weird is it only happens once.  If the user clicks Cancel, we close the session, and the user starts a new connection there's no prompt that time.  Even weirder is that since it's a cancel, I'm not finding any LogMeIn related firewall permissions created as a result of this, so I'm back to wondering what entries should be created ahead of time.

       

      Of course what would be ideal would be never getting this even the once.  And I can't be sure it won't all happen again if I change out to a new copy of Calling Card - like if someone wants to change our corporate branding.

      Thanks

       

      • AshC's avatar
        AshC
        Retired GoTo Contributor
        3 years ago

        The most likely cause for the installation path change would be using InTune to deploy the software instead of an MSI or regular install through LMI.   Is it possible to manually allow 'callingcard.exe' into the new path determined?