IBM Security Verify

Hi,

I have simple request to run a LCR to find active accounts that belongs to inactive persons, and then to execute action on them.

So I put a filter:

(&(${owner.erpersonstatus}=1)(eraccountstatus=0))

And it works fine,

but up to some point, like maybe up to 2000 inactive persons.

After, it does not work anymore - I can observe errors in IM trace log - invalid filter with huge string that shows it compares an account against every inactive person. I got error in LDAP - db2cli log of Ldap's DB2 says not enough storage or heap for AGENT_STACK_SZ.

I've tried fiddling with AGENT_STACK_SZ. of Ldap's DB2, no help.

Is it possible to create better filter that will do the same thing but will not exhaust system resources?

Thanks,

Mita 

I am afraid to tell you that this is an RTFM :-) 

The relevant section is https://www.ibm.com/docs/en/sig-and-i/10.0.0?topic=expressions-known-limitations

I just ran into the same limitation myself recently - basically there are 2 ways this can be solved - either doing this as a "paged approach" to get the relevant entities from the ldap or implementing the relationship relation as a custom search extension in ldap server. But I do not see any plans to do either (and I know that the first option was approached by a customer case earlier with no success).

I suggest you raise an Idea for this.

As an actual solution you can do run without a filter and filter in the process - this is of course not a real solution but just a workaround.

HTH

Hi,

I have simple request to run a LCR to find active accounts that belongs to inactive persons, and then to execute action on them.

So I put a filter:

(&(${owner.erpersonstatus}=1)(eraccountstatus=0))

And it works fine,

but up to some point, like maybe up to 2000 inactive persons.

After, it does not work anymore - I can observe errors in IM trace log - invalid filter with huge string that shows it compares an account against every inactive person. I got error in LDAP - db2cli log of Ldap's DB2 says not enough storage or heap for AGENT_STACK_SZ.

I've tried fiddling with AGENT_STACK_SZ. of Ldap's DB2, no help.

Is it possible to create better filter that will do the same thing but will not exhaust system resources?

Thanks,

Mita 

I am reading it, I swear! It just this, used to work for years, then it stopped working, at some point.

Thanks for pointing me to the known limitation - I know now it won't work this way, so I will try to cut it in pieces, or something. I will post here if I solve it, one way or another.

Thanks!

Mita

I am afraid to tell you that this is an RTFM :-) 

The relevant section is https://www.ibm.com/docs/en/sig-and-i/10.0.0?topic=expressions-known-limitations

I just ran into the same limitation myself recently - basically there are 2 ways this can be solved - either doing this as a "paged approach" to get the relevant entities from the ldap or implementing the relationship relation as a custom search extension in ldap server. But I do not see any plans to do either (and I know that the first option was approached by a customer case earlier with no success).

I suggest you raise an Idea for this.

As an actual solution you can do run without a filter and filter in the process - this is of course not a real solution but just a workaround.

HTH

Hi,

I have simple request to run a LCR to find active accounts that belongs to inactive persons, and then to execute action on them.

So I put a filter:

(&(${owner.erpersonstatus}=1)(eraccountstatus=0))

And it works fine,

but up to some point, like maybe up to 2000 inactive persons.

After, it does not work anymore - I can observe errors in IM trace log - invalid filter with huge string that shows it compares an account against every inactive person. I got error in LDAP - db2cli log of Ldap's DB2 says not enough storage or heap for AGENT_STACK_SZ.

I've tried fiddling with AGENT_STACK_SZ. of Ldap's DB2, no help.

Is it possible to create better filter that will do the same thing but will not exhaust system resources?

Thanks,

Mita 

This is IMHO a stupid implementation as it builds up a filter with all the values of the relationship - and the ldap filter has limitation. I do not remember whether that was fixed in later ISDS releases - but we had the problem with a windows SDS having a significantly smaller filter size limitation than the linux/AIX ones (4K vs 64K IIRC) so on windows you would hit that limitation much faster than on linux (or the SDS VA)...

