Highlighted
Absent Member.
Absent Member.
1488 views

No CN on LDAP driver default policy

I got past the connection issue I was having in a previous post but now am having a policy issue. In the creation transform, the default policy for the LDAP driver has a ruled named "User Required Attributes" that will veto if the operational attribute CN is not available. My trace shows that is the policy that is vetoing the operation. I did a trace output message right before that rule and the CN is indeed empty but I don't know why. The object I am testing with definitely has a CN attribute. I can disable the rule but then I get the same issue with the nspmDistributionPassword. I checked the filter and the schema mapping. They are mapped and set to synchronize in the filter properly by default. I don't know why this default policy doesn't seem to be working. I'm just trying to set up basic replication to openLDAP. Any suggestions?
Labels (1)
0 Likes
21 Replies
Highlighted
Knowledge Partner
Knowledge Partner

On 10/15/2018 7:44 PM, bobbintb wrote:
>
> I meant "uniqueID=testuser,OU=People,OU=cp" gets turned into
> "uid=queID=testuser,OU=People,OU=cp".


For somereason you have a token-substring, stripping off the first three
characters. So uniqueID becomes queID which is weird.

Should be ParseDN of length 1, start -1 to get the testuser out of it.
And then build a DN that makes sense for your LDAP.



0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

On 10/15/2018 03:54 PM, bobbintb wrote:
>
> It looks like the default policy is not constructing the DN properly. It
> is returning ",o=lp5" because the token property "unmatched-src-dn" has
> no value. I don't know how to fix this.


unmatched-src-dn is an interesting token in that it only works based on
the most-recent call to if-src-dn, so if you accidentally disabled that,
usually in a matching policy, then that would explain things:

https://www.netiq.com/documentation/identity-manager-developer/dtd-documentation/dirxmlscript/token-unmatched-src-dn.html

This is not intuitive, at all, so it is a good question to ask.

I think you have found your original issue, so a new thread for your other
issue may be in order as you suggested, but otherwise you may want to
explain a bit more about what you have done to make changes to the
matching policy. I specifically mean this part from your recent trace
snippet:


16:41:18 F5DE1700 Drvrs: Luminis ST: Action:
do-find-matching-object(scope="entry",arg-dn("uid="+token-substring(start="3",token-op-property("unmatched-src-dn"))+","+token-global-variable("driver.ldap.base.container"))).
16:41:18 F5DE1700 Drvrs: Luminis ST:
arg-dn("uid="+token-substring(start="3",token-op-property("unmatched-src-dn"))+","+token-global-variable("driver.ldap.base.container"))
16:41:18 F5DE1700 Drvrs: Luminis ST: token-text("uid=")
16:41:18 F5DE1700 Drvrs: Luminis ST:
token-substring(start="3",token-op-property("unmatched-src-dn"))
16:41:18 F5DE1700 Drvrs: Luminis ST:
token-substring(start="3",token-op-property("unmatched-src-dn"))
16:41:18 F5DE1700 Drvrs: Luminis ST: token-op-property("unmatched-src-dn")
16:41:18 F5DE1700 Drvrs: Luminis ST: Token Value:
"uniqueID=testuser,OU=People,OU=cp".
16:41:18 F5DE1700 Drvrs: Luminis ST: Arg Value:
"uniqueID=testuser,OU=People,OU=cp".
16:41:18 F5DE1700 Drvrs: Luminis ST: Token Value:
"queID=testuser,OU=People,OU=cp".
16:41:18 F5DE1700 Drvrs: Luminis ST: token-text(",")
16:41:18 F5DE1700 Drvrs: Luminis ST:
token-global-variable("driver.ldap.base.container")
16:41:18 F5DE1700 Drvrs: Luminis ST: Token Value: "o=lp5".
16:41:18 F5DE1700 Drvrs: Luminis ST: Arg Value:
"uid=queID=testuser,OU=People,OU=cp,o=lp5".


Notice that you have a token-substring call in there which is stripping
off the first three characters of your DN. Of course, maybe that's
default, since normally that would nicely strip off 'cn=', but you are
using the uniqueID attribute as your naming attribute, so it's pretty
sloppy if that was what was shipped since you could easily use the DN
parsing methods to more-easily get this. Either way, you could probably
most-easily fix it by changing the '3', in the substring token to '7'
since that is the character length of 'uniqueID='.


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

