NOTICE: COMMUNITY PERFORMANCE DEGRADATION
Our community is currently experiencing some performance degradation with slow page loading. Our platform SaaS vendor is working on the issue.
Highlighted
Absent Member.
Absent Member.
369 views

Bi-directiona edir2edir driver not base context issues

Hello All, please bare with me. We have the Bi-Directional edir2edir drivcer configured, and it is running and talking to the connected edirectory server. However we are having a weird issue. I have a base container called:
o=nlsd this exists on idm, and also exists on the server we want to sync (edir). For the Base context in the driver we configured o=nlsd. We start the driver, turn on ndstrace and run a sync, and we can see that indeed idm is talking to the connected edir server with the driver, however, even though we have NO COMMA in the base specified contect we keep see this:

3179341568 LDAP: [2019/03/04 9:47:11.681] Illegal ndsname ",o=nlsd" in ldap2uND
SDN, err = 34 (0x22)
3179341568 LDAP: [2019/03/04 9:47:11.681] ldap2uNDSDN ldapDN = ",o=nlsd" - erro
r 34 (0x22)
3179341568 LDAP: [2019/03/04 9:47:11.681] nds_back_search: ldap2uNDSDN failed w
ith err 34 (0x22)
3611682560 LDAP: [2019/03/04 9:47:11.732] BIO ctrl called with unknown cmd 7
3668465408 LDAP: [2019/03/04 9:47:11.736] Illegal ndsname ",o=nlsd" in ldap2uND
SDN, err = 34 (0x22)
3668465408 LDAP: [2019/03/04 9:47:11.736] ldap2uNDSDN ldapDN = ",o=nlsd" - erro
r 34 (0x22)
3668465408 LDAP: [2019/03/04 9:47:11.736] dn2urdn failed for ",o=nlsd" - cannot
add, err = 34 (0x22)

I have reconfigured the driver and checked the context MANY time, we do not have a comma in this field, as well, we tried several different ways od specifying the base DN, and when talking the driver ALWAYS adds the comma....can anyone help with this, and tell us why this is happening upon sync? Are base syntax seems correct.
Labels (1)
0 Likes
5 Replies
Highlighted
Knowledge Partner
Knowledge Partner

Re: Bi-directiona edir2edir driver not base context issues

We can definitely see what you see, but it would be helpful to see the IDM
driver config's startup trace, level three (3) or higher, so we can see
what configuration parameters may eventually lead to this. That trace
will be taken from the engine side, of course.

Is this the first time, ever, you've set this up? Is it possible you set
it up once, tor it down, and did it again on the engine side, possibly
leaving pieces behind somewhere which are hard to find?


--
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
Highlighted
Absent Member.
Absent Member.

Re: Bi-directiona edir2edir driver not base context issues

Here is a deeper LDAP trace from the connected system in a paste bin. With extended trace on, we can see that for some reason the base scope from the driver is being recorded as ",o=nlsd" I havve went into the driver cinfiguration several time and it is definatly o=nlsd, NOT ,o=nlsd....so I'm not sure where it's grabbing this from. Here is a trace form the connected system:
https://pastebin.com/zcUk7HG8 (this is from the connected server running change-log drvier)

IDM emgine/server travce with follow with hiher trace options on.
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

Re: Bi-directiona edir2edir driver not base context issues

Is the driver config trace (from the engine side) not an option to be
posted? You should be able to set a trace level (three (3) or higher) and
a trace file on the IDM server itself (e.g.
/var/log/idm/driver-object-name.trace) after creating the /var/log/idm
directory and then it will start writing immediately. Restart the object
and the output there can be very useful.

--
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
Highlighted
Absent Member.
Absent Member.

Re: Bi-directiona edir2edir driver not base context issues

Drive Trace, log value of 3:

https://drive.google.com/file/d/1jhbxPxYyfDEe4ZHzVEpdZ2geze30uoXW/view

This sticks out, but I don't know how to fix it:
[03/04/19 13:07:57.076]:edir2edir ST:Applying policy: %+C%14CNOVLEDIR2DFC-sub-mp%-C.
[03/04/19 13:07:57.077]:edir2edir ST: Applying to add #1.
[03/04/19 13:07:57.077]:edir2edir ST: Evaluating selection criteria for rule 'veto out-of-scope events'.
[03/04/19 13:07:57.077]:edir2edir ST: (if-op-property 'attempt-to-match' not-available) = FALSE.
[03/04/19 13:07:57.077]:edir2edir ST: (if-op-property 'attempt-to-match' equal "false") = FALSE.
[03/04/19 13:07:57.077]:edir2edir ST: Rule rejected.
[03/04/19 13:07:57.077]:edir2edir ST: Evaluating selection criteria for rule 'Store the target container'.
[03/04/19 13:07:57.078]:edir2edir ST: (if-global-variable 'drv.edir.base.container' not-equal "") = TRUE.
[03/04/19 13:07:57.078]:edir2edir ST: Rule selected.
[03/04/19 13:07:57.078]:edir2edir ST: Applying rule 'Store the target container'.
[03/04/19 13:07:57.078]:edir2edir ST: Action: do-set-local-variable("edirBaseContainer",","+token-global-variable("drv.edir.base.container")).
[03/04/19 13:07:57.078]:edir2edir ST: arg-string(","+token-global-variable("drv.edir.base.container"))
[03/04/19 13:07:57.079]:edir2edir ST: token-text(",")
[03/04/19 13:07:57.079]:edir2edir ST: token-global-variable("drv.edir.base.container")
[03/04/19 13:07:57.079]:edir2edir ST: Token Value: "o=nlsd".
[03/04/19 13:07:57.079]:edir2edir ST: Arg Value: ",o=nlsd".
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

Re: Bi-directiona edir2edir driver not base context issues

On 03/04/2019 01:44 PM, Techlord wrote:
>
> Drive Trace, log value of 3:
>
> https://drive.google.com/file/d/1jhbxPxYyfDEe4ZHzVEpdZ2geze30uoXW/view


Thanks, that helps, especially since this section of the trace did not
include the operation document leading to this point, so it was not enough
to provide a root cause for the symptom.

Looking in the full trace I see the message you reported when you first
tried to migrate a container under the system container. Because this
container is not within the 'nlsd' container at the top of the tree, the
"unmatched-src-dn" is zero-length, and because it is not a user or group
object you hit the "match everything else" rule, which tries to put the
source object's unmatched-src-dn in front of the remote tree's base; the
former being latter, and the latter being o=nlsd, means you end up with
",o=nlsd", which is what you see in trace with the LDAP errors.

The next event I see in trace is for a test user under the data container
(data\users\test), which is not part of the base context set to sync from
the engine to the remote tree, so that gets vetoed.

A ton of events go through for invalid objects which are all vetoed, then
the organization goes through again with the same result as above.

After a bunch of other invalid objects fail, the last thing I see is an
attempt for the heartbeat to happen, which fails with a protocol error.
My only guess at why is that the changelog module is not working properly
on the remote side, though I'm not sure why that would be.

At the end of the day, it may be that the base container on the vault side
is mis-configured. The idv.idt.data.users global configuration variable
perhaps should be 'data' instead of 'nlsd', since 'nlsd' is the remote
tree's base container, and there are clearly users, even test users, in
the more-cmmon-for-a-vault 'data' base context.

--
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
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.