Skip to content

FAQ

Jump to bottom
Deon George edited this page Feb 2, 2026 · 12 revisions

With PLA v2, there are some implementation considerations - especially for those who previously used PLA v1.

My issues are not covered below, how can I debug whats going on?

There are 3 things you should look at to debug what's going on:

  1. Perform the query with an ldap client (like ldapsearch) and see if you are getting the results you expected. If you are performing queries as anonymous, ensure your ldapsearch query is using anonymous as well. Likewise, if you are doing queries as an authed user, ensure your lpapsearch query is perform it as that user too.

  2. Look at the debugging log of your LDAP server. You may need to turn it on, or turn it up and re-do the query

  3. Look at the log for PLA, its stored in storage/logs. By default PLA doesnt have full debugging enabled, so you may need to enable that if you are not seeing your problem in the log. Set LOG_LEVEL=debug in your .env file.

Additionally, there is a demo for most servers available at https://phpldapadmin.org. Retry your operation using a demo server - this may help eliminate whether the problem is related to your environment.

If you think you have found a bug, and can provide detailed instructions so that it can be reproduced, please open an issue and provide those details.

Before opening a ticket, please check to see if it hasn't already been reported, and if it has, please provide any additional information that will help it be fixed.

TIP: Issues opened with:

  • details enabling the problem to be reproduced,
  • including (if appropriate) an LDIF with the data that exhibits the problem,
  • a patch (or a git pull request) to fix the problem

will be looked at first :)

I cannot login to PLA [LDAP_LOGIN_ATTR set to dn]

NOTE: This specifically applies if you are attempting logging in with the rootdn and the relevant password. This applies to openldap but may apply to other LDAP servers.

You can confirm this, if when using openldap, you'll see the following in your slapd log:

68049600.366eef01 0xfffe05af1ab0 conn=1105 fd=30 ACCEPT from IP=10.0.0.2:32818 (IP=0.0.0.0:389)
68049600.3677a7c9 0xfffe095fcab0 conn=1105 op=0 BIND dn="cn=admin,dc=Test" method=128
68049600.3699cba9 0xfffe095fcab0 conn=1105 op=0 BIND dn="cn=admin,dc=Test" mech=SIMPLE bind_ssf=0 ssf=0
68049600.369cb2d6 0xfffe095fcab0 conn=1105 op=0 RESULT tag=97 err=0 qtime=0.000013 etime=0.002692 text=
68049600.36eb49c9 0xfffe078f7ab0 conn=1105 op=1 SRCH base="cn=admin,dc=Test" scope=0 deref=0 filter="(objectClass=*)"
68049600.36eb93ae 0xfffe078f7ab0 conn=1105 op=1 SRCH attr=entryuuid *
68049600.37389ae3 0xfffe078f7ab0 conn=1105 op=1 SEARCH RESULT tag=101 err=32 qtime=0.000126 etime=0.005515 nentries=0 text=
68049601.0bbb6ecb 0xfffe05af1ab0 conn=1105 op=2 UNBIND
68049601.0bc180b1 0xfffe05af1ab0 conn=1105 fd=30 closed

In the above example, a login is attempted using cn=admin,dc=Test, which is also the rootdn used for one of the namespaces in the server.

olcRootDN: cn=admin,dc=Test
olcRootPW:: [ROOTDN PASSWORD]

You can see from op=0 that the BIND was successful - so a correct password was used.

However, for op=1 PLA is performing a query to retrieve the entry for cn=admin,dc=Test, which fails err=32, where this error corresponds to the error no such object.

In PLA v2, in order for a user to login to the LDAP server, there must be an existing entry already defined in the server for the user to login. The rootdn cannot be used, as the object doesnt exist.

See first time setup to create an administrator user.

I cannot login to PLA [LDAP_USERNAME empty (anonymous bind)]

If you choose not to use LDAP_USERNAME and LDAP_PASSWORD in your configuration, so that PLA browses your LDAP server with an anoymous bind by default, then you'll need to make sure that anonymous can:

  • Search the LDAP server and find entires.
  • If you specify LDAP_LOGIN_ATTR that is an attribute (eg: uid) and not dn (for DN logins), then anonymous bind searches will need to be able to search those attributes,
  • When a search is performed, the results include objectclass values unless:
    • unless you override config/pla.php and change LDAP_LOGIN_OBJECTCLASS to be blank, OR
    • change config/auth.php and disable App\Ldap\Rules\LoginObjectclassRule::class from providers.ldap.rules.

In the example below, if user bart attempted to login and supplied the correct password, he would not be successful because objectclass is not being returned by anonymous query.

> ldapsearch -vxh localhost -b 'ou=People,o=Simpsons' -s sub

# Bart Simpson, People, Simpsons
dn: cn=Bart Simpson,ou=People,o=Simpsons
cn: Bart Simpson
gidNumber: 1000
givenName: Bart
homeDirectory: /home/users/simpsons/bart
mail: bart.simpson@example.com
sn: Simpson
uid: bart
uidNumber: 1000

First time setup - how do I create an administrator user?

As per above, you cannot login to an LDAP server, using the rootdn - because it doesnt exist (and PLA needs the user to exist in the LDAP server in order to login).

Background

  • You've just installed an LDAP server, and have it running. (You will need the rootdn and password).
  • You've just installed PLA. (You will need to configure it with a temporary configuration.)

Steps

  1. Edit your PLA .env file (or set the appropriate variables - see Configuration Variables for more information.
  • LDAP_USERNAME set this to your rootdn
  • LDAP_PASSWORD set this to your rootdn's password
  • LDAP_ALLOW_GUEST set to true
  1. Browse to PLA's root URL, you are actually logged in as the rootdn and you should be able to browse the tree. DONT try and login, you are already logged in - it will only fail. The rootdn has full access to the server and can create/delete details in the namespace it is the rootdn for.
  2. Create your LDAP hierarchy, including your desired admin user
  3. Re-edit your .env file, and
    • Set LDAP_ALLOW_GUEST to false
    • Review your setting for LDAP_LOGIN_ATTR - it defaults to uid so your ldap server that you created in step 3 must have a uid attribute if you leave this. You can change it to dn, mail or any other attribute you want. (It must represent a unique value for the attribute in your tree.)
    • If you change LDAP_LOGIN_ATTR also adjust LDAP_LOGIN_ATTR_DESC as appropriate
    • Review your setting for LDAP_LOGIN_OBJECTCLASS - it defaults to posixAccount, which means your user that you created in step 3 must have a objectclass with posixAccount
    • You may also want to change LDAP_USERNAME and LDAP_PASSWORD - you can set them to blank values if you want PLA to use anonymous queries when a user isnt logged in. (Your ACLs will need to allow anonymous to query the server to find the user DN when that user is logging in.)
  4. You may want to create your ACLs, to elevate your administrator user, and restrict what regular user's can do - that is LDAP server specific, so refer to your LDAP servers' manual for details.

Clone this wiki locally