On 05/05/2014 09:29 AM, Ted Strother wrote:
An indication that the password was incorrect, as in another dsgw instance that we have (from back when it was netscape directory): Authentication Failed Authentication failed because the password you supplied is incorrect. Please click the Retry button and try again. If you have forgotten the password for this entry, a directory administrator must reset the password for you.
An indication that the password was incorrect, as in another dsgw instance that we have (from back when it was netscape directory):
Authentication Failed
Authentication failed because the password you supplied is incorrect. Please click the Retry button and try again. If you have forgotten the password for this entry, a directory administrator must reset the password for you.
Ok. Must be a regression. Please file a ticket.
On Mon, May 5, 2014 at 11:26 AM, Rich Megginson wrote: On 05/05/2014 07:34 AM, Ted Strother wrote: I have a web server running dsgw which is pointing at an ldap instance on another server in the config. Searches work fine, actions tht require auth work fine when the password was correct. When an incorrect password is entered it is still accepted, a cookie is created, and as soon as an operation that requires auth is tried it errors out. Incorrect users are still rejected, it is only when a correct user but incorrect password is entered that this behavior is seen. Has anyone seen this before? What behavior are you expecting? --
On Mon, May 5, 2014 at 11:26 AM, Rich Megginson wrote:
On 05/05/2014 07:34 AM, Ted Strother wrote: I have a web server running dsgw which is pointing at an ldap instance on another server in the config. Searches work fine, actions tht require auth work fine when the password was correct. When an incorrect password is entered it is still accepted, a cookie is created, and as soon as an operation that requires auth is tried it errors out. Incorrect users are still rejected, it is only when a correct user but incorrect password is entered that this behavior is seen. Has anyone seen this before? What behavior are you expecting? --
On 05/05/2014 07:34 AM, Ted Strother wrote:
I have a web server running dsgw which is pointing at an ldap instance on another server in the config. Searches work fine, actions tht require auth work fine when the password was correct. When an incorrect password is entered it is still accepted, a cookie is created, and as soon as an operation that requires auth is tried it errors out. Incorrect users are still rejected, it is only when a correct user but incorrect password is entered that this behavior is seen. Has anyone seen this before? What behavior are you expecting?
I have a web server running dsgw which is pointing at an ldap instance on another server in the config. Searches work fine, actions tht require auth work fine when the password was correct.
When an incorrect password is entered it is still accepted, a cookie is created, and as soon as an operation that requires auth is tried it errors out. Incorrect users are still rejected, it is only when a correct user but incorrect password is entered that this behavior is seen.
Has anyone seen this before?
What behavior are you expecting?
--
Additional data points: unauthenticated binds are not allowed, ldapsearch correctly returns when Invalid credentials are entered, 389-dsgw-1.1.11-1.el6.x86_64 on a rhel6 server.
The incorrect behavior can be replicated by taking a brand new server, pointing /etc/dirsrv/dsgw/default.conf at the ldap server, copying dsgw-httpd.conf into /etc/httpd/conf.d, giving apache write access to /var/run/dirsrv/dsgw/cookies, and browsing to http://server/dsgw then trying to authenticate.
The following were created as a workaround, but it causes a separate set of issues:
{{{ [tstrothe@directory dsgw-cgi-bin]$ cat auth.wrapper
use CGI qw(:standard); use strict; use warnings;
my $DSGWRoot = '/usr/share/dirsrv/dsgw'; my $DSGWConfigFileLocation = "$DSGWRoot/config/dsgw.conf";
print "Expires: Tue, 18 May 2999 12:00:00 GMT\n";
my $authresult = /usr/lib64/dirsrv/dsgw-cgi-bin/auth.orig;
/usr/lib64/dirsrv/dsgw-cgi-bin/auth.orig
my $validity = /usr/lib64/dirsrv/dsgw-cgi-bin/dosearch; if ( index( $validity, "Invalid credentials" ) != -1 ) { print $validity; print ; /usr/lib64/dirsrv/dsgw-cgi-bin/unauth; print ; print ""; print ; exit 0; } else { print $authresult; print ""; }; [tstrothe@directory dsgw-cgi-bin]$ cat doauth.wrapper
/usr/lib64/dirsrv/dsgw-cgi-bin/dosearch
/usr/lib64/dirsrv/dsgw-cgi-bin/unauth
my $authresult = /usr/lib64/dirsrv/dsgw-cgi-bin/doauth.orig; my $validity = /usr/lib64/dirsrv/dsgw-cgi-bin/dosearch; if ( index( $validity, "Invalid credentials" ) != -1 ) { print $validity; print ; /usr/lib64/dirsrv/dsgw-cgi-bin/unauth; print ; print ""; exit 0; } else { print $authresult; }; [tstrothe@directory dsgw-cgi-bin]$ cat lang.wrapper
/usr/lib64/dirsrv/dsgw-cgi-bin/doauth.orig
my $cgi = new CGI; my $UID = $cgi->param('uid'); my $templateName = $cgi->param('templateName'); my $cookie = $cgi->cookie('nsdsgwauth');
my $AuthDN; if ($cgi->cookie('nsdsgwauth') =~ /^[a-f0-9]+:(.*)$/i) { $AuthDN = $1; }; my ($AuthID) = split(',', $AuthDN); my ($AuthPassword) = split(':', $cookie);
if ( $AuthPassword eq '[unauthenticated]' ) { system ( "/usr/lib64/dirsrv/dsgw-cgi-bin/lang.orig" ); } else { my $validity = /usr/lib64/dirsrv/dsgw-cgi-bin/dosearch;
if ( index( $validity, "Invalid credentials" ) != -1 ) { print $validity; print ; system ( "/usr/lib64/dirsrv/dsgw-cgi-bin/unauth" ); print ; print ""; exit 0; }; system ( "/usr/lib64/dirsrv/dsgw-cgi-bin/lang.orig" ); };
[tstrothe@directory dsgw-cgi-bin]$ cat search.wrapper
if ( $AuthPassword eq '[unauthenticated]' ) { system ( "/usr/lib64/dirsrv/dsgw-cgi-bin/search.orig" ); } else { my $validity = /usr/lib64/dirsrv/dsgw-cgi-bin/dosearch;
if ( index( $validity, "Invalid credentials" ) != -1 ) { print $validity; print ; system ( "/usr/lib64/dirsrv/dsgw-cgi-bin/unauth" ); print ; print ""; exit 0 }; system ( "/usr/lib64/dirsrv/dsgw-cgi-bin/search.orig" ); };
}}}
Here is a patch that fixed it:
[tstrothe@directory-dev 389-dsgw-tstrothe]$ diff -Naur /usr/local/src/389-dsgw-orig/doauth.c doauth.c --- /usr/local/src/389-dsgw-orig/doauth.c 2013-08-20 16:08:15.000000000 -0400 +++ doauth.c 2016-06-14 15:18:37.458767411 -0400 @@ -65,13 +65,18 @@
cred.bv_val = password; cred.bv_len = strlen(password);
Replying to [comment:5 tstrothe]:
Here is a patch that fixed it: Thank you so much for providing a patch. Could it be possible to create a git patch file and attach it to this ticket? Thanks!
The modification was made to the source tarball: http://www.port389.org/binaries/389-dsgw-1.1.11.tar.bz2
And it was done by a co-worker (cche@umich.edu) so unfortunately I can't do a git patch
attachment 0001-auth-regression-fix-47795.patch
Metadata Update from @tstrothe: - Issue set to the milestone: 389-dsgw 1.1.12
DSGW is deprecated, closing ticket
Metadata Update from @mreynolds: - Custom field reviewstatus adjusted to None - Issue close_status updated to: wontfix - Issue status updated to: Closed (was: Open)
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/1126
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.