[phpldapadmin] [ phpldapadmin-Bugs-3317146 ] sasl auth options unsupported

"SourceForge.net" <[email protected]> Sat, 25 Jun 2011 21:19:34 -0700
Newsgroups gmane.comp.ldap.davedap
Message-ID <[email protected]>
Bugs item #3317146, was opened at 2011-06-15 21:52
Message generated for change (Comment added) made by malibee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=498546&aid=3317146&group_id=61828

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Despot (malibee)
Assigned to: Nobody/Anonymous (nobody)
Summary: sasl auth options unsupported

Initial Comment:
- phpldadmin 1.2.1.1, direct download from Sourceforge
- OpenLDAP 2.4.21
- Apache 2.2.14
- PHP 5.3.2
- Ubuntu 10.04 (Lucid Lynx)

1. Rename config.php.example to config.php. Seems to work fine (I didn't test this extensively, but the login screen is displayed). 
2. Uncomment this line in the otherwise unmodified config.php file:

$servers->setValue('server','sasl_auth',false);

The following error results:

"Function error called incorrectly [ERROR: Setting a index [server,sasl_auth] that isnt predefined.]"

This is almost certainly a dupe of #3111146, but I don't know of a way to add myself as an affected user. The issue is show-stopper for me, so I'd like to put a bounty on it. I will donate $20 to the project once the bug is fixed.

----------------------------------------------------------------------

>Comment By: Despot (malibee)
Date: 2011-06-25 21:19

Message:
Nevermind. Turns out there was a setting in Firefox that controls the
delegation of credentials. While FF allows the Negotiate method for HTTPS
connections by default, credential delegation has to be specified manually
using the setting "network.negotiate-auth.delegation-uris" in about.config

Cheers

----------------------------------------------------------------------

Comment By: Despot (malibee)
Date: 2011-06-25 10:28

Message:
Thanks...how have you verified that you're using Negotiate instead of a
cached password? Can you still access the SANDPIT location if you set
KrbMethodK5Passwd to 'Off' and restart Apache? Also, what version of
mod_auth_kerb are you using?



----------------------------------------------------------------------

Comment By: Deon George (wurley)
Date: 2011-06-25 03:50

Message:
Sure, my config is:

        <Location /SANDPIT>
                #SSLRequireSSL
                AuthType Kerberos
                AuthName "Kerberos Login"
                KrbMethodNegotiate On
                KrbMethodK5Passwd On
                KrbAuthRealms LEENOOKS.VPN
                KrbSaveCredentials On
                Krb5KeyTab /etc/httpd/conf/keytab
                require valid-user
        </Location>


----------------------------------------------------------------------

Comment By: Despot (malibee)
Date: 2011-06-24 23:50

Message:
You're quite right about my local error issue being outside of PLA. I built
the simplest possible test PHP file, and the credentials are most
definitely not being cached, even though KrbSaveCredentials has been
explicitly set. Enabling KrbMethodK5Passwd sets the KRB5_CCNAME Apache
variable when I login using Basic Auth and seems to initiate the
credentials cache correctly, but as soon as KrbMethodK5Passwd is turned
off, I get the local error.

wurley, I know this isn't really a PLA issue, but do you mind posting your
working Apache config? Mine looks like this:

<Directory /var/www/>

       ...

        AuthType Kerberos
        AuthName "Kerberos Login"
        KrbAuthRealm REALM
        Krb5Keytab /etc/apache2/apache2.keytab
        KrbMethodK5Passwd off
        KrbSaveCredentials on
        require valid-user

        ...

</Directory>

----------------------------------------------------------------------

Comment By: Despot (malibee)
Date: 2011-06-22 23:39

Message:
Interesting, thanks for the info. Regarding your issue with loading times
over a WAN link, seems like the best approach would be to avoid restricting
access unless absolutely necessary. I suspect securing just the PLA index
page itself would be sufficient; I can't think of a scenario where
unauthorized access to icons would be a security risk.

I discovered that Apache was logging GSSAPI errors to the auth facility,
which ended up in auth.log instead of the Apache log. I'm reproducing the
error here as Google bait:

apache2: GSSAPI Error: Unspecified GSS failure.  Minor code may provide
more information (Credentials cache file '/tmp/krb5cc_33' not found)

However, access to a sample HTML document and a phpinfo() test both work
like a charm. So, more testing. Further bulletins as events warrant.

----------------------------------------------------------------------

Comment By: Deon George (wurley)
Date: 2011-06-22 04:32

Message:
My test environment is CentOS 5.5, openldap 2.3.43, php 5.3.6, apache
2.2.15, krb5 1.6.1.

I've also used negotiate, which worked fine (firebox 4.0.1 on ubuntu
10.04), except it was slow over a WAN link (due to each connection
negotiating a kerberous ticket - I'm sure there must be some caching that
I'm not using, or a better apache config that I could use - since it was
the icons that were probably having (unnecessary) tickets created between
the browser and server).

