Hello,
In our organisation we have the category Streaming media blocked for general users.
But we want to have an exception for a certain AD-group. So far all is ok, the rule looks like this:
Authentication.UserGroups | at least one in list | AD-Groups: Allow Spotify |
AND | URL.SmartMatch (Spotify URLs) | equals | true |
So after that users of the AD-group can visit spotify.com or go into https://open.spotify.com etc, but as soon as they try to play any music, nothing happens.
I found out that if longer up among the rulesets, we have the part about SSL scanning and there is an exception list there for URL that should not use SSL scanning. I put in "spotify.com" in that list and then playback is fine, but then spotify works for everyone which should not be the case.
I then tried to copy that rule and modify it into my own and put it where the Spotify rule is to just disable SSL scanning for spotify allowed users but I cannot get it to work whatever I do.
Any tips on how I can make such rule that disables SSL scanning ONLY for Spotify and ONLY for a certain AD-group?
Or is there any other smarter way to get the playback on spotify working for a certain group without tampering with SSL?
Solved! Go to Solution.
Here is what I was thinking in my rule (untested). In the SSL Scanner ruleset, add a rule under "SSL Scanner" to do the bypass based on AD group AND URLs. You would do a stop rule set, which would not process anything else on the SSL scanner rules and jump to the next ruleset. This works IF the user is already authenticated and you have their groups.
Hello David,
When you disable SSL scanning, the proxy will only see a connection to the URL host i.e. www.spotify.com. Not any specific URL that is requested by the client. I guess this is why it is then working for everyone. You can test to use Applicaton Control instead teh URL.Smart.Match (Check against a list of appliactions). If you want to bypass SSL Scanning depending on the usergroup, the authentication needs to happen before the SSL ruleset.
I have of course authentication before SSL rules, but that does not matter, I cannot get it to work anyway.
I tried playing around with application control, but do not really understand how it should work with spotify.
I could of course learn by reading and reading and watching videos for hour or days, but I feel like the most quick way of learning is to get an example of how the rule(s) should look like if I would like to allow Spotify playback for a certain AD-group.
The rules we have setup in general is imported from the McAfee suggested template, so everything from Authentication to SSL scanning and regular rules for users and groups comes in the suggested order from McAfee.
Can you or anyone else give an example to how I should set this up?
Attached is how the ruleset order is.
Have you tried adding a condition to that specific Spotify rule for specific User groups?
It would be something like Authentication.UserGroups contains "SpotifyUsers"? You could also do Authentication.UserName is in list "Spotify Users" (assumes you created a list for spotify users in MWG called "Spotify Users"?
If that condition on that specific rule doesn't work, you should be able to enable rule tracing to see why it doesn't match, which should help on the path to determine what needs to be added.
For your first reply, Yes, this is what I have done to unlock spotify site for agents in that group, but playback of music is not working.
For your second reply, I have no idea how to implement that in the current rule which is based on an event in the rule. Please see attached screenshot.
It's under rule Criteria. Click Add ->User/Group Criteria then Authentication.UserGroups. See attached
Here is what I was thinking in my rule (untested). In the SSL Scanner ruleset, add a rule under "SSL Scanner" to do the bypass based on AD group AND URLs. You would do a stop rule set, which would not process anything else on the SSL scanner rules and jump to the next ruleset. This works IF the user is already authenticated and you have their groups.
Of course, I feel very stupid now. That is something I should have thought of myself, but I was snowed in on other ways to do it.
Thank you, that did it 🙂
Corporate Headquarters
6220 America Center Drive
San Jose, CA 95002 USA