So I opened a support case on this but that went no where.  I was just told full admin rights are needed for the proxy user, which I've never granted to the proxy user in all the NAM implementations I've done.  What's also odd is that the -659 error is a time sync problem normally, but there is no time issue in the NAM admin store.  But seeing as there are other typos in the error message, I'm guessing it is a typo and could really be a -1659 error.

It appears no one has any idea what rights are really required and it's not documented.

Matt

I got the same response a few years ago...

Well, I gave the AM proxy user Supervisor Entry from [Root] and it made no difference, so this error must be something that is not rights related.  It does seem to be OAuth related somehow as it happens during OAuth requests.

Did you manage to solve it?

We are also getting this issue, but only when we point NAM to both LDAP nodes.

If we only use one LDAP node then we don't have the problem.

No, never did.  The support case has been "Pending Support (New Activity)" status since February 2, 2022.  So I doubt I'll get any response at this point.

It doesn't seem like it has any effect on anything really, so I am just ignoring it right now.

Matt

I just looked an I am getting that same error as well.  It also seems to be working fine...

Hello Matt, I was able to reproduce the issue, setting up a new proxy user with rights limitations. I only set the write on the nidsOAuthGrant attribute and it was giving me the same error : -1659

After setting the write right on the ACL (and enable inherit) I was able to get the problem out of the system

The issue started when trying to get the Access Token, but once these rights were set, the Access Token is working again.

KR. 

Michel

Thanks for the update.  From what level did you grant Write on ACL? The root of the tree?  Isn't grant write to ACL basically giving the proxy user more or less full admin rights?

Matt

hello Matt,

I granted the rights only from top user container, as this is only needed on the user objects. It gives more rights, but this is the only working alternative for not granting the full admin rights, which are then for the complete tree.

So I limit it to the base containers where the rights are actually needed. If more user containers exist, then I set the same rights on these containers, everything to avoid having full admin rights on the tree.

KR.

Michel

Hello,

Can you confirm that you are in fact getting -1659? Because this is not what we are getting. We are getting -659.

All my servers are in perfect sync but I am still getting the message. And I am ONLY getting it when I am using two LDAP nodes.

So it doesn't look like it is permission related for me.