You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-user@db.apache.org by Thomas <Th...@t-online.de> on 2011/01/16 20:47:04 UTC
Trying to migrate to LDAP (but getting Error 08004)
Thanks for reading my post. Any help to get Derby work with LDAP would be
greatly appreciated.
What I am trying to achieve and what I have done so far:
I would like to prepare my system for production use and migrate off the
BUILTIN authentication system to use LDAP as external directory service.
My testing environment is Apache Derby 10.7.1 on a stable Debian 5.x Lenny
server running on my own local area network and accessed from a Windows XP
client on the same network. As LDAP server I have chosen ApacheDS 1.5.7
which is running on the same server machine as the Derby Network Server.
While trying to get Derby to speak to my LDAP server I have for now
turned off SSL.
The following preparations have been taken on the Derby side:
(the server machine is called 'miniserver')
export DERBY_HOME=/var/lib/derby/db-derby-10.7.1.1-bin
java -jar -Dderby.system.home=/var/lib/derby/db-derby-10.7.1.1-data
$DERBY_HOME/lib/derbyrun.jar server start -h 0.0.0.0
java -jar -Dderby.system.home=/var/lib/derby/db-derby-10.7.1.1-data
$DERBY_HOME/lib/derbyrun.jar ij
connect 'jdbc:derby://miniserver:1527/ldaptest;create=true';
CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(
'derby.connection.requireAuthentication', 'true');
CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(
'derby.authentication.provider','LDAP');
CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(
'derby.authentication.server','miniserver:10389');
CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(
'derby.authentication.ldap.searchBase','o=THMB');
CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(
'derby.user.thill','uid=thill,o=THMB');
CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(
'derby.database.sqlAuthorization', 'true');
connect 'jdbc:derby://miniserver:1527/ldaptest;shutdown=true';
(all these statement execute without any problem)
jndi.jar, ldap.jar and providerutil.jar are part of my CLASSPATH,
the jar files have also been copied into the $DERBY_HOME$/lib folder
and also the complete folder structure for jndi112 and LDAP103 as
downloaded from the Oracle/SUN homepage were copied into derby.system.home.
ApacheDS is running fine and two test users (one with uid=thill and
userPassword=xx) have been defined in my directory.
====> IMPORTANT: Accessing the directory from Apache Directory Studio
and/or by using the java program AdvancedBindDemo which can be found
on the ApacheDS tutorial is working as expected!!, i.e. I can
successfully bind with uid=thill, o=thmb and userPassword xx.
So I am assuming the server side is in good shape.
However when trying to speak to Directory Server from Derby/IJ I am
getting error messages.
Here is my connect statement:
connect 'jdbc:derby://miniserver:1527/ldaptest;user=thill;password=xx';
and the trace output (I have added line breaks as needed to allow
posting here):
BEGIN TRACE_DRIVER_CONFIGURATION
Driver: Apache Derby Network Client JDBC Driver 10.7.1.1 - (1040133)
Compatible JRE versions: { 1.3, 1.4 }
Range checking enabled: true
Bug check level: 0xff
Default fetch size: 64
Default isolation: 2
No security manager detected.
Detected local client host: miniserver/127.0.1.1
JDBC 1 system property jdbc.drivers = null
Java Runtime Environment version 1.6.0_22
Java Runtime Environment vendor = Sun Microsystems Inc.
Java vendor URL = http://java.sun.com/
Java installation directory = /usr/lib/jvm/java-6-sun-1.6.0.22/jre
Java Virtual Machine specification version = 1.0
Java Virtual Machine specification vendor = Sun Microsystems Inc.
Java Virtual Machine specification name = Java Virtual Machine
Specification
Java Virtual Machine implementation version = 17.1-b03
Java Virtual Machine implementation vendor = Sun Microsystems Inc.
Java Virtual Machine implementation name = Java HotSpot(TM) Client VM
Java Runtime Environment specification version = 1.6
Java Runtime Environment specification vendor = Sun Microsystems Inc.
Java Runtime Environment specification name = Java Platform API Specification
Java class format version number = 50.0
Java class path = /var/lib/derby/db-derby-10.7.1.1-bin/lib/derbyrun.jar
Java native library path = /usr/lib/jvm/java-6-sun-1.6.0.22/jre/lib
/i386/client:
/usr/lib/jvm/java-6-sun-1.6.0.22/jre/lib/i386:/usr/lib/jvm
/java-6-sun-1.6.0.22/jre/../lib/i386:/usr/java/packages/lib/i386:/lib:/usr/lib
Path of extension directory or directories = /usr/lib/jvm
/java-6-sun-1.6.0.22/jre/lib/ext:/usr/java/packages/lib/ext
Operating system name = Linux
Operating system architecture = i386
Operating system version = 2.6.26-2-686
File separator ("/" on UNIX) = /
Path separator (":" on UNIX) = :
User's account name = root
User's home directory = /root
User's current working directory = /root
END TRACE_DRIVER_CONFIGURATION
BEGIN TRACE_CONNECTS
Attempting connection to miniserver:1527/ldaptest;traceFile=/root/trace.out
Using properties: { user=thill, traceFile=/root/trace.out, password=** }
END TRACE_CONNECTS
[net][time:1295204362513][thread:main][tracepoint:1][Request.flush]
SEND BUFFER: EXCSAT (ASCII) (EBCDIC)
0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF 0123456789ABCDEF
0000 006AD04100010064 10410010115E8485 .j.A...d.A...^.. .|}..........;de
0010 9982A88495839481 89950009116DC485 .............m.. rbydncmain..._De
0020 9982A80021115AC4 D5C3F1F0F0F7F061 ....!.Z........a rby...!DNC10070/
0030 F1F04BF74BF14BF1 4060404DF1F0F4F0 ..K.K.K.@`@M.... 10.7.1.1 - (1040
0040 F1F3F35D00181404 1403000724070007 ...]........$... 133)............
0050 240F000714400007 1C0804B8000E1147 $....@.........G ..... ..........
0060 D8C4C5D9C2E861D1 E5D4 ......a... QDERBY/JVM
SEND BUFFER: ACCSEC (ASCII) (EBCDIC)
0000 0036D00100020030 106D000611A20003 .6.....0.m...... ..}......_...s..
0010 0026211093848197 A385A2A35EA39981 .&!.........^... ....ldaptest;tra
0020 8385C68993857E61 999696A361A39981 ......~a....a... ceFile=/root/tra
0030 83854B96A4A3 ..K... ce.out
[net][time:1295204362515][thread:main][tracepoint:2][Reply.fill]
RECEIVE BUFFER: EXCSATRD (ASCII) (EBCDIC)
0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF 0123456789ABCDEF
0000 0088D04200010082 1443001D115ED585 ...B.....C...^.. .h}....b.....;Ne
0010 A3A6969992E28599 A58599C39695A399 ................ tworkServerContr
0020 9693409481899500 1814041403000724 ..@............$ ol main.........
0030 070007240F000714 4000071C0804B800 ...$....@....... ........ .......
0040 101147C197818388 8540C4859982A800 ..G......@...... ...Apache Derby.
0050 18116DD585A3A696 9992E28599A58599 ..m............. .._NetworkServer
0060 C39695A399969300 21115AC3E2E2F1F0 ........!.Z..... Control...!CSS10
0070 F0F7F061F1F04BF7 4BF14BF14060404D ...a..K.K.K.@`@M 070/10.7.1.1 - (
0080 F1F0F4F0F1F3F35D .......] 1040133)
RECEIVE BUFFER: ACCSECRD (ASCII) (EBCDIC)
0000 0010D0020002000A 14AC000611A20003 ................ ..}..........s..
[net][time:1295204362543][thread:main][tracepoint:1][Request.flush]
SEND BUFFER: SECCHK (ASCII) (EBCDIC)
0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF 0123456789ABCDEF
0000 0045D0410001003F 106E000611A20003 .E.A...?.n...... ..}......>...s..
0010 002621106C646170 746573743B747261 .&!.ldaptest;tra ....%./......../
0020 636546696C653D2F 726F6F742F747261 ceFile=/root/tra ....%....??..../
0030 63652E6F75740009 11A07468696C6C00 ce.out....thill. ...?.........%%.
0040 0611A12A2A ...** ..~..
SEND BUFFER: ACCRDB (ASCII) (EBCDIC)
0000 00B8D001000200B2 2001002621106C64 ........ ..&!.ld ..}...........%.
0010 6170746573743B74 7261636546696C65 aptest;traceFile /......../....%.
0020 3D2F726F6F742F74 726163652E6F7574 =/root/trace.out ...??..../...?..
0030 0006210F2407000C 112E444E43313030 ..!.$.....DNC100 ...........+....
0040 3730003C210437C4 D5C3F1F0F0F7F0D1 70.<!.7......... .......DNC10070J
0050 E5D4404040404040 4040404040404040 ..@@@@@@@@@@@@@@ VM
0060 4084859982A88495 8394818995404040 @............@@@ derbydncmain
0070 4040404040404040 404040404000000D @@@@@@@@@@@@@... ...
0080 002F51544453514C 41534300172135D5 ./QTDSQLASC..!5. .......<.......N
0090 C6F0F0F0F1F0F12E D7F2C3C4012D9032 .............-.2 F000101.P2CD....
00A0 2917001600350006 119C04B80006119D )....5.......... ................
00B0 04B00006119E04B8 ........ ........
[net][time:1295204363203][thread:main][tracepoint:2][Reply.fill]
RECEIVE BUFFER: SECCHKRM (ASCII) (EBCDIC)
0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF 0123456789ABCDEF
0000 0015D0020001000F 1219000611490008 .............I.. ..}.............
0010 000511A413 ..... ...u.
BEGIN TRACE_DIAGNOSTICS
[derby][SQLException@22c95b] java.sql.SQLException
[derby][SQLException@22c95b] SQL state = 08004
[derby][SQLException@22c95b] Error code = 40000
[derby][SQLException@22c95b] Message = Connection authentication failure
occurred. Reason: userid or password invalid.
[derby][SQLException@22c95b] Stack trace follows
org.apache.derby.client.am.SqlException: Connection authentication failure
occurred. Reason: userid or password invalid.
at org.apache.derby.client.net.NetConnection.
mapSecchkcd(Unknown Source)
at org.apache.derby.client.net.NetConnection.
securityCheckComplete(Unknown Source)
at org.apache.derby.client.net.NetConnectionReply.
parseSECCHKRM(Unknown Source)
at org.apache.derby.client.net.NetConnectionReply.
parseSECCHKreply(Unknown Source)
at org.apache.derby.client.net.NetConnectionReply.
readSecurityCheck(Unknown Source)
at org.apache.derby.client.net.NetConnection.
readSecurityCheckAndAccessRdb(Unknown Source)
at org.apache.derby.client.net.NetConnection.
flowSecurityCheckAndAccessRdb(Unknown Source)
at org.apache.derby.client.net.NetConnection.
flowUSRIDPWDconnect(Unknown Source)
at org.apache.derby.client.net.NetConnection.
flowConnect(Unknown Source)
at org.apache.derby.client.net.NetConnection.
<init>(Unknown Source)
at org.apache.derby.client.net.NetConnection40.
<init>(Unknown Source)
at org.apache.derby.client.net.ClientJDBCObjectFactoryImpl40.
newNetConnection(Unknown Source)
at org.apache.derby.jdbc.ClientDriver.connect(Unknown Source)
at java.sql.DriverManager.getConnection(DriverManager.java:582)
at java.sql.DriverManager.getConnection(DriverManager.java:154)
at org.apache.derby.impl.tools.ij.ij.dynamicConnection(Unknown Source)
at org.apache.derby.impl.tools.ij.ij.ConnectStatement(Unknown Source)
at org.apache.derby.impl.tools.ij.ij.ijStatement(Unknown Source)
at org.apache.derby.impl.tools.ij.utilMain.
runScriptGuts(Unknown Source)
at org.apache.derby.impl.tools.ij.utilMain.go(Unknown Source)
at org.apache.derby.impl.tools.ij.Main.go(Unknown Source)
at org.apache.derby.impl.tools.ij.Main.mainCore(Unknown Source)
at org.apache.derby.impl.tools.ij.Main.main(Unknown Source)
at org.apache.derby.tools.ij.main(Unknown Source)
at org.apache.derby.iapi.tools.run.main(Unknown Source)
END TRACE_DIAGNOSTICS
Re: Trying to migrate to LDAP (but getting Error 08004)
Posted by Bryan Pendleton <bp...@gmail.com>.
Hi Thomas,
This is great progress!
It seems to me that you have identified several places where we could improve
the Derby documentation.
And your experience with the database properties versus system properties
seems unexpected to me; I think as you do that this feels like a flaw in Derby,
and your technique of using the database properties ought to have worked.
> : miniserver:10389 [Root exception is java.security.AccessControlException:
> access denied (java.net.SocketPermission miniserver resolve)]
This feels to me like a security policy configuration issue. Derby has
a rich ability to be configured for different security permissions. See
http://db.apache.org/derby/docs/10.6/adminguide/tadminnetservbasic.html
I'm guessing, because I don't know a lot about the security configuration,
but I think that you may be able to locate a security policy which is controlling
the Derby server's behavior, and alter that security policy to grant the
appropriate SocketPermission to Derby:
http://db.apache.org/derby/docs/10.6/adminguide/tadminnetservcustom.html
In your particular example, "miniserver" is the name of your LDAP server, and
the Derby code was apparently denied the permission to resolve that DNS
name into an IP address.
I hope that you take the time to file some JIRA issues describing the areas
of documentation and of implementation that you think could be improved, and
I also encourage you to contribute as much of your hard-earned wisdom to the
Derby wiki as possible, so that others can benefit from it in the future.
thanks,
bryan
Re: Trying to migrate to LDAP (but getting Error 08004)
Posted by "Dag H. Wanvik" <da...@oracle.com>.
Thomas <Th...@t-online.de> writes:
> to start with? Is this an AccessControl/Security issue or an issue that it does
I is anAccessControl/Security issue.
> not know how to resolve the servername to an IP-Address? What exactly would I
> need to put as 'permission java.netSocketPermission' if not '*' and 'accept'?
Looking into the default server policy file, see SocketPermission only
in one location:
grant codeBase "${derby.install.url}derbynet.jar"
{
:
// Accept connections from any host. Derby is listening to the host
// interface specified via the -h option to "NetworkServerControl
// start" on the command line, via the address parameter to the
// org.apache.derby.drda.NetworkServerControl constructor in the API
// or via the property derby.drda.host; the default is localhost.
// You may want to restrict allowed hosts, e.g. to hosts in a specific
// subdomain, e.g. "*.acme.com".
permission java.net.SocketPermission "*", "accept";
That is, I don't see the derby.jar codebase having any permission to
resolve and connect to your LDAP server. You may have to add something
like
grant codeBase "${derby.install.url}derby.jar"
{
:
new --> permission java.net.SocketPermission "miniserver", "connect,accept";
since the code that is failing is inside derby.jar.
The "resolve" permission is implied by "connect", cf.
http://download.oracle.com/javase/6/docs/api/java/net/SocketPermission.html
Not sure if you need the "accept".
Dag
Re: Trying to migrate to LDAP (but getting Error 08004)
Posted by Thomas <Th...@t-online.de>.
> This means that a) you are running with the Java security manager
> enabled, and b) you need to add a missing SocketPermission to the
> derby.jar codebare in a policy file, cf.
>
ad a) yes, the security manager enabled is the default java security manager
which is what is confirmed in derby.log and matches what is stated in the
documentation ("If you boot the Network Server without specifying a security
manager, the Network Server will install a default Java security manager
enforcing a Basic policy")
ad b) I assume the concrete property referred to that would need to set/checked
is the java.net.SocketPermission property which can be set as documented in the
last line of the examples in the documentation, i.e.
permission java.net.SocketPermission "*", "accept";
which is the deault. What I do not quite understand is, if the default "*" -
which I have not changed - leads to connections being accepted from any host,
why am I then getting the
> java.sql.SQLException: Connection refused : javax.naming.CommunicationException
> : miniserver:10389 [Root exception is java.security.AccessControlException:
> access denied (java.net.SocketPermission miniserver resolve)]
> at org.apache.derby.impl.jdbc.authentication.
> JNDIAuthenticationSchemeBase.getLoginSQLException(Unknown Source)
> at org.apache.derby.impl.jdbc.authentication.LDAPAuthentication
> SchemeImpl.authenticateUser(Unknown Source)
to start with? Is this an AccessControl/Security issue or an issue that it does
not know how to resolve the servername to an IP-Address? What exactly would I
need to put as 'permission java.netSocketPermission' if not '*' and 'accept'?
Thanks
Re: Trying to migrate to LDAP (but getting Error 08004)
Posted by "Dag H. Wanvik" <da...@oracle.com>.
Hi,
Thomas <Th...@t-online.de> writes:
> java.sql.SQLException: Connection refused : javax.naming.CommunicationException
> : miniserver:10389 [Root exception is java.security.AccessControlException:
> access denied (java.net.SocketPermission miniserver resolve)]
> at org.apache.derby.impl.jdbc.authentication.
> JNDIAuthenticationSchemeBase.getLoginSQLException(Unknown Source)
> at org.apache.derby.impl.jdbc.authentication.LDAPAuthentication
> SchemeImpl.authenticateUser(Unknown Source)
This means that a) you are running with the Java security manager
enabled, and b) you need to add a missing SocketPermission to the
derby.jar codebare in a policy file, cf.
http://db.apache.org/derby/docs/10.7/adminguide/tadminnetservrun.html
http://db.apache.org/derby/docs/10.7/adminguide/tadminnetservcustom.html
You can temporarily run the Derby server without the security manager
enabled (to test the LDAP), by starting the server with the
-noSecurityManager option, cf.
http://db.apache.org/derby/docs/10.7/adminguide/tadminnetservopen.html
Thanks,
Dag
> at org.apache.derby.impl.jdbc.authentication.AuthenticationServiceBase.
> authenticate(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.checkUserCredentials
> (Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.<init>(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedConnection30.<init>(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedConnection40.<init>(Unknown Source)
> at org.apache.derby.jdbc.Driver40.getNewEmbedConnection(Unknown Source)
> at org.apache.derby.jdbc.InternalDriver.connect(Unknown Source)
> at org.apache.derby.jdbc.AutoloadedDriver.connect(Unknown Source)
> at org.apache.derby.impl.drda.Database.makeConnection(Unknown Source)
> at org.apache.derby.impl.drda.DRDAConnThread.getConnFromDatabaseName
> (Unknown Source)
> at org.apache.derby.impl.drda.DRDAConnThread.verifyUserIdPassword
> (Unknown Source)
> at org.apache.derby.impl.drda.DRDAConnThread.parseSECCHK(Unknown Source)
> at org.apache.derby.impl.drda.DRDAConnThread.parseDRDAConnection
> (Unknown Source)
> at org.apache.derby.impl.drda.DRDAConnThread.processCommands
> (Unknown Source)
> at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source)
> Cleanup action completed
> Tue Jan 18 20:44:37 CET 2011 Thread[DRDAConnThread_3,5,main]
> (DATABASE = ldaptest), (DRDAID = {1}), Connection refused : javax.naming.
> CommunicationException: miniserver:10389 [Root exception is java.security.
> AccessControlException: access denied (java.net.SocketPermission
> miniserver resolve)]
>
> Here is the derby.properties file used:
> # Licensed to the Apache Software Foundation (ASF) under one or more
> # contributor license agreements. See the NOTICE file distributed with
> # this work for additional information regarding copyright ownership.
> # The ASF licenses this file to You under the Apache License, Version 2.0
> # (the "License"); you may not use this file except in compliance with
> # the License. You may obtain a copy of the License at
> #
> # http://www.apache.org/licenses/LICENSE-2.0
> #
> # Unless required by applicable law or agreed to in writing, software
> # distributed under the License is distributed on an "AS IS" BASIS,
> # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> # See the License for the specific language governing permissions and
> # limitations under the License.
>
> # derby.properties
> #
> # we are using the default properties values for this demo
> #
> derby.language.logQueryPlan=false
> # derby.drda.logConnections=true
> # derby.drda.traceAll=true
> derby.connection.requireAuthentication=true
> derby.authentication.provider=LDAP
> derby.authentication.server=ldap://miniserver:10389/
> derby.authentication.ldap.searchBase=o=THMB
>
> ad 2) I have passed the properties on the command line as suggested (after
> having removed the derby.properties file). In this scenario the network
> driver lead to the same results as the embedded driver. Athorisation worked
> as expected; no entries in derby.log.
>
> In summary my testing seems to evidence that the network driver is only
> working in conjunction with LDAP authorization if the required properties
> are passed on the command line when starting up the server. (So there is
> a way to achieve what I was trying to do.) However, when defining
> the properties as data-base properties, these are ignored by the driver. (which
> I would say is a bug). When defining the properties as system-wide properties
> in derby.properties, then the< seem to be recognized, but this sceanrio might
> require modification of the security policy file (which I don't know yet),
> before this approach will potentially work as well.
>
> Btw: the documentation is lacking details/guidance in this regards
>
> Regards
Re: Trying to migrate to LDAP (but getting Error 08004)
Posted by Thomas <Th...@t-online.de>.
I have now tested the following two scenarios in conjunction with the network
driver:
1) using system-wide properties rather than data-base level properties
2) as you suggested, supply the properties as command line parameters
ad 1) when trying to connect using IJ I continue to receive error 08004,
however now the following messages are written to derby.log (which I have to
admit do not tell me much at this stage - but at least it looks like the
network driver has recognized the "LDAP" related properties. Note: I had
started IJ on the same machine where Derby and directory server are running)
me much :
Tue Jan 18 20:44:36 CET 2011:
Booting Derby version The Apache Software Foundation - Apache Derby - 10.7.1.1
- (1040133): instance a816c00e-012d-9aa7-e0cc-00005302821d
on database directory /var/lib/derby/db-derby-10.7.1.1-data/ldaptest with
class loader sun.misc.Launcher$AppClassLoader@7d772e
Loaded from file:/var/lib/derby/db-derby-10.7.1.1-bin/lib/derby.jar
java.vendor=Sun Microsystems Inc.
java.runtime.version=1.6.0_22-b04
Database Class Loader started - derby.database.classpath=''
Tue Jan 18 20:44:37 CET 2011 Thread[DRDAConnThread_3,5,main] (XID = 13),
(SESSIONID = 0), (DATABASE = ldaptest), (DRDAID = {1}), Cleanup action starting
java.sql.SQLException: Connection refused : javax.naming.CommunicationException
: miniserver:10389 [Root exception is java.security.AccessControlException:
access denied (java.net.SocketPermission miniserver resolve)]
at org.apache.derby.impl.jdbc.authentication.
JNDIAuthenticationSchemeBase.getLoginSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.authentication.LDAPAuthentication
SchemeImpl.authenticateUser(Unknown Source)
at org.apache.derby.impl.jdbc.authentication.AuthenticationServiceBase.
authenticate(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection.checkUserCredentials
(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection.<init>(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection30.<init>(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection40.<init>(Unknown Source)
at org.apache.derby.jdbc.Driver40.getNewEmbedConnection(Unknown Source)
at org.apache.derby.jdbc.InternalDriver.connect(Unknown Source)
at org.apache.derby.jdbc.AutoloadedDriver.connect(Unknown Source)
at org.apache.derby.impl.drda.Database.makeConnection(Unknown Source)
at org.apache.derby.impl.drda.DRDAConnThread.getConnFromDatabaseName
(Unknown Source)
at org.apache.derby.impl.drda.DRDAConnThread.verifyUserIdPassword
(Unknown Source)
at org.apache.derby.impl.drda.DRDAConnThread.parseSECCHK(Unknown Source)
at org.apache.derby.impl.drda.DRDAConnThread.parseDRDAConnection
(Unknown Source)
at org.apache.derby.impl.drda.DRDAConnThread.processCommands
(Unknown Source)
at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source)
Cleanup action completed
Tue Jan 18 20:44:37 CET 2011 Thread[DRDAConnThread_3,5,main]
(DATABASE = ldaptest), (DRDAID = {1}), Connection refused : javax.naming.
CommunicationException: miniserver:10389 [Root exception is java.security.
AccessControlException: access denied (java.net.SocketPermission
miniserver resolve)]
Here is the derby.properties file used:
# Licensed to the Apache Software Foundation (ASF) under one or more
# contributor license agreements. See the NOTICE file distributed with
# this work for additional information regarding copyright ownership.
# The ASF licenses this file to You under the Apache License, Version 2.0
# (the "License"); you may not use this file except in compliance with
# the License. You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
# derby.properties
#
# we are using the default properties values for this demo
#
derby.language.logQueryPlan=false
# derby.drda.logConnections=true
# derby.drda.traceAll=true
derby.connection.requireAuthentication=true
derby.authentication.provider=LDAP
derby.authentication.server=ldap://miniserver:10389/
derby.authentication.ldap.searchBase=o=THMB
ad 2) I have passed the properties on the command line as suggested (after
having removed the derby.properties file). In this scenario the network
driver lead to the same results as the embedded driver. Athorisation worked
as expected; no entries in derby.log.
In summary my testing seems to evidence that the network driver is only
working in conjunction with LDAP authorization if the required properties
are passed on the command line when starting up the server. (So there is
a way to achieve what I was trying to do.) However, when defining
the properties as data-base properties, these are ignored by the driver. (which
I would say is a bug). When defining the properties as system-wide properties
in derby.properties, then the< seem to be recognized, but this sceanrio might
require modification of the security policy file (which I don't know yet),
before this approach will potentially work as well.
Btw: the documentation is lacking details/guidance in this regards
Regards
Re: Trying to migrate to LDAP (but getting Error 08004)
Posted by Bryan Pendleton <bp...@gmail.com>.
> 08004 with the message 'invalid athentication..'. Hard to believe that
> the network client driver is not working, whereas the embedded driver does!?
I wonder if, for some reason, the network server isn't seeing the authentication
properties that you have set, and so is not doing LDAP authentication but
rather is doing traditional Derby authentication.
Does it change anything if you set the authentication properties on the
network server's command line, as described here:
http://db.apache.org/derby/docs/10.6/devguide/cdevsetprop11561.html
thanks,
bryan
Re: Trying to migrate to LDAP (but getting Error 08004)
Posted by Thomas <Th...@t-online.de>.
Bryan,
thanks for your answers and suggestions. My updates are as follow:
1) derby.log does not contain any information other than the server having
been started
2) I added 'ldap:://' at the start and '/' at the end of the value for
property derby.authentication.server and (after having dropped and
recreated the whole data base) retested still using the network client
driver - no difference, i.e. still receiving the same error
3) I then used the embedded driver and recreated the database from scratch
once again - and found everything working as expected with this driver!
So using correct credentials I could connect to the data base and select
data, providing incorrect user name and/or password resulted in the error
08004 with the message 'invalid athentication..'. Hard to believe that
the network client driver is not working, whereas the embedded driver does!?
-> where the normal use case I would consider using LDAP only in multi-user/
networked environments (and with all the warnings about the BUILTIN security
system and the advise to use LDAP I would have expected quite some people
having switched and then run into this problem??).
Can you please advise on next steps?, i.e. should I create a JIRA issue
immediately or will/should someone from the development try to reproduce
first?
Regards
Thomas
Re: Trying to migrate to LDAP (but getting Error 08004)
Posted by Bryan Pendleton <bp...@gmail.com>.
> [derby][SQLException@22c95b] Message = Connection authentication failure
> occurred. Reason: userid or password invalid.
Perhaps more information is available in the derby.log file that the network
server produced. Can you post the contents of that file?
Also, I think that this line:
'derby.authentication.server','miniserver:10389');
doesn't look right. According to
http://db.apache.org/derby/docs/10.6/devguide/cdevcsecure863446.html
it should look like:
derby.authentication.server=ldap://godfrey:389/
(note the 'ldap://' at the start, and the '/' at the end).
Does it help to provide the ldap:// prefix, and add a slash at the end?
Looking at the code in LDAPAuthenticationSchemeImpl.java it looks like
it tries to add the 'ldap://' itself if it isn't present, but maybe...?
Lastly, can you try doing this with the embedded driver rather than
the client/server driver? That might simplify the configuration somewhat
and make the error messages more obvious (error messages passed from the
server to the client sometimes don't contain as much information as the
error messages that are emitted by the embedded driver).
thanks,
bryan