What: If you use JIT provisioning, go to your IDP and check if email attribute is present and contains the user’s email address. Then check if the mapping is done correctly (i.e. uses the correct email attribute name). Finally, create a new admin user in your IDP and check if that new admin can log in.
When : By April 15th
Why: Zscaler has deployed a fix for attribute validation during JIR provisioning. If you use JIT and don’t verify the mapping, you may see the error “Primary Email is required” while logging in to the admin console.
In Zscaler Client Connector version 4.8 there is a new useful feature called Device Location Services. It’s quite handy, because in rare cases where the IP-location database is out of sync, the Zscaler brain thinks that your public IP address points to a different region than the one where you really are. This might lead to a situation where you’re in California, but you get mapped to a DC in Atlanta just because your provider started to advertise your network range from Atlanta. There are many ways to fix this but for the sake of this blog entry let’s limit it to two: – you raise a ticket to get a so-called Geo override done by network support – you enable Endpoint Location services (keyword: endPointLocationForDCSelectionVisibility)
To get endpoint location services enabled, you also need to raise a ticket (but only once) to get this feature enabled. After this is done, you can see the option Use Endpoint Location for Zscaler DC Selection in the app profile under Advanced tab:
Let’s see if this actually does anything. Before enabling it, Zscaler looks at my public IP and will probably think that my location is Warsaw, Poland because of the IP-database mapping. I’m currently onnected to the London DC because with the ‘test’ zscalerone cloud I don’t actually have a better option.
I then enable the feature and in Zscaler app click on Update Policy.
Let’s make sure that Windows Location services are on:
I can see that Zscaler Client Connector accessed my location just a moment ago.
If I export the ZCC logs, at 18:23:733 there is information about UPDATE_ZIA_GEO_LOCATION. This is good.
…but sadly it’s not working. ZCC fails to get my location and falls back to the IP mapping. At this point I have no idea what i’m doing wrong so I guess it’s time to do some internal investigation.
15 minutes later I realize that I first need to restart the ZCC service on my PC and then finally I see the following log entry with the right coordinates, based on my WiFi (This is very interesting but it’s a topic for a different discussion)
This location is Strzelin, Poland. From now on, the choice of DC will be based on my geographical location and not on my public IP. In this case the difference is about 300km and while to me personally it makes no difference on the zscalerone cloud, if I was on a commercial ‘customer’ cloud, I would probably now get connected to Vienna DC rather than to Warsaw DC.
Finally, I would like to underline that my opinion is that this feature should only be enabled if you cannot change your DC selection in any other way. Treat it like a last-resort thing, because it’s usually better to modify the PAC file (especially if you’re in Europe it’s a good idea to use the country gateway variable) or enable ZIA latency-based Service Edge assignment . Also, even if you’re very far away from a DC (in my case Poland > UK), the chances are that you will get a very good connection to it anyway. However, if you’re in a large country like the US, device location services might be quite useful.
The goal here is to set a URL filtering policy that will caution the user about visiting a certain URL. Let’s say that the user wants to go to a gambling website. You don’t want to block it but maybe you feel that it’s best to warn the user that you are monitoring this activity. The user gets the Caution page with a Continue button, clicks on the button and can finally do some good old gambling.
Step 1 Create a URL policy with Action: Caution with Redirect In my case the URL category ‘gazeta’ contains a popular news portal Gazeta.pl
Step 2 Activate the policy
Step 3 You need a server where you can host the redirect page. In my case it’s my own laptop with XAMPP software where I have the Apache server running, hence 127.0.0.1/indexa.php
Then create a file called indexa.php with the following code and put the file in the xampp’s htdocs folder.
<html>
<head>
<title>test</title>
</head>
<body>
<?php
$url = $_GET['url'] ?? '';
$referer = $_GET['referer'] ?? '';
$reason = $_GET['reason'] ?? '';
$reason_code = $_GET['reasoncode'] ?? '';
$timebound = $_GET['timebound'] ?? '';
$action = $_GET['action'] ?? '';
$kind = $_GET['kind'] ?? '';
$rule = $_GET['rule'] ?? '';
$cat = $_GET['cat'] ?? '';
$user = $_GET['user'] ?? '';
$lang = $_GET['lang'] ?? '';
$zsq = explode("zsq", $_GET['zsq'] ?? '');
?>
<h1>hello from Apache... YOU HAVE BEEN CAUTIONED MY FRIEND!!! </h1>
<?php
echo "Portal " . $url . " MAY HAVE BEEN COMPROMISED"
The animals are totally optional but the rest is not. Whether you decide to pass on other arguments to Zscaler is up to you but url, rid and cat are mandatory.
Step 4 Go to gazeta.pl and you can see the following instead:
Click on the button and you can see the news portal.
You can change the action to Block with Redirect as well. In that case you don’t need to pass on the arguments to Zscaler because the user will never get to the original URL anyway
One of my clients asked me yesterday how to override DNS responses. This turned out to be quite easy… but only if you know how to do it 😀
Prerequisite: 1) You need to make sure that DNS traffic reaches Zscaler. This means that your DNS server cannot be a private IP address. Set it to e.g. 8.8.8.8. 2) This will not work for explicit proxy forwarding method (e.g. without ZCC). Why? DNS control does not manage this traffic even though Zscaler service edge resolves those requests. Again, we need to see incoming DNS traffic from the client.
Step 1
Create a new URL category with your FQDN. In my case i created the category ‘gazeta‘ which includes the fqdn gazeta.pl
Step 2 Create a DNS control policy with Request Category: <your new category> and Redirect Response field set to <IP address you want to set instead of the normal returned IP>
Here I’m changing the returned IP to 4.3.2.1
Step 3 Activate the change.
Step 4 Verify it’s working as required:
Interestingly enough, I was still able to open the website because in this logic, gazeta.pl is not enough. You need to have http://www.gazeta.pl as well or the logic will not apply.
Now you can use regex patterns to match multiple URLs.
As part of this update, in the Administration > URL Categories > Add URL Category window, the URL Type toggle has been added to select one of the following options:
Exact: to add the custom URLs, keywords, and IP ranges to a category.
Regex: to add patterns to a category.
Remember that you need to open a support ticket to get this feature enabled! This feature is still in Limited Availability so expect some questions from the support team before they enable it.
I’ll try and test this as soon as I get this feature enabled on my tenant.
My name is Tomek De Wille. Welcome to my blog about Zscaler 