starred/lldap-lldap
1
0
Fork 0
mirror of https://github.com/lldap/lldap.git synced 2026-04-25 08:15:52 +03:00
Code Issues 101 Projects Releases 10 Packages Wiki Activity

[GH-ISSUE #1260] [SUPPORT] LLDAP with TAK server #445

New issue
Closed
opened 2026-02-27 08:17:19 +03:00 by kerem · 15 comments
kerem commented 2026-02-27 08:17:19 +03:00
Owner
Copy link

Originally created by @sgofferj on GitHub (Aug 22, 2025).
Original GitHub issue: https://github.com/lldap/lldap/issues/1260

Describe the bug
LLDAP forces custom attribute names to lower case. This creates problems with at least TAK server which expects its custom attributes

  • takCallSign
  • takColor
  • takRole
    to be in camel case.

To Reproduce
Steps to reproduce the behavior:

  1. create custom attribute in camel case
  2. Query a user

Expected behavior
LLDAP should not force custom attributes to lower case.

Logs
LLDAP

ldapsearch -x -LLL -H ldap://xxx -b 'uid=stefan gofferje,ou=people,dc=gofferje,dc=net'
dn: uid=stefan gofferje,ou=people,dc=gofferje,dc=net
cn: Stefan Gofferje
createtimestamp: 2025-08-21T09:41:07.113369451+00:00
entryuuid: 50fdf2d2-8887-3295-b042-5691e7677469
first_name: Stefan
givenname: Stefan
last_name: Gofferje
mail: xxxxxxxxxxxxx
objectclass: inetOrgPerson
objectclass: posixAccount
objectclass: mailAccount
objectclass: person
sn: Gofferje
takcallsign: Wolfman
takcolor: Yellow
takrole: Team member
uid: stefan gofferje

OpenLDAP

ldapsearch -x -LLL -H ldapi:/// -b "cn=Stefan Gofferje,ou=users,dc=gofferje,dc=net"
dn: cn=Stefan Gofferje,ou=users,dc=gofferje,dc=net
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: posixAccount
objectClass: person
objectClass: top
objectClass: takObjectClass
sn: Gofferje
uid: sgofferj
takCallSign: Wolfman
takColor: Yellow
cn: Stefan Gofferje
displayName: Stefan Gofferje
mail: xxxx
takRole: Team member
description: Server admin
Originally created by @sgofferj on GitHub (Aug 22, 2025). Original GitHub issue: https://github.com/lldap/lldap/issues/1260 **Describe the bug** LLDAP forces custom attribute names to lower case. This creates problems with at least TAK server which expects its custom attributes - takCallSign - takColor - takRole to be in camel case. **To Reproduce** Steps to reproduce the behavior: 1. create custom attribute in camel case 2. Query a user **Expected behavior** LLDAP should not force custom attributes to lower case. **Logs** LLDAP ``` ldapsearch -x -LLL -H ldap://xxx -b 'uid=stefan gofferje,ou=people,dc=gofferje,dc=net' dn: uid=stefan gofferje,ou=people,dc=gofferje,dc=net cn: Stefan Gofferje createtimestamp: 2025-08-21T09:41:07.113369451+00:00 entryuuid: 50fdf2d2-8887-3295-b042-5691e7677469 first_name: Stefan givenname: Stefan last_name: Gofferje mail: xxxxxxxxxxxxx objectclass: inetOrgPerson objectclass: posixAccount objectclass: mailAccount objectclass: person sn: Gofferje takcallsign: Wolfman takcolor: Yellow takrole: Team member uid: stefan gofferje ``` OpenLDAP ``` ldapsearch -x -LLL -H ldapi:/// -b "cn=Stefan Gofferje,ou=users,dc=gofferje,dc=net" dn: cn=Stefan Gofferje,ou=users,dc=gofferje,dc=net objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: posixAccount objectClass: person objectClass: top objectClass: takObjectClass sn: Gofferje uid: sgofferj takCallSign: Wolfman takColor: Yellow cn: Stefan Gofferje displayName: Stefan Gofferje mail: xxxx takRole: Team member description: Server admin ```
kerem 2026-02-27 08:17:19 +03:00
  • closed this issue
  • added the
    bug
         label
kerem commented 2026-02-27 08:17:20 +03:00
Author
Owner
Copy link

@sgofferj commented on GitHub (Aug 22, 2025):

Seems, TAK server also expects a custom objectClass named takObjectClass. I suppose, we can't have those?

<!-- gh-comment-id:3213499855 --> @sgofferj commented on GitHub (Aug 22, 2025): Seems, TAK server also expects a custom objectClass named takObjectClass. I suppose, we can't have those?
kerem commented 2026-02-27 08:17:20 +03:00
Author
Owner
Copy link

@nitnelave commented on GitHub (Aug 22, 2025):

The LDAP protocol defines attributes as case insensitive, and they should be interpreted as such by the clients. I would consider that a TAK bug.

As for custom object classes, you can add a class to every user or every group (though not in the UI, it's not implemented yet). You can use lldap-cli for that

<!-- gh-comment-id:3213546285 --> @nitnelave commented on GitHub (Aug 22, 2025): The LDAP protocol defines attributes as case insensitive, and they should be interpreted as such by the clients. I would consider that a TAK bug. As for custom object classes, you can add a class to every user or every group (though not in the UI, it's not implemented yet). You can use lldap-cli for that
kerem commented 2026-02-27 08:17:20 +03:00
Author
Owner
Copy link

@sgofferj commented on GitHub (Aug 22, 2025):

Thank you for your reply! I actually manually changed the attribute names in the DB to be camel case. Also added all object classes but no joy. I'm not really an LDAP expert - if the output of ldapsearch is identical, does it mean it should work from LDAP point of view? I'm trying to figure out where I need to turn some screws.

<!-- gh-comment-id:3213647846 --> @sgofferj commented on GitHub (Aug 22, 2025): Thank you for your reply! I actually manually changed the attribute names in the DB to be camel case. Also added all object classes but no joy. I'm not really an LDAP expert - if the output of ldapsearch is identical, does it mean it should work from LDAP point of view? I'm trying to figure out where I need to turn some screws.
kerem commented 2026-02-27 08:17:20 +03:00
Author
Owner
Copy link

@nitnelave commented on GitHub (Aug 22, 2025):

I would strongly recommend against changing the values in the DB (or accessing the DB directly at all). I'm not 100% sure, but I think the attributes will not match anything anymore since we do case insensitive comparisons by turning the inputs to lowercase and checking against the DB value. If that's not lowercase, nothing can match.

<!-- gh-comment-id:3213696049 --> @nitnelave commented on GitHub (Aug 22, 2025): I would strongly recommend against changing the values in the DB (or accessing the DB directly at all). I'm not 100% sure, but I think the attributes will not match anything anymore since we do case insensitive comparisons by turning the inputs to lowercase and checking against the DB value. If that's not lowercase, nothing can match.
kerem commented 2026-02-27 08:17:20 +03:00
Author
Owner
Copy link

@sgofferj commented on GitHub (Aug 22, 2025):

Yeah, you are right, the UI didn't work anymore 😆 .
I used the ldiffs here to set up the test with OpenLDAP: https://github.com/takcluster/takserver-ldap/tree/main
It would be great if you could give some advice on how to get LLDAP working with TAK because OpenLDAP really is a monster!

<!-- gh-comment-id:3213705015 --> @sgofferj commented on GitHub (Aug 22, 2025): Yeah, you are right, the UI didn't work anymore 😆 . I used the ldiffs here to set up the test with OpenLDAP: https://github.com/takcluster/takserver-ldap/tree/main It would be great if you could give some advice on how to get LLDAP working with TAK because OpenLDAP really is a monster!
kerem commented 2026-02-27 08:17:20 +03:00
Author
Owner
Copy link

@nitnelave commented on GitHub (Aug 22, 2025):

I expect that it'll require a code change in TAK if they expect camel case attributes.

<!-- gh-comment-id:3213713164 --> @nitnelave commented on GitHub (Aug 22, 2025): I expect that it'll require a code change in TAK if they expect camel case attributes.
kerem commented 2026-02-27 08:17:20 +03:00
Author
Owner
Copy link

@sgofferj commented on GitHub (Aug 22, 2025):

It also didn't work when I changed the attribute names in the DB and LLDAP returned the attribute names in camel case. Something else must be off...

<!-- gh-comment-id:3213783582 --> @sgofferj commented on GitHub (Aug 22, 2025): It also didn't work when I changed the attribute names in the DB and LLDAP returned the attribute names in camel case. Something else must be off...
kerem commented 2026-02-27 08:17:20 +03:00
Author
Owner
Copy link

@sgofferj commented on GitHub (Aug 22, 2025):

The OpenLDAP config has some long numbers in them which look like they could be some UUIDs or something. Is that maybe something which is need for the attributes to work? I wiresharked the connection between the TAK server and LLDAP and those attributes didn't show up by name in any packet.

dn: cn=local,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: local
olcAttributeTypes: ( 1.2.840.113556.1.8000.2554.9934.47039.1675.18175.33308.6358906.6646288 NAME 'takCallSign'
  DESC 'takCallSign'
  EQUALITY caseIgnoreMatch
  SUBSTR caseIgnoreSubstringsMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
  SINGLE-VALUE )
olcAttributeTypes: ( 1.2.840.113556.1.8000.2554.3917.2598.15359.18049.37293.1439613.13249228 NAME 'takColor'
  DESC 'takColor'
  EQUALITY caseIgnoreMatch
  SUBSTR caseIgnoreSubstringsMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
  SINGLE-VALUE )
olcAttributeTypes: ( 1.2.840.113556.1.8000.2554.27632.51136.11289.16603.48658.12192876.4577004 NAME 'takRole'
  DESC 'takRole'
  EQUALITY caseIgnoreMatch
  SUBSTR caseIgnoreSubstringsMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
  SINGLE-VALUE )
olcObjectClasses: ( 1.2.840.113556.1.8000.2554.2761.51136.11289.16603.48658.12192876.4577001 NAME 'takObjectClass'
  DESC 'takObjectClass'
  SUP top
  AUXILIARY MAY ( takCallSign $ takColor $ takRole ) )
<!-- gh-comment-id:3214188768 --> @sgofferj commented on GitHub (Aug 22, 2025): The OpenLDAP config has some long numbers in them which look like they could be some UUIDs or something. Is that maybe something which is need for the attributes to work? I wiresharked the connection between the TAK server and LLDAP and those attributes didn't show up by name in any packet. ``` dn: cn=local,cn=schema,cn=config objectClass: olcSchemaConfig cn: local olcAttributeTypes: ( 1.2.840.113556.1.8000.2554.9934.47039.1675.18175.33308.6358906.6646288 NAME 'takCallSign' DESC 'takCallSign' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) olcAttributeTypes: ( 1.2.840.113556.1.8000.2554.3917.2598.15359.18049.37293.1439613.13249228 NAME 'takColor' DESC 'takColor' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) olcAttributeTypes: ( 1.2.840.113556.1.8000.2554.27632.51136.11289.16603.48658.12192876.4577004 NAME 'takRole' DESC 'takRole' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) olcObjectClasses: ( 1.2.840.113556.1.8000.2554.2761.51136.11289.16603.48658.12192876.4577001 NAME 'takObjectClass' DESC 'takObjectClass' SUP top AUXILIARY MAY ( takCallSign $ takColor $ takRole ) ) ```
kerem commented 2026-02-27 08:17:20 +03:00
Author
Owner
Copy link

@nitnelave commented on GitHub (Aug 23, 2025):

That's part of the schema, and these are alternate names for the attributes. LDAP clients sometimes can use either, but the readable names are more common

<!-- gh-comment-id:3216688227 --> @nitnelave commented on GitHub (Aug 23, 2025): That's part of the schema, and these are alternate names for the attributes. LDAP clients sometimes can use either, but the readable names are more common
kerem commented 2026-02-27 08:17:20 +03:00
Author
Owner
Copy link

@sgofferj commented on GitHub (Aug 24, 2025):

Is it possible to use define those "UUID"s in LLDAP? E.g. can I use that as objectClass / attribute name? Is there a way to find out what the TAK server requests? As I mentioned, I'm not familiar at all with the LDAP protocol and also Wireshark doesn't seem to be able to do more than display the hexdump of the packets. I'm completely in the dark but I would really like to use LLDAP for my TAK server and get rid of OpenLDAP.

<!-- gh-comment-id:3217900082 --> @sgofferj commented on GitHub (Aug 24, 2025): Is it possible to use define those "UUID"s in LLDAP? E.g. can I use that as objectClass / attribute name? Is there a way to find out what the TAK server requests? As I mentioned, I'm not familiar at all with the LDAP protocol and also Wireshark doesn't seem to be able to do more than display the hexdump of the packets. I'm completely in the dark but I would really like to use LLDAP for my TAK server and get rid of OpenLDAP.
kerem commented 2026-02-27 08:17:20 +03:00
Author
Owner
Copy link

@nitnelave commented on GitHub (Aug 24, 2025):

In verbose mode, LLDAP logs all the requests/responses it receives, so you should be able to see what's going on (though it is a bit verbose, you can grep for SearchRequest and SearchResponse or SearchRequestResponse to filter out most of the irrelevant stuff)

<!-- gh-comment-id:3217902890 --> @nitnelave commented on GitHub (Aug 24, 2025): In verbose mode, LLDAP logs all the requests/responses it receives, so you should be able to see what's going on (though it _is_ a bit verbose, you can grep for SearchRequest and SearchResponse or SearchRequestResponse to filter out most of the irrelevant stuff)
kerem commented 2026-02-27 08:17:20 +03:00
Author
Owner
Copy link

@sgofferj commented on GitHub (Aug 24, 2025):

The only thing I found which appeared to be related was this.

LdapPartialAttribute { atype: "takcallsign", vals: ["Wolfman actual"] }, LdapPartialAttribute { atype: "takcolor", vals: ["Red"] }, LdapPartialAttribute { atype: "takrole", vals: ["HQ"] }, LdapPartialAttribute { atype: "uid", vals: ["sgofferj"] }] })

