I did some more checking on this, the tcpdump captures I just did show
that regardless of typing in a password, PF is connected to the AD-based
LDAP store and looking for the username. I am also seeing that the LDAP
finds the username, and then I see PF do a rebind as the username, and I
am seeing the bind come back successful.
I am seeing the password itself in the packet capture.
I did two captures, one with using a password, one without. Both LDAP
conversations work, the second LDAP query (where a password was not used
in the PF login screen) works without the password. It appears that
AD-based LDAP does allow a password-less bind when a valid username is
supplied. I have read mixed views on this being a true anonymous bind or
not. In my thinking, this is not an anonymous bind.
Anyway, so the one thing that seems broken is the check for null data in
the password field in PF.
It also appears to be the case that any user in the same LDAP search
base will also be able to login regardless of PF permission setup. To
explain this better by example:
1) user nritter and user jblow are both in the "InformationSystems"
LDAP search base.
2) User nritter is configured in admin_perm.conf, but jblow is not
3) Currently, both nritter and jblow are able to login to the
webui.
- User jblow ends up having the default permissions level as
specified in the "default_role=" of admin.perm
Separate from the null data field validation issue, is there a
configuration in PF that needs to be made to change how jblow user
scenarios like I mentioned above are dealt with?
Nick
From: Francois Gaudreault [mailto:[email protected]]
Sent: Thursday, June 30, 2011 12:14 PM
To: [email protected]
Subject: Re: [Packetfence-users] LDAP auth for webui issue in PF 2.2.1
HI Nicholas,
I updated to PF 2.2.1 last night, everything is working great with the
exception that the PF admin WebUI login is requiring a valid username
from the context I have specified in admin_ldap.conf, but ignoring the
password entered, and a password does not even need to be entered. A
tcpdump on the PF server confirms that PF is checking the username
against the LDAP server.
That's seems quite weird to me, it should also check that the password
is working by binding to the LDAP server with the user credentials.
In checking the documentation, I have no user.conf anywhere. I also
noticed in the PF 2.2.1 source distro that there is a ui.conf that I
don't have in my RPM updated 2.2.1 install (although I don't know that
that file plays any role in the WebUI setup/authentication.
user.conf is for the captive portal authentication, not the admin UI.
Upon further testing, I noticed the following when authentication to the
admin webui:
The username must be in the LDAP source specified in the admin_ldap.conf
The username does not also need to be specified in admin.perm
None of the usernames in the LDAP source exist in the admin.conf file
The username used works with and without the use of a password
Because of items 3 and 4 above, it seems that some functionality in
login.php is not work properly....I noticed that there is a function
that is supposed to check for null passwords, which does not seem to be
working. The function for validating the username against a local flat
file when no result comes from LDAP seems to not be working correctly.
AD/LDAP does not permit anonymous binds, yet somehow LDAP is being used
to some degree as revealed by tcpdump captures.
If you put no password, it should try to do an anonymous bind and fail.
If it passes, that mean that the anonymous bind pass. Can you show us
using an ldapsearch that the anonymous binds are NOT working?
--
Francois Gaudreault, ing. jr
[email protected] :: +1.514.447.4918 (x130) :: www.inverse.ca
Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence
(www.packetfence.org)
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Packetfence-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/packetfence-users