If there is something else that needs to be fixed in PLA, happy to do it,
since I'm sure others will benefit too. However, in your case, I think your
issue is outside of PLA...

----------------------------------------------------------------------

Comment By: Despot (malibee)
Date: 2011-06-22 00:11

Message:
Good article, thanks. The -2 error was resolved (for the moment) by using
Apache's Basic Auth mechanism instead of relying on GSSAPI SPNEGO in the
browser. Putting a pin in that, I've gotten as far as this:

slapd[1441]: conn=1378 op=0 BIND dn="" method=163
slapd[1441]: conn=1378 op=0 RESULT tag=97 err=14 text=SASL(0): successful
result: 
slapd[1441]: conn=1378 op=1 BIND dn="" method=163
slapd[1441]: conn=1378 op=1 RESULT tag=97 err=14 text=SASL(0): successful
result: 
slapd[1441]: conn=1378 op=2 BIND dn="" method=163
slapd[1441]: SASL [conn=1378] Failure: Inappropriate authentication

As a test I replaced the variable references in the call to ldap_sasl_bind
in ds_ldap.php with hardcoded, known-good values, and received the same
error. I believe this indicates that the inappropriate authentication issue
doesn't relate to PLA's configuration file specifically, and is part of a
larger issue with PLA's interface to PHP/LDAP. I'd be interested to know
what versions of PHP and OpenLDAP you're running; I have 5.3.2 and 2.4.2
respectively.

The issue seems larger and only tangentially related, so it might be time
to mark this bug closed. The bug on which I placed the bounty is fixed, so
I'm willing to pay up, although I would like very much to have my
configuration working before paying the bounty. I'll leave the pay now/pay
later decision to you.

----------------------------------------------------------------------

Comment By: Deon George (wurley)
Date: 2011-06-21 04:27

Message:
"Local error" normally indicates that php (or rather apache) doesnt have a
TGT. If you are using mod_auth_kerb, make sure you have "KrbSaveCredentials
on".

My configuration is basically the same as this setup, which works fine:
http://left.subtree.org/2007/06/26/phpldapadmin-and-kerberos/

----------------------------------------------------------------------

Comment By: Despot (malibee)
Date: 2011-06-20 23:24

Message:
This snippet from the PLA log file seems relevant:

