Video Screencast Help
Protect Your POS Environment Against Retail Data Breaches. Learn More.

Permission issue using ASDK for starting a task.

Created: 05 Jul 2013 • Updated: 05 Jul 2013 | 5 comments

Hallo @all,

I'm trying to use a VBScript to start a task over the ASDK. If a user which is member of the Symantec Administrators starts the script the task is started like expected. If a user with less permissions is executing the script the task isn't started and I receive the following error message:

Altiris.ASDK.Task.COM: Method failed. Exception: Server was unable to process request. ---> Unable to check for license '9f9a80fc-2d71-4b08-a1ad
-fb146b4af2c6'. Error: 'The current user does not have required permission 'read' to load item 'd0e33520-c160-11d2-8612-00104b74a9df'.'.

If the same user is trying to start the same task over the Management Console the task is started normally.

9f9a80fc-2d71-4b08-a1ad-fb146b4af2c6 --> Altiris Task Management
d0e33520-c160-11d2-8612-00104b74a9df --> Notification Server

Where could I define these permissions ?

Greetings Chris

 

Operating Systems:

Comments 5 CommentsJump to latest comment

michael cole's picture

Hi Chris,

I suspect, since I've looked before, that there is no documentation to define how to give precise security rights for any single item. In addition, the item "Notification Server", is not very specific, so the message isn't helpful for us.

When creating roles for groups of users don't consider that the only way to do this is by assigning nothing and building up. It is very easy to prevent certain console actions by removing the ability to 'see' the item. In that way by merely disabling all the menu items and adding only the items you need is perfectly safe inside your corporate firewall for practicality purposes.

Always work from cloned roles, never change the default roles like supervisors/level 1 workers.

If you have to break inheritance, try to make this the last thing you do, since it's not easy to come back to that configuration.

Document every checkbox you change, do it one at a time and test. It's slow but it works.

Group your security items together in seperate areas of the menu trees. Take your role and give it a corner of every space like in the menu system, in the jobs and tasks tree, filters, resources, in the organisational tree etc. if you design your role first and layout the areas then assigning permissions to those areas becomes more easy and less reliant on inheritance.

Test it again. Every configurable permission interacts with another item in a complex way. A policy has targets, computers, tasks, automation policies, a menu item, which all need to be read, some require write priviledges even though there can be no obvious reason.

TL;DR

To find out the answer to your question, it is probably somewhere between administrators and supervisors. Start with Administrator role and switch things off one at a time until you break it, then you have it, unless more than one item was required of course ;)

Michael Cole

Principal Business Critical Engineer

Business Critical Services

ChristophMueller's picture

Thank you for the tipps for setting permissions. Making my life easier :-)
Unfortunatelly there are some things I can't figure out.

The "Notification Server" object I specified above seems to be the main root object of the console. The settings or the resource folder seems to be childs of this "Notification Server" object. Editing permissions is not possible there. I was able to retrieve the permissions of that root object. Only "Symantec Administrators" and System is defined.

If I start with your tipp cloning "Symantec Administrators" role and removing permissions this will work but the role I want should not have a lot of permissions and removing thousands of permissions will make me mad :-) It seems also than not to be possible to remove permissions from the settings folder.

Now I come to an other conclusion --> Starting Tasks with ASDK requires tge Symatec Administrators Role.

I'm not shure if this is wanted or a bug. Because starting a task inside the console works with less permissions... starting the same task with the same user over ASDK brings me that obvious error:

'The current user does not have required permission 'read' to load item 'd0e33520-c160-11d2-8612-00104b74a9df'.'.
 

Any Ideas more ? Or would it be a good idea to open a support case ?

michael cole's picture

Hi Chris,

The "Notification Server" object I specified above seems to be the main root object of the console. The settings or the resource folder seems to be childs of this "Notification Server" object. Editing permissions is not possible there

Here is the trick;

You can obtain read permissions on the root item by breaking the inheritance on whatever role you cloned. This allows you to get read on the root.(see below for link to instructions)

If that is all it required (read on the root) then you might find you have solved this. What I cannot tell you is what exactly this will grant/break/fix/change elsewhere so I recommend full testing and accept your fate.

I suspect you might need more than this though since the message will just change to something further down the tree, but at least it gets you started.

I don;t want to discourage you from calling support, however the standard mantra is that they can assist with anything that is not working according to documentation. Being that there is no specific documentation it is unlikely they can identify what you need.

For a general security how-to landing page please visit http://www.symantec.com/docs/HOWTO62791

For instructions on breaking inheritance please see http://www.symantec.com/docs/HOWTO62814

If you find this leads you to a fix please come back and share with Connect!

 

Thanks!

 

 

Michael Cole

Principal Business Critical Engineer

Business Critical Services

Stefan S.'s picture

I have asked support the question earlier and it is correct you can only "run" the asdk if you are part of the Symantec Administrators group.

Trying to clone the group does not help either because some of the permissions are hidden and not copied and therefore even a clone of the Symantec Administrators group would not work.

