Anonymous_User Absent Member.
Absent Member.
1061 views

LDAPS error when accessing SSPR via Internet


Hi,
We have a Entrust GetAccess protected web portal. When redirecting to
SSPR on intranet e.g.
http://<pr.eu.company.biz>/SSPR/public/CommandServlet?processAction=checkExpire
all works fine. However, when accessing from the internet on
https://<eu.company.com>/SSPR/public/CommandServlet?processAction=checkExpire
get a -669 error failing to bind ldaps.
The internet connection is SSL terminated so all traffic is converted to
http. Is this a firewall or SSPR issue?
Thanks
Mark


--
mratcliffe
------------------------------------------------------------------------
mratcliffe's Profile: https://forums.netiq.com/member.php?userid=3754
View this thread: https://forums.netiq.com/showthread.php?t=49299

0 Likes
5 Replies
Anonymous_User Absent Member.
Absent Member.

Re: LDAPS error when accessing SSPR via Internet

Your HTTP connection and your LDAP connections are completely independent.
Web applications like SSPR should not be making any decisions about which
LDAP URL to use depending on the URL used by clients to access the web
application. As a result, I am guessing that the second system does not
work at all in any case, and you'll probably want to do some
troubleshooting on the connection between SSPR and LDAPS. In particular
I'd try using ndstrace to see what is coming in from SSPR on the
eDirectory side using the commands below:

Code:
--------------------
ndstrace
set dstrace=nodebug
dstrace +time +tags +ldap
dstrace file on
set dstrace=*r
#perform test here with SSPR
dstrace file off
quit
--------------------

Post the resulting /var/opt/novell/eDirectory/log/ndstrace.log file.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: LDAPS error when accessing SSPR via Internet


Aaron,
No way I can see to add attachment in we b interface so have copied the
text from the trae I believer is relevant. server 10.128.133.75 is the
SSPR server. Does this indicate the issue? One point that might be
relevant is that the GetAccess web access tool connects to LDAP on port
389, though I tried temporarily pointing SSPR to LDAP server on port 389
and just got the same -669 error binding to port 389 that I got binding
to 636.
As this only happens on Internet connections is this a firewall issue?
Thanks

