pfSense

Jim Pingle wrote:

If the remote access server is accepting the login, what could pfSense do differently? pfSense sends the request and the server accepts it.

It's come up before but any of the suggested workarounds based on pfSense are kludges at best and do not prevent other things from authenticating against AD improperly.

It's an AD issue, not a pfSense issue. Fix your authentication server so it rejects those invalid logins.

https://forum.netgate.com/topic/139397/captive-portal-with-ad-ldap-authenticates-without-a-password

I understand your position, but this is the way AD has worked and until 2019 there is no option to stop unauthenticated binds (and upgrading is not always an option, not necessarily right away). However, there have been are still applications developed which use AD authentication and do not have this issue because using an empty password is never allowed. We too use many Windows-based and Linux-based applications with AD auth, and none works this way - authentication is not possible with just the user and no password.

The fact that the CP on pfSense allows authentication without a password while knowing how AD works is a flaw and a security risk. At least if it were documented in the pfSense documentation, one would understand the risk.

What you are saying practically, is that until everyone upgrades to Windows Server 2019 to be able to turn off unauthenticated binds, CP with AD authentication as it is by default on pfSense is not usable.

Obviously we will try then to see how we can modify the CP login page to work around this and not allow authentication with no password, but hopefully this flaw can be considered and fixed in some future version. pfSense has a good reputation and fixing an obvious security hole would help maintain that. Not even considering a fix, even if at a remote point in time really does not look good.

If nothing at all, then at least point this fact out in the pfSense documentation and warn users.

Thank you for understanding,
Aurelian

pfSense is not allowing this behavior. AD is. pfSense can't fix your AD security or configuration. Period.

Having pfSense prevent empty passwords does nothing to stop AD from being a giant security gap in this case. Anything else that hits AD would have the same issue, and trying to solve it anywhere other than AD is negligent from a security standpoint. If you have a problem with that, take it up with Microsoft, not us.

There are patches in the thread I linked that some have used to hack around the awful AD behavior, but it won't be changed in pfSense releases since it's not a pfSense problem.

You could use NPS instead of using LDAP and still use AD via RADIUS.

Aurelian Rau wrote:

Jim Pingle wrote:

If the remote access server is accepting the login, what could pfSense do differently? pfSense sends the request and the server accepts it.

It's come up before but any of the suggested workarounds based on pfSense are kludges at best and do not prevent other things from authenticating against AD improperly.

It's an AD issue, not a pfSense issue. Fix your authentication server so it rejects those invalid logins.

https://forum.netgate.com/topic/139397/captive-portal-with-ad-ldap-authenticates-without-a-password

I understand your position, but this is the way AD has worked and until 2019 there is no option to stop unauthenticated binds (and upgrading is not always an option, not necessarily right away). However, there have been are still applications developed which use AD authentication and do not have this issue because using an empty password is never allowed. We too use many Windows-based and Linux-based applications with AD auth, and none works this way - authentication is not possible with just the user and no password.

The fact that the CP on pfSense allows authentication without a password while knowing how AD works is a flaw and a security risk. At least if it were documented in the pfSense documentation, one would understand the risk.

Please check the "Add option to (dis)allow unauthenticated LDAP binds" feature #9909

Viktor Gurov wrote:

Please check the "Add option to (dis)allow unauthenticated LDAP binds" feature #9909

Thank you Viktor, this is useful.

I know we all love to hate Microsoft, but that does not solve anything - this does.

Until version 2.5 comes we will use the other work-arounds.

Thank you,
Aurelian