We also had this similar problem with different "java.lang.SecurityException: Admin does not have *****" and we spent few days to solve them totally.
This was really painful and a lot of time spent on it. I think main reason is because migration documentation is not detailed enough and it lacks a lot of information. This is specially bad in the case of backwards compatibility with devices with Knox API < 22. The information is really confusing with the licence handling process, specially in real life implementation where we have Samsung devices with different OS versions. So at the end we have to deal with many unexpected errors that could have been easier to solve if the migration information and samples would have been much more precise.
If it may be of some help for someone that is still having similar problem, here you have some important details to be considered if you have to migrate to knew Knox SDK 3.x but your deployed devices still have the old Knox API < 22:
1) don't use Android API build version to decide if Samsung device with Knox should implement the compatible backwards licence : it was our first (basic) error and this gave us a lot of confusion because, as it can be seen in the compatible table (https://seap.samsung.com/sdk/knox-version-mapping), backwards licence must only be used when Knox API < 22 and this means that some Nougat devices have to implement it meanwhile other Nougat devices can use new KPE (as you can see in the table, Samsung experts decided to implement new KPE licence in the middle of the Nougat development instead of waiting to new Oreo first version, so we were really confused when some of our Nougat devices were having so many problems with licence activation)
2) at least in the Development phase, those old devices need to validate first the new KPE licence in order to grant correctly all the permissions : at least in all our testing within our deployment specific scenario, we checked that it was really needed to validate the new KPE licence first and not the backwards compatible one (honestly, we don't know if this is normal or not because in the official information it is indicated to use both BUT if you read more carefully, it is also indicated "in development, it is optional" https://seap.samsung.com/license-keys/about-licenses)
3) use "EnterpriseLicenseManager.ACTION_LICENSE_STATUS" in the Action of the IntentFilter used for the licence receiver that allows to validate the new KPE licence : in the compatible sample, it is the only one to be used, but as in our deployment we have all kind of devices, we made the terrible mistake to use the "KnoxEnterpriseLicenseManager.ACTION_LICENSE_STATUS" to validate the KPE licence in old Knox API < 22 devices, and it did not work until we used "EnterpriseLicenseManager.ACTION_LICENSE_STATUS" for the new KPE licence activation
4) related with previous point, there is no way to receive "EnterpriseLicenseManager.LICENSE_RESULT_TYPE_ACTIVATION" when we check the result type for the KPE validation (neither the EnterpriseLicenseManager.LICENSE_RESULT_TYPE_DEACTIVATION that in fact does NOT exist), so the only type result to check is the EnterpriseLicenseManager.LICENSE_RESULT_TYPE_VALIDATION one
As said before, all those last small details were the reason behind our SecurityException "Admin does not have permission" cases. And for sure, this could have been avoided if the availble migration documentation would be a little more detailed with better explained samples.