Sch01's picture

Hi Christoph,

In fact, these items have securities that not allow seeing it through the console, and changing the level of these items (e.g. 0') change nothing, you cannot see them.

To play, you can use the import/export tool to extract all items under 'd0e33520-c160-11d2-8612-00104b74a9df' it's funny to see the subtree cos' all ASDK entries are inside and you can find which Item can be sought by a call of an ASDK Web Services, but if you expect to change the security information in xlm files to import them again in order to overwrite DB entries it's doesn't working cos' most subfolders contain only an xml file called 'Thisfolder' with just security permissions on it, no security trustees.

In Fact the security is based on two tables ’SecurityTrusteePermission’ and 'SecurityACEDATA'

The First contain the security permission(s) gived to a role managed by an Id, for example, if in the security manager you give the right to read on an item, you will have an entry in this table with an Id, the GUID of the Role and the GUID of the security Permission 'Read'.

You can find all the GUID of security Permission in the table named 'SecurityPermission'.

The second Table (SecurityACEDATA) use the Id to define which items will be granted for the Role and Permission provided by the Id, for example if from the security manager you give the permission 'Read' on 2 filters for a role, you will see in the table two entries with the GUID of the Filters and the Id (from the table 'SecurityTrusteePermission' with the GUID of Role and the Permission 'Read' associate to this Id).

you can use this SQL Query bellow to find which roles have permission defined on a specific Item:

/*Start Query*/

SELECT DISTINCT SecurityRole.Name AS 'Security role name', SecurityPermission.Name AS 'Permission'

FROM SecurityEntity INNER JOIN

SecurityACE ON SecurityEntity.Guid = SecurityACE.EntityGuid INNER JOIN

SecurityTrusteePermission ON SecurityACE.TrusteePermissionId = SecurityTrusteePermission.Id INNER JOIN

SecurityPermission ON SecurityTrusteePermission.PermissionGuid = SecurityPermission.Guid INNER JOIN

SecurityRole ON SecurityTrusteePermission.TrusteeGuid = SecurityRole.TrusteeGuid

WHERE SecurityEntity.Guid ='d0e33520-c160-11d2-8612-00104b74a9df'

/*End Query*/

You need to change the SecurityEntity.Guid value to find permission on other items.

Ok, now you can see that other built-in roles than Symantec Administrators have access to this Item wink

So, you can use one of these roles (e.g.Patch Management Roll Out have minimum rights on the console).

But if you want to apply only the ‘Read’ permission right on the Item for your specific Role you have to inject it directly to the DB (cos’ you still haven't access to this Items through the security manager).

You have 2 Stored Procedures to help you.

If you already have a role that has at least a ‘Read’ permission right on an item, you don’t have to use the 1st Step.

Anyway, understand that you need at least a custom Role for this procedure.

Step 1

The first SP is named ‘spSetSecurityTrusteePermissions’ and will create the Id entry in the Table ‘SecurityTrusteePermission’.

You need to provide some parameters to this SP:

  • @TrusteeGuids that is the GUID of the Role you want to target (you can find it in the table named SecurityRole, or using the SMC and retrieve the GUID from the Properties of your Item)
  • @PermissionGuids that is the GUID of the permission ‘Read’ (you can find it in the table named ‘SecurityPermission’)

Look Out that these entries must be Text (without ‘’)

After that, replace the value 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx' by the value provided in the previous step in the SQL Query bellow and execut it against the DB.

/*Start Query*/

SELECT Id

FROM SecurityTrusteePermission

WHERE trusteeGuid ='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx' and PermissionGuid='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx'

/*End Query*/

This Query will return the Id that it will be use be the second SP (for information) and insure you that the Id is created for the role and permission right you want

Step 2

Use the second SP that is called ‘spSetSecurityACEData’

You need to provide some parameters to this SP:

  • @EntityGuid that is the GUID of the Item
  • @TrusteeGuids the same that previous steps
  • @PermissionGuids the same that the previous steps

Look Out that only @EntityGuid expect a value like uniqueidentifier (with ‘’) all other entries must be Text (without ‘’)

using @TrusteeGuids and @PermissionGuids the SP will find the Id and associate it to the @PermissionGuids

The permission will be associates to the Item for your Role like ‘Non Inherited’

Play Again the SQL Query that show you which roles and rights are granted for an Item (the first I have provided) and you will see that now your role have the permission right(s) for the Items.

I don’t know why but you need to wait few minutes before it is functional.

Note1: after that, you should see all items in security manager for the targeted role, but it's just a view on the console root architecture, not rights are associate with these items, and if you use an account that is member of this role and also member of a role with Menu access rights(e.g.Level 1 worker), you will see in the SMC that you have all items in the selected menu but only those that have rights from the second role can be view (with associated actions), all others items from the first role (custom one) are not available in the console (error message that says the user don't have the read rights on the iitem)
 

That's It indecision