ALERT! The community will be read-only starting on April 19, 8am Pacific as the migration begins. Read more for important details.
ALERT! The community will be read-only starting on April 19, 8am Pacific as the migration begins.Read more for important details.
2546 views

AD Driver - Error on removing AD Group Memberships

Hello,
I have a quite standard AD integration with Identity Manager.
In this scenario some default roles are attached to internal IDM dynamic groups membership in order to automatically grant (and revoke) roles when users get (or lose) some attributes.

In details, at creation time, active users gets 2 default roles (1 for AD account, and 1 for a specific AD group membership).
This roles are correctly automatically granted by RRSD basing on the membership of a dynamic group.
All this correctly works symmetrically, when a user is deactivated, it automatically loses the dynamic group membership, and the RRSD correcly revokes the 2 roles (AD account, and AD group membership).

The problem occurs when the AD driver tries to enforce these revocations on Active Directory, it correctly removes the AD account (the driver is actually configured to disable AD account and move it to a designed OU) but it doesn't delete the AD group membership. The operation fails with an error on the driver side (which is also not notified, thus giving the false feedback that role is correctly removed).
The reason for this, is that the AD driver (triggered by RRSD) removes the AD account BEFORE deleting the AD group membership, this of course lead to the error on the AD endpoint side.

The error is constant, it happens in the same way, for every user's deactivation; all roles are revoked in IDM, AD account is disabled and moved, but all AD group memberships are left untouched.

My question is: as in my opinion this is very basic AD provisioning/deproviosning task, is there anything im doing wrong? I was trying to achieve basic automatic attribute-based provisioning tasks, by using smart implementation (dynamic groups, RRSD, ecc...) thus avoiding custom policies and keeping things clean, simple, and easy maintainable.

Thank you in advance.

Here extraction from Version Discovery Tool:

Identity Manager Version Discovery Tool v2.0
Novell, Inc. Copyright 2003, 2004

Parameter Summary:
Found 17 Identity Manager Drivers

Driver Set: DriverSet.Services.Vault
Driver Set running on Identity Vault: XXX.Services.Vault
Last log time: Wed Mar 14 15:11:24 CET 2018
Found eDirectory attributes associated with Identity Manager 4.5.4.0 AE

Driver: RoleResourceService.DriverSet.Services.Vault
Driver name: Identity Manager Roles and Resource Service Driver
Driver module: com.novell.nds.dirxml.driver.nrf.NRFDriverShim
Driver Set running on Identity Vault: XXX.Services.Vault
Driver ID: ROLESVC
Driver version: 4.5.0.0

Driver: UserApplication.atmDriverSet.Services.Vault
Driver name: Identity Manager Composer and/or User Application Service Driver
Driver module: com.novell.idm.driver.ComposerDriverShim
Driver Set running on Identity Vault: XXX.Services.Vault
Driver ID: UAPROV
Driver version: 0.20141007.205046

Driver: AD.DriverSet.Services.Vault
Driver name: Identity Manager Driver for Active Directory and Exchange 2000
Driver module: addriver.dll
Driver Set running on Identity Vault: XXX.Services.Vault
Driver ID: AD
Driver version: 4.0.2.0
Labels (1)
0 Likes
19 Replies
Knowledge Partner Knowledge Partner
Knowledge Partner

daniele_martinuzzi;2489410 wrote:
Hello,
I have a quite standard AD integration with Identity Manager.
In this scenario some default roles are attached to internal IDM dynamic groups membership in order to automatically grant (and revoke) roles when users get (or lose) some attributes.

In details, at creation time, active users gets 2 default roles (1 for AD account, and 1 for a specific AD group membership).
This roles are correctly automatically granted by RRSD basing on the membership of a dynamic group.
All this correctly works symmetrically, when a user is deactivated, it automatically loses the dynamic group membership, and the RRSD correcly revokes the 2 roles (AD account, and AD group membership).

