-
-
Notifications
You must be signed in to change notification settings - Fork 176
FAQ
With PLA v2, there are some implementation considerations - especially for those who previously used PLA v1.
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.
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 notdn
(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 changeLDAP_LOGIN_OBJECTCLASS
to be blank, OR - change
config/auth.php
and disableApp\Ldap\Rules\LoginObjectclassRule::class
fromproviders.ldap.rules.
- unless you override
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