LDAP LAMBDA



  • We do offer paid support plans if you'd like engineering support.

    We do our best to get to all of the community issues as well, but our resources are limited.

    Hope to get back to this soon.



  • @robotdan

    I'm very disappointed with this reply.

    In order to evaluate Fusion Auth I had to buy a subscription in the first place (Fusion Reactor) just to get it up sand running in a lab environment (it's not even in production).

    There's no documentation, and you can't even provide a reference lambda that works.

    I'm happy to provide the engineering resources on our side to get this working but I'm hesitant to pay further for a product that is lacking in basic documentation when we are just in the evaluation phase. If it turns out there is some other critical component or feature that is bit suitable then it would be wasted resources.

    Regards

    Brad



  • Hi Bradley,

    I understand your frustration. We're working on documenting this functionality, but as Daniel mentioned, this is a technology preview so there will be some sharp edges. I'm sorry you ran into one during your evaluation.

    For the developer edition we only offer community/best effort support as laid out here: https://fusionauth.io/pricing ; if you want guaranteed support request turnaround times, we do offer other plans, as previously mentioned.

    If you'd like, I'm happy to reach out to you when the feature is more fully documented.

    We also only want happy customers, so we're happy to refund your developer subscription.

    Please let me know,
    Dan



  • Regarding the proximate question, if you don't provide a user id, fusionauth will create one. So instead of trying to translate the active directory guid to a string, I'd just omit the assignment to user.id in the lambda and see if that works.



  • Hi Dan,

    I've noticed that the documentation has been updated, thats great, thanks.

    https://fusionauth.io/docs/v1/tech/lambdas/ldap-connector-reconcile

    Here it says that the UID must be a string. From Active Directory, the UID is in binary format. I've tried not assigning an ID but this doesnt work. I get this in the event log:

    8/3/2020 11:49:05 pm BST
    . WARNING DISCARDING USER because it was missing a unique id in the [user.id] property.

    So unless I'm missing something, I'm still in the position where I need to somehow convert from binary to text format.

    What LDAP directory (OpenLDAP, AD etc) are you guys testing against internally?

    --
    Brad.



  • Hiya,

    Glad the additional documentation is helpful.

    OpenLDAP is one of the LDAP servers we tested against. I'm not sure we've tested ActiveDirectory as an LDAP connector.

    https://stackoverflow.com/questions/57019325/convert-objectguid-to-uuid-string-using-javascript might be useful for doing the conversion to a string from the binary guid.

    We're using nashorn to execute the javascript; I think you need to define any functions within your main function (reconcile). Here's an issue with that information.

    HTH.



  • The problem is that the array of bytes from AD is being interpreted as invalid UTF-16 data.

    This can be seen because I've attempted to get the raw binary data from the objectGUID as follows:

    for (i = 0; i < userAttributes.objectGUID.length; i++)
    {
    console.debug("GUID " + i + ": " + userAttributes.objectGUID.charCodeAt(i));
    }

    This ends up printing the following data:

    GUID 0: 65533
    GUID 1: 65533
    GUID 2: 65533
    GUID 3: 1008
    GUID 4: 65533
    GUID 5: 65533
    GUID 6: 68
    GUID 7: 65533
    GUID 8: 65533
    GUID 9: 65533
    GUID 10: 1568
    GUID 11: 65533
    GUID 12: 88
    GUID 13: 65533

    Is it possible that I can go through the source code at all? I thought there was an open source version of FusionAuth but I couldnt find the code for it.

    I imagine that such binary data needs to actually be an array of bytes. Something is trying to UTF-16 decode the data, and as per https://www.fileformat.info/info/unicode/char/0fffd/index.htm the actual binary data is being replaced with the UTF-16 value of 65533.

    Given that the vast majority of the world (like it or not) use Active Directory, the LDAP feature is not going to be very valuable to your customers unless we can work through this.

    We have over 150 Linux servers, all joined to an Active Directory domain running on the only two Windows servers we have in our estate. Not ideal, but thats the reality of the world we live in.



  • Hi @bradley-kite

    I agree, we should definitely support activedirectory. Can you please file a bug with exact repro steps? I was going to file a bug for you and realized I didn't necessarily have all the steps, which is super helpful to folks working on the issue.

    https://github.com/FusionAuth/fusionauth-issues/issues/new/choose

    Please feel free to link to this forum topic in the "Additional info" section so the devs can have more context for what you've tried to accomplish.



  • Hi Dan,

    Thanks - I've created a ticket here:

    https://github.com/FusionAuth/fusionauth-issues/issues/822

    Regards

    Brad.



  • In case anyone else would like to do the same, I have found a solution which I have detailed here:

    https://github.com/FusionAuth/fusionauth-issues/issues/822#issuecomment-680172776


Log in to reply
 

Looks like your connection to FusionAuth Forum was lost, please wait while we try to reconnect.