The problem occurs when the AD driver tries to enforce these revocations on Active Directory, it correctly removes the AD account (the driver is actually configured to disable AD account and move it to a designed OU) but it doesn't delete the AD group membership. The operation fails with an error on the driver side (which is also not notified, thus giving the false feedback that role is correctly removed).
The reason for this, is that the AD driver (triggered by RRSD) removes the AD account BEFORE deleting the AD group membership, this of course lead to the error on the AD endpoint side.

The error is constant, it happens in the same way, for every user's deactivation; all roles are revoked in IDM, AD account is disabled and moved, but all AD group memberships are left untouched.

My question is: as in my opinion this is very basic AD provisioning/deproviosning task, is there anything im doing wrong? I was trying to achieve basic automatic attribute-based provisioning tasks, by using smart implementation (dynamic groups, RRSD, ecc...) thus avoiding custom policies and keeping things clean, simple, and easy maintainable.

Thank you in advance.

Here extraction from Version Discovery Tool:

Identity Manager Version Discovery Tool v2.0
Novell, Inc. Copyright 2003, 2004

Parameter Summary:
Found 17 Identity Manager Drivers

Driver Set: DriverSet.Services.Vault
Driver Set running on Identity Vault: XXX.Services.Vault
Last log time: Wed Mar 14 15:11:24 CET 2018
Found eDirectory attributes associated with Identity Manager 4.5.4.0 AE

Driver: RoleResourceService.DriverSet.Services.Vault
Driver name: Identity Manager Roles and Resource Service Driver
Driver module: com.novell.nds.dirxml.driver.nrf.NRFDriverShim
Driver Set running on Identity Vault: XXX.Services.Vault
Driver ID: ROLESVC
Driver version: 4.5.0.0

Driver: UserApplication.atmDriverSet.Services.Vault
Driver name: Identity Manager Composer and/or User Application Service Driver
Driver module: com.novell.idm.driver.ComposerDriverShim
Driver Set running on Identity Vault: XXX.Services.Vault
Driver ID: UAPROV
Driver version: 0.20141007.205046

Driver: AD.DriverSet.Services.Vault
Driver name: Identity Manager Driver for Active Directory and Exchange 2000
Driver module: addriver.dll
Driver Set running on Identity Vault: XXX.Services.Vault
Driver ID: AD
Driver version: 4.0.2.0


Removing the user from the group should work regardless of what else you're doing (except for deleting the AD object, of course). If you move the user to a different container, the GUID doesn't change, so the association is correct, and updates to the object should still work. The group hasn't changed either, so changes to it should also work.

So, post us a level 3 trace of this failure and let's see what's going on with it.
Knowledge Partner Knowledge Partner
Knowledge Partner

dgersic;2489412 wrote:
Removing the user from the group should work regardless of what else you're doing (except for deleting the AD object, of course). If you move the user to a different container, the GUID doesn't change, so the association is correct, and updates to the object should still work. The group hasn't changed either, so changes to it should also work.

So, post us a level 3 trace of this failure and let's see what's going on with it.


And level 3-5+ trace (during debugging of complex cases I increase level 10 trace) for Remote Loader side. It will help to understand the real order of operations on AD side.
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

First, nice write-up. This has a lot of great information to help us
understand the situation. It appears you have put a lot of thought into this.

On 10/24/2018 08:54 AM, daniele martinuzzi wrote:
>
> The problem occurs when the AD driver tries to enforce these revocations
> on Active Directory, it correctly removes the AD account (the driver is
> actually configured to disable AD account and move it to a designed OU)
> but it doesn't delete the AD group membership. The operation fails with
> an error on the driver side (which is also not notified, thus giving the
> false feedback that role is correctly removed).
> The reason for this, is that the AD driver (triggered by RRSD) removes
> the AD account BEFORE deleting the AD group membership, this of course
> lead to the error on the AD endpoint side.


Do you have the trace, level three (3) or higher, of this taking place?

If you simply move the user in microsoft active directory (MAD) to a new
container then, as I believe you are seeing, the membership are intact,
but the association to that object should also still work, so subsequent
group membership changes should still flow through and allow removal from
the group when that group change goes through the driver. That you are
not seeing this makes me wonder if either you have some policy cleaning up
associations (less likely, as you are not even deleting the user in MAD)
or if you have a policy blocking events on disabled users. Either way, a
trace from the engine side of the failing transaction would probably be
very helpful.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.

