[9.193-11][Bug] Device specific Authentication don't work

Authentication is about How do you find out what the name of the user is.

Policies is about How do you treat different users differently.

You cannot create a policy that applies only to iPhone -- but you can create a policy for a user that has both a laptop and an iPhone and the policy is applied equally for both.  That user now has the ability to authenticate differently on different device types.


Let me give an example to show how this is supposed to work:
Lets say that you have a 9.1 system that uses transparent mode with browser auth (you log in via a portal page).  Lets say that you have a bunch of company laptops that are all part of your domain.  Lets also say that you have employees who bring their personal iPhones into work.
Finally, lets say that you have an Assignment/Filter Action that says your AD Group Sales is restricted from going to sites like **** and Gambling and you have another Assignment/Filter Action that says your IT department can go to any site category.

In 9.1 the laptops get a Portal page, the user enters in their name and password and then can browse.  Sales users are restricted, and IT users are not.  When a sales guy brings in his iPhone, Safari on the phone also gets a browser portal login.  Sales guy enters in his AD name and password and can browse with his restrictions.

With 9.2 the UTM can now do AD SSO in transparent mode.  The administrator decides to try this out and turns it on - now suddenly all the laptop "just work" without any login prompts (that is what Single Sign On does) and people are still restricted accordingly.  When sales guy brings in his iPhone and tries to browse in Safari he does not get the browser portal login, instead he gets a browser pop-up asking for credentials.  A sales guy logs in with his phone and gets the sales restrictions, an IT guy logs in with his phone and doesn't get any restrictions.

Now lets says that he (or you as an admin) don't like the experience of a browser pop-up on the iPhone and you like the browser portal page better.  As an admin, you can change it so that iPhones go back to authenticating with Browser while all your other devices can use the new AD SSO.

In general we find that where AD SSO works well (usually Windows and Mac computers) admins prefer to use it and where it does not work well (mobile devices, BYOD, guest networks) admins prefer browser portals.


Here is another setup you could do.  Maybe in your network you hate the fact that iPhones have to log in at all and you would rather have them have no authentication.  These non-authenticated phones you want to severely limit their internet access.  With the device specific authentication you then set iPhone authentication to None.  When the iPhone tries to use the internet, the UTM applies the first policy that matches - which will likely by the Base Policy (since it did not match either Sales or IT).  You can set the filter action on your Base Policy to be fairly restrictive.

Authentication is about How do you find out what the name of the user is.

Policies is about How do you treat different users differently.

You cannot create a policy that applies only to iPhone -- but you can create a policy for a user that has both a laptop and an iPhone and the policy is applied equally for both.  That user now has the ability to authenticate differently on different device types.


Let me give an example to show how this is supposed to work:
Lets say that you have a 9.1 system that uses transparent mode with browser auth (you log in via a portal page).  Lets say that you have a bunch of company laptops that are all part of your domain.  Lets also say that you have employees who bring their personal iPhones into work.
Finally, lets say that you have an Assignment/Filter Action that says your AD Group Sales is restricted from going to sites like **** and Gambling and you have another Assignment/Filter Action that says your IT department can go to any site category.

In 9.1 the laptops get a Portal page, the user enters in their name and password and then can browse.  Sales users are restricted, and IT users are not.  When a sales guy brings in his iPhone, Safari on the phone also gets a browser portal login.  Sales guy enters in his AD name and password and can browse with his restrictions.

With 9.2 the UTM can now do AD SSO in transparent mode.  The administrator decides to try this out and turns it on - now suddenly all the laptop "just work" without any login prompts (that is what Single Sign On does) and people are still restricted accordingly.  When sales guy brings in his iPhone and tries to browse in Safari he does not get the browser portal login, instead he gets a browser pop-up asking for credentials.  A sales guy logs in with his phone and gets the sales restrictions, an IT guy logs in with his phone and doesn't get any restrictions.

Now lets says that he (or you as an admin) don't like the experience of a browser pop-up on the iPhone and you like the browser portal page better.  As an admin, you can change it so that iPhones go back to authenticating with Browser while all your other devices can use the new AD SSO.

In general we find that where AD SSO works well (usually Windows and Mac computers) admins prefer to use it and where it does not work well (mobile devices, BYOD, guest networks) admins prefer browser portals.


Here is another setup you could do.  Maybe in your network you hate the fact that iPhones have to log in at all and you would rather have them have no authentication.  These non-authenticated phones you want to severely limit their internet access.  With the device specific authentication you then set iPhone authentication to None.  When the iPhone tries to use the internet, the UTM applies the first policy that matches - which will likely by the Base Policy (since it did not match either Sales or IT).  You can set the filter action on your Base Policy to be fairly restrictive.