On RHEL 7.4, Apache/2.4.6 using mod_authnz_ldap.so and AuthLDAPInitialBindAsUser config.

The configuration is to do LDAP authentication by binding as the user logging on.

When the user is prompted for his username/password in the "Authentication required" popup:

  • If the user and either leaves the two fields blank or only enter his username and leaves the password field blank and hits "OK", he gets a page with "The server encountered an internal error or misconfiguration and was unable to complete your request." - there's no error in /var/log/httpd/error_log
  • If the user enters an invalid username and/or invalid password, the system reacts normally and presents the popup again.
  • If the user enters the correct username and password, the system reacts normally and is presented the desired web page.

How to prevent this error page?


<VirtualHost *:80>
    ServerName kibana.mydomain.com
    ProxyPass /
    ProxyPassReverse /

    <Location "/app/kibana">
        AuthType basic
        AuthName "LDAP Login"
        AuthBasicProvider ldap
        AuthLDAPURL "ldap://ldap.mydomain/dc=example,dc=com?sAMAccountName?sub?(objectClass=*)"
        AuthLDAPInitialBindAsUser on
        AuthLDAPInitialBindPattern (.*) "CN=$1,ou=users,dc=example,dc=com"
        Require valid-user


I set LDAPLibraryDebug 7 and got the following error message in /var/log/httpd/error_log

res_errno: 1, res_error: <000004DC: LdapErr: DSID-0C09075A, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v1db1>, res_matched: <> ldap_free_request (origid 2, msgid 2) ldap_parse_result ldap_err2string [Thu Nov 29 20:36:09.068006 2018] [authnz_ldap:info] [pid 25551] [client] AH01695: auth_ldap authenticate: user authentication failed; URI /home/debug.jsp [ldap_search_ext_s() for user failed] [Operations error] <---- *this should result in authentication failure not Operation errors which cannot be handled by the http landler and ends up as an internal server error*

The message "In order to perform this operation a successful bind must be completed on the connection." leads me to believe that the module is attempting to perform another operation even though the binding is incomplete. But it should actually react exactly like when the password is invalid or when the username was not provided.

Error message when the username is passed but the password field is left empty:

[Thu Nov 29 20:48:48.818805 2018] [authnz_ldap:info] [pid 25550] [client] AH01695: auth_ldap authenticate: user the.user authentication failed; URI /home/debug.jsp [LDAP: ldap_simple_bind() failed][Invalid credentials] [Thu Nov 29 20:48:48.818833 2018] [auth_basic:error] [pid 25550] [client] AH01617: user the.user: authentication failure for "/home/debug.jsp": Password Mismatch

Error message when no user name is entered but there is a value in the password field

[Thu Nov 29 20:49:18.720210 2018] [authnz_ldap:info] [pid 25549] [client] AH01695: auth_ldap authenticate: user authentication failed; URI /home/debug.jsp [LDAP: ldap_simple_bind() failed][Invalid credentials] [Thu Nov 29 20:49:18.720222 2018] [auth_basic:error] [pid 25549] [client] AH01617: user : authentication failure for "/home/debug.jsp": Password Mismatch

Message when a correct username/password

[Thu Nov 29 20:53:29.658294 2018] [authnz_ldap:debug] [pid 25551] mod_authnz_ldap.c(593): [client] AH01697: auth_ldap authenticate: accepting the.user [Thu Nov 29 20:53:29.658328 2018] [authz_core:debug] [pid 25551] mod_authz_core.c(809): [client] AH01626: authorization result of Require valid-user : granted [Thu Nov 29 20:53:29.658338 2018] [authz_core:debug] [pid 25551] mod_authz_core.c(809): [client] AH01626: authorization result of : granted [Thu Nov 29 20:53:29.658546 2018] [proxy:debug] [pid 25551] mod_proxy.c(1123): [client] AH01143: Running scheme http handler (attempt 0)

  • 1
    You need to ensure you're fully patched. RH7.4 is old and out of date; yum update should bring it up to 7.5 with all published patches. It's very possible that mod_auth_ldap has been changed to fix this. Dec 3, 2018 at 1:00

2 Answers 2


Here is another post about the same issue. The solution proposed there (which worked for me when I encountered this issue) is to add this option to your LDAP config:

AuthLDAPBindAuthoritative off

From the Apache docs:

By default, subsequent authentication providers are only queried if a user cannot be mapped to a DN, but not if the user can be mapped to a DN and their password cannot be verified with an LDAP bind. If AuthLDAPBindAuthoritative is set to off, other configured authentication modules will have a chance to validate the user if the LDAP bind (with the current user's credentials) fails for any reason.

So it seems setting this option to off makes Apache convert the error into an attempt to query the non-existent next authentication provider. When this fails, the expected 401 error page is displayed instead of 500.


I believe there is no error, just that your error page for that particular issue is set to default. I would suggest finding a way to set the on password error page to the one you specify.

If you want to look at it better enable the LDAPLibraryDebug

More Information: Apache Mods: mod_authnz_ldap

Video with Config: YouTube Video on LDAP

  • Could you provide your reasoning behind this with a link to either official documentation stating that this is expected behavior or an article/blog/forum post explaining this behavior?
    – kemotep
    Nov 27, 2018 at 22:26
  • 1
    My reasoning is that there' no errors passed. The correct password and user work. Invalid options don't create errors nor allow access. Leaving both empty, resulting in an error message to the user, but not in the logs. Makes me think that the fields both being empty just needs a setting to tell what error page to throw. Nov 27, 2018 at 22:51
  • Thank you for adding the additional context to your post.
    – kemotep
    Nov 28, 2018 at 1:57
  • 1
    I don't think that a distinction of not having provided a user/password, or only the username or only the password is made. If the user did not pass a user/password, it should be a standard HTTP 401 Unauthorized, not an "Internal Server Error" - hence the updated problem above and the first quote showing what I found in /var/log/httpd/error_log
    – Mike
    Nov 30, 2018 at 2:10
  • Of course, an empty password is not going to match, if there is a password, which we have already established there is. 0 can't = 1. The same goes for if the user field is empty, is there a user with no name that has a password to match the one provided. It is a logic circuit. It is just some were that a setting is just missing or pointing in the wrong place. Nov 30, 2018 at 3:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .