search

kanidm / ldap3

Rust LDAP3 Server Protocol Library
Mozilla Public License 2.0
51 stars 11 forks source link

Possibility to ignore unknown controls #57

Closed MDM23 closed 1 month ago

MDM23 commented 1 month ago

I'm currently encountering the same difficulties as mentioned in #28. A client that needs to connect to my server sends a control with OID 1.3.6.1.4.1.6666.5327.2 within the bind request. I cannot find any information about this specific control, but it prevents me from handling the authentication.

Basically, I would just need the changes which were done in #30. Would there still be a possibility to implement something like this? If that's to specific, just let me know. I could just create an own fork for that use-case.

Firstyear commented 1 month ago

So the reason I don't want to ignore unknowns is because it's better to be aware of what controls might be requested, and that we may need to implement them.

If we allow ignoring I'd say it should be a cfg flag, but still unsure about it.

Doing some research, that control doesn't appear to have any defined specification or references so I wonder what it is ....

nitnelave commented 1 month ago

I would argue that the decision of what to do with unknown controls rests with the application. Reporting a list of unknown/unparsed controls with a query sounds like a good compromise. If it's important to the application, they can log an error (rather than fail to parse), or refuse to process the message. And they'll have the OID of the missing control.

Firstyear commented 1 month ago

After some thought, I think you're right @nitnelave. I'm happy to accept the PR allowing unknown controls.

nitnelave commented 1 month ago

@MDM23 I won't have time to work on that, do you want to prepare a PR?

MDM23 commented 1 month ago

@nitnelave Sure, I'll take care of it! :+1:

MDM23 commented 1 month ago

Doing some research, that control doesn't appear to have any defined specification or references so I wonder what it is ....

Not sure what it is actually used for. The client is an Ascom IP DECT Base Station. A parent OID is registered here but there is no hint about what 5327.2 means. So I think they just use this internally when talking to one of their own services.