in a do_search return.

I don't see any explicit requests for those "UUIDs".
I tried to add those UUIDs as custom attributes but LLDAP won't let me because of the ".".

I bury LLDAP then and go back to OpenLDAP with their lousy web UI and huge mem consumption...

<!-- gh-comment-id:3217912667 --> @sgofferj commented on GitHub (Aug 24, 2025): The only thing I found which appeared to be related was this. ``` LdapPartialAttribute { atype: "takcallsign", vals: ["Wolfman actual"] }, LdapPartialAttribute { atype: "takcolor", vals: ["Red"] }, LdapPartialAttribute { atype: "takrole", vals: ["HQ"] }, LdapPartialAttribute { atype: "uid", vals: ["sgofferj"] }] }) ``` in a do_search return. I don't see any explicit requests for those "UUIDs". I tried to add those UUIDs as custom attributes but LLDAP won't let me because of the ".". I bury LLDAP then and go back to OpenLDAP with their lousy web UI and huge mem consumption...
kerem commented 2026-02-27 08:17:20 +03:00
Author
Owner
Copy link

@nitnelave commented on GitHub (Aug 24, 2025):

Yeah, we don't send the UUIDs for the attributes.

Honestly, it's worth filing a bug with TAK for the case insensitive attributes, it's not LDAP compliant.