First of all, many thanks to both of you, your support is very useful and appreciated.
I understand your point and that comes as a great news, as I have been blaming the "wrong order" from the beginning, but you made me re-think of it, the problem is that it should work in any order, not the order itself. Good change of perspective, I appreciate that

Yes, I've been putting a lot of thought into this, you can definitely say it aloud... I've been struggling with it for like 7 months now 😄
I'm not new to Identity Management, but relatively new to NetIQ IDM.

Back to the problem, I do have full traces of a user deactivation collected, but they are almost 3000 lines each (AD Driver log and RRSD Driver log), I don't know if it's a good idea to just paste them here (as it will be an unreadable mess), neither I can see an option to attach files here. What would be the best option?
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

You probably know, but just in case:

Trace directly to files from a particular driver config (only one driver
config per trace file).
Trace at level three (3), or higher if needed.

Length is not a big deal; I've opened 2+ GiB files before (thank you
'less' and 'vi') and it's just fine; the important thing is to capture the
data we need (thus write directly to file; no using ndstrace/iMonitor).
After you read a few dozen/hundred/thousand traces you stop caring about size.

With regard to where to put it, if it fits here then this is a great place
for it. If not, post a link to it pasted on SUSE Paste, or PasteBin, or
something similar. If you have a server where you can drop the file for
us to access directly (HTTP presumably) that's fine too.

In this case what we really need to see is just the microsoft active
directory (MAD) driver side, since everything in the vault is, as reported
by you, correct. If RRSD modifies the users, we'll see those changes come
through the MAD driver (filter and permissions permitting) and from there
we will just need to see how the system handles it before giving it to
MAD, in this case perhaps incorrectly.


--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

daniele_martinuzzi;2489429 wrote:
First of all, many thanks to both of you, your support is very useful and appreciated.
I understand your point and that comes as a great news, as I have been blaming the "wrong order" from the beginning, but you made me re-think of it, the problem is that it should work in any order, not the order itself. Good change of perspective, I appreciate that

Yes, I've been putting a lot of thought into this, you can definitely say it aloud... I've been struggling with it for like 7 months now 😄
I'm not new to Identity Management, but relatively new to NetIQ IDM.

Back to the problem, I do have full traces of a user deactivation collected, but they are almost 3000 lines each (AD Driver log and RRSD Driver log), I don't know if it's a good idea to just paste them here (as it will be an unreadable mess), neither I can see an option to attach files here. What would be the best option?


If you haven't done this before, you should definitely read Fernando's Cool Solutions articles on gathering and reading traces:

https://www.netiq.com/communities/cool-solutions/capturing-and-reading-novell-identity-manager-traces/

https://www.netiq.com/communities/cool-solutions/comprehending-idm-traces-part-1/



If you're relatively new to NetIQ's IDM, you might also find my intro series useful:

https://www.netiq.com/communities/cool-solutions/guided-tour-novell-identity-manager-2/


Since this is a customization, not out of the box behaviour, it's likely a bug in the way it has been implemented. A level 3 trace of the MAD driver will show us what is happening, then we can explain why and how to fix it. Use susepaste.org or pastebin and put the URL here.

Also, if there is any sensitive information in the trace, you might want to run it through a search-and-replace first to mask it.
0 Likes

dgersic;2489481 wrote:
If you haven't done this before, you should definitely read Fernando's Cool Solutions articles on gathering and reading traces:

https://www.netiq.com/communities/cool-solutions/capturing-and-reading-novell-identity-manager-traces/

https://www.netiq.com/communities/cool-solutions/comprehending-idm-traces-part-1/



If you're relatively new to NetIQ's IDM, you might also find my intro series useful:

https://www.netiq.com/communities/cool-solutions/guided-tour-novell-identity-manager-2/

Thanks, very useful readings, I found them months ago and I'm still reading through them

dgersic;2489481 wrote:

Since this is a customization, not out of the box behaviour, it's likely a bug in the way it has been implemented. A level 3 trace of the MAD driver will show us what is happening, then we can explain why and how to fix it. Use susepaste.org or pastebin and put the URL here.

Why do you say that? That's exactly the opposite of what I'm trying to achieve. I would like to use OOTB features instead of custom logic. And that's the reason why I'm doing it this way. Indeed maybe the root cause of the problem is that I'm misunderstanding something, and doing things the wrong way. But what I want is the basic, standard, plain, OOTB way. As much as possible, of course
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

>> Since this is a customization, not out of the box behaviour, it's likely
>> a bug in the way it has been implemented. A level 3 trace of the MAD
>> driver will show us what is happening, then we can explain why and how
>> to fix it. Use susepaste.org or pastebin and put the URL here.
>>

> Why do you say that? That's exactly the opposite of what I'm trying to
> achieve. I would like to use OOTB features instead of custom logic. And
> that's the reason why I'm doing it this way. Indeed maybe the root cause
> of the problem is that I'm misunderstanding something, and doing things
> the wrong way. But what I want is the basic, standard, plain, OOTB way.
> As much as possible, of course


OOTB behavior is basically impossible. The drivers try but once you
stray from a set model it needs customization.

They are not evil or bad, just life.

Converse is everything is controlled by other aspects of your products.

0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

daniele_martinuzzi;2489500 wrote:
Thanks, very useful readings, I found them months ago and I'm still reading through them


Why do you say that? That's exactly the opposite of what I'm trying to achieve. I would like to use OOTB features instead of custom logic. And that's the reason why I'm doing it this way. Indeed maybe the root cause of the problem is that I'm misunderstanding something, and doing things the wrong way. But what I want is the basic, standard, plain, OOTB way. As much as possible, of course


None of the OOTB driver packages remove association. There's a reason for that. The customizations here, move to an "inactives" container, and remove association, are the implimentation bug I was referring to. The default assumption is that if the object exists, then the association is there and can be used to refer to the object (otherwise, the Matching Rule is used to find it, and associate it). Notice that the Matching Rule happens even before the Create Rule.

We do customize drivers, pretty much all of them, because the default out of the box configuration rarely matches exactly what we need them to do. But it helps to understand how the defaults are intended to work, so that you don't accidently trip over them later.
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

On 10/31/2018 9:54 AM, dgersic wrote:
>
> daniele_martinuzzi;2489500 Wrote:
>> Thanks, very useful readings, I found them months ago and I'm still
>> reading through them
>>
>>
>> Why do you say that? That's exactly the opposite of what I'm trying to
>> achieve. I would like to use OOTB features instead of custom logic. And
>> that's the reason why I'm doing it this way. Indeed maybe the root cause
>> of the problem is that I'm misunderstanding something, and doing things
>> the wrong way. But what I want is the basic, standard, plain, OOTB way.
>> As much as possible, of course

>
> None of the OOTB driver packages remove association. There's a reason
> for that. The customizations here, move to an "inactives" container, and
> remove association, are the implimentation bug I was referring to. The
> default assumption is that if the object exists, then the association is
> there and can be used to refer to the object (otherwise, the Matching
> Rule is used to find it, and associate it). Notice that the Matching
> Rule happens even before the Create Rule.
>
> We do customize drivers, pretty much all of them, because the default
> out of the box configuration rarely matches exactly what we need them to
> do. But it helps to understand how the defaults are intended to work, so
> that you don't accidently trip over them later.


The Packaged versions of the drivers, that started with IDM 4 did a
better job of allowing an OOTB model, that lasts about 10 minutues into
a project since EVERYONE has exception to handle.

Alas, tis the way of the world. If you think about it, you can usually
avoid modifying the packages and doing it all in your own policies,
which you can package as well if you like for deployment.


0 Likes

Thank you all for all your enlightening answers. I do believe that removing the association is not a correct step.
Unfortunately the driver was not implemented by me, so at the moment I do not have a precise idea of why this step has been added
(and what could happen removing it), but I will definitely try to remove it.
Thank you all by now, I will surely take further advantage of your precious support on this
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.