ldapjs
GSSAPI
Just wondering if there is any plans to ever support GSSAPI for authentication
Hi,
It's somewhere on the list, although pretty far down unless someone else wants to pick it up.
I'm looking into at least client-side strong authentication support. Trying to get a handle on the message system now. I might have something working soon.
That is absolutely fantastic, if you need help testing anything we are almost ready to implement ldap client side support into our system and would be willing to help out.
@jmrenner I have also been working on something for a client based solution. Have you had any luck with it? I am writing an addon that interacts with the Cyrus SASL C libraries. I have been able to authenticate with LDAP and I am now working on actually requesting some data from LDAP under that authentication.
Wow totally missed your comment. nah, the farthest i could get was authenticating if i poached the GSSAPI token. I tried reading through Cyrus but I just got lost in all of that. If you can authenticate though, most of the hard work should be done. at least that's what it seems like
Curious if anyone is working on this. Bump if not. This seems advantageous to match ldapsearch util.
The issue, https://github.com/ldapjs/node-ldapjs/issues/85, points to a pull request, https://github.com/ldapjs/node-ldapjs/pull/473, which seems to be locked from comments. Given the closed tag, I'm not sure if it was integrated into v2 -- I didn't think any SASL had been -- and there's a request for changes on the PR, making it seem it's still pending.
I haven't looked into the code, but if it had been integrated a question remains whether SASL provides the ability to use GSSAPI, Kerberos, NTLM, etc or is limited in the PR's abstraction. I could be mistaken, but I thought the last time I read the docs on createClient, it mentioned only basic auth and no support for GSSAPI or SASL.
The PR was closed because it had been abandoned by the author. It was subsequently locked because people were not adding useful conversation around it. We welcome contributions to add desired functionality. But patience must be exercised as the maintainer team numbers 2, and we have other priorities.
The PR was closed because it had been abandoned by the author. It was subsequently locked because people were not adding useful conversation around it. We welcome contributions to add desired functionality. But patience must be exercised as the maintainer team numbers 2, and we have other priorities.
Thank you for the reply and your logic sounds reasonable. It's much easier for us consumers to be a requestor and express wants than to be a capable developer and fulfill them 😄 I admire this library and wish I could use it to replace a system call to ldapsearch. In my case, GSSAPI is absolutely needed to interface with LDAP.
Regarding priorities, I am not sure how you are determining them, but I suspect it might have something to do with community-desire (interest) and ease-to-accomplish (time). If we look at posts/comments over the years related to this issue, it seems the desire for GSSAPI/SASL started at least as long ago as 2011 and now (over 10 years later), comments are still trickling in from others (even on the PR mentioned in previous comment). Perhaps the duration of this interest might elevate its priority?
In the meantime, I'll try to take a pass at the code, but I should mention this is outside my domain so I don't have any faith I could do it -- I wonder how many use this library that do.
The only priority is what a contributor wants to work on. That is typically related to their own problems. Until someone who needs a feature contributes it, it will not be worked on.
PR #826 hopefully solves this issue. As I actually need this feature at work, I'm willing to spend more time on this if needed.
👋
On February 22, 2023, we released version 3 of this library. As a result, we are closing this issue/pull request.
Please see issue #839 for more information, including how to proceed if you feel this closure is in error.