Sometimes they needed to use Chrome for it to work, other times they needed to use Internet Explorer, but one way or another they got into the meetings. Since the component installs on a per-user basis, we tried installing it both as an administrator and under the end user's account.īefore we rolled out the application white list earlier this year, on the rare occasions when any of our users needed to join a Skype for Business meeting (hosted by a client company or a vendor), they were able to do so, using the browser component.
#SKYPE WEB APP INSTALL#
In practice, the browsers are completely ignoring that the component is installed, instructing the end user to download and install the component, and even if we do everything necessary to make that happen, the cycle simply repeats. In theory, this component allows someone to observe (but not contribute to) a meeting via Internet Explorer or Google Chrome.
For parties that do not have a paid membership, the meeting specifically tells them to install the skype for business web browser plugin add-on component. Skype meetings are not supposed to require a paid membership to join them. We are not the ones hosting these meetings, nor do we have any control of which version of Skype for Business is used to host the meetings. Perhaps I did not adequately clarify this point. Aside from making a special user account with no whitelist, the sole purpose of which is to join skype for business meetings, what options (if any) do I have here? Is there a way to actually white list the Skype for Business Web App Plugin? Is there a way to use the Skype for Business application to join meetings without an account? (We tried making them computer based and the user accounts ignored those.) Basically we put giant gaping security holes in our application whitelist to allow this plugin, and it's still not enough. Our application white lists are user based. We also had to uninstall the application after trying to use it, because if the application is installed the meetings will try to default to it, preventing users from even attempting to use the web app plugin. Because the installed application (which would actually work much better with a white list) requires a Skype for Business account to use, this avenue is not an option. Note that we do not have a Skype for Business account.
And for the life of me I cannot find what security-forsaken application is trying to run, because the one that shows up as blocked in the event log is already whitelisted six ways from Sunday. So we tried allowing each individual executable by name, with no folder location restriction, but that's STILL not good enough. (Full whitelisted path is "C:\Users\%username%\AppData\Local\Microsoft\SkypeForBusinessPlugin\" meaning any application in that folder or any subfolder thereof would be allowed.) But that doesn't solve the problem. We know the directory where it installs, and allowed the entire directory, with the %username% variable. Second, once the plugin is installed, and once we make sure the user is opening a browser that allows the third-party plugin, it still gets blocked by policy. Because every host seems to have their own installer, hosted on their own server, and they always insist on installing THEIR web app. Instead, we save the installer to a special directory, so that the users can install it under their accounts. We can't just blanket allow the installer from any location, since that's a disaster waiting to happen. This makes the list very broad as is, but one application seems to demand a total lack of application restriction to function: the Skype for Business web app.įirst, even if the employee has the web app installed, it insists on installing again, even if the person clicks the link that says they already have it installed. We deployed an application white list several months ago after more than a year of refinement, and have been tweaking it since then to allow all the programs our employees need to use.