Cannot detect base DN of an AD server when using an IP address

[jnweiger]

Seen with user-ldap-0.17.0

This is a strange one. I have an AD server running at a private network 10.42.0.2 with ldapsearch, I can happily connect like this:

ldapsearch -d 0 -H ldap://10.42.0.2 -D administrator@ker.jw-qa.owncloud.works -w "$password" -b dc=ker,dc=jw-qa,dc=owncloud,dc=works

In the web UI of user_ldap this IP address seems to work (Green bullet, connection OK) But then the 'Detect Base DN' fails:

Server log snippet:

{"reqId":"CNKX0LO13BWW9dOexuSx","level":2,"time":"2023-06-27T10:06:11+00:00","remoteAddr":"","user":"--","app":"OCA\\User_LDAP\\User\\Manager","method":"--","url":"--","message":"No cached ldap result found for C4773B0D-A2C1-4970-9706-F9B28CD1F4DB"}
{"reqId":"CNKX0LO13BWW9dOexuSx","level":2,"time":"2023-06-27T10:06:11+00:00","remoteAddr":"","user":"--","app":"OCA\\User_LDAP\\User\\Manager","method":"--","url":"--","message":"No cached ldap result found for C4773B0D-A2C1-4970-9706-F9B28CD1F4DB"}
{"reqId":"CNKX0LO13BWW9dOexuSx","level":2,"time":"2023-06-27T10:06:11+00:00","remoteAddr":"","user":"--","app":"OCA\\User_LDAP\\User\\Manager","method":"--","url":"--","message":"No cached ldap result found for C4773B0D-A2C1-4970-9706-F9B28CD1F4DB"}
{"reqId":"TOD1j08AUXEU1HX5ul2x","level":1,"time":"2023-06-27T10:10:01+00:00","remoteAddr":"","user":"--","app":"cron","method":"--","url":"--","message":"Invalidating tokens older than 2023-06-27T09:50:01+00:00"}
{"reqId":"ZJq1vlcCZuRDQw1cKlNG5wAAAAQ","level":3,"time":"2023-06-27T10:11:10+00:00","remoteAddr":"217.84.2.76","user":"admin","app":"PHP","method":"POST","url":"\/apps\/user_ldap\/ajax\/wizard.php","message":"ldap_search(): Partial search results returned: Sizelimit exceeded at \/var\/www\/owncloud\/apps\/user_ldap\/lib\/LDAP.php#296"}

Workaround:

• create a DNS entry and use it like this:

[IljaN]

@jnweiger Maybe the issue is something else? @pako81 Just tested it with private ip-address and can detect the DN. Also the error message seems to be unrelated to DN detection:

ldap_search(): Partial search results returned: Sizelimit exceeded at...

[cdamken]

@jnweiger Could you provide the config report with the whole LDAP configuration?, Just screenshots are not enough.

[jnweiger]

@cdamken config report here configreport.txt.zip

[jvillafanez]

Target code is https://github.com/owncloud/user_ldap/blob/71cf34e054037074901d0e9cab35d5157bde5457/lib/Wizard.php#L670C33-L670C33 If the check against the user agent fails, we intentionally check against the host. Maybe we should do an additional check against the user agent in a different way?

I think we need to discuss a strategy first in order to decide how we want to guess the base dn. Does it seems better to check for the domain using the user agent instead of the host (assuming the first check fails)?

[cdamken]

I think we need to discuss a strategy first in order to decide how we want to guess the base dn. Does it seem better to check for the domain using the user agent instead of the host (assuming the first check fails)?

I like the approach, @hodyroff @jnweiger @pako81 What do you think?

[jnweiger]

I always assumed, the autodetect code would interact with the ldap server to find the base DN. :see_no_evil: Okay, is pure guesswork based on previous elements, that the user entered. I somehow disagree with the comment in https://github.com/owncloud/user_ldap/blob/71cf34e054037074901d0e9cab35d5157bde5457/lib/Wizard.php#L677 It seems to be more of a 50% gamble, if the base DN can be written in DN notation (uid=Administrator,dc=ker,dc=jw-qa,dc=owncloud,dc=works) or if it needs to be written in email notation (Administrator@ker.jw-qa.owncloud.works)

I'd suggest to allow extraction from the email form too, something like #800 should do the trick.

[jvillafanez]

How useful is to keep the check with the host? I mean, checking against ip addresses will always fail, and checking against a hostname might or might not be right.

[dpapac]

@jnweiger What is your take on @jvillafanez comment?

[jnweiger]

I assume, nothing bad happens, if a check fails. So checking against the host does the trick, if its DNS name is within the AD Domain. Makes sense to keep that, imo.

There is a slight chance, that an unintended (but working) base DN is found by matching the hostname, while a check against the user would have found the "intended" base DN. But as this is only a "guess" feature, it is perfectly fine to err in special cases.

[jnweiger]

Confirmed fixed in user-ldap-0.18.0 with #800

Detect Base DN works with:

---

In this case only the User DN can help to find the correct value: dc=ker,dc=jw-qa,dc=owncloud,dc=works OK