Real gurus stay quite and silent
Joke aside, these log extracts tell us very few.
Let me translate it, having in mind that both are only extract, thus you have a truncated view
although my post will be a long one
the "good" authentication:
- step 48: to me a very strange one
client searches RootDSE (because base="") for entry matching (cn=*)
none is found but this is expected because there is no such entry in RootDSE. We can elaborate on this later.
- step 49: search for all entries in dc=rapheal.... being "posixaccount". 11 are found
- step 50: again this strange RootDSE search
- step 51: search for entries being "zentyalgroup": 7 are found
That's it... is it enough to correlate with "good authentication" ? I don't think so, let's see the "wrong authentication"
- step 14: search for cn=wireless within cn=wireless,ou=groups,dc=rapheal... and retrieve "dn".
to me this is another very strange sequence: as rdn IS cn=wireless, result of such search MUST return entry used as search base, therefore this is, to me again, totally useless. Anyway...
- step 15: standard search command
(all entries matching "uid=dhoff"). Expected result is "1" and indeed there is one and only one found
so far so good but here again I would like to spend hours discussing what is retrieved once entry is found. Retrieve radius related attributes is perfectly fine. Retrieving password related attributes is not acceptable. If such password can be retrieved using LDAP command (mean read) then you are exposed to brute force attack. look at this search. It retrieves "userpassword" (std LDAP password), dbcspwd (account's LAN manager pwd), "sambaNtPassword", "sambaLmPassword", "ntPassword", "lmPassword". I really wonder why
- step 16: same as step 15, retrieving only DN, goal being to point to this (found) entry.
- step 17: I've to admit that I don't understand this search syntax
Reason is that I don't know about the "?" logical operator in this search filter:
filter="(&(cn=wireless)(&(objectClass=posixGroup)(?member=dhoff)))"
it looks like searching for posixgroup entries (here thus "group") called wireless (cn=wireless) and having dhoff as member but
(?member=...) as far as I know, is not described in any LDAP related RFC. Something specific to OpenLDAP ? I doubt...
anyway, as expected, not such entry is found
- step 18: search uid=dhoff entry in order to retrieve groups this entry is member of. no special comment here
- step 19: 100% similar to step 14. To me, meaning less
is it enough to state that authentication fails ? For sure no but this shows some "interesting" (somehow) behaviour.
Does it help ? I doubt
I would like Zentyal team to comment on the "?" within the search filter however