https://github.com/lldap/lldap logo
Powered by
VeenarM - I'm attempting to hook an application...
# troubleshooting
v
I'm attempting to hook an application up to lldap, but having issues with it when its maping membersOf roles.
a
message has been deleted
v
It has a default ldapVendor setting for these two values: 
dnAttributeName: 'entryDN',
uuidAttributeName: 'entryUUID',
where things like ActiveDirectroy is 
dnAttributeName: 'distinguishedName',
uuidAttributeName: 'objectGUID',
and FreeIPA is 
dnAttributeName: 'dn',
uuidAttributeName: 'ipaUniqueID',
Any idea what they would be in LLDAP?
n
Are these groups or users, I can't tell?
The DN would be uid for users, group_id (or just id?) for groups The uuid would be uuid
v
i'll give it a crack
debug it through
hmm looks like the memberOf value needs to match the 'dn' value pulled :\ i think its a problem with the app but ill continue trying.. e.g it's trying to map the memberOf which is the full dn (cn=GROUP,ou=aaa) etc.. not just a list of 'group names'.
n
Then you can use "dn"
v
my filers with dn don't return anything
n
Can you share some verbose logs?
v
unfortunately there aren't really any logs, i'm debugging inside a plugin for the backstage portal
it loads the users/groups just fine, it sjust not mapping them due to there code
n
Right, I was asking about the LLDAP 🪵 logs
v
oh
1 sec, i'll remote in
n
I just want to check that the query is correct and we return the right thing
v
Copy code
2024-09-27 21:47:35.691805+10:002024-09-26T19:38:41.455295356+00:00  INFO     LDAP session [ 91.5ms | 0.64% / 100.00% ]
2024-09-27 21:47:35.691961+10:002024-09-26T19:38:41.455335174+00:00  INFO     ┝━ LDAP request [ 87.2ms | 95.26% ]
2024-09-27 21:47:35.692002+10:002024-09-26T19:38:41.544210576+00:00  INFO     ┝━ LDAP request [ 62.5µs | 0.07% ]
2024-09-27 21:47:35.692037+10:002024-09-26T19:38:41.585856775+00:00  INFO     ┝━ LDAP request [ 2.23ms | 2.43% ]
2024-09-27 21:47:35.692071+10:002024-09-26T19:38:41.590700363+00:00  INFO     ┝━ LDAP request [ 1.46ms | 1.59% ]
2024-09-27 21:47:35.692106+10:002024-09-26T19:38:41.593529546+00:00  WARN     │  ┝━ 🚧 [warn]: Ignoring unrecognized group attribute: memberof\n\
2024-09-27 21:47:35.692141+10:00To disable this warning, add it to "ignored_group_attributes" in the config.
2024-09-27 21:47:35.692175+10:002024-09-26T19:38:41.593556305+00:00  WARN     │  ┝━ 🚧 [warn]: Ignoring unrecognized group attribute: memberof\n\
2024-09-27 21:47:35.692209+10:00To disable this warning, add it to "ignored_group_attributes" in the config.
2024-09-27 21:47:35.692243+10:002024-09-26T19:38:41.593580029+00:00  WARN     │  ┕━ 🚧 [warn]: Ignoring unrecognized group attribute: memberof\n\
2024-09-27 21:47:35.692277+10:00To disable this warning, add it to "ignored_group_attributes" in the config.
2024-09-27 21:47:35.692317+10:002024-09-27T11:47:35.691066044+00:00  INFO     ┕━ LDAP request [ 5.40µs | 0.01% ]
2024-09-27 21:47:35.692353+10:002024-09-27T11:47:35.691658806+00:00  ERROR    🚨 [error]: [LDAP] Service Error: while handling incoming messages: while receiving LDAP op: Connection reset by peer (os error 104)
n
We'll need the verbose logs
You can change that in the config or in the env
v
ah ill enable and reboot
just standard LOG_LEVEL im guessing?
n
LLDAP_VERBOSE=true
Or verbose = true in the config
v
truenas slow as.. so lets see how long it 😄
Copy code
2024-09-27 22:01:06.817692+10:002024-09-27T12:01:06.817182460+00:00  DEBUG    HTTP request [ 151µs | 100.00% ] method: "GET" | uri: "/"
2024-09-27 22:01:06.817832+10:002024-09-27T12:01:06.817319768+00:00  DEBUG    ┕━ 🐛 [debug]:  | status_code: 200
2024-09-27 22:01:15.817348+10:002024-09-27T12:01:15.816852944+00:00  DEBUG    HTTP request [ 145µs | 100.00% ] method: "GET" | uri: "/"
2024-09-27 22:01:15.817473+10:002024-09-27T12:01:15.816984270+00:00  DEBUG    ┕━ 🐛 [debug]:  | status_code: 200
2024-09-27 22:01:18.817268+10:002024-09-27T12:01:18.816807194+00:00  DEBUG    HTTP request [ 146µs | 100.00% ] method: "GET" | uri: "/"
2024-09-27 22:01:18.817350+10:002024-09-27T12:01:18.816941879+00:00  DEBUG    ┕━ 🐛 [debug]:  | status_code: 200
just a bunch of that
n
Did you run the plugin query?
v
yeh
n
And no LDAP query in the LDAP logs?
Then the plugin didn't send a query
v
I'm getting data back
debugging i can see all the user/group data coming back
just nothing showing up in the lldap container logs
n
Do you have 2 LLDAP running?
Is that the right IP?
Sorry to be a bit pushy, but in these cases it's always been a confusing user setup, so far
v
nah, it's just a truenas container on k3s (domain name with cerbot etc...)
n
Well, the place you're getting the logs from is not the place that's receiving the queries, that's all I can say
v
well it is, cause when i shut down the container no queries work :\
ill try the other containers see if anything in them (the db) one etc.. or maybe its loggin to file not stdout
oh hey there some are
finally caught up
Copy code
2024-09-27 22:09:57.495687+10:002024-09-27T12:03:07.719059592+00:00  DEBUG    │  ┝━ 🐛 [debug]:  | response: SearchResultEntry(LdapSearchResultEntry { dn: "uid=admin,ou=people,dc=lldap,dc=blank,dc=com,dc=au", attributes: [LdapPartialAttribute { atype: "memberOf", vals: ["cn=GITLAB-NP-Users,ou=groups,dc=lldap,dc=blank,dc=com,dc=au", "cn=lldap_admin,ou=groups,dc=lldap,dc=blank,dc=com,dc=au"] }, LdapPartialAttribute { atype: "uid", vals: ["admin"] }, LdapPartialAttribute { atype: "id", vals: ["admin"] }, LdapPartialAttribute { atype: "objectclass", vals: ["inetOrgPerson", "posixAccount", "mailAccount", "person"] }, LdapPartialAttribute { atype: "mail", vals: ["john@blank.com.au"] }, LdapPartialAttribute { atype: "cn", vals: ["Administrator"] }, LdapPartialAttribute { atype: "createtimestamp", vals: ["2024-05-21T09:24:46.718506+00:00"] }, LdapPartialAttribute { atype: "entryuuid", vals: ["1b217ebd-e0b1-383c-a300-b9e86571ba21"] }] })
n
Looks reasonable
v
hey found the right value
n
What was it?
v
Just dn and uuid
Lots of debugging to check values 😄
Defaults were like entryDN etc
n
Do you think you can write a sample config for backstage?
v
Yeah, already got one, I’ll try get it added to there code templates.
They’re pretty good for contributions
Tomorrow task, it’s almost midnight ttyl ty!
n
(I mean, for LLDAP!)
v
Sure
That has a full domain example
Not sure where you'd want it in lldaps documentation
n
Ideally in example_configs/backstage.md, with a link to it in the readme Thanks!
v
I'll look at doing that this weekend, the guys atbackstage would like confirmation that the default for the vendor LLDAP fields are infact: dn entryuuid Can you confirm? my tests show this as being accurate, just wanting to double check before I make a PR in there code.
n
dn sounds right, and the canonical name for the UUID is just uuid, but entryUuid is a synonym so it'll work just as well. If you have to choose though, uuid is probably better.
v
I'll double check and test uuid as well before implementing it.
when I'm done with backstage, i'll do the example config for lldap.
default settings, dn is provided but uuid is not
dn is provided, entryuuid works ootb
n
Huh, weird Well, that's your answer
v
Just double testing, if i pass 'uuid' into the attribute filter, if it comes through (i suspect it will)
yeah, uuid works if its passed into the filter along with * +
options: filter: (&(!(uid=lldap*))) attributes: ['*', '+', 'uuid']
n
Yeah, wildcards don't cover everything
Maybe they should
v
So I am easy on what you would prefer to be the expected settings.
I can just use entryuuid and attributes of * + , or use uuid and pass uuid into the attributes.
I'm easy either way
n
Ideally you would request uuid
v
i'll test it with no attributes at all
Yeah nothing
need to tell it to return
That's ok, i'll add it as the default requirement in the config.
PreviousNext
Powered by