Role that not allows to delete drivers

[YagoMA]

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!

[geoffc]

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.

[dgersic]

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.

[geoffc]

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)