Knowledge Partner
Knowledge Partner
624 views

Where do supportedExtension values come from?

I have an eDir 9.0.4 server that is missing a bunch of supportedExtension values, like 2.16.840.1.113719.1.148.100.3. Going by the docs, this was added in eDir 8.5, so 9.* should have it, I'd think, but RootDSE claims otherwise.

No, don't know the history of the box. Parachuted in to working on a dead UserApp issue. UserApp / configupdate.sh won't work, because 2.16.840.1.113719.1.148.100.3 is missing.
Labels (1)
0 Likes
9 Replies
Knowledge Partner
Knowledge Partner

Re: Where do supportedExtension values come from?

Docs: https://www.novell.com/documentation/developer/ldapover/ldap_enu/data/a6ik7oi.html?view=print

2.16.840.1.113719.1.148.100.3 SSLDAP_READ_SECRET_REQUEST


Also, TID 7016946 - Tried. Did not work. Still don't have the needed extension(s) listed.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Where do supportedExtension values come from?

I believe they are stored on the LDAP Server object to which the current
system is linked in a multi-valued attribute which stores both the request
and response OIDs. You can hack them in, if you have the base64-encoding
bits worked out, which means you can pull them from another server.

I do not remember if I ever figured out perfectly how they came to exist
in the first place, whether it was the appropriate module loading (e.g.
ldapxs or nldap, or whatever), or if it was an installer, or something
else, but I know I used to copy them from one server to another, e.g. in
order t make Universal Password (UP) work properly. If you have a working
box (with those extensions), LDIF out the values from there (both request
and its matching response, usually one integer higher in the last position
in the OID, so 1.16.840.113719.1.148.100.4 for you) and LDIF them into the
box where you need it.

Just to be sure, you are pointing to the box hosting the IDM engine and
UserApp driver, right? This may be one of those reasons that you MUST (no
really) point the UserApp to the correct engine box. If that's all, it is
silly, but it may be one of many other better reasons.


--
Good luck.

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

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

Re: Where do supportedExtension values come from?

ab;2484202 wrote:
I believe they are stored on the LDAP Server object to which the current
system is linked in a multi-valued attribute which stores both the request
and response OIDs. You can hack them in, if you have the base64-encoding
bits worked out, which means you can pull them from another server.


I considered doing that, but it seemed that if the extension info attribute is missing, that whatever support it's intending to indicate probably isn't there either.


ab;2484202 wrote:

I do not remember if I ever figured out perfectly how they came to exist
in the first place, whether it was the appropriate module loading (e.g.
ldapxs or nldap, or whatever), or if it was an installer, or something
else, but I know I used to copy them from one server to another, e.g. in
order t make Universal Password (UP) work properly. If you have a working
box (with those extensions), LDIF out the values from there (both request
and its matching response, usually one integer higher in the last position
in the OID, so 1.16.840.113719.1.148.100.4 for you) and LDIF them into the
box where you need it.


Looking at the extension attribute on the LDAP server, 1.16.840.113719.1.148.100.3 and 1.16.840.113719.1.148.100.4 seem to reference "lsss". I checked, and module lsss was not loaded. So I loaded it. That seemed to be ok, now it says it's loaded, but nothing changed on the Root DSE or the LDAP Server object.


ab;2484202 wrote:

Just to be sure, you are pointing to the box hosting the IDM engine and
UserApp driver, right? This may be one of those reasons that you MUST (no
really) point the UserApp to the correct engine box. If that's all, it is
silly, but it may be one of many other better reasons.


Yes, same server. I've not even gotten to the UserApp itself yet. It doesn't work now. Just trying to get its configupdate.sh script to work first.


--
Good luck.

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

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

Re: Where do supportedExtension values come from?

On 07/17/2018 04:04 PM, dgersic wrote:
>
> I considered doing that, but it seemed that if the extension info
> attribute is missing, that whatever support it's intending to indicate
> probably isn't there either.


I agree with your logic, but reality does not work that way sometimes. I
remember learning a fair bit about line folding thanks to those values'
length as I was moving them from one server to another. At the end of the
day, I think 'ndsconfig' is supposed to add them, e.g. when you add that
"newer" NMAS stuff, or some other module, to an eDiretory instance, since
otherwise every load/unload of eDirectory would need to possibly change
those values, and that's probably wasteful . That they are not getting
loaded automatically for you is silly, but I've seen it happen a million
times before, though admittedly not since eDirectory 8.7, or maybe the
early 8.8.x stuff at the latest; it's been a long time, and in those days
it was always the 'Set Universal Password' task in iManager would give an
error about not being able to do what it needed to.


--
Good luck.

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

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

Re: Where do supportedExtension values come from?

ab;2484202 wrote:
I believe they are stored on the LDAP Server object to which the current
system is linked in a multi-valued attribute which stores both the request
and response OIDs. You can hack them in, if you have the base64-encoding
bits worked out, which means you can pull them from another server.


So, for future reference ... no, you can't. Well, you can. You can LDIF in the relevant missing extension values:


E#2.16.840.1.113719.1.148.100.1#2.16.840.1.113719.1.148.100.2#lsss
E#2.16.840.1.113719.1.148.100.3#2.16.840.1.113719.1.148.100.4#lsss
E#2.16.840.1.113719.1.148.100.5#2.16.840.1.113719.1.148.100.6#lsss
E#2.16.840.1.113719.1.148.100.7#2.16.840.1.113719.1.148.100.8#lsss
E#2.16.840.1.113719.1.148.100.9#2.16.840.1.113719.1.148.100.10#lsss
E#2.16.840.1.113719.1.148.100.11#2.16.840.1.113719.1.148.100.12#lsss
E#2.16.840.1.113719.1.148.100.13#2.16.840.1.113719.1.148.100.14#lsss
E#2.16.840.1.113719.1.148.100.15#2.16.840.1.113719.1.148.100.16#lsss
E#2.16.840.1.113719.1.148.100.17#2.16.840.1.113719.1.148.100.18#lsss


