Skip to content

FAQ

Jump to bottom
Deon George edited this page May 26, 2025 · 3 revisions

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

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.

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: [email protected]
sn: Simpson
uid: bart
uidNumber: 1000
Clone this wiki locally