You could argue that an ldap filter size limitation is not really relevant - but I think for all practical (non-stupid) use cases the limitation is not a real problem :-)  - but from a purist PoV this of course should not be there...

I am reading it, I swear! It just this, used to work for years, then it stopped working, at some point.

Thanks for pointing me to the known limitation - I know now it won't work this way, so I will try to cut it in pieces, or something. I will post here if I solve it, one way or another.

Thanks!

Mita

I am afraid to tell you that this is an RTFM :-) 

The relevant section is https://www.ibm.com/docs/en/sig-and-i/10.0.0?topic=expressions-known-limitations

I just ran into the same limitation myself recently - basically there are 2 ways this can be solved - either doing this as a "paged approach" to get the relevant entities from the ldap or implementing the relationship relation as a custom search extension in ldap server. But I do not see any plans to do either (and I know that the first option was approached by a customer case earlier with no success).

I suggest you raise an Idea for this.

As an actual solution you can do run without a filter and filter in the process - this is of course not a real solution but just a workaround.

HTH

Hi,

I have simple request to run a LCR to find active accounts that belongs to inactive persons, and then to execute action on them.

So I put a filter:

(&(${owner.erpersonstatus}=1)(eraccountstatus=0))

And it works fine,

but up to some point, like maybe up to 2000 inactive persons.

After, it does not work anymore - I can observe errors in IM trace log - invalid filter with huge string that shows it compares an account against every inactive person. I got error in LDAP - db2cli log of Ldap's DB2 says not enough storage or heap for AGENT_STACK_SZ.

I've tried fiddling with AGENT_STACK_SZ. of Ldap's DB2, no help.

Is it possible to create better filter that will do the same thing but will not exhaust system resources?

Thanks,

Mita 

I prefer to use the SDI instead of LCR always to have better control, also audit records also very neat and clean.

This is IMHO a stupid implementation as it builds up a filter with all the values of the relationship - and the ldap filter has limitation. I do not remember whether that was fixed in later ISDS releases - but we had the problem with a windows SDS having a significantly smaller filter size limitation than the linux/AIX ones (4K vs 64K IIRC) so on windows you would hit that limitation much faster than on linux (or the SDS VA)...

You could argue that an ldap filter size limitation is not really relevant - but I think for all practical (non-stupid) use cases the limitation is not a real problem :-)  - but from a purist PoV this of course should not be there...

I am reading it, I swear! It just this, used to work for years, then it stopped working, at some point.

Thanks for pointing me to the known limitation - I know now it won't work this way, so I will try to cut it in pieces, or something. I will post here if I solve it, one way or another.

Thanks!

Mita

I am afraid to tell you that this is an RTFM :-) 

The relevant section is https://www.ibm.com/docs/en/sig-and-i/10.0.0?topic=expressions-known-limitations

I just ran into the same limitation myself recently - basically there are 2 ways this can be solved - either doing this as a "paged approach" to get the relevant entities from the ldap or implementing the relationship relation as a custom search extension in ldap server. But I do not see any plans to do either (and I know that the first option was approached by a customer case earlier with no success).

I suggest you raise an Idea for this.

As an actual solution you can do run without a filter and filter in the process - this is of course not a real solution but just a workaround.

HTH

Hi,

I have simple request to run a LCR to find active accounts that belongs to inactive persons, and then to execute action on them.

So I put a filter:

(&(${owner.erpersonstatus}=1)(eraccountstatus=0))

And it works fine,

but up to some point, like maybe up to 2000 inactive persons.

After, it does not work anymore - I can observe errors in IM trace log - invalid filter with huge string that shows it compares an account against every inactive person. I got error in LDAP - db2cli log of Ldap's DB2 says not enough storage or heap for AGENT_STACK_SZ.

I've tried fiddling with AGENT_STACK_SZ. of Ldap's DB2, no help.

Is it possible to create better filter that will do the same thing but will not exhaust system resources?

Thanks,

Mita