(Note, these values are actually NUL terminated strings, so they need to be base64 encoded.)

but, then after you do that, nldap will no longer initialize. It loads, and dies:


load nldap:
241469184 LDAP: [2018/07/18 11:14:23.962] Waiting for 0 worker threads, 0 monitor threads, and 0 misc threads to terminate
241469184 LDAP: [2018/07/18 11:14:23.962] Deallocating list of search rewriter callbacks
241469184 LDAP: [2018/07/18 11:14:23.962] Deallocating list of computed attribute evaluators
241469184 LDAP: [2018/07/18 11:14:23.962] Deallocating list of value translation callbacks
241469184 LDAP: [2018/07/18 11:14:23.962] LDAP Agent for NetIQ eDirectory 9.0.4 (40006.36) stopped
0 Likes
Knowledge Partner
Knowledge Partner

Re: Where do supportedExtension values come from?

dgersic;2484279 wrote:
So, for future reference ... no, you can't. Well, you can. You can LDIF in the relevant missing extension values:


Updated: I deleted / recreated the LDAP Server / LDAP Group objects again. Then LDIF'd in these values again, and now nldap will load and initialize. That got configupdate.sh to work, at least I think it worked. It seems to store its data ok, and I see it doing a bunch of stuff over LDAP now (ndstrace +LDAP) that it wouldn't do before.

So, progress. Now to figure out what the *&$^#@$ UserApp itself is complaining about. But that's for a different forum.

I'd still like to know how this is supposed to work. And what the '-641' errors I get from "ndsconfig upgrade" and "ssscfg -c" are coming from.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Where do supportedExtension values come from?

On 07/18/2018 10:54 AM, dgersic wrote:
>
> dgersic;2484279 Wrote:
>> So, for future reference ... no, you can't. Well, you can. You can LDIF
>> in the relevant missing extension values:

>
> Updated: I deleted / recreated the LDAP Server / LDAP Group objects
> again. Then LDIF'd in these values again, and now nldap will load and
> initialize. That got configupdate.sh to work, at least I think it
> worked. It seems to store its data ok, and I see it doing a bunch of
> stuff over LDAP now (ndstrace +LDAP) that it wouldn't do before.


Thanks for sharing your results; it's nice to know some steps that still work.

--
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
Micro Focus Expert
Micro Focus Expert

Re: Where do supportedExtension values come from?

On 2018-07-17 22:44, dgersic wrote:
>
> Docs:
> https://www.novell.com/documentation/developer/ldapover/ldap_enu/data/a6ik7oi.html?view=print
>
> 2.16.840.1.113719.1.148.100.3 SSLDAP_READ_SECRET_REQUEST


Did you install and configure secret store?
https://www.netiq.com/documentation/identity-manager-46/setup/data/b18c7efb.html#b1ed9595

>
>
> Also, TID 7016946 - Tried. Did not work. Still don't have the needed
> extension(s) listed.
>
>



--
Norbert
0 Likes
Knowledge Partner
Knowledge Partner

Re: Where do supportedExtension values come from?

klasen;2484227 wrote:
On 2018-07-17 22:44, dgersic wrote:
>
> Docs:
> https://www.novell.com/documentation/developer/ldapover/ldap_enu/data/a6ik7oi.html?view=print
>
> 2.16.840.1.113719.1.148.100.3 SSLDAP_READ_SECRET_REQUEST


Did you install and configure secret store?
https://www.netiq.com/documentation/identity-manager-46/setup/data/b18c7efb.html#b1ed9595

>
>
> Also, TID 7016946 - Tried. Did not work. Still don't have the needed
> extension(s) listed.
>
>



--
Norbert


Well, I didn't install this, but it appears that the schema is there:


Source Handler: ICE SCH Data handler for NetIQ eDirectory (version: 40006.34 )
Destination Handler: ICE LDAP handler for NetIQ eDirectory (version: 40006.34 )
Getting source schema...done.

Summary :
Total Records Parsed = 23
Attributes Parsed = 14
ObjectClasses Parsed = 9

Getting destination schema...done.
Starting schema update...
Schema already updated.
Done.


though a manual examination of the /opt/novell/eDirectory/lib64/nds-schema/sssv3.sch file vs. the actual directory schema shows some differences. So that's interesting. Not sure if it matters or not.

Attempting the configuration though throws an interesting error:


IDM2:/opt/novell/eDirectory/bin # ./ssscfg -c -a admin.system

[1] Instance at /etc/opt/novell/eDirectory/conf/nds.conf: IDM2.OU=servers.O=system.TREE
Password:
Logging into the tree as "admin.system". Please Wait ...

ERROR : Administrator "admin.system" could not be authenticated. Verify that you have entered the correct password.
Invalid request.
Error:-641
Failed to extend schema for NetIQ SecretStore Services!!


It's a valid user. I tried all forms of "FqDN" there (dotted, LDAP, dotted with qualifiers). Invalid user DN results in "ERROR : Unable to resolve the administrator object..." so it's not a resolution problem. Invalid password results in a -699 error and a retry, so it's not a password error.
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.