<!-- gh-comment-id:3217925356 --> @nitnelave commented on GitHub (Aug 24, 2025): Yeah, we don't send the UUIDs for the attributes. Honestly, it's worth filing a bug with TAK for the case insensitive attributes, it's not LDAP compliant.
kerem commented 2026-02-27 08:17:20 +03:00
Author
Owner
Copy link

@sgofferj commented on GitHub (Aug 24, 2025):

I don't even know if the case matters. When I changed the attribute names in the DB, LLDAP did return the attribute names in camel case and TAK server still ignored it, so my best guess is that it looks at those UUIDs. But as I said, I don't know anything about the LDAP protocol. TAK is a US DoD product. Without a developer contract you don't get access to their bugtracker. The version here on GitHub is years old and the account appears abandoned.
I tried looking into the TAK server source but it's pretty complicated. I couldn't find anything holding up orange signs "I'm doing the LDAP attribute stuff".
If there's no interest from the LLDAP project side to help make it work, I can't use LLDAP because I don't know how. No hard feelings, I know how open source works 🙂

<!-- gh-comment-id:3218192087 --> @sgofferj commented on GitHub (Aug 24, 2025): I don't even know if the case matters. When I changed the attribute names in the DB, LLDAP did return the attribute names in camel case and TAK server still ignored it, so my best guess is that it looks at those UUIDs. But as I said, I don't know anything about the LDAP protocol. TAK is a US DoD product. Without a developer contract you don't get access to their bugtracker. The version here on GitHub is years old and the account appears abandoned. I tried looking into the TAK server source but it's pretty complicated. I couldn't find anything holding up orange signs "I'm doing the LDAP attribute stuff". If there's no interest from the LLDAP project side to help make it work, I can't use LLDAP because I don't know how. No hard feelings, I know how open source works 🙂
kerem commented 2026-02-27 08:17:20 +03:00
Author
Owner
Copy link

