Captive Portal login with blank password when using LDAP

[Quaid0808]

Hi.

We have discovered a bug in captive portal, at least after upgrade to 17.1.1.
Captive portal with LDAP backend allows login with blank password as long as username is correct.
If typing wrong password, access is denied, correct password is working as expected.
We have tried to delete the captive portal and installed a new in 17.1, but as long as using LDAP backend, blank password is allowed.
When using local users, then captive portal is working as expected.

Best regards,
Eyvind

[AdSchellevis]

Hi Eyvind,

You probably have anonymous binds enabled in your ldap server, leading to the acceptance of empty passwords.
A long time ago I had a similar question from another user using AD, there was a document about how to control that in windows, but I don't have it available at the moment. Google will very likely help you out here.

Our ldap connector just tries to bind using the supplied credentials.

Best regards,

Ad

[Quaid0808]

Hi. Thanks for reply.

I have not found any solution for LDAP. Tester works like it should, blank password not allowed, and connection to LDAP server is with binding (username/password).
I changed server to Radius, and then captive portal is working as expected.

I have also tried with 2 different Active Directory servers, one which was installed from start with Windows 2012 server, but the same happens here.

Also: I have OpenVPN running with same LDAP server, and here blank password is refused, so I still think there is a bug in captive portal...

Best regards,
Eyvind

[Quaid0808]

About AD and anonymous binds:

Active Directory (past Windows 2000) does not allow anonymous operations other than rootDSE searches, by default. So, if you are able to bind anonymously to Active Directory, that means one of two things. Either

    You are connecting to RootDSE, for which anonymous binds should be allowed by design.
    You have already modified Active Directory to allow anonymous binds for non-rootDSE operations and now you need to revert that configuration.

Anonymous binds to RootDSE should be allowed, because RootDSE is how most applications obtain information about the directory in order to complete further binds, such as distinguished names of various partitions, etc. No sensitive information is contained within RootDSE, and anonymous binding to RootDSE is how it was designed to work. Things will break if applications cannot bind anonymously to RootDSE.

[AdSchellevis]

The ldap authentication in the captive portal is the same as the gui, so maybe you have an issue elsewhere in your configuration.

Can you check your authentication log and inspect if the authenticated user matches the one in the log?

Code: [Select]

grep AUT /var/log/portalauth.log

I don't have an ldap server at hand to test at the moment, but both diag_authentication.php and the captive portal use the same method as far as I can see:

https://github.com/opnsense/core/blob/66d982fd16b5ca7a2452ae8c6ed2df7a4852215a/src/etc/inc/auth.inc#L769-L777


https://github.com/opnsense/core/blob/master/src/opnsense/mvc/app/controllers/OPNsense/CaptivePortal/Api/AccessController.php#L141-L160

[Quaid0808]

Hi,

Output from logfile with different scenarios:
Trying a unknown user: (null password)

Feb 22 19:40:55 OPNsensetest captiveportal[60900]: DENY eyvindh (192.168.10.50) zone 0

Trying a user with wrong password:

Feb 22 19:42:08 OPNsensetest captiveportal[60900]: LDAP bind error (Invalid cred                                          entials)
Feb 22 19:42:08 OPNsensetest captiveportal[60900]: DENY eyvind (192.168.10.50) z                                          one 0

Trying a known user with blank password:
Feb 22 19:42:31 OPNsensetest captiveportal[60900]: AUTH eyvind (192.168.10.50) zone 0

Same result with correct username/password.

Best regards,
Eyvind

[AdSchellevis]

Hi Eyvind,

I checked all of the code underneath it, but can't find a logical reason why your experiencing this issue, other then weirdness on the server side (or in the standard php ldap libraries, which I don't expect).
At the moment I don't have a windows server available, but will try to install one as soon as I can find some time to check it out.

Regards,

Ad

[fabian]

May sound stupid but another idea would be rejecting passwords with a length < 1. This would force accounts to have a password set.

[AdSchellevis]

For the captive portal, I wouldn't really mind denying empty passwords, but at some point in time someone will try to authenticate a user which has a blank password intentionally and complains about it that.
From an architectural point of view, the authentication server should handle it's proper rules.

[AdSchellevis]

I just installed a 2012r2 server and checked the binding behaviour, when there's no password and the user is not known, a bind to the base dn in anonymous mode is performed. Which is accepted by default in AD.

I couldn't find a simple method to disable anonymous binds in 2012r2, so for ldap authentication I tend to follow fabian's advise here.

The following patch disallows empty ldap passwords.

Code: [Select]

opnsense-patch 741082208


[franco]

Asking for user account status or user groups would be a logical step to avoid this maybe?