Armada Security Polices-System Keys

[otobmark]

I was reading over the guide that just dropped on sharefiles about security and keys. While there were several things that puzzled me such as security policies of one subscriber unit automatically populating across entire fleet I thought I'd just ask one at a time. The section "Share System Programming without Sharing ESKs" caught my attention. As a mostly auxiliary role person, I'm not likely to be given my own Child key and at most given temporary custody of an ESK for purpose of a particular event or operation. If I get credentialed as a TRS programmer it might change but unlikely. So, the ability of being able to program without possessing the system key of course caught my attention. I applaud the effort but it does seem that the process is cumbersome especially on part of party possessing the ESK. Without dire need I don't envision that the key possessor would be inclined to use the process. Maybe some of you on this forum might experiment on using this method and report back a pro/con report.
Now here is my offbeat question: Using this method, would the subscriber unit be able to be reloaded with the system in the future? For me, I'd like the option to clear out what I'm not using at the moment but have the option to reload the system in the future when I do need it. I realize it would be specific to a particular radio (esn, ID etc). I doubt this would be an intended purpose for the non-esk method but might it be an unintended feature?

 

[kd4efm]

Mark, the way I understand it with the new setting was this

Child ESK allows “ESK Only” &/or “Strictness Rule” control A Child ESK may now be programmed with the ability to change the “ESK Only” parameter and/or “Strictness Rule” parameter of a system.

System Key mode “Zone/Channel” A new system key strictness mode of "Zone/Channel" has been added to Armada. When selected, this allows Talk Groups to be assigned to a Zone without the system key present.

HELP FILE NOTES
System Key Rules
- For radios using Firmware Version 8.40.x or later programmed by Armada
1.40.15.130 and later, you can configure P25 Trunking systems to follow
certain system key rules. These rules define the configuration behavior
of a system depending on when system keys are and are not present.

To change the system key strictness rules of a system,
you must have that system’s master key, soft key (if allowed) or a slave
key that has been provisioned with Allow Change of System Key Rules. If you change a system’s ID (key),
the system will automatically be put back to ‘strict’ rules.

“Strict” - If a system has this option enabled, all system
parameters are hidden and may not be edited without a valid System Key.
This includes channel parameters. A missing system key or locked out system/channel
RSD prevents viewing and editing of system parameters—the same as was
true for systems programmed by Armada 1.34.x and earlier.
These strict rules are on and this parameter is checked
when systems get upgraded.
This parameter is selected when creating a new system.

An Armada administrator with a valid soft or master system
key may turn this parameter off or back on. A slave ESK with Allow Change of System Key Rules can also change this value.
If the system has Require ESK to Edit checked—or if the profile’s security policy requires
ESKs to edit, only a master ESK can change the strict rule checkbox.
A slave ESK with Allow Change of System Key Rules can also change this value.
If this is checked, users may not view system parameters
without a system key. If checked and the slave ESK has system or
channel lockout enabled, system or channel parameters cannot be viewed.

Strict is automatically selected when any of the following is true:
- Armada gets upgraded from 1.36.21 and earlier
to 1.36.21 and later.
- The system’s ID gets changed.
- A new system gets created. The system cannot be edited
until a system ID gets selected.

“Lenient” - If a system has this option enabled, all
system parameters can be seen and “non-critical” system parameters may
be edited without a System Key. It works the same as “Strict,” except
that Require ESK to Edit does not have to be checked. Refer to the "Parameters That Require a System
Key for Editing" section of System Channel Copy Paste.

“Zone/Channel” - If a system has this option enabled,
it works the same as “Lenient,” except that it doesn't lock out the associated
channels’ talkgroup or security options. This option does not work with
talkgroup restrictions on slave ESKs. This setting cannot be chosen if
Require ESK to Edit is checked.

Note: A system
key (with valid Unit IDs) is required to link a template using the "Zone/Channel"
option.

 

[otobmark]

Workflow:
1 System owner sets their system to use Lenient rules.
2 Organization programmer gets system owner's system on their radios; this is the
tricky part of avoiding using ESKs; here is one possible set of steps:
a Organization programmer emails their fleet (including linked templates) to
system administrator.
b System administrator puts their system (and channels) on the imported profiles;
including assigning unit IDs to all radios; then exports and emails back.
c Organization programmer imports their fleet, now with system administrator's
system.
3 Organization programmer updates channel aliases, scan lists, etc. as desired, but
cannot change critical system parameters.
4 Organization programmer writes to all their radios

Reading between the lines it looks like once emailed template complete with linked radios is received then radios can be programmed without key. I’m guessing if radio is unlinked for any reason from template then it cannot be relinked without key. Question is what can be done to the linked template in absence of key.

 

[kd4efm]

Workflow:
1 System owner sets their system to use Lenient rules.
2 Organization programmer gets system owner's system on their radios; this is the
tricky part of avoiding using ESKs; here is one possible set of steps:
a Organization programmer emails their fleet (including linked templates) to
system administrator.
b System administrator puts their system (and channels) on the imported profiles;
including assigning unit IDs to all radios; then exports and emails back.
c Organization programmer imports their fleet, now with system administrator's
system.
3 Organization programmer updates channel aliases, scan lists, etc. as desired, but
cannot change critical system parameters.
4 Organization programmer writes to all their radios

Reading between the lines it looks like once emailed template complete with linked radios is received then radios can be programmed without key. I’m guessing if radio is unlinked for any reason from template then it cannot be relinked without key. Question is what can be done to the linked template in absence of key.

Mark, Short answer "i don't think so"

 

[otobmark]

My previous post was quoted from the Kenwood Guide. This isn’t my theory but their recommendation of how to do it.
My part was about linking. It “seems” if I don’t unlink I’m good to go within lenient rules for system with key and completely free on all Systems/channels not using a key. At present i alternate between multiple templates (in same radio) depending on mission. So… if I unlink from the template received from System Admin to link to one of my alternate templates then is there away to “relink“ to template sent from system admin? Possibly if I re-import the fleet file from system admin.
This is a down in the weeds issue so I’m only asking in the spirit of is anyone else curious about it.
If the kenwood method works then my workaround would be to not unlink template but just edit it heavily per mission provided the linked plug will continue to be able to be shot to radio without a key.