[0.000]              ds(0072-017): .DS::getValue: Entered (sasl|mech)
[0.000]              ds(0072-017): .DS::getValue: Entered (sasl|realm)
[0.000]              ds(0072-017): .DS::getValue: Entered (sasl|props)
[0.008]       functions(0124-001): app_error_handler: Entered
(2|ldap_sasl_bind(): Unable to bind to server: Local
error|/usr/share/phpldapadmin/lib/ds_ldap.php|664|a:4:{s:8:"resource";i:0;s:6:"method";s:4:"user";s:5:"fargs";a:2:{i:0;i:0;i:1;s:4:"user";}
[0.001]         ds_ldap(0202-016): ldap::connect: Resource [Resource id
#25], Bind Result
[a:3:{s:2:"id";s:28:"kerberosPrincipal@REALM";s:4:"pass";s:0:"";s:6:"result";b:0;}]
[0.000]         ds_ldap(0206-016): ldap::connect: Leaving with FALSE, bind
FAILed

----------------------------------------------------------------------

Comment By: Despot (malibee)
Date: 2011-06-20 23:07

Message:
Getting closer...the PLA interface comes up, but binding to the directory
fails. The slapd logs indicate the connection is made, and then immediately
dropped. I'm going to have to look into this tomorrow; it's not immediately
apparent if this is a configuration issue or a result of the bug. It looks
as if PLA is trying to bind anonymously, but I haven't figured out a way to
get PLA to print the bind DN in its debug output.

For your reading pleasure, here's the configuration I'm using (*shakes
fist at pastebin being "under heavy load"*):

$servers = new Datastore();

$servers->newServer('ldap_pla');
$servers->setValue('server','name','LDAP');
$servers->setValue('server','host','ldap.fqdn');
$servers->setValue('server','port',389);
$servers->setValue('server','base',array('dc=fdqn,dc=com'));
$servers->setValue('login','bind_id','');
$servers->setValue('login','bind_pass','');
$servers->setValue('server','tls',false);

# SASL auth
$servers->setValue('login','auth_type','sasl');
$servers->setValue('sasl','mech','GSSAPI');
$servers->setValue('sasl','realm','REALM');
$servers->setValue('sasl','authz_id',null);
$servers->setValue('sasl','authz_id_regex','/^uid=([^,]+)(.+)/i');
$servers->setValue('sasl','authz_id_replacement','$1');
$servers->setValue('sasl','props',null);

$servers->setValue('appearance','password_hash','md5');
$servers->setValue('login','attr','dn');
$servers->setValue('login','fallback_dn',false);
#$servers->setValue('login','class',null);
$servers->setValue('server','read_only',false);
$servers->setValue('appearance','show_create',true);

$servers->setValue('auto_number','enable',true);
$servers->setValue('auto_number','mechanism','search');
$servers->setValue('auto_number','search_base',null);
$servers->setValue('auto_number','min',array('uidNumber'=>1000,'gidNumber'=>500));
$servers->setValue('auto_number','dn',null);
$servers->setValue('auto_number','pass',null);

$servers->setValue('login','anon_bind',false);
$servers->setValue('custom','pages_prefix','custom_');
$servers->setValue('unique','attrs',array('mail','uid','uidNumber'));
$servers->setValue('unique','dn',null);
$servers->setValue('unique','pass',null);

$servers->setValue('server','visible',true);
$servers->setValue('login','timeout',30);
$servers->setValue('server','branch_rename',false);
$servers->setValue('server','custom_sys_attrs',array('passwordExpirationTime','passwordAllowChangeTime'));
$servers->setValue('server','custom_attrs',array('nsRoleDN','nsRole','nsAccountLock'));
#$servers->setValue('force_may','attrs',array('uidNumber','gidNumber','sambaSID'));

----------------------------------------------------------------------

Comment By: Deon George (wurley)
Date: 2011-06-20 20:49

Message:
The config.php.example is wrong - see patch #446faf7 which shows the
correct settings.

----------------------------------------------------------------------

Comment By: Despot (malibee)
Date: 2011-06-20 20:09

Message:
Hi wurley, thanks for the update. The good news is I don't get that error
message anymore. The bad news is I get one very much like it:

Function error called incorrectly [ERROR: Setting a index
[server,sasl_mech] that isnt predefined.]

Here's the relevant section of my config file:

$servers->setValue('login','auth_type','sasl');
$servers->setValue('server','sasl_mech','GSSAPI');
$servers->setValue('server','sasl_realm','KERBEROS.REALM');
$servers->setValue('server','sasl_authz_id',null);
$servers->setValue('server','sasl_authz_id_regex','/^uid=([^,]+)(.+)/i');
$servers->setValue('server','sasl_authz_id_replacement','$1');
$servers->setValue('server','sasl_props',null);

This is with git rev #afa4a9. I did a find / -type d -name 'phpldapadmin'
to make sure there wasn't another copy of phpldapadmin lurking about. Seems
the issue is still at large. :/

----------------------------------------------------------------------

Comment By: Deon George (wurley)
Date: 2011-06-20 03:43

Message:
Please see Git patch #afa4a9 that hopefully fixes SASL/GSSAPI
authentication with PLA.

Let me know if it doesnt work for you.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=498546&aid=3317146&group_id=61828

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a 
definitive record of customers, application performance, security 
threats, fraudulent activity and more. Splunk takes this data and makes 
sense of it. Business sense. IT sense. Common sense.. 
http://p.sf.net/sfu/splunk-d2d-c1
______________________________________
phpLDAPadmin development mailing list.
To unsbuscribe: https://lists.sourceforge.net/lists/listinfo/phpldapadmin-devel
http://phpldapadmin.sourceforge.net/