starred/lldap-lldap

Fork 0

mirror of https://github.com/lldap/lldap.git synced 2026-04-25 16:25:55 +03:00

[GH-ISSUE #158] Authentik Support - attrs: ["*", "+"] not supported #62

New issue

Closed

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

kerem commented

2026-02-27 08:15:02 +03:00

Owner

Originally created by @strazto on GitHub (May 4, 2022).
Original GitHub issue: https://github.com/lldap/lldap/issues/158

Originally assigned to: @strazto on GitHub.

This is more of a tracking issue to track my own process of getting this to work with authentik, however, i do not

2022-05-04T05:56:29.541807Z DEBUG lldap::infra::ldap_handler: Received search request: LdapSearchRequest { base: "ou=people,dc=example,dc=com", scope: Subtree, aliases: Always, sizelimit: 0, timelimit: 0, typesonly: false, filter: Equality("objectClass", "person"), attrs: ["*", "+"] }    
2022-05-04T05:56:29.542227Z  INFO sqlx::query: SELECT `users`.`user_id`, `email`, `users`.`display_name`, …; rows: 12, elapsed: 256.336µs

...

2022-05-04T05:56:29.543631Z DEBUG lldap::infra::ldap_server: Replying with LDAP op: SearchResultDone(LdapResult { code: NoSuchAttribute, matcheddn: "", message: "Unsupported group attribute: objectSid", referral: [] })

Although I'm unsure if i've correctly config'd this on the authentik side ( maybe 85% sure), I get the impression that lldap just can't handle the attrs: ["*", "+"] part of the query.

On authentik's end, that part of the query can't be customized, I assume it's some part of the lldap protocol that just isn't implemented by lldap

Originally created by @strazto on GitHub (May 4, 2022). Original GitHub issue: https://github.com/lldap/lldap/issues/158 Originally assigned to: @strazto on GitHub. This is more of a tracking issue to track my own process of getting this to work with authentik, however, i do not ``` 2022-05-04T05:56:29.541807Z DEBUG lldap::infra::ldap_handler: Received search request: LdapSearchRequest { base: "ou=people,dc=example,dc=com", scope: Subtree, aliases: Always, sizelimit: 0, timelimit: 0, typesonly: false, filter: Equality("objectClass", "person"), attrs: ["*", "+"] } 2022-05-04T05:56:29.542227Z INFO sqlx::query: SELECT `users`.`user_id`, `email`, `users`.`display_name`, …; rows: 12, elapsed: 256.336µs ``` ... ``` 2022-05-04T05:56:29.543631Z DEBUG lldap::infra::ldap_server: Replying with LDAP op: SearchResultDone(LdapResult { code: NoSuchAttribute, matcheddn: "", message: "Unsupported group attribute: objectSid", referral: [] }) ``` Although I'm unsure if i've correctly config'd this on the authentik side ( maybe 85% sure), I get the impression that lldap just can't handle the `attrs: ["*", "+"]` part of the query. On authentik's end, that part of the query can't be customized, I assume it's some part of the lldap protocol that just isn't implemented by lldap

kerem

2026-02-27 08:15:02 +03:00

closed this issue
added the
bug
label

kerem commented

2026-02-27 08:15:03 +03:00

Author

Owner

@strazto commented on GitHub (May 4, 2022):

I think I've improved my authentik side settings, but I'm getting the following:

2022-05-04T06:08:44.978120Z DEBUG lldap::infra::ldap_handler: Received search request: LdapSearchRequest { base: "ou=groups,dc=example,dc=com", scope: Subtree, aliases: Always, sizelimit: 0, timelimit: 0, typesonly: false, filter: Equality("objectClass", "groupOfUniqueNames"), attrs: ["member", "uid", "distinguishedName"] }

2022-05-04T06:08:44.978925Z DEBUG lldap::infra::ldap_server: Replying with LDAP op: SearchResultDone(LdapResult { code: NoSuchAttribute, matcheddn: "", message: "Unsupported group attribute: distinguishedName", referral: [] })

To summarize what I'm now getting:

Authentik's sync result:

ldap_sync_ldap_user

Task finished with errors
LDAPNoSuchAttributeResult - 16 - noSuchAttribute - None - Unsupported user attribute: * - searchResDone - None
ldap_sync_ldap_group

Task finished with errors
LDAPNoSuchAttributeResult - 16 - noSuchAttribute - None - Unsupported group attribute: * - searchResDone - None
ldap_sync_ldap_membership

Task finished with errors
LDAPNoSuchAttributeResult - 16 - noSuchAttribute - None - Unsupported group attribute: distinguishedName - searchResDone - None

I don't know whether authentik should just be more configurable, of if lldap needs to implement these

@strazto commented on GitHub (May 4, 2022): I think I've improved my authentik side settings, but I'm getting the following: ``` 2022-05-04T06:08:44.978120Z DEBUG lldap::infra::ldap_handler: Received search request: LdapSearchRequest { base: "ou=groups,dc=example,dc=com", scope: Subtree, aliases: Always, sizelimit: 0, timelimit: 0, typesonly: false, filter: Equality("objectClass", "groupOfUniqueNames"), attrs: ["member", "uid", "distinguishedName"] } ``` ``` 2022-05-04T06:08:44.978925Z DEBUG lldap::infra::ldap_server: Replying with LDAP op: SearchResultDone(LdapResult { code: NoSuchAttribute, matcheddn: "", message: "Unsupported group attribute: distinguishedName", referral: [] }) ``` To summarize what I'm now getting: Authentik's sync result: ``` ldap_sync_ldap_user Task finished with errors LDAPNoSuchAttributeResult - 16 - noSuchAttribute - None - Unsupported user attribute: * - searchResDone - None ldap_sync_ldap_group Task finished with errors LDAPNoSuchAttributeResult - 16 - noSuchAttribute - None - Unsupported group attribute: * - searchResDone - None ldap_sync_ldap_membership Task finished with errors LDAPNoSuchAttributeResult - 16 - noSuchAttribute - None - Unsupported group attribute: distinguishedName - searchResDone - None ``` I don't know whether authentik should just be more configurable, of if lldap needs to implement these

kerem commented

2026-02-27 08:15:03 +03:00

Author

Owner

@strazto commented on GitHub (May 7, 2022):

Handling `*` and `+`

So, * appears to represent ALL_ATTRIBUTES - it's a request to return all.
+ represents OPERATIONAL_ATTRIBUTES - I don't actually know what this means

We see this in Authentik's source, here:

github.com/goauthentik/authentik@03d5b9e7e9/authentik/sources/ldap/sync/users.py (L22-L26)

Our handling of attributes is here:

github.com/nitnelave/lldap@f689458aa2/server/src/infra/ldap_handler.rs (L103-L145)

It's sensible - Iterate over specified attributes, try to handle them, return the exception if we cant (or whatever the correct rust-ic way to say that is)

What we need to do with *, however, is to expand that out into a vector that includes all valid user attributes, then pass that to the match statement

As for + - I don't know what an "operational" attribute is

Handling DistinguishedName

I think this is much simpler, correct me if I'm wrong, but DistinguishedName is just an alias for dn ?

Change the match operand from "dn" to "dn" | "distinguishedname"

github.com/nitnelave/lldap@f689458aa2/server/src/infra/ldap_handler.rs (L155-L158)

@strazto commented on GitHub (May 7, 2022): # Handling `*` and `+` So, `*` appears to represent `ALL_ATTRIBUTES` - it's a request to return all. `+` represents `OPERATIONAL_ATTRIBUTES` - I don't actually know what this means We see this in Authentik's source, here: https://github.com/goauthentik/authentik/blob/03d5b9e7e941df57d17730b889b9c44ff3ee64b0/authentik/sources/ldap/sync/users.py#L22-L26 Our handling of attributes is here: https://github.com/nitnelave/lldap/blob/f689458aa2888ddb7386f6fed89ec17d8747e325/server/src/infra/ldap_handler.rs#L103-L145 It's sensible - Iterate over specified attributes, try to handle them, return the exception if we cant (or whatever the correct rust-ic way to say that is) What we need to do with `*`, however, is to expand that out into a vector that includes all valid user attributes, then pass that to the match statement As for `+` - I don't know what an "operational" attribute is # Handling DistinguishedName I think this is much simpler, correct me if I'm wrong, but `DistinguishedName` is just an alias for `dn` ? Change the match operand from `"dn"` to `"dn" | "distinguishedname"` https://github.com/nitnelave/lldap/blob/f689458aa2888ddb7386f6fed89ec17d8747e325/server/src/infra/ldap_handler.rs#L155-L158

kerem commented

2026-02-27 08:15:03 +03:00

Author

Owner

@strazto commented on GitHub (May 7, 2022):

Operational attributes defined by:

http://www.ldapexplorer.com/en/manual/107070300-operational-attributes.htm#:~:text=Operational%20attributes%20are%20attributes%20which,has%20to%20request%20them%20explicitly.

Operational attributes are specified and described officially in RFC 4512 in paragraph 3.4 (Operational Attributes). Particularly this specification enumerates the following attributes, which can be encountered in all sorts of directory services:

creatorsName: The object's creator, unfortunately not implemented in ADS environments

createTimestamp: Date and time when the object was created

modifiersName: Tthe account which last altered the object, unfortunately not implemented in ADS environments

modifyTimestamp: Date and time when the object was last modified

You can only evaluate the set of operational attributes if you check the schema of the regarding directory services.

So, the + means return create | modify timestamp, for us

@strazto commented on GitHub (May 7, 2022): Operational attributes defined by: http://www.ldapexplorer.com/en/manual/107070300-operational-attributes.htm#:~:text=Operational%20attributes%20are%20attributes%20which,has%20to%20request%20them%20explicitly. > > Operational attributes are specified and described officially in [RFC 4512](http://www.ietf.org/rfc/rfc4512.txt) in paragraph 3.4 (Operational Attributes). Particularly this specification enumerates the following attributes, which can be encountered in all sorts of directory services: > > creatorsName: The object's creator, unfortunately not implemented in ADS environments > > createTimestamp: Date and time when the object was created > > modifiersName: Tthe account which last altered the object, unfortunately not implemented in ADS environments > > modifyTimestamp: Date and time when the object was last modified > > You can only evaluate the set of operational attributes if you check the schema of the regarding directory services. So, the + means return create | modify timestamp, for us

kerem referenced this issue

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

[PR #62] [MERGED] Improve new user experience #519