[GH-ISSUE #1329] [FEATURE REQUEST] Support binary (Octet String) attributes other than JpegPhoto #465

New issue

Open

opened 2026-02-27 08:17:25 +03:00 by kerem · 3 comments

kerem commented

2026-02-27 08:17:25 +03:00

Owner

Originally created by @pfeigl on GitHub (Oct 15, 2025).
Original GitHub issue: https://github.com/lldap/lldap/issues/1329

Motivation
We are using LLDAP as a development replacement for a full blown Active Directory. All we do is read users from LLDAP and sync their attributes to our local database.
In Prod we do this using a real Active Directory server, for dev we started using LLDAP in a container setup.
Apart from some obvious differences between AD and LDAP this works just great.

However, there is one specific field which we use and cannot work around currently. In AD there is a field called "objectSid" which is a so called SecurityIdentifier in AD. We are totally fine to self-define these fields and provide meaningful mock-data for it.

However the field is saved as binary (octet-string) in AD and we currently cannot manage to save this currently.
See here for details: https://ldapwiki.com/wiki/Wiki.jsp?page=OctetString

Describe the solution you'd like
Similar logic like the one with Jpegs where a base64 String can be transmitted and is decoded server-side would help alot here. Either via file-input or even text based input would be totally fine.

Describe alternatives you've considered
I'm not sure whether it would work out, if we would insert the correct value via the DB directly. I'll give it a try, but fear that atleast later edits via the UI will cause problems.

Originally created by @pfeigl on GitHub (Oct 15, 2025). Original GitHub issue: https://github.com/lldap/lldap/issues/1329 **Motivation** We are using LLDAP as a development replacement for a full blown Active Directory. All we do is read users from LLDAP and sync their attributes to our local database. In Prod we do this using a real Active Directory server, for dev we started using LLDAP in a container setup. Apart from some obvious differences between AD and LDAP this works just great. However, there is one specific field which we use and cannot work around currently. In AD there is a field called "objectSid" which is a so called `SecurityIdentifier` in AD. We are totally fine to self-define these fields and provide meaningful mock-data for it. However the field is saved as binary (octet-string) in AD and we currently cannot manage to save this currently. See here for details: https://ldapwiki.com/wiki/Wiki.jsp?page=OctetString **Describe the solution you'd like** Similar logic like the one with Jpegs where a base64 String can be transmitted and is decoded server-side would help alot here. Either via file-input or even text based input would be totally fine. **Describe alternatives you've considered** I'm not sure whether it would work out, if we would insert the correct value via the DB directly. I'll give it a try, but fear that atleast later edits via the UI will cause problems.

kerem added the

enhancement

label

2026-02-27 08:17:25 +03:00

kerem commented

2026-02-27 08:17:26 +03:00

Author

Owner

@pfeigl commented on GitHub (Oct 15, 2025):

Small update: I tried setting the correct blob via SQL directly and it leads to errors, because the binary cannot be cast to a string.

@pfeigl commented on GitHub (Oct 15, 2025): Small update: I tried setting the correct blob via SQL directly and it leads to errors, because the binary cannot be cast to a string.

kerem commented

2026-02-27 08:17:26 +03:00

Author

Owner

@nitnelave commented on GitHub (Oct 15, 2025):

Yeah, there's nothing fundamentally incompatible about binary blobs, we already handle them for jpeg photos. However, what you want is a binary blob with no validation (not a valid utf-8 string, not a valid jpeg).

That's something we could add, and I don't expect it to be too hard. I'd welcome PRs

@nitnelave commented on GitHub (Oct 15, 2025): Yeah, there's nothing fundamentally incompatible about binary blobs, we already handle them for jpeg photos. However, what you want is a binary blob with no validation (not a valid utf-8 string, not a valid jpeg). That's something we could add, and I don't expect it to be too hard. I'd welcome PRs

kerem commented

2026-02-27 08:17:26 +03:00

Author

Owner

@pfeigl commented on GitHub (Oct 21, 2025):

Just wanted to follow-up on this. After a few more problems with our dev-setup based on lldap (mainly, we need modify support for our tests) we eventually moved to a container based solution using Samba AD DC, because it provides pretty much all the nitty-gritty details which differentiate LDAP and Microsoft AD.

Thus we don't need this change. Feel free to close, if you want to. Thanks for your fast response!

@pfeigl commented on GitHub (Oct 21, 2025): Just wanted to follow-up on this. After a few more problems with our dev-setup based on lldap (mainly, we need modify support for our tests) we eventually moved to a container based solution using [Samba AD DC](https://wiki.samba.org/index.php/Setting_up_Samba_as_an_Active_Directory_Domain_Controller), because it provides pretty much all the nitty-gritty details which differentiate LDAP and Microsoft AD. Thus we don't need this change. Feel free to close, if you want to. Thanks for your fast response!