Yes, I had noticed "start 3" thing after the fact and have held off on creating a new thread until I get stuck on that. I can find that actual policy though; it's not in the placement transform. I'll just have to go back and look at another trace now that I have more info but my hunch is that adding "uid" to the filter somehow screwed up the schema mapping. I didn't realize "uniqueID" was already in the filter so I added "uid". I know eDir uses "uniqueID" as an alias for "uid" or does some sort of magic with it. Since there doesn't seem to be a policy that does the substring strip (I'll have to double check), I'm thinking having "uid" and "uniqueID" both in the filter messed things up on the backend. Anyway, if that's not it and I can't locate the policy anywhere then I'll open a new thread. I've been too quick too post lately anyhow and just need to slow down.
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

On 10/15/2018 5:54 PM, bobbintb wrote:
>
> It looks like the default policy is not constructing the DN properly. It
> is returning ",o=lp5" because the token property "unmatched-src-dn" has
> no value. I don't know how to fix this.


In the Match policy set, the first rule, in most NetIQ provided policies
uses the If SourceDN in subtree, usually ~idv.dit.data.users~ so it
checks against a GCV.

Then inside that IF block (I THINK it works inside the entire Policy
object but not after that) you can Set Op Property unmatched-src-dn with
the noun token Unmatched Source DN. This returns the value.

If my users is
o\ou1\ou2\ou3\geoffc

And my idv.dit.data.users is o\ou1 then the unmatched source dn is
ou2\ou3\geoffc

This tells me where the user is, relative to where I defined users as
starting from.

ParseDN for length 1, start at -1 will get you the geoffc part.



0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

>
> Then things go sideways in the matching rule, but that's probably a
> result of whatever it was that you disabled. It's trying to parse data
> that isn't there, which then fails. Go enable it again.


Also no Placement rule, so that is why no dest DN that I can see.


0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

On 10/15/2018 3:44 PM, bobbintb wrote:
> 13:37:49 F5DE1700 Drvrs: Luminis ST: Action: do-find-matching-object(scope="entry",arg-dn("uid="+token-substring(start="3",token-op-property("unmatched-src-dn"))+","+token-global-variable("driver.ldap.base.container"))).


Why is your match rule, using substring here? (To remove the CN=? Odd)
Also, unmatched-src-dn as an operation property is not being set by the
normally previous rule. Most NetIQ packages come with this as the first
policy in the Match rules.

If you do a condition, with a if sourceDN in subtree, and then inside
you can use the Unmatched Src DN noun token, to get the value, and set
that into an op-property.

That is where it is trying to get the CN value from for the query at
least and failing.
0 Likes
Highlighted
Absent Member.
Absent Member.

geoffc;2489871 wrote:
On 10/15/2018 3:44 PM, bobbintb wrote:
> 13:37:49 F5DE1700 Drvrs: Luminis ST: Action: do-find-matching-object(scope="entry",arg-dn("uid="+token-substring(start="3",token-op-property("unmatched-src-dn"))+","+token-global-variable("driver.ldap.base.container"))).


Why is your match rule, using substring here? (To remove the CN=? Odd)
Also, unmatched-src-dn as an operation property is not being set by the
normally previous rule. Most NetIQ packages come with this as the first
policy in the Match rules.

If you do a condition, with a if sourceDN in subtree, and then inside
you can use the Unmatched Src DN noun token, to get the value, and set
that into an op-property.

That is where it is trying to get the CN value from for the query at
least and failing.


That's just the way the rule is by default, with the substring. I guess it was trying to strip 'cn='. I thought it weird as well and it's has caused other problems until I fixed it. The issue as I recall was that unmatched-src-dn was not being set. I think there was another default rule I disabled that set unmatched-src-dn. It might have been causing another issue, I don't recall. It's been corrected. There are a few default rules that have not seemed to have worked out as intended so it's taken some trial and error.
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

On 10/31/2018 11:04 AM, bobbintb wrote:
>
> geoffc;2489871 Wrote:
>> On 10/15/2018 3:44 PM, bobbintb wrote:
>>> 13:37:49 F5DE1700 Drvrs: Luminis ST: Action:

>> do-find-matching-object(scope="entry",arg-dn("uid="+token-substring(start="3",token-op-property("unmatched-src-dn"))+","+token-global-variable("driver.ldap.base.container"))).
>>
>> Why is your match rule, using substring here? (To remove the CN=? Odd)
>> Also, unmatched-src-dn as an operation property is not being set by the
>> normally previous rule. Most NetIQ packages come with this as the first
>> policy in the Match rules.
>>
>> If you do a condition, with a if sourceDN in subtree, and then inside
>> you can use the Unmatched Src DN noun token, to get the value, and set
>> that into an op-property.
>>
>> That is where it is trying to get the CN value from for the query at
>> least and failing.

>
> That's just the way the rule is by default, with the substring. I guess
> it was trying to strip 'cn='. I thought it weird as well and it's has
> caused other problems until I fixed it. The issue as I recall was that
> unmatched-src-dn was not being set. I think there was another default
> rule I disabled that set unmatched-src-dn. It might have been causing
> another issue, I don't recall. It's been corrected. There are a few
> default rules that have not seemed to have worked out as intended so
> it's taken some trial and error.


Agreed, it is usually set in the first Match policy. Also it sets op
property of attempt-to-match which there is a Veto policy if not set.

This is how NetIQ handled the idea of using Entitlements, or not, and
allowing you to leverage in different types of entitlements, without
stomping on each other or duplicating policies that might collide.


0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

On 10/31/2018 11:04 AM, bobbintb wrote:
>
> geoffc;2489871 Wrote:
>> On 10/15/2018 3:44 PM, bobbintb wrote:
>>> 13:37:49 F5DE1700 Drvrs: Luminis ST: Action:

>> do-find-matching-object(scope="entry",arg-dn("uid="+token-substring(start="3",token-op-property("unmatched-src-dn"))+","+token-global-variable("driver.ldap.base.container"))).
>>
>> Why is your match rule, using substring here? (To remove the CN=? Odd)
>> Also, unmatched-src-dn as an operation property is not being set by the
>> normally previous rule. Most NetIQ packages come with this as the first
>> policy in the Match rules.
>>
>> If you do a condition, with a if sourceDN in subtree, and then inside
>> you can use the Unmatched Src DN noun token, to get the value, and set
>> that into an op-property.
>>
>> That is where it is trying to get the CN value from for the query at
>> least and failing.

>
> That's just the way the rule is by default, with the substring. I guess
> it was trying to strip 'cn='. I thought it weird as well and it's has
> caused other problems until I fixed it. The issue as I recall was that
> unmatched-src-dn was not being set. I think there was another default
> rule I disabled that set unmatched-src-dn. It might have been causing
> another issue, I don't recall. It's been corrected. There are a few
> default rules that have not seemed to have worked out as intended so
> it's taken some trial and error.


Oh and the substring of 3 is really odd, but ya, ParseDN is the proper
way not substring, that is just a dumb default approach. Be a nice Bug
to enter to fix in the package.


0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

On 10/31/2018 11:04 AM, bobbintb wrote:
>
> geoffc;2489871 Wrote:
>> On 10/15/2018 3:44 PM, bobbintb wrote:
>>> 13:37:49 F5DE1700 Drvrs: Luminis ST: Action:

>> do-find-matching-object(scope="entry",arg-dn("uid="+token-substring(start="3",token-op-property("unmatched-src-dn"))+","+token-global-variable("driver.ldap.base.container"))).
>>
>> Why is your match rule, using substring here? (To remove the CN=? Odd)
>> Also, unmatched-src-dn as an operation property is not being set by the
>> normally previous rule. Most NetIQ packages come with this as the first
>> policy in the Match rules.
>>
>> If you do a condition, with a if sourceDN in subtree, and then inside
>> you can use the Unmatched Src DN noun token, to get the value, and set
>> that into an op-property.
>>
>> That is where it is trying to get the CN value from for the query at
>> least and failing.

>
> That's just the way the rule is by default, with the substring. I guess
> it was trying to strip 'cn='. I thought it weird as well and it's has
> caused other problems until I fixed it. The issue as I recall was that
> unmatched-src-dn was not being set. I think there was another default
> rule I disabled that set unmatched-src-dn. It might have been causing
> another issue, I don't recall. It's been corrected. There are a few
> default rules that have not seemed to have worked out as intended so
> it's taken some trial and error.


Yep it really does do the Substring in the base package. Interstingly in
the third policy they use SourceDN token, with convert and use the
ParseDN implied in there to do it.

That is a bad choice in that package.


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.