Table of Contents
← Hide Table of Contents
Active Directory Integration: Troubleshooting
Active Directory Integration: TroubleshootingIf you encounter an issue configuring MIDAS to authenticate against your Active Directory, a good place to start is the "Test" button on the MIDAS Admin Options → Manage Users & Permissions → Single-Sign On (SSO). This button will test whether MIDAS is able to connect to and query the Active Directory using the settings you've specified.
If this test fails, these settings are the first thing to check.
You can also enable debug logging by selecting the "Enable Debug Logging" option and clicking "Save Changes". With debugging enabled, failed and successful LDAP authentications will be logged to a "/debug-ldap.dat" file in your MIDAS directory.
Warning: It is recommended to only enable Debug logging whilst troubleshooting integration with your AD. Once up and running, it's strongly advised to disable this logging, otherwise the log file can become very large!
Common issues, their causes and resolutions are outlined in the table below...
| Symptom | Possible Cause(s) | Resolution |
| Integration Test fails with "An error occurred binding to the LDAP server: [82] An error occurred in C<Net::LDAP>" | A bug exists in some recent versions of ActivePerl (and also Strawberry Perl) which may prevent the Net::LDAP module from functioning correctly. | The workaround (other than installing an earlier version of Perl) is to rename the "INET6.pm" module within your current Perl distribution to something else. INET6.pm provides IPv6 support for Perl, and can commonly be found at C:\Perl64\site\lib\IO\Socket\INET6.pm (depending upon the location of Perl on your system). For more information on this workaround, please see this post. If you have other Perl applications still requiring INET6.pm, an alternative potential workaround also exists. |
| Integration Test fails with "Unable to determine the currently logged in user" | This indicates that your server has not been correctly configured to support Active Directory authentication at the location from which you're running the ADtest tool | Please make sure you've followed the steps for configuring your server carefully. A common cause of this on Apache servers is not correctly configuring the <location> directive - remember, this should specify the server path of your MIDAS installation, relative to the server's document root (i.e. relative to "public_html" or "htdocs") |
| Integration Test fails with "The maximum number of search results to return has been exceeded" | An LDAP_SIZELIMIT_EXCEEDED error indicates that a search query made by MIDAS to your Active Directory returned more results than the maximum number of search results your Active Directory is currently configured to return in a single query (typically more than 1,000). This may be due to a too generic "base" setting in MIDAS, or a very large number of groups within the base of your AD that MIDAS searched. | Consider narrowing down the "Base" in which MIDAS will search your Active Directory to be more specific - See configuring MIDAS. Alternatively, you may need to increase the maximum search results limit in your Active Directory. Please refer to the documentation for your Active Directory for guidance to increase this limit. |
| After configuring and enabling LDAP integration, when I access MIDAS, I still see a login screen | If MIDAS is unable to successfully connect to and query your Active Directory, it will fall back to the standard login screen. | Go to MIDAS Admin Options → Manage Users & Permissions → Single-Sign On (SSO) and check your Active Directory settings are correct using the "Test" button |
| If there is no email address in your Active Directory for your username, the user will see the standard MIDAS login screen. | If you've enabled debug logging, this cause will be indicated in the debug log. An email address should be entered in your Active Directory for each user who will be accessing MIDAS. | |
| If there is no User Group in MIDAS with a name matching the name of the user's Primary Group setting in your Active Directory, and the "If no matching User Group exists, block access" option in MIDAS is selected, the user will see the standard MIDAS login screen. | If you've enabled debug logging, this cause will be indicated in the debug log.
| |
| If a user's MIDAS account has been "suspended", they will be returned to the login screen rather than seamlessly logged in. | If you've enabled debug logging, this cause will be indicated in the debug log. Go to MIDAS Admin Options → Manage Users & Permissions → Users and check that the user account in question hasn't been suspended. | |
| A dialog prompting for credentials is shown when accessing MIDAS | Your browser has not been configured to present the username of the currently logged-in user to the server where your MIDAS resides. | See Configuring Web Browsers |
| Unable to change user's primary group - the "Set Primary Group" button is disabled | If the "Set Primary Group" button within your Windows Active Directory, "User Properties → Member Of" dialog is disabled (greyed out), this can occur if you're trying to set a Local/built-in group as primary (such as Users, Backup Operators, etc) | Select another Global (non-built-in) user group, and the "Set Primary Group" button should become enabled. If you have not defined any other user groups, create a new global security group and you should then be able to set it as the Primary Group for individual users. Alternatively, see our "I can't change user's Primary Groups in my Active Directory, yet I need to assign different users different permissions!" FAQ entry for a workaround. |