Hi,

You may want to check if there is some logic inside operational workflow of person modify where actual extension is skipped under some circumstances.

Other than that - trace.log, msg.log 

Hope this helps.

Mita

Ciao Mita,

In fact, that was my first thought as well.
But the invoked operation is always the same (modify person).
What changes is that if it's invoked from the role members list, no changes to the person's erroles attribute are detected.
If, on the other hand, the role is removed directly from the person, then the removal works.

And I still can't understand why this anomalous behavior occurs for a certain "bad" role, while for another role everything works as expected.

Okay regarding the logs to monitor, but which packages should be set to a higher level in order to try to catch some clues?

Thanks, as always.
And if I find out anything, of course I'll post it here.

Hi,

You may want to check if there is some logic inside operational workflow of person modify where actual extension is skipped under some circumstances.

Other than that - trace.log, msg.log 

Hope this helps.

Mita

What you would like to check is the data services person - put that to DEBUG level in your logging properties.

The real problem here is whether you can provoke the error consistently - my theory is that the Role Composition UI is handling this wrong - maybe because of shadowing some data to rdbms tables and loosing synch somehow. 

I have not debugged the Role Composition yet so I have to guess right now - but the best advice I can give you is to get a case out of the door...

HTH 

Ciao Mita,

In fact, that was my first thought as well.
But the invoked operation is always the same (modify person).
What changes is that if it's invoked from the role members list, no changes to the person's erroles attribute are detected.
If, on the other hand, the role is removed directly from the person, then the removal works.

And I still can't understand why this anomalous behavior occurs for a certain "bad" role, while for another role everything works as expected.

Okay regarding the logs to monitor, but which packages should be set to a higher level in order to try to catch some clues?

Thanks, as always.
And if I find out anything, of course I'll post it here.

Hi,

You may want to check if there is some logic inside operational workflow of person modify where actual extension is skipped under some circumstances.

Other than that - trace.log, msg.log 

Hope this helps.

Mita

I've found a way to make the error reproducible, and I guess it may be a bug.

I'll shortly post something more

What you would like to check is the data services person - put that to DEBUG level in your logging properties.

The real problem here is whether you can provoke the error consistently - my theory is that the Role Composition UI is handling this wrong - maybe because of shadowing some data to rdbms tables and loosing synch somehow. 

I have not debugged the Role Composition yet so I have to guess right now - but the best advice I can give you is to get a case out of the door...

HTH 

Ciao Mita,

In fact, that was my first thought as well.
But the invoked operation is always the same (modify person).
What changes is that if it's invoked from the role members list, no changes to the person's erroles attribute are detected.
If, on the other hand, the role is removed directly from the person, then the removal works.

And I still can't understand why this anomalous behavior occurs for a certain "bad" role, while for another role everything works as expected.

Okay regarding the logs to monitor, but which packages should be set to a higher level in order to try to catch some clues?

Thanks, as always.
And if I find out anything, of course I'll post it here.

Hi,

You may want to check if there is some logic inside operational workflow of person modify where actual extension is skipped under some circumstances.

Other than that - trace.log, msg.log 

Hope this helps.

Mita

That would be great - then I can debug it in my own systems.

I've found a way to make the error reproducible, and I guess it may be a bug.

I'll shortly post something more

What you would like to check is the data services person - put that to DEBUG level in your logging properties.

The real problem here is whether you can provoke the error consistently - my theory is that the Role Composition UI is handling this wrong - maybe because of shadowing some data to rdbms tables and loosing synch somehow. 

I have not debugged the Role Composition yet so I have to guess right now - but the best advice I can give you is to get a case out of the door...

HTH 

Ciao Mita,

In fact, that was my first thought as well.
But the invoked operation is always the same (modify person).
What changes is that if it's invoked from the role members list, no changes to the person's erroles attribute are detected.
If, on the other hand, the role is removed directly from the person, then the removal works.

And I still can't understand why this anomalous behavior occurs for a certain "bad" role, while for another role everything works as expected.

Okay regarding the logs to monitor, but which packages should be set to a higher level in order to try to catch some clues?

Thanks, as always.
And if I find out anything, of course I'll post it here.

Hi,

You may want to check if there is some logic inside operational workflow of person modify where actual extension is skipped under some circumstances.

Other than that - trace.log, msg.log 

Hope this helps.

Mita

Here we are:

It seems there is an "incorrect" reading of data from LDAP.
First of all:

• I am using Apache Directory Studio

• ISIM is 10.0.0.3

• SDS is 6.4 fp24   (in the coming months we will migrate to IVIG 11)

First, look at all the orgRole entries as I see them in LDAP (allRoles.png).
All roles have a DN ending with "DC=COM" (uppercase).

Now look at the erroles attribute of a person (personErroles.png).
Only one role ends with "DC=COM", while all the others end with "dc=com".

Well, the uppercase role is the one that shows the issue.
If edited directly in LDAP, it behaves correctly.

Now I need to run some additional checks (I'll keep you posted), because these problematic roles show a very similar (in my opinion identical) issue when the removal is requested via Java API as well.
In particular, this method:

com.ibm.itim.dataservices.model.domain.Person.removeRole(DistinguishedName roleDN)

seems to suffer from the same problem.

I still need to complete a few more checks and I will be sure to update you.

That would be great - then I can debug it in my own systems.

I've found a way to make the error reproducible, and I guess it may be a bug.

I'll shortly post something more

What you would like to check is the data services person - put that to DEBUG level in your logging properties.

The real problem here is whether you can provoke the error consistently - my theory is that the Role Composition UI is handling this wrong - maybe because of shadowing some data to rdbms tables and loosing synch somehow. 

I have not debugged the Role Composition yet so I have to guess right now - but the best advice I can give you is to get a case out of the door...

HTH 

Ciao Mita,

In fact, that was my first thought as well.
But the invoked operation is always the same (modify person).
What changes is that if it's invoked from the role members list, no changes to the person's erroles attribute are detected.
If, on the other hand, the role is removed directly from the person, then the removal works.

And I still can't understand why this anomalous behavior occurs for a certain "bad" role, while for another role everything works as expected.

Okay regarding the logs to monitor, but which packages should be set to a higher level in order to try to catch some clues?

Thanks, as always.
And if I find out anything, of course I'll post it here.

Hi,

You may want to check if there is some logic inside operational workflow of person modify where actual extension is skipped under some circumstances.

Other than that - trace.log, msg.log 

Hope this helps.

Mita

Good catch !

That I believe is a problem that has been fixed several places - when ITIM was migrated to version 5 this started as some places in the core did not ensure that Java being case sensitive was aligned with ldap be in case insensitive....

I believe this is a problem when your tenant/ldap data in enRole.properties are defined with uppercase - these are the properties from one of my test systems : 

############################################################# Default tenant information###########################################################enrole.defaulttenant.id=orgenrole.defaultadmin.id=ITIM Managerenrole.organization.name=Organization############################################################# LDAP server information###########################################################enrole.ldapserver.root=dc=comenrole.ldapserver.home=ou=itimenrole.ldapserver.agelimit=62enrole.ldapserver.ditlayout=com.ibm.itim.dataservices.dit.itim.FlatHashedLayoutenrole.ldap.provider=IBM

  If you could provide your setup I will try to see if I can get this verified on the latest IVIG level - but please raise a case 

Here we are:

It seems there is an "incorrect" reading of data from LDAP.
First of all:

• I am using Apache Directory Studio

• ISIM is 10.0.0.3

• SDS is 6.4 fp24   (in the coming months we will migrate to IVIG 11)

First, look at all the orgRole entries as I see them in LDAP (allRoles.png).
All roles have a DN ending with "DC=COM" (uppercase).

Now look at the erroles attribute of a person (personErroles.png).
Only one role ends with "DC=COM", while all the others end with "dc=com".

Well, the uppercase role is the one that shows the issue.
If edited directly in LDAP, it behaves correctly.

Now I need to run some additional checks (I'll keep you posted), because these problematic roles show a very similar (in my opinion identical) issue when the removal is requested via Java API as well.
In particular, this method:

com.ibm.itim.dataservices.model.domain.Person.removeRole(DistinguishedName roleDN)

seems to suffer from the same problem.

I still need to complete a few more checks and I will be sure to update you.

That would be great - then I can debug it in my own systems.

I've found a way to make the error reproducible, and I guess it may be a bug.

I'll shortly post something more

What you would like to check is the data services person - put that to DEBUG level in your logging properties.

The real problem here is whether you can provoke the error consistently - my theory is that the Role Composition UI is handling this wrong - maybe because of shadowing some data to rdbms tables and loosing synch somehow. 

I have not debugged the Role Composition yet so I have to guess right now - but the best advice I can give you is to get a case out of the door...

HTH 

Ciao Mita,

In fact, that was my first thought as well.
But the invoked operation is always the same (modify person).
What changes is that if it's invoked from the role members list, no changes to the person's erroles attribute are detected.
If, on the other hand, the role is removed directly from the person, then the removal works.

And I still can't understand why this anomalous behavior occurs for a certain "bad" role, while for another role everything works as expected.

Okay regarding the logs to monitor, but which packages should be set to a higher level in order to try to catch some clues?

Thanks, as always.
And if I find out anything, of course I'll post it here.

Hi,

You may want to check if there is some logic inside operational workflow of person modify where actual extension is skipped under some circumstances.

Other than that - trace.log, msg.log 

Hope this helps.

Mita

I will open a case of course.

Just an information: is enRole.properties enough for you to check?

Good catch !

That I believe is a problem that has been fixed several places - when ITIM was migrated to version 5 this started as some places in the core did not ensure that Java being case sensitive was aligned with ldap be in case insensitive....

I believe this is a problem when your tenant/ldap data in enRole.properties are defined with uppercase - these are the properties from one of my test systems : 

############################################################# Default tenant information###########################################################enrole.defaulttenant.id=orgenrole.defaultadmin.id=ITIM Managerenrole.organization.name=Organization############################################################# LDAP server information###########################################################enrole.ldapserver.root=dc=comenrole.ldapserver.home=ou=itimenrole.ldapserver.agelimit=62enrole.ldapserver.ditlayout=com.ibm.itim.dataservices.dit.itim.FlatHashedLayoutenrole.ldap.provider=IBM

  If you could provide your setup I will try to see if I can get this verified on the latest IVIG level - but please raise a case 

Here we are:

It seems there is an "incorrect" reading of data from LDAP.
First of all:

• I am using Apache Directory Studio

• ISIM is 10.0.0.3

• SDS is 6.4 fp24   (in the coming months we will migrate to IVIG 11)

First, look at all the orgRole entries as I see them in LDAP (allRoles.png).
All roles have a DN ending with "DC=COM" (uppercase).

Now look at the erroles attribute of a person (personErroles.png).
Only one role ends with "DC=COM", while all the others end with "dc=com".

Well, the uppercase role is the one that shows the issue.
If edited directly in LDAP, it behaves correctly.

Now I need to run some additional checks (I'll keep you posted), because these problematic roles show a very similar (in my opinion identical) issue when the removal is requested via Java API as well.
In particular, this method:

com.ibm.itim.dataservices.model.domain.Person.removeRole(DistinguishedName roleDN)

seems to suffer from the same problem.

I still need to complete a few more checks and I will be sure to update you.

That would be great - then I can debug it in my own systems.

I've found a way to make the error reproducible, and I guess it may be a bug.

I'll shortly post something more

What you would like to check is the data services person - put that to DEBUG level in your logging properties.

The real problem here is whether you can provoke the error consistently - my theory is that the Role Composition UI is handling this wrong - maybe because of shadowing some data to rdbms tables and loosing synch somehow. 

I have not debugged the Role Composition yet so I have to guess right now - but the best advice I can give you is to get a case out of the door...

HTH 

Ciao Mita,

In fact, that was my first thought as well.
But the invoked operation is always the same (modify person).
What changes is that if it's invoked from the role members list, no changes to the person's erroles attribute are detected.
If, on the other hand, the role is removed directly from the person, then the removal works.

And I still can't understand why this anomalous behavior occurs for a certain "bad" role, while for another role everything works as expected.

Okay regarding the logs to monitor, but which packages should be set to a higher level in order to try to catch some clues?

Thanks, as always.
And if I find out anything, of course I'll post it here.

Hi,

You may want to check if there is some logic inside operational workflow of person modify where actual extension is skipped under some circumstances.

Other than that - trace.log, msg.log 

Hope this helps.

Mita

I will open a case of course.

Just an information: is enRole.properties enough for you to check?

Good catch !

That I believe is a problem that has been fixed several places - when ITIM was migrated to version 5 this started as some places in the core did not ensure that Java being case sensitive was aligned with ldap be in case insensitive....

I believe this is a problem when your tenant/ldap data in enRole.properties are defined with uppercase - these are the properties from one of my test systems : 

############################################################# Default tenant information###########################################################enrole.defaulttenant.id=orgenrole.defaultadmin.id=ITIM Managerenrole.organization.name=Organization############################################################# LDAP server information###########################################################enrole.ldapserver.root=dc=comenrole.ldapserver.home=ou=itimenrole.ldapserver.agelimit=62enrole.ldapserver.ditlayout=com.ibm.itim.dataservices.dit.itim.FlatHashedLayoutenrole.ldap.provider=IBM

  If you could provide your setup I will try to see if I can get this verified on the latest IVIG level - but please raise a case 

Here we are:

It seems there is an "incorrect" reading of data from LDAP.
First of all:

• I am using Apache Directory Studio

• ISIM is 10.0.0.3

• SDS is 6.4 fp24   (in the coming months we will migrate to IVIG 11)

First, look at all the orgRole entries as I see them in LDAP (allRoles.png).
All roles have a DN ending with "DC=COM" (uppercase).

Now look at the erroles attribute of a person (personErroles.png).
Only one role ends with "DC=COM", while all the others end with "dc=com".

Well, the uppercase role is the one that shows the issue.
If edited directly in LDAP, it behaves correctly.

Now I need to run some additional checks (I'll keep you posted), because these problematic roles show a very similar (in my opinion identical) issue when the removal is requested via Java API as well.
In particular, this method:

com.ibm.itim.dataservices.model.domain.Person.removeRole(DistinguishedName roleDN)

seems to suffer from the same problem.

I still need to complete a few more checks and I will be sure to update you.

That would be great - then I can debug it in my own systems.

I've found a way to make the error reproducible, and I guess it may be a bug.

I'll shortly post something more

What you would like to check is the data services person - put that to DEBUG level in your logging properties.

The real problem here is whether you can provoke the error consistently - my theory is that the Role Composition UI is handling this wrong - maybe because of shadowing some data to rdbms tables and loosing synch somehow. 

I have not debugged the Role Composition yet so I have to guess right now - but the best advice I can give you is to get a case out of the door...

HTH 

Ciao Mita,

In fact, that was my first thought as well.
But the invoked operation is always the same (modify person).
What changes is that if it's invoked from the role members list, no changes to the person's erroles attribute are detected.
If, on the other hand, the role is removed directly from the person, then the removal works.

And I still can't understand why this anomalous behavior occurs for a certain "bad" role, while for another role everything works as expected.

Okay regarding the logs to monitor, but which packages should be set to a higher level in order to try to catch some clues?

Thanks, as always.
And if I find out anything, of course I'll post it here.

Hi,

You may want to check if there is some logic inside operational workflow of person modify where actual extension is skipped under some circumstances.

Other than that - trace.log, msg.log 

Hope this helps.

Mita

...eeehmmmmm...

I don't know how to get the enrole.properties file from the virtual appliance (I thought it was given along with the support file...)

No problem anyway

The keys you showed are lowercase:

I will open a case of course.

Just an information: is enRole.properties enough for you to check?

Good catch !

That I believe is a problem that has been fixed several places - when ITIM was migrated to version 5 this started as some places in the core did not ensure that Java being case sensitive was aligned with ldap be in case insensitive....

I believe this is a problem when your tenant/ldap data in enRole.properties are defined with uppercase - these are the properties from one of my test systems : 

############################################################# Default tenant information###########################################################enrole.defaulttenant.id=orgenrole.defaultadmin.id=ITIM Managerenrole.organization.name=Organization############################################################# LDAP server information###########################################################enrole.ldapserver.root=dc=comenrole.ldapserver.home=ou=itimenrole.ldapserver.agelimit=62enrole.ldapserver.ditlayout=com.ibm.itim.dataservices.dit.itim.FlatHashedLayoutenrole.ldap.provider=IBM

  If you could provide your setup I will try to see if I can get this verified on the latest IVIG level - but please raise a case 

Here we are:

It seems there is an "incorrect" reading of data from LDAP.
First of all:

• I am using Apache Directory Studio

• ISIM is 10.0.0.3

• SDS is 6.4 fp24   (in the coming months we will migrate to IVIG 11)

First, look at all the orgRole entries as I see them in LDAP (allRoles.png).
All roles have a DN ending with "DC=COM" (uppercase).

Now look at the erroles attribute of a person (personErroles.png).
Only one role ends with "DC=COM", while all the others end with "dc=com".

Well, the uppercase role is the one that shows the issue.
If edited directly in LDAP, it behaves correctly.

Now I need to run some additional checks (I'll keep you posted), because these problematic roles show a very similar (in my opinion identical) issue when the removal is requested via Java API as well.
In particular, this method:

com.ibm.itim.dataservices.model.domain.Person.removeRole(DistinguishedName roleDN)

seems to suffer from the same problem.

I still need to complete a few more checks and I will be sure to update you.

That would be great - then I can debug it in my own systems.

I've found a way to make the error reproducible, and I guess it may be a bug.

I'll shortly post something more

What you would like to check is the data services person - put that to DEBUG level in your logging properties.

The real problem here is whether you can provoke the error consistently - my theory is that the Role Composition UI is handling this wrong - maybe because of shadowing some data to rdbms tables and loosing synch somehow. 

I have not debugged the Role Composition yet so I have to guess right now - but the best advice I can give you is to get a case out of the door...

HTH 

Ciao Mita,

In fact, that was my first thought as well.
But the invoked operation is always the same (modify person).
What changes is that if it's invoked from the role members list, no changes to the person's erroles attribute are detected.
If, on the other hand, the role is removed directly from the person, then the removal works.

And I still can't understand why this anomalous behavior occurs for a certain "bad" role, while for another role everything works as expected.

Okay regarding the logs to monitor, but which packages should be set to a higher level in order to try to catch some clues?

Thanks, as always.
And if I find out anything, of course I'll post it here.

Hi,

You may want to check if there is some logic inside operational workflow of person modify where actual extension is skipped under some circumstances.

Other than that - trace.log, msg.log 

Hope this helps.

Mita

Okay, case TS021539008 has been opened.
I'm not expecting a solution; the intention is to highlight and track down the issue.

In the meantime, I will proceed with verifying whether the problem also affects the API.

For now, I can only thank you for your help.

I'll keep you updated.

...eeehmmmmm...

I don't know how to get the enrole.properties file from the virtual appliance (I thought it was given along with the support file...)

No problem anyway

The keys you showed are lowercase:

I will open a case of course.

Just an information: is enRole.properties enough for you to check?

Good catch !

That I believe is a problem that has been fixed several places - when ITIM was migrated to version 5 this started as some places in the core did not ensure that Java being case sensitive was aligned with ldap be in case insensitive....

I believe this is a problem when your tenant/ldap data in enRole.properties are defined with uppercase - these are the properties from one of my test systems : 

############################################################# Default tenant information###########################################################enrole.defaulttenant.id=orgenrole.defaultadmin.id=ITIM Managerenrole.organization.name=Organization############################################################# LDAP server information###########################################################enrole.ldapserver.root=dc=comenrole.ldapserver.home=ou=itimenrole.ldapserver.agelimit=62enrole.ldapserver.ditlayout=com.ibm.itim.dataservices.dit.itim.FlatHashedLayoutenrole.ldap.provider=IBM

  If you could provide your setup I will try to see if I can get this verified on the latest IVIG level - but please raise a case 

Here we are:

It seems there is an "incorrect" reading of data from LDAP.
First of all:

• I am using Apache Directory Studio

• ISIM is 10.0.0.3

• SDS is 6.4 fp24   (in the coming months we will migrate to IVIG 11)

First, look at all the orgRole entries as I see them in LDAP (allRoles.png).
All roles have a DN ending with "DC=COM" (uppercase).

Now look at the erroles attribute of a person (personErroles.png).
Only one role ends with "DC=COM", while all the others end with "dc=com".

Well, the uppercase role is the one that shows the issue.
If edited directly in LDAP, it behaves correctly.

Now I need to run some additional checks (I'll keep you posted), because these problematic roles show a very similar (in my opinion identical) issue when the removal is requested via Java API as well.
In particular, this method:

com.ibm.itim.dataservices.model.domain.Person.removeRole(DistinguishedName roleDN)

seems to suffer from the same problem.

I still need to complete a few more checks and I will be sure to update you.

That would be great - then I can debug it in my own systems.

I've found a way to make the error reproducible, and I guess it may be a bug.

I'll shortly post something more

What you would like to check is the data services person - put that to DEBUG level in your logging properties.

The real problem here is whether you can provoke the error consistently - my theory is that the Role Composition UI is handling this wrong - maybe because of shadowing some data to rdbms tables and loosing synch somehow. 

I have not debugged the Role Composition yet so I have to guess right now - but the best advice I can give you is to get a case out of the door...

HTH 

Ciao Mita,

In fact, that was my first thought as well.
But the invoked operation is always the same (modify person).
What changes is that if it's invoked from the role members list, no changes to the person's erroles attribute are detected.
If, on the other hand, the role is removed directly from the person, then the removal works.

And I still can't understand why this anomalous behavior occurs for a certain "bad" role, while for another role everything works as expected.

Okay regarding the logs to monitor, but which packages should be set to a higher level in order to try to catch some clues?

Thanks, as always.
And if I find out anything, of course I'll post it here.

Hi,

You may want to check if there is some logic inside operational workflow of person modify where actual extension is skipped under some circumstances.

Other than that - trace.log, msg.log 

Hope this helps.

Mita

I can say with certainty that the Java method

com.ibm.itim.dataservices.model.domain.Person.removeRole(DistinguishedName roleDN)

shows the same behavior as well.

Thanks again!

Okay, case TS021539008 has been opened.
I'm not expecting a solution; the intention is to highlight and track down the issue.

In the meantime, I will proceed with verifying whether the problem also affects the API.

For now, I can only thank you for your help.

I'll keep you updated.

...eeehmmmmm...

I don't know how to get the enrole.properties file from the virtual appliance (I thought it was given along with the support file...)

No problem anyway

The keys you showed are lowercase:

I will open a case of course.

Just an information: is enRole.properties enough for you to check?

Good catch !

That I believe is a problem that has been fixed several places - when ITIM was migrated to version 5 this started as some places in the core did not ensure that Java being case sensitive was aligned with ldap be in case insensitive....

I believe this is a problem when your tenant/ldap data in enRole.properties are defined with uppercase - these are the properties from one of my test systems : 

############################################################# Default tenant information###########################################################enrole.defaulttenant.id=orgenrole.defaultadmin.id=ITIM Managerenrole.organization.name=Organization############################################################# LDAP server information###########################################################enrole.ldapserver.root=dc=comenrole.ldapserver.home=ou=itimenrole.ldapserver.agelimit=62enrole.ldapserver.ditlayout=com.ibm.itim.dataservices.dit.itim.FlatHashedLayoutenrole.ldap.provider=IBM

  If you could provide your setup I will try to see if I can get this verified on the latest IVIG level - but please raise a case 

Here we are:

It seems there is an "incorrect" reading of data from LDAP.
First of all:

• I am using Apache Directory Studio

• ISIM is 10.0.0.3

• SDS is 6.4 fp24   (in the coming months we will migrate to IVIG 11)

First, look at all the orgRole entries as I see them in LDAP (allRoles.png).
All roles have a DN ending with "DC=COM" (uppercase).

Now look at the erroles attribute of a person (personErroles.png).
Only one role ends with "DC=COM", while all the others end with "dc=com".

Well, the uppercase role is the one that shows the issue.
If edited directly in LDAP, it behaves correctly.

Now I need to run some additional checks (I'll keep you posted), because these problematic roles show a very similar (in my opinion identical) issue when the removal is requested via Java API as well.
In particular, this method:

com.ibm.itim.dataservices.model.domain.Person.removeRole(DistinguishedName roleDN)

seems to suffer from the same problem.

I still need to complete a few more checks and I will be sure to update you.

That would be great - then I can debug it in my own systems.

I've found a way to make the error reproducible, and I guess it may be a bug.

I'll shortly post something more

What you would like to check is the data services person - put that to DEBUG level in your logging properties.

The real problem here is whether you can provoke the error consistently - my theory is that the Role Composition UI is handling this wrong - maybe because of shadowing some data to rdbms tables and loosing synch somehow. 

I have not debugged the Role Composition yet so I have to guess right now - but the best advice I can give you is to get a case out of the door...

HTH 

Ciao Mita,

In fact, that was my first thought as well.
But the invoked operation is always the same (modify person).
What changes is that if it's invoked from the role members list, no changes to the person's erroles attribute are detected.
If, on the other hand, the role is removed directly from the person, then the removal works.

And I still can't understand why this anomalous behavior occurs for a certain "bad" role, while for another role everything works as expected.

Okay regarding the logs to monitor, but which packages should be set to a higher level in order to try to catch some clues?

Thanks, as always.
And if I find out anything, of course I'll post it here.

Hi,

You may want to check if there is some logic inside operational workflow of person modify where actual extension is skipped under some circumstances.

Other than that - trace.log, msg.log 

Hope this helps.

Mita

So, as not to waste your time on the LDAP domain names in enrole.props…
Fortunately, I discovered the cause of the presence of the DC=COM roles.

1. In their container ou=roles, it's a "messed up" display in Directory Studio: if I export them, the resulting file correctly shows dc=com.

2. On the person entries: it's due to an old loading assembly that used to write DC=COM (which I'm not sure whether to thank, for bringing the bug to light).

Many thanks again.

I can say with certainty that the Java method

com.ibm.itim.dataservices.model.domain.Person.removeRole(DistinguishedName roleDN)

shows the same behavior as well.

Thanks again!

Okay, case TS021539008 has been opened.
I'm not expecting a solution; the intention is to highlight and track down the issue.

In the meantime, I will proceed with verifying whether the problem also affects the API.

For now, I can only thank you for your help.

I'll keep you updated.

...eeehmmmmm...

I don't know how to get the enrole.properties file from the virtual appliance (I thought it was given along with the support file...)

No problem anyway

The keys you showed are lowercase:

I will open a case of course.

Just an information: is enRole.properties enough for you to check?

Good catch !

That I believe is a problem that has been fixed several places - when ITIM was migrated to version 5 this started as some places in the core did not ensure that Java being case sensitive was aligned with ldap be in case insensitive....

I believe this is a problem when your tenant/ldap data in enRole.properties are defined with uppercase - these are the properties from one of my test systems : 

############################################################# Default tenant information###########################################################enrole.defaulttenant.id=orgenrole.defaultadmin.id=ITIM Managerenrole.organization.name=Organization############################################################# LDAP server information###########################################################enrole.ldapserver.root=dc=comenrole.ldapserver.home=ou=itimenrole.ldapserver.agelimit=62enrole.ldapserver.ditlayout=com.ibm.itim.dataservices.dit.itim.FlatHashedLayoutenrole.ldap.provider=IBM

  If you could provide your setup I will try to see if I can get this verified on the latest IVIG level - but please raise a case 

Here we are:

It seems there is an "incorrect" reading of data from LDAP.
First of all:

• I am using Apache Directory Studio

• ISIM is 10.0.0.3

• SDS is 6.4 fp24   (in the coming months we will migrate to IVIG 11)

First, look at all the orgRole entries as I see them in LDAP (allRoles.png).
All roles have a DN ending with "DC=COM" (uppercase).

Now look at the erroles attribute of a person (personErroles.png).
Only one role ends with "DC=COM", while all the others end with "dc=com".

Well, the uppercase role is the one that shows the issue.
If edited directly in LDAP, it behaves correctly.

Now I need to run some additional checks (I'll keep you posted), because these problematic roles show a very similar (in my opinion identical) issue when the removal is requested via Java API as well.
In particular, this method:

com.ibm.itim.dataservices.model.domain.Person.removeRole(DistinguishedName roleDN)

seems to suffer from the same problem.

I still need to complete a few more checks and I will be sure to update you.

That would be great - then I can debug it in my own systems.

I've found a way to make the error reproducible, and I guess it may be a bug.

I'll shortly post something more

What you would like to check is the data services person - put that to DEBUG level in your logging properties.

The real problem here is whether you can provoke the error consistently - my theory is that the Role Composition UI is handling this wrong - maybe because of shadowing some data to rdbms tables and loosing synch somehow. 

I have not debugged the Role Composition yet so I have to guess right now - but the best advice I can give you is to get a case out of the door...

HTH 

Ciao Mita,

In fact, that was my first thought as well.
But the invoked operation is always the same (modify person).
What changes is that if it's invoked from the role members list, no changes to the person's erroles attribute are detected.
If, on the other hand, the role is removed directly from the person, then the removal works.

And I still can't understand why this anomalous behavior occurs for a certain "bad" role, while for another role everything works as expected.

Okay regarding the logs to monitor, but which packages should be set to a higher level in order to try to catch some clues?

Thanks, as always.
And if I find out anything, of course I'll post it here.

Hi,

You may want to check if there is some logic inside operational workflow of person modify where actual extension is skipped under some circumstances.

Other than that - trace.log, msg.log 

Hope this helps.

Mita

Thanks for letting me know 😀

But debugging is seldom a waste of time - I almost always learns a little bit more about how things works :-)

But I still think that IVIG does not handle ldap case insensitive data correct is still a bug - yes I know you should not do stuff in ldap directly - but it should not really matter....

So, as not to waste your time on the LDAP domain names in enrole.props…
Fortunately, I discovered the cause of the presence of the DC=COM roles.

1. In their container ou=roles, it's a "messed up" display in Directory Studio: if I export them, the resulting file correctly shows dc=com.

2. On the person entries: it's due to an old loading assembly that used to write DC=COM (which I'm not sure whether to thank, for bringing the bug to light).

Many thanks again.

I can say with certainty that the Java method

com.ibm.itim.dataservices.model.domain.Person.removeRole(DistinguishedName roleDN)

shows the same behavior as well.

Thanks again!

Okay, case TS021539008 has been opened.
I'm not expecting a solution; the intention is to highlight and track down the issue.

In the meantime, I will proceed with verifying whether the problem also affects the API.

For now, I can only thank you for your help.

I'll keep you updated.

...eeehmmmmm...

I don't know how to get the enrole.properties file from the virtual appliance (I thought it was given along with the support file...)

No problem anyway

The keys you showed are lowercase:

I will open a case of course.

Just an information: is enRole.properties enough for you to check?

Good catch !

That I believe is a problem that has been fixed several places - when ITIM was migrated to version 5 this started as some places in the core did not ensure that Java being case sensitive was aligned with ldap be in case insensitive....

I believe this is a problem when your tenant/ldap data in enRole.properties are defined with uppercase - these are the properties from one of my test systems : 

############################################################# Default tenant information###########################################################enrole.defaulttenant.id=orgenrole.defaultadmin.id=ITIM Managerenrole.organization.name=Organization############################################################# LDAP server information###########################################################enrole.ldapserver.root=dc=comenrole.ldapserver.home=ou=itimenrole.ldapserver.agelimit=62enrole.ldapserver.ditlayout=com.ibm.itim.dataservices.dit.itim.FlatHashedLayoutenrole.ldap.provider=IBM

  If you could provide your setup I will try to see if I can get this verified on the latest IVIG level - but please raise a case 

Here we are:

It seems there is an "incorrect" reading of data from LDAP.
First of all:

• I am using Apache Directory Studio

• ISIM is 10.0.0.3

• SDS is 6.4 fp24   (in the coming months we will migrate to IVIG 11)

First, look at all the orgRole entries as I see them in LDAP (allRoles.png).
All roles have a DN ending with "DC=COM" (uppercase).

Now look at the erroles attribute of a person (personErroles.png).
Only one role ends with "DC=COM", while all the others end with "dc=com".

Well, the uppercase role is the one that shows the issue.
If edited directly in LDAP, it behaves correctly.

Now I need to run some additional checks (I'll keep you posted), because these problematic roles show a very similar (in my opinion identical) issue when the removal is requested via Java API as well.
In particular, this method:

com.ibm.itim.dataservices.model.domain.Person.removeRole(DistinguishedName roleDN)

seems to suffer from the same problem.

I still need to complete a few more checks and I will be sure to update you.

That would be great - then I can debug it in my own systems.

I've found a way to make the error reproducible, and I guess it may be a bug.

I'll shortly post something more

What you would like to check is the data services person - put that to DEBUG level in your logging properties.

The real problem here is whether you can provoke the error consistently - my theory is that the Role Composition UI is handling this wrong - maybe because of shadowing some data to rdbms tables and loosing synch somehow. 

I have not debugged the Role Composition yet so I have to guess right now - but the best advice I can give you is to get a case out of the door...

HTH 

Ciao Mita,

In fact, that was my first thought as well.
But the invoked operation is always the same (modify person).
What changes is that if it's invoked from the role members list, no changes to the person's erroles attribute are detected.
If, on the other hand, the role is removed directly from the person, then the removal works.

And I still can't understand why this anomalous behavior occurs for a certain "bad" role, while for another role everything works as expected.

Okay regarding the logs to monitor, but which packages should be set to a higher level in order to try to catch some clues?

Thanks, as always.
And if I find out anything, of course I'll post it here.

Hi,

You may want to check if there is some logic inside operational workflow of person modify where actual extension is skipped under some circumstances.

Other than that - trace.log, msg.log 

Hope this helps.

Mita

So, as not to waste your time on the LDAP domain names in enrole.props…
Fortunately, I discovered the cause of the presence of the DC=COM roles.

1. In their container ou=roles, it's a "messed up" display in Directory Studio: if I export them, the resulting file correctly shows dc=com.

2. On the person entries: it's due to an old loading assembly that used to write DC=COM (which I'm not sure whether to thank, for bringing the bug to light).

Many thanks again.

I can say with certainty that the Java method

com.ibm.itim.dataservices.model.domain.Person.removeRole(DistinguishedName roleDN)

shows the same behavior as well.

Thanks again!

Okay, case TS021539008 has been opened.
I'm not expecting a solution; the intention is to highlight and track down the issue.

In the meantime, I will proceed with verifying whether the problem also affects the API.

For now, I can only thank you for your help.

I'll keep you updated.

...eeehmmmmm...

I don't know how to get the enrole.properties file from the virtual appliance (I thought it was given along with the support file...)

No problem anyway

The keys you showed are lowercase:

I will open a case of course.

Just an information: is enRole.properties enough for you to check?

Good catch !

That I believe is a problem that has been fixed several places - when ITIM was migrated to version 5 this started as some places in the core did not ensure that Java being case sensitive was aligned with ldap be in case insensitive....

I believe this is a problem when your tenant/ldap data in enRole.properties are defined with uppercase - these are the properties from one of my test systems : 

############################################################# Default tenant information###########################################################enrole.defaulttenant.id=orgenrole.defaultadmin.id=ITIM Managerenrole.organization.name=Organization############################################################# LDAP server information###########################################################enrole.ldapserver.root=dc=comenrole.ldapserver.home=ou=itimenrole.ldapserver.agelimit=62enrole.ldapserver.ditlayout=com.ibm.itim.dataservices.dit.itim.FlatHashedLayoutenrole.ldap.provider=IBM

  If you could provide your setup I will try to see if I can get this verified on the latest IVIG level - but please raise a case 

Here we are:

It seems there is an "incorrect" reading of data from LDAP.
First of all:

• I am using Apache Directory Studio

• ISIM is 10.0.0.3

• SDS is 6.4 fp24   (in the coming months we will migrate to IVIG 11)

First, look at all the orgRole entries as I see them in LDAP (allRoles.png).
All roles have a DN ending with "DC=COM" (uppercase).

Now look at the erroles attribute of a person (personErroles.png).
Only one role ends with "DC=COM", while all the others end with "dc=com".

Well, the uppercase role is the one that shows the issue.
If edited directly in LDAP, it behaves correctly.

Now I need to run some additional checks (I'll keep you posted), because these problematic roles show a very similar (in my opinion identical) issue when the removal is requested via Java API as well.
In particular, this method:

com.ibm.itim.dataservices.model.domain.Person.removeRole(DistinguishedName roleDN)

seems to suffer from the same problem.

I still need to complete a few more checks and I will be sure to update you.

That would be great - then I can debug it in my own systems.

I've found a way to make the error reproducible, and I guess it may be a bug.

I'll shortly post something more

What you would like to check is the data services person - put that to DEBUG level in your logging properties.

The real problem here is whether you can provoke the error consistently - my theory is that the Role Composition UI is handling this wrong - maybe because of shadowing some data to rdbms tables and loosing synch somehow. 

I have not debugged the Role Composition yet so I have to guess right now - but the best advice I can give you is to get a case out of the door...

HTH 

Ciao Mita,

In fact, that was my first thought as well.
But the invoked operation is always the same (modify person).
What changes is that if it's invoked from the role members list, no changes to the person's erroles attribute are detected.
If, on the other hand, the role is removed directly from the person, then the removal works.

And I still can't understand why this anomalous behavior occurs for a certain "bad" role, while for another role everything works as expected.

Okay regarding the logs to monitor, but which packages should be set to a higher level in order to try to catch some clues?

Thanks, as always.
And if I find out anything, of course I'll post it here.

Hi,

You may want to check if there is some logic inside operational workflow of person modify where actual extension is skipped under some circumstances.

Other than that - trace.log, msg.log 

Hope this helps.

Mita

So, as not to waste your time on the LDAP domain names in enrole.props…
Fortunately, I discovered the cause of the presence of the DC=COM roles.

1. In their container ou=roles, it's a "messed up" display in Directory Studio: if I export them, the resulting file correctly shows dc=com.

2. On the person entries: it's due to an old loading assembly that used to write DC=COM (which I'm not sure whether to thank, for bringing the bug to light).

Many thanks again.

I can say with certainty that the Java method

com.ibm.itim.dataservices.model.domain.Person.removeRole(DistinguishedName roleDN)

shows the same behavior as well.

Thanks again!

Okay, case TS021539008 has been opened.
I'm not expecting a solution; the intention is to highlight and track down the issue.

In the meantime, I will proceed with verifying whether the problem also affects the API.

For now, I can only thank you for your help.

I'll keep you updated.

...eeehmmmmm...

I don't know how to get the enrole.properties file from the virtual appliance (I thought it was given along with the support file...)

No problem anyway

The keys you showed are lowercase:

I will open a case of course.

Just an information: is enRole.properties enough for you to check?

Good catch !

That I believe is a problem that has been fixed several places - when ITIM was migrated to version 5 this started as some places in the core did not ensure that Java being case sensitive was aligned with ldap be in case insensitive....

I believe this is a problem when your tenant/ldap data in enRole.properties are defined with uppercase - these are the properties from one of my test systems : 

############################################################# Default tenant information###########################################################enrole.defaulttenant.id=orgenrole.defaultadmin.id=ITIM Managerenrole.organization.name=Organization############################################################# LDAP server information###########################################################enrole.ldapserver.root=dc=comenrole.ldapserver.home=ou=itimenrole.ldapserver.agelimit=62enrole.ldapserver.ditlayout=com.ibm.itim.dataservices.dit.itim.FlatHashedLayoutenrole.ldap.provider=IBM

  If you could provide your setup I will try to see if I can get this verified on the latest IVIG level - but please raise a case 

Here we are:

It seems there is an "incorrect" reading of data from LDAP.
First of all:

• I am using Apache Directory Studio

• ISIM is 10.0.0.3

• SDS is 6.4 fp24   (in the coming months we will migrate to IVIG 11)

First, look at all the orgRole entries as I see them in LDAP (allRoles.png).
All roles have a DN ending with "DC=COM" (uppercase).

Now look at the erroles attribute of a person (personErroles.png).
Only one role ends with "DC=COM", while all the others end with "dc=com".

Well, the uppercase role is the one that shows the issue.
If edited directly in LDAP, it behaves correctly.

Now I need to run some additional checks (I'll keep you posted), because these problematic roles show a very similar (in my opinion identical) issue when the removal is requested via Java API as well.
In particular, this method:

com.ibm.itim.dataservices.model.domain.Person.removeRole(DistinguishedName roleDN)

seems to suffer from the same problem.

I still need to complete a few more checks and I will be sure to update you.

That would be great - then I can debug it in my own systems.

I've found a way to make the error reproducible, and I guess it may be a bug.

I'll shortly post something more

What you would like to check is the data services person - put that to DEBUG level in your logging properties.

The real problem here is whether you can provoke the error consistently - my theory is that the Role Composition UI is handling this wrong - maybe because of shadowing some data to rdbms tables and loosing synch somehow. 

I have not debugged the Role Composition yet so I have to guess right now - but the best advice I can give you is to get a case out of the door...

HTH 

Ciao Mita,

In fact, that was my first thought as well.
But the invoked operation is always the same (modify person).
What changes is that if it's invoked from the role members list, no changes to the person's erroles attribute are detected.
If, on the other hand, the role is removed directly from the person, then the removal works.

And I still can't understand why this anomalous behavior occurs for a certain "bad" role, while for another role everything works as expected.

Okay regarding the logs to monitor, but which packages should be set to a higher level in order to try to catch some clues?

Thanks, as always.
And if I find out anything, of course I'll post it here.

Hi,

You may want to check if there is some logic inside operational workflow of person modify where actual extension is skipped under some circumstances.

Other than that - trace.log, msg.log 

Hope this helps.

Mita

Here we are:

It seems there is an "incorrect" reading of data from LDAP.
First of all:

• I am using Apache Directory Studio

• ISIM is 10.0.0.3

• SDS is 6.4 fp24   (in the coming months we will migrate to IVIG 11)

First, look at all the orgRole entries as I see them in LDAP (allRoles.png).
All roles have a DN ending with "DC=COM" (uppercase).

Now look at the erroles attribute of a person (personErroles.png).
Only one role ends with "DC=COM", while all the others end with "dc=com".

Well, the uppercase role is the one that shows the issue.
If edited directly in LDAP, it behaves correctly.

Now I need to run some additional checks (I'll keep you posted), because these problematic roles show a very similar (in my opinion identical) issue when the removal is requested via Java API as well.
In particular, this method:

com.ibm.itim.dataservices.model.domain.Person.removeRole(DistinguishedName roleDN)

seems to suffer from the same problem.

I still need to complete a few more checks and I will be sure to update you.

------------------------------
Andrea Gatto
------------------------------


Original Message:
Sent: Wed February 25, 2026 06:48 AM
From: Franz Wolfhagen
Subject: Mysterious role behaviour

That would be great - then I can debug it in my own systems.

------------------------------
Franz Wolfhagen
WW IAM Solution Architect - Certified Consulting IT Specialist
IBM Expert Labs


Original Message:
Sent: Wed February 25, 2026 06:40 AM
From: Andrea Gatto
Subject: Mysterious role behaviour

I've found a way to make the error reproducible, and I guess it may be a bug.

I'll shortly post something more

------------------------------
Andrea Gatto


Original Message:
Sent: Wed February 25, 2026 06:19 AM
From: Franz Wolfhagen
Subject: Mysterious role behaviour

What you would like to check is the data services person - put that to DEBUG level in your logging properties.

The real problem here is whether you can provoke the error consistently - my theory is that the Role Composition UI is handling this wrong - maybe because of shadowing some data to rdbms tables and loosing synch somehow. 

I have not debugged the Role Composition yet so I have to guess right now - but the best advice I can give you is to get a case out of the door...

HTH 

------------------------------
Franz Wolfhagen
WW IAM Solution Architect - Certified Consulting IT Specialist
IBM Expert Labs


Original Message:
Sent: Wed February 25, 2026 03:43 AM
From: Andrea Gatto
Subject: Mysterious role behaviour

Ciao Mita,

In fact, that was my first thought as well.
But the invoked operation is always the same (modify person).
What changes is that if it's invoked from the role members list, no changes to the person's erroles attribute are detected.
If, on the other hand, the role is removed directly from the person, then the removal works.

And I still can't understand why this anomalous behavior occurs for a certain "bad" role, while for another role everything works as expected.

Okay regarding the logs to monitor, but which packages should be set to a higher level in order to try to catch some clues?

Thanks, as always.
And if I find out anything, of course I'll post it here.

------------------------------
Andrea Gatto


Original Message:
Sent: Tue February 24, 2026 12:41 PM
From: Mita Mitic
Subject: Mysterious role behaviour

Hi,

You may want to check if there is some logic inside operational workflow of person modify where actual extension is skipped under some circumstances.

Other than that - trace.log, msg.log 

Hope this helps.

Mita

------------------------------
Mita Mitic

I had a similar case-sensitivity issue. I used this approach to tell LDAP to ignore case sensitivity. Maybe you can apply the same approach to the enroles attribute.
https://www.ibm.com/support/pages/making-policy-checking-case-insensitive

------------------------------
Rudy Santos
------------------------------


Original Message:
Sent: Wed February 25, 2026 07:47 AM
From: Andrea Gatto
Subject: Mysterious role behaviour

Here we are:

It seems there is an "incorrect" reading of data from LDAP.
First of all:

• I am using Apache Directory Studio

• ISIM is 10.0.0.3

• SDS is 6.4 fp24   (in the coming months we will migrate to IVIG 11)

First, look at all the orgRole entries as I see them in LDAP (allRoles.png).
All roles have a DN ending with "DC=COM" (uppercase).

Now look at the erroles attribute of a person (personErroles.png).
Only one role ends with "DC=COM", while all the others end with "dc=com".

Well, the uppercase role is the one that shows the issue.
If edited directly in LDAP, it behaves correctly.

Now I need to run some additional checks (I'll keep you posted), because these problematic roles show a very similar (in my opinion identical) issue when the removal is requested via Java API as well.
In particular, this method:

com.ibm.itim.dataservices.model.domain.Person.removeRole(DistinguishedName roleDN)

seems to suffer from the same problem.

I still need to complete a few more checks and I will be sure to update you.

------------------------------
Andrea Gatto


Original Message:
Sent: Wed February 25, 2026 06:48 AM
From: Franz Wolfhagen
Subject: Mysterious role behaviour

That would be great - then I can debug it in my own systems.

------------------------------
Franz Wolfhagen
WW IAM Solution Architect - Certified Consulting IT Specialist
IBM Expert Labs


Original Message:
Sent: Wed February 25, 2026 06:40 AM
From: Andrea Gatto
Subject: Mysterious role behaviour

I've found a way to make the error reproducible, and I guess it may be a bug.

I'll shortly post something more

------------------------------
Andrea Gatto


Original Message:
Sent: Wed February 25, 2026 06:19 AM
From: Franz Wolfhagen
Subject: Mysterious role behaviour

What you would like to check is the data services person - put that to DEBUG level in your logging properties.

The real problem here is whether you can provoke the error consistently - my theory is that the Role Composition UI is handling this wrong - maybe because of shadowing some data to rdbms tables and loosing synch somehow. 

I have not debugged the Role Composition yet so I have to guess right now - but the best advice I can give you is to get a case out of the door...

HTH 

------------------------------
Franz Wolfhagen
WW IAM Solution Architect - Certified Consulting IT Specialist
IBM Expert Labs


Original Message:
Sent: Wed February 25, 2026 03:43 AM
From: Andrea Gatto
Subject: Mysterious role behaviour

Ciao Mita,

In fact, that was my first thought as well.
But the invoked operation is always the same (modify person).
What changes is that if it's invoked from the role members list, no changes to the person's erroles attribute are detected.
If, on the other hand, the role is removed directly from the person, then the removal works.

And I still can't understand why this anomalous behavior occurs for a certain "bad" role, while for another role everything works as expected.

Okay regarding the logs to monitor, but which packages should be set to a higher level in order to try to catch some clues?

Thanks, as always.
And if I find out anything, of course I'll post it here.

------------------------------
Andrea Gatto


Original Message:
Sent: Tue February 24, 2026 12:41 PM
From: Mita Mitic
Subject: Mysterious role behaviour

Hi,

You may want to check if there is some logic inside operational workflow of person modify where actual extension is skipped under some circumstances.

Other than that - trace.log, msg.log 

Hope this helps.

Mita

------------------------------
Mita Mitic

@Mikio: Thanks. I tried it and it works just as you said. Apparently ADS displays the base DN exactly as it is entered in the configuration. Fortunately, it's only a display issue: if you export the data (LDIF or CSV), the case is correct.

@Rudy: Just from reading the title, it doesn't seem to apply to my case. However, I'm interested in it, but I was only able to read the title - it seems I'm not authorized to view the page you linked (even though I log in). Could you paste the text here?

Ciao & thank you

I had a similar case-sensitivity issue. I used this approach to tell LDAP to ignore case sensitivity. Maybe you can apply the same approach to the enroles attribute.
https://www.ibm.com/support/pages/making-policy-checking-case-insensitive

------------------------------
Rudy Santos


Original Message:
Sent: Wed February 25, 2026 07:47 AM
From: Andrea Gatto
Subject: Mysterious role behaviour

Here we are:

It seems there is an "incorrect" reading of data from LDAP.
First of all:

• I am using Apache Directory Studio

• ISIM is 10.0.0.3

• SDS is 6.4 fp24   (in the coming months we will migrate to IVIG 11)

First, look at all the orgRole entries as I see them in LDAP (allRoles.png).
All roles have a DN ending with "DC=COM" (uppercase).

Now look at the erroles attribute of a person (personErroles.png).
Only one role ends with "DC=COM", while all the others end with "dc=com".

Well, the uppercase role is the one that shows the issue.
If edited directly in LDAP, it behaves correctly.

Now I need to run some additional checks (I'll keep you posted), because these problematic roles show a very similar (in my opinion identical) issue when the removal is requested via Java API as well.
In particular, this method:

com.ibm.itim.dataservices.model.domain.Person.removeRole(DistinguishedName roleDN)

seems to suffer from the same problem.

I still need to complete a few more checks and I will be sure to update you.

------------------------------
Andrea Gatto


Original Message:
Sent: Wed February 25, 2026 06:48 AM
From: Franz Wolfhagen
Subject: Mysterious role behaviour

That would be great - then I can debug it in my own systems.

------------------------------
Franz Wolfhagen
WW IAM Solution Architect - Certified Consulting IT Specialist
IBM Expert Labs


Original Message:
Sent: Wed February 25, 2026 06:40 AM
From: Andrea Gatto
Subject: Mysterious role behaviour

I've found a way to make the error reproducible, and I guess it may be a bug.

I'll shortly post something more

------------------------------
Andrea Gatto


Original Message:
Sent: Wed February 25, 2026 06:19 AM
From: Franz Wolfhagen
Subject: Mysterious role behaviour

What you would like to check is the data services person - put that to DEBUG level in your logging properties.

The real problem here is whether you can provoke the error consistently - my theory is that the Role Composition UI is handling this wrong - maybe because of shadowing some data to rdbms tables and loosing synch somehow. 

I have not debugged the Role Composition yet so I have to guess right now - but the best advice I can give you is to get a case out of the door...

HTH 

------------------------------
Franz Wolfhagen
WW IAM Solution Architect - Certified Consulting IT Specialist
IBM Expert Labs


Original Message:
Sent: Wed February 25, 2026 03:43 AM
From: Andrea Gatto
Subject: Mysterious role behaviour

Ciao Mita,

In fact, that was my first thought as well.
But the invoked operation is always the same (modify person).
What changes is that if it's invoked from the role members list, no changes to the person's erroles attribute are detected.
If, on the other hand, the role is removed directly from the person, then the removal works.

And I still can't understand why this anomalous behavior occurs for a certain "bad" role, while for another role everything works as expected.

Okay regarding the logs to monitor, but which packages should be set to a higher level in order to try to catch some clues?

Thanks, as always.
And if I find out anything, of course I'll post it here.

------------------------------
Andrea Gatto


Original Message:
Sent: Tue February 24, 2026 12:41 PM
From: Mita Mitic
Subject: Mysterious role behaviour

Hi,

You may want to check if there is some logic inside operational workflow of person modify where actual extension is skipped under some circumstances.

Other than that - trace.log, msg.log 

Hope this helps.

Mita

------------------------------
Mita Mitic

Set the enroles attribute to be case ignore string. I had similar problem with other "DN attribute" and this approach solved my issue.

To ignore the case when checking compliance, set the equality matching rule on the attribute in the ITIM LDAP Server schema to "EQUALITY 2.5.13.2" (caseIgnoreMatch)". ITIM checks the equality matching rule during compliance checking and compares the values based on this setting.

To change the behavior, using the IDS Web Admin Console, modify the erLdapGroupName and erLdapContainerName attributes to an equality matching rule of "EQUALITY 2.5.13.2" (caseIgnoreMatch)".

Even thought ITIM caches the ITIM LDAP Server schema and periodically refreshes it, it would be best to restart the ITIM Application Server(s).

@Mikio: Thanks. I tried it and it works just as you said. Apparently ADS displays the base DN exactly as it is entered in the configuration. Fortunately, it's only a display issue: if you export the data (LDIF or CSV), the case is correct.

@Rudy: Just from reading the title, it doesn't seem to apply to my case. However, I'm interested in it, but I was only able to read the title - it seems I'm not authorized to view the page you linked (even though I log in). Could you paste the text here?

Ciao & thank you

I had a similar case-sensitivity issue. I used this approach to tell LDAP to ignore case sensitivity. Maybe you can apply the same approach to the enroles attribute.
https://www.ibm.com/support/pages/making-policy-checking-case-insensitive

------------------------------
Rudy Santos


Original Message:
Sent: Wed February 25, 2026 07:47 AM
From: Andrea Gatto
Subject: Mysterious role behaviour

Here we are:

It seems there is an "incorrect" reading of data from LDAP.
First of all:

• I am using Apache Directory Studio

• ISIM is 10.0.0.3

• SDS is 6.4 fp24   (in the coming months we will migrate to IVIG 11)

First, look at all the orgRole entries as I see them in LDAP (allRoles.png).
All roles have a DN ending with "DC=COM" (uppercase).

Now look at the erroles attribute of a person (personErroles.png).
Only one role ends with "DC=COM", while all the others end with "dc=com".

Well, the uppercase role is the one that shows the issue.
If edited directly in LDAP, it behaves correctly.

Now I need to run some additional checks (I'll keep you posted), because these problematic roles show a very similar (in my opinion identical) issue when the removal is requested via Java API as well.
In particular, this method:

com.ibm.itim.dataservices.model.domain.Person.removeRole(DistinguishedName roleDN)

seems to suffer from the same problem.

I still need to complete a few more checks and I will be sure to update you.

------------------------------
Andrea Gatto


Original Message:
Sent: Wed February 25, 2026 06:48 AM
From: Franz Wolfhagen
Subject: Mysterious role behaviour

That would be great - then I can debug it in my own systems.

------------------------------
Franz Wolfhagen
WW IAM Solution Architect - Certified Consulting IT Specialist
IBM Expert Labs


Original Message:
Sent: Wed February 25, 2026 06:40 AM
From: Andrea Gatto
Subject: Mysterious role behaviour

I've found a way to make the error reproducible, and I guess it may be a bug.

I'll shortly post something more

------------------------------
Andrea Gatto


Original Message:
Sent: Wed February 25, 2026 06:19 AM
From: Franz Wolfhagen
Subject: Mysterious role behaviour

What you would like to check is the data services person - put that to DEBUG level in your logging properties.

The real problem here is whether you can provoke the error consistently - my theory is that the Role Composition UI is handling this wrong - maybe because of shadowing some data to rdbms tables and loosing synch somehow. 

I have not debugged the Role Composition yet so I have to guess right now - but the best advice I can give you is to get a case out of the door...

HTH 

------------------------------
Franz Wolfhagen
WW IAM Solution Architect - Certified Consulting IT Specialist
IBM Expert Labs


Original Message:
Sent: Wed February 25, 2026 03:43 AM
From: Andrea Gatto
Subject: Mysterious role behaviour

Ciao Mita,

In fact, that was my first thought as well.
But the invoked operation is always the same (modify person).
What changes is that if it's invoked from the role members list, no changes to the person's erroles attribute are detected.
If, on the other hand, the role is removed directly from the person, then the removal works.

And I still can't understand why this anomalous behavior occurs for a certain "bad" role, while for another role everything works as expected.

Okay regarding the logs to monitor, but which packages should be set to a higher level in order to try to catch some clues?

Thanks, as always.
And if I find out anything, of course I'll post it here.

------------------------------
Andrea Gatto


Original Message:
Sent: Tue February 24, 2026 12:41 PM
From: Mita Mitic
Subject: Mysterious role behaviour

Hi,

You may want to check if there is some logic inside operational workflow of person modify where actual extension is skipped under some circumstances.

Other than that - trace.log, msg.log 

Hope this helps.

Mita

------------------------------
Mita Mitic