[24/11/2013 16:50:24.72] LDAP : DEBUG :
(10.128.133.75:3850)(0x0080:0x63) DoSearch on connection 0x177ccea0
[24/11/2013 16:50:24.72] LDAP : DEBUG :
(10.128.133.75:3850)(0x0080:0x63) Search request:
base: "ou=people,ou=partners,ou=identities,o=company"
scope:2 dereference:0 sizelimit:2 timelimit:0 attrsonly:0
filter: "(&(objectClass=nissanperson)(cn=PST0524))"
attribute: "1.1"
[24/11/2013 16:50:24.72] LDAP : DEBUG :
(10.128.133.75:3850)(0x0080:0x63) Sending search result entry
"cn=PST0524,ou=TestAccts,ou=People,ou=Partners,ou=Identities,o=company"
to connection 0x177ccea0
[24/11/2013 16:50:24.72] LDAP : INFO :
(10.128.133.75:3850)(0x0080:0x63) Sending operation result 0:"":"" to
connection 0x177ccea0
[24/11/2013 16:50:24.74] LDAP : DEBUG : New TLS connection
0x144f1638 from 10.128.133.75:3852, monitor = 0xb40, index = 10
[24/11/2013 16:50:24.74] LDAP : INFO : Monitor 0xb40 initiating
TLS handshake on connection 0x144f1638
[24/11/2013 16:50:24.74] LDAP : INFO :
(10.128.133.75:3852)(0x0000:0x00) DoTLSHandshake on connection
0x144f1638
[24/11/2013 16:50:24.91] LDAP : INFO : BIO ctrl called with
unknown cmd 7
[24/11/2013 16:50:24.91] LDAP : INFO :
(10.128.133.75:3852)(0x0000:0x00) Completed TLS handshake on connection
0x144f1638
[24/11/2013 16:50:24.91] LDAP : DEBUG :
(10.128.133.75:3852)(0x0001:0x60) DoBind on connection 0x144f1638
[24/11/2013 16:50:24.91] LDAP : DEBUG :
(10.128.133.75:3852)(0x0001:0x60) Bind
name:cn=PST0524,ou=TestAccts,ou=people,ou=partners,ou=identities,o=company,
version:3, authentication:simple
[24/11/2013 16:50:25.16] LDAP : DEBUG : New cleartext connection
0x143c9008 from 10.128.148.2:65355, monitor = 0xb40, index = 31
[24/11/2013 16:50:28.08] LDAP : WARN :
(10.128.133.75:3852)(0x0001:0x60) Failed to authenticate local on
connection 0x144f1638, err = failed authentication (-669)
[24/11/2013 16:50:28.08] LDAP : INFO :
(10.128.133.75:3852)(0x0001:0x60) Sending operation result 49:"":"NDS
error: failed authentication (-669)" to connection 0x144f1638
[24/11/2013 16:50:28.08] LDAP : INFO : Monitor 0xb40 found
connection 0x144f1638 ending TLS session
[24/11/2013 16:50:28.08] LDAP : INFO :
(10.128.133.75:3852)(0x0000:0x00) DoTLSShutdown on connection
0x144f1638
[24/11/2013 16:50:28.08] LDAP : INFO :
(10.128.133.75:3852)(0x0000:0x00) Connection 0x144f1638 read failure,
setting err = -5875
[24/11/2013 16:50:28.08] LDAP : INFO : Monitor 0xb40 found
connection 0x144f1638 socket failure, err = -5875, 0 of 0 bytes read
[24/11/2013 16:50:28.08] LDAP : INFO : Monitor 0xb40 initiating
close for connection 0x144f1638
[24/11/2013 16:50:28.08] LDAP : INFO : Server closing connection
0x144f1638, socket error = -5875
[24/11/2013 16:50:28.08] LDAP : INFO : Connection 0x144f1638
closed
[24/11/2013 16:50:33.64] LDAP : DEBUG :
(10.128.133.75:3850)(0x0081:0x63) DoSearch on connection 0x177ccea0
[24/11/2013 16:50:33.64] LDAP : DEBUG :
(10.128.133.75:3850)(0x0081:0x63) Search request:
base: "ou=people,ou=partners,ou=identities,o=company"
scope:2 dereference:0 sizelimit:2 timelimit:0 attrsonly:0
filter: "(&(objectClass=nissanperson)(cn=PST0524))"
attribute: "1.1"
[24/11/2013 16:50:33.64] LDAP : DEBUG :
(10.128.133.75:3850)(0x0081:0x63) Sending search result entry
"cn=PST0524,ou=TestAccts,ou=People,ou=Partners,ou=Identities,o=company"
to connection 0x177ccea0
[24/11/2013 16:50:33.64] LDAP : INFO :
(10.128.133.75:3850)(0x0081:0x63) Sending operation result 0:"":"" to
connection 0x177ccea0
[24/11/2013 16:50:33.64] LDAP : DEBUG : New TLS connection
0x144f1638 from 10.128.133.75:3853, monitor = 0xb40, index = 10
[24/11/2013 16:50:33.64] LDAP : INFO : Monitor 0xb40 initiating
TLS handshake on connection 0x144f1638
[24/11/2013 16:50:33.64] LDAP : INFO :
(10.128.133.75:3853)(0x0000:0x00) DoTLSHandshake on connection
0x144f1638
[24/11/2013 16:50:33.85] LDAP : INFO : BIO ctrl called with
unknown cmd 7
[24/11/2013 16:50:33.85] LDAP : INFO :
(10.128.133.75:3853)(0x0000:0x00) Completed TLS handshake on connection
0x144f1638
[24/11/2013 16:50:33.85] LDAP : DEBUG :
(10.128.133.75:3853)(0x0001:0x60) DoBind on connection 0x144f1638
[24/11/2013 16:50:33.85] LDAP : DEBUG :
(10.128.133.75:3853)(0x0001:0x60) Bind
name:cn=PST0524,ou=TestAccts,ou=people,ou=partners,ou=identities,o=company,
version:3, authentication:simple
[24/11/2013 16:50:34.49] LDAP : DEBUG : New cleartext connection
0x143c8d30 from 10.128.148.60:52448, monitor = 0xb40, index = 32
[24/11/2013 16:50:34.50] LDAP : INFO : Monitor 0xb40 found
connection 0x143c8d30 socket closed, err = -5871, 0 of 0 bytes read
[24/11/2013 16:50:34.50] LDAP : INFO : Monitor 0xb40 initiating
close for connection 0x143c8d30
[24/11/2013 16:50:34.50] LDAP : INFO : Server closing connection
0x143c8d30, socket error = -5871
[24/11/2013 16:50:34.50] LDAP : INFO : Connection 0x143c8d30
closed
[24/11/2013 16:50:36.97] LDAP : WARN :
(10.128.133.75:3853)(0x0001:0x60) Failed to authenticate local on
connection 0x144f1638, err = failed authentication (-669)
[24/11/2013 16:50:36.97] LDAP : INFO :
(10.128.133.75:3853)(0x0001:0x60) Sending operation result 49:"":"NDS
error: failed authentication (-669)" to connection 0x144f1638
[24/11/2013 16:50:36.97] LDAP : INFO : Monitor 0xb40 found
connection 0x144f1638 ending TLS session
[24/11/2013 16:50:36.97] LDAP : INFO :
(10.128.133.75:3853)(0x0000:0x00) DoTLSShutdown on connection
0x144f1638
[24/11/2013 16:50:36.97] LDAP : INFO :
(10.128.133.75:3853)(0x0000:0x00) Connection 0x144f1638 read failure,
setting err = -5875
[24/11/2013 16:50:36.97] LDAP : INFO : Monitor 0xb40 found
connection 0x144f1638 socket failure, err = -5875, 0 of 0 bytes read
[24/11/2013 16:50:36.97] LDAP : INFO : Monitor 0xb40 initiating
close for connection 0x144f1638
[24/11/2013 16:50:36.97] LDAP : INFO : Server closing connection
0x144f1638, socket error = -5875
[24/11/2013 16:50:36.97] LDAP : INFO : Connection 0x144f1638
closed
[24/11/2013 16:50:40.19] LDAP : DEBUG : New cleartext connection
0x144f1638 from 10.128.148.59:36061, monitor = 0xb40, index = 10
[24/11/2013 16:50:40.19] LDAP : INFO : Monitor 0xb40 found
connection 0x144f1638 socket closed, err = -5871, 0 of 0 bytes read
[24/11/2013 16:50:40.19] LDAP : INFO : Monitor 0xb40 initiating
close for connection 0x144f1638
[24/11/2013 16:50:40.19] LDAP : INFO : Server closing connection
0x144f1638, socket error = -5871
[24/11/2013 16:50:40.19] LDAP : INFO : Connection 0x144f1638
closed


