LDAP LAMBDA

bradley.kite

Any update on this guys? I cannot commit our solution to being based on FusionAuth if I'm not able to get this working.

Thanks in advance

--
Brad.

robotdan

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.

bradley.kite

@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

dan

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

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.

bradley.kite

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.

dan

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.

bradley.kite

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.

dan

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.

bradley.kite

Hi Dan,

Thanks - I've created a ticket here:

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

Regards

Brad.

bradley.kite

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