YagoMA Absent Member.
Absent Member.
348 views

Role that not allows to delete drivers

Hello, happy to greet you,

We are working on our client and a new request has emerged. We need to create a role that does not allow administrator users to delete any driver from Designer and iManager. What would be the privileges that we would have to add to get it?

We are using IDM v.4.5.6, eDirectory v.9.0.4, iManager v.2.7.7 and Designer v.4.6.

Thanks in advance, best regards!
Labels (1)
0 Likes
3 Replies
Knowledge Partner
Knowledge Partner

Re: Role that not allows to delete drivers

On 6/22/2018 12:44 PM, YagoMA wrote:
>
> Hello, happy to greet you,
>
> We are working on our client and a new request has emerged. We need to
> create a role that does not allow administrator users to delete any
> driver from Designer and iManager. What would be the privileges that we
> would have to add to get it?


That is a new one.

So you have users with too many permissions, and specifically in the
DriverSet container (also driverset I imagine) you want to block
deleting the DirXML-Driver objects.

First off they are containers, and non-empty so a simple delete with fail.

You could use an Inherited Rights Filter (IRF) to block the inheritance
of S and delete rights. But first you must explicitly grant those
permissions to some object directly, so the IRF does not itself block
your real admin users.

I would pick a small container in your tree, grant a couple of objects
explicit full rights, and then try an IRF and see if your inherited
admins can get in there and delete. Once you are sure it works on a
'safe' part of the tree, do the same att the driverset level.


0 Likes
Knowledge Partner
Knowledge Partner

Re: Role that not allows to delete drivers

YagoMA;2482930 wrote:
Hello, happy to greet you,

We are working on our client and a new request has emerged. We need to create a role that does not allow administrator users to delete any driver from Designer and iManager. What would be the privileges that we would have to add to get it?

We are using IDM v.4.5.6, eDirectory v.9.0.4, iManager v.2.7.7 and Designer v.4.6.

Thanks in advance, best regards!


If you can't trust you admins not to do something they shouldn't do, who will be the admin that decides what the admins can do? Can you trust that admin?

You can set ACLs and IRFs to block and allow specific access to objects in containers, and driverset and driver objects are containers. In addition to Geoff's answer, you may need to add ACLs below the IRF, to allow for other objects to be added, changed, or deleted below the driver object level.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Role that not allows to delete drivers

On 6/22/2018 3:44 PM, dgersic wrote:
>
> YagoMA;2482930 Wrote:
>> Hello, happy to greet you,
>>
>> We are working on our client and a new request has emerged. We need to
>> create a role that does not allow administrator users to delete any
>> driver from Designer and iManager. What would be the privileges that we
>> would have to add to get it?
>>
>> We are using IDM v.4.5.6, eDirectory v.9.0.4, iManager v.2.7.7 and
>> Designer v.4.6.
>>
>> Thanks in advance, best regards!

>
> If you can't trust you admins not to do something they shouldn't do, who
> will be the admin that decides what the admins can do? Can you trust
> that admin?
>
> You can set ACLs and IRFs to block and allow specific access to objects
> in containers, and driverset and driver objects are containers. In
> addition to Geoff's answer, you may need to add ACLs below the IRF, to
> allow for other objects to be added, changed, or deleted below the
> driver object level.


Agreed, if you cannot trust your admins, find better admins, do not try
to block them. Stupid cannot be stopped!

As for the IRF, be careful you can chop off your access to part of your
tree if you are not careful. Try it in a test tree you can throw away if
you screw it up, not production. (NTS can fix it by hex editing out the
IRF ACL but don't get to that point)

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.