--
mratcliffe
------------------------------------------------------------------------
mratcliffe's Profile: https://forums.netiq.com/member.php?userid=3754
View this thread: https://forums.netiq.com/showthread.php?t=49299

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: LDAPS error when accessing SSPR via Internet


Aaron,
We have run a test with our networks guys with SSPR connecting to LDAP
on port 389. They report the password field in the packet that sspr
sends to LDAP contains the text:

BOGUS_PASSWORD
then the ldap server replies with the following info:
bind response
invalid credentials
NDS error: failed authentication

What would be setting BOGUS_PASSWORD


--
mratcliffe
------------------------------------------------------------------------
mratcliffe's Profile: https://forums.netiq.com/member.php?userid=3754
View this thread: https://forums.netiq.com/showthread.php?t=49299

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: LDAPS error when accessing SSPR via Internet

Good question. I'm a bit lost on that, and would guess something other
than SSPR is doing that, but I do not know how to nail that down. I have
downloaded the full PWM source code and do not see any instance of 'bogus'
(case-insensitive search) in there so unless that was added in SSPR and
also not available in the clear in my deployed 'sspr30' directory then
that would seem to confirm something else is getting in the way.

My only likely guess on why this would happen with 389 is that some
application is trying to check for the LDAP server to return an error 13
(confidentiality required) just in case TLS needs to be enabled in one
form or another. This error is returned by eDirectory (and other
services) by default when trying to bind with a password on a non-SSLized
(TCP 389 by default) connection without implementing the STARTTLS (TLS
within LDAP) control to protect the credentials, indicating to the client
that "You are sending a password so now protect it with security somehow."
The only problem with this error message is that it usually happens after
the credentials have been sent across the wire in the clear, unprotected
form. Having something send a 'BOGUS_PASSWORD' value first, while causing
a failed login once, would let the client side determine if it needs to
use TLS to secure the credentials or if a subsequent attempt with the real
password is likely to work.

My recommendation at this point is to test away from the firewall.
Configure Apache Tomcat to use HTTPS on 8443 or whatever port and have it
all work, and then compare with what you are seeing in your current
environment. Considering the trouble you're having my guess is that it is
something in your environment like the firewall or other intermediate
applications (the Entrust stuff perhaps?).

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: LDAPS error when accessing SSPR via Internet


Yes it is looking more like the Entrust stuff. We have tracked where
the BOGUS_PASSWORD is set. The correct userid and password comes in
from the SSL terminator to the MS ISA proxy servers which are also
Entrust GetAccess runtimes (agents in Access Manager terminology). The
ISAs send out the userid and BOGUS_PASSWORD to the SSPR server.
Therefore, our suspicion is the GetAccess runtime on the ISA is where
the problem is. I have raised this with Entrust now.
Will let you know when we get it resolved.


--
mratcliffe
------------------------------------------------------------------------
mratcliffe's Profile: https://forums.netiq.com/member.php?userid=3754
View this thread: https://forums.netiq.com/showthread.php?t=49299

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.