At the moment policy syncing of scheduling is not possible. You are speaking of the section in the SaaS console under Web Protection > Policies > Policy Scheduling, correct?
Here is some examples if you wish to formulate rules based on time in the MWG:
#730 - 0959
((DateTime.Time.Hour equals 07 AND DateTime.Time.Minute greater than or equals 30) OR (DateTime.Time.Hour greater than or equals 08))
(DateTime.Time.Hour less than 10)
#1010 - 1159
((DateTime.Time.Hour equals 10 AND DateTime.Time.Minute greater than or equals 10) OR (DateTime.Time.Hour greater than or equals 11))
(DateTime.Time.Hour less than 12)
(DateTime.Time.Hour equals 12 AND DateTime.Time.Minute greater than or equals 30)
(DateTime.Time.Hour equals 13)
(DateTime.Time.Hour equals 14 AND DateTime.Time.Minute less than 50)
#1500 - 1559
(DateTime.Time.Hour equals 15)
As of right now, the synchronization functionality is limited to the items available in the MWG UI. Meaning SaaS functionality cannot be synced TO MWG (despite it having some of the capabilities I'm sure).
As far as how to use Web Hybrid groups/policies, there is a rule set in the library called "Web Hybrid - Apply HybridPolicy on Premise". This can be used to apply the policies you have defined in the cloud on-premise.
In the future though I think this will be turned around. MWG policy will be synced to the cloud.
I'm not worried about the "scheduling" per se. I wuld just like MWG to be able to utilize the web hybrid groups/policies. Ideally I want to set up groups and assign them to policies in 1 area, then just sync them around.
Here is what I have done:
I have a test VM setup that is using the MWG as a proxy for filtering.
On the SaaS Control Console I setup a group and added my user account to it
I created a policy to block a particular website
I used the policy scheduler to assign that policy to my group every day
On the MWG I then loaded the web hybrid policies from the library.
I synced the MWG Web hybrid config from SaaS
I confirmed that the group I am in has the test policy in the web hybrid list
I saved and applied everything.
It did not block the site for me unfortunately. Is there something I missed or might be doing wrong?
The SaaS policy ruleset does not incorporate authentication, so your groups are not known when you are going through the MWG.
How are you authenticating with SaaS? I would imagine MCP.
If MCP, then you can incorporate the MCP authentication ruleset into the MWG rules and assign policy based on group membership.
Well we are using MCP for authentication but we only planned on using that to authenticate when offsite because we don't want to point the MCP configuration to our internal MWG since theyw will not be able to get to it off site. Here's our current scenario:
We have 1 MWG VM setup with an internal IP at one of our remote offices. We are using that to filter everyone on site at that location.
We have SaaS setup and going to use MCP to authenticate them when offsite and the SaaS will filter them accordingly.
In ePO under the MCP configuration you can enter the proxy servers you want to use. We currently just have the McAfee SaaS load balancer. I do not want to enter our MWG address since it's an internal address and if it ever tries to connect to it offsite, it will not be able to reach it.
So currently I have to setup seperate groups and policies on the SaaS than I do on the MWG. Additionally I do not see actual "policies" in MWG in the sense that SaaS has policies. For instance, you can have a policy that says accountants can get to finance sites etc. There are the Web Hybrid Poilicies that pull down from SaaS Control Console but I can not figure out how to apply those.
There is a couple of things to take away from this:
1. MCP will failover is a proxy is not reachable (so it will use the first available proxy) -- so far as I remember
2. If MCP is not used for redirection when users on the network, then some other form of authentication will need to be done on the Web Gateway to perform filtering based on user or group
3. MWG does not have Policies in the sense that SaaS does. This is by design because the Web Gateway is so flexible. SaaS on the other hand is a bit more rigid in its design this makes it more consumable for the masses.
Ultimatley it may not be a bad idea to specify the Web Gateway in the MCP configuration (first in the list so SaaS is not used on-premise), this way Authentication can be handled by MCP and proxy settings do not need to be used, or if you are using WCCP, then you do not need to setup the authentication server (https://community.mcafee.com/docs/DOC-4384).
On the topic of policies you could have MWG setup like the SaaS proxies (by using the ruleset in the library), but this limits the features you are able to use on the MWG. For example (for illustration purposes) MWG only allows you to sync URL whitelists/blacklists, URL Category whitelists/blacklists, and AV settings TO SaaS or FROM SaaS. In your MWG policies, you are blocking exe downloads because its policy to do so. If you used the ruleset in the library you dont have the option to block exe downloads because it is not apart of the feature set.
In the future revisions this will change but at the moment if you to use the SaaS policy information to forumlate your MWG policies you may be limiting what the MWG can do. You can modify the SaaS policy rules, but you'd have you maintain it in two places still.
I know you have a case open on this, so I may chime in there but I'm out of the starting tomorrow, and will be back on next Wednesday.
Each failure ID has a failure reason string (human readable), the property is Authentication.FailureReason.Message.
0 No Failure - Authentication was fine
1 Unexpected Credentials - Authentication was out of expected order (applies to NTLM)
2 Unknown User - User doesnt exist in directory.
3 Wrong Password - Bad password (can apply in other situations, see https://community.mcafee.com/message/268185#268185)
4 No Credentials - No credentials were sent (ignore if authentication hasnt failed -- NTLM)
5 No Server Available - Directory server MWG attempted to contact was not reachable.
6 Proxy Timeout - MWG was communicating with a resource and it took too long to get an answer.
7 Server Timeout - ?
8 Communication Error - Server that MWG was communicating with shut down the connection.
10000 Internal Error -catch all
Using the failureIDs is not without their pitfalls though:
Do you have a use case for the failure IDs? Most of the time the you should only look at the failure ID if authentication actually failed (Authentication.Failed equals true).
In a version 7.3 installastation, what's the best way to get this list of failured IDs to record a text string in a log file instead of a numeric code? I'm sure it will involve mapping, but I have no experience doing that from scratch.
Edit: never mind. I found Authentication.FailureReason.Message. I did go ahead and create a map so I could include your comments but I am not actually using it in the rules; it is just for reference.