@sgofferj commented on GitHub (Aug 24, 2025):

As a last resort, I went through everything again, figured out that the names of the attributes can be defined in the TAK server config, set the attribute names as lowercase, tried again and still not. So I know now that the attributes are recognized by name, not by UUID because the names can be configured.

I'm now completely at the end of any ideas.

<!-- gh-comment-id:3218283008 --> @sgofferj commented on GitHub (Aug 24, 2025): As a last resort, I went through everything again, figured out that the names of the attributes can be defined in the TAK server config, set the attribute names as lowercase, tried again and still not. So I know now that the attributes are recognized by name, not by UUID because the names can be configured. I'm now completely at the end of any ideas.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
dependabot/github_actions/codecov/codecov-action-6
copilot/fix-equality-filters-list-attributes
dependabot/github_actions/docker/build-push-action-7
dependabot/github_actions/docker/metadata-action-6
dependabot/github_actions/docker/setup-buildx-action-4
dependabot/github_actions/docker/login-action-4
copilot/update-download-artifact-action
copilot/fix-opensuse-warnings
copilot/fix-1268
copilot/fix-727
copilot/fix-898
copilot/fix-1256
copilot/fix-1251
copilot/fix-1249
copilot/fix-1206
user-attribute-form
user-ui
group-ui
server-user-attribute-schema
crates
haveibeenpwned
v0.6.2
v0.6.1
v0.6.0
v0.5.0
v0.4.3
v0.4.2
v0.4.1
v0.4.0
v0.3.0
v0.2.0
v0.0.1
Labels
Clear labels   
backend

   
blocked

   
bug

   
cleanup

   
dependencies

   
docker

   
documentation

   
duplicate

   
enhancement

   
enhancement

   
frontend

   
github_actions

   
good first issue

   
help wanted

   
help wanted

   
integration

   
invalid

   
ldap

   
pull-request

Mirrored from GitHub Pull Request

  
question

   
rust

   
rust

   
tests

   
wontfix
No labels
backend
blocked
bug
cleanup
dependencies
docker
documentation
duplicate
enhancement
enhancement
frontend
github_actions
good first issue
help wanted
help wanted
integration
invalid
ldap
pull-request
question
rust
rust
tests
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/lldap-lldap#445
No description provided.