You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@directory.apache.org by Joel Pearson <jo...@ipaustralia.gov.au> on 2016/08/19 03:04:47 UTC
[Studio] Apache Directory Studio can't discover base dn for old Sun
DS server [SEC=UNCLASSIFIED]
I'm using Apache Directory Studio (2.0.0.v20151221-M10) as an ldap browser, and a few years back Apache Directory Studio stopped being able to discover the Base DN of a particular (old) Sun Directory Server we have.
I found this question (http://superuser.com/questions/740877/how-do-i-query-the-available-base-dns-in-an-openldap-server) that helped discover the base DN on the command line.
This ldapsearch command shows the base DN:
# ldapsearch -H ldap://servername-sds:389 -x -D "uid=admin,dc=company,dc=org,dc=au" -b "" -w password -s base \* +| grep namingContexts
But according to the search logs tab of Apache Directory Studio, it uses this command to discover the base DN:
#!SEARCH REQUEST (119) OK
#!CONNECTION ldap://servername-sds:389
#!DATE 2016-08-19T02:38:59.301
# LDAP URL : ldap://servername-sds:389/?namingContexts,subschemaSubentry,supportedLDAPVersion,supportedSASLMechanisms,supportedExtension,supportedControl,supportedFeatures,vendorName,vendorVersion,+,objectClass??(objectClass=*)
# command line : ldapsearch -H ldap://servername-sds:389 -x -D "uid=admin,dc=company,dc=org,dc=au" -W -b "" -s base "(objectClass=*)" "namingContexts" "subschemaSubentry" "supportedLDAPVersion" "supportedSASLMechanisms" "supportedExtension" "supportedControl" "supportedFeatures" "vendorName" "vendorVersion" "+" "objectClass"
# baseObject :
# scope : baseObject (0)
# derefAliases : neverDerefAliases (0)
# sizeLimit : 0
# timeLimit : 0
# typesOnly : False
# filter : (objectClass=*)
# attributes : namingContexts subschemaSubentry supportedLDAPVersion supportedSASLMechanisms supportedExtension supportedControl supportedFeatures vendorName vendorVersion + objectClass
#!SEARCH RESULT DONE (119) OK
#!CONNECTION ldap://servername-sds:389
#!DATE 2016-08-19T02:38:59.304
# numEntries : 1
Which when run on the command line does return the namingContexts, but for some reason, Apache Directory Studio doesn't show the base DN, which is super weird.
Any idea how I can convince Apache Directory Studio to work? It's the best open source ldap browser I've used so far, so it's sad it doesn't work for this particular server.
Curiously it works for other Sun DS servers, but I think I am binding with a user that has more privileges, although it is actually finding the baseDN but not displaying it in the GUI it seems.
Thanks,
Joel
PS. I posted this on super user (http://superuser.com/questions/1115240/apache-directory-studio-cant-discover-base-dn-for-old-sun-ds-server), but I think this mailing list is probably more likely to be seen by the right people here on the mailing list. Hopefully this doesn't count as cross-posting.
RE: [Studio] Apache Directory Studio can't discover base dn for old
Sun DS server [SEC=UNCLASSIFIED]
Posted by Joel Pearson <jo...@ipaustralia.gov.au>.
Sure
> -----Original Message-----
> From: Emmanuel Lécharny [mailto:elecharny@gmail.com]
> Sent: Friday, 19 August 2016 3:15 PM
> To: users@directory.apache.org
> Subject: Re: [Studio] Apache Directory Studio can't discover base dn for old Sun DS server [SEC=UNCLASSIFIED]
>
> Le 19/08/16 à 05:04, Joel Pearson a écrit :
> > I'm using Apache Directory Studio (2.0.0.v20151221-M10) as an ldap browser, and a few years back Apache Directory Studio stopped
> being able to discover the Base DN of a particular (old) Sun Directory Server we have.
> >
> > I found this question (http://superuser.com/questions/740877/how-do-i-query-the-available-base-dns-in-an-openldap-server)
> that helped discover the base DN on the command line.
> >
> > This ldapsearch command shows the base DN:
> >
> > # ldapsearch -H ldap://servername-sds:389 -x -D "uid=admin,dc=company,dc=org,dc=au" -b "" -w password -s base \* +| grep
> namingContexts
> >
> > But according to the search logs tab of Apache Directory Studio, it uses this command to discover the base DN:
> >
> > #!SEARCH REQUEST (119) OK
> > #!CONNECTION ldap://servername-sds:389
> > #!DATE 2016-08-19T02:38:59.301
> > # LDAP URL : ldap://servername-
> sds:389/?namingContexts,subschemaSubentry,supportedLDAPVersion,supportedSASLMechanisms,supportedExtension,supportedC
> ontrol,supportedFeatures,vendorName,vendorVersion,+,objectClass??(objectClass=*)
> > # command line : ldapsearch -H ldap://servername-sds:389 -x -D "uid=admin,dc=company,dc=org,dc=au" -W -b "" -s base
> "(objectClass=*)" "namingContexts" "subschemaSubentry" "supportedLDAPVersion" "supportedSASLMechanisms"
> "supportedExtension" "supportedControl" "supportedFeatures" "vendorName" "vendorVersion" "+" "objectClass"
> > # baseObject :
> > # scope : baseObject (0)
> > # derefAliases : neverDerefAliases (0)
> > # sizeLimit : 0
> > # timeLimit : 0
> > # typesOnly : False
> > # filter : (objectClass=*)
> > # attributes : namingContexts subschemaSubentry supportedLDAPVersion supportedSASLMechanisms supportedExtension
> supportedControl supportedFeatures vendorName vendorVersion + objectClass
> >
> > #!SEARCH RESULT DONE (119) OK
> > #!CONNECTION ldap://servername-sds:389
> > #!DATE 2016-08-19T02:38:59.304
> > # numEntries : 1
> >
> > Which when run on the command line does return the namingContexts, but for some reason, Apache Directory Studio doesn't show
> the base DN, which is super weird.
>
> Indeed...
>
> Do you mind posting the result you get ?
# extended LDIF
#
# LDAPv3
# base <> with scope baseObject
# filter: (objectClass=*)
# requesting: namingContexts subschemaSubentry supportedLDAPVersion supportedSASLMechanisms supportedExtension supportedControl supportedFeatures vendorName vendorVersion + objectClass
#
#
dn:
namingContexts: dc=company,dc=org,dc=au
subschemaSubentry: cn=schema
supportedLDAPVersion: 2
supportedLDAPVersion: 3
supportedSASLMechanisms: EXTERNAL
supportedSASLMechanisms: DIGEST-MD5
supportedExtension: 2.16.840.1.113730.3.5.7
supportedExtension: 2.16.840.1.113730.3.5.8
supportedExtension: 1.3.6.1.4.1.4203.1.11.1
supportedExtension: 1.3.6.1.4.1.42.2.27.9.6.25
supportedExtension: 2.16.840.1.113730.3.5.3
supportedExtension: 2.16.840.1.113730.3.5.5
supportedExtension: 2.16.840.1.113730.3.5.6
supportedExtension: 2.16.840.1.113730.3.5.4
supportedExtension: 1.3.6.1.4.1.42.2.27.9.6.1
supportedExtension: 1.3.6.1.4.1.42.2.27.9.6.2
supportedExtension: 1.3.6.1.4.1.42.2.27.9.6.3
supportedExtension: 1.3.6.1.4.1.42.2.27.9.6.4
supportedExtension: 1.3.6.1.4.1.42.2.27.9.6.5
supportedExtension: 1.3.6.1.4.1.42.2.27.9.6.6
supportedExtension: 1.3.6.1.4.1.42.2.27.9.6.7
supportedExtension: 1.3.6.1.4.1.42.2.27.9.6.8
supportedExtension: 1.3.6.1.4.1.42.2.27.9.6.9
supportedExtension: 1.3.6.1.4.1.42.2.27.9.6.23
supportedExtension: 1.3.6.1.4.1.42.2.27.9.6.11
supportedExtension: 1.3.6.1.4.1.42.2.27.9.6.12
supportedExtension: 1.3.6.1.4.1.42.2.27.9.6.13
supportedExtension: 1.3.6.1.4.1.42.2.27.9.6.14
supportedExtension: 1.3.6.1.4.1.42.2.27.9.6.15
supportedExtension: 1.3.6.1.4.1.42.2.27.9.6.16
supportedExtension: 1.3.6.1.4.1.42.2.27.9.6.17
supportedExtension: 1.3.6.1.4.1.42.2.27.9.6.18
supportedExtension: 1.3.6.1.4.1.42.2.27.9.6.19
supportedExtension: 1.3.6.1.4.1.42.2.27.9.6.21
supportedExtension: 1.3.6.1.4.1.42.2.27.9.6.22
supportedExtension: 1.3.6.1.4.1.42.2.27.9.6.24
supportedExtension: 1.3.6.1.4.1.1466.20037
supportedExtension: 1.3.6.1.4.1.4203.1.11.3
supportedControl: 2.16.840.1.113730.3.4.2
supportedControl: 2.16.840.1.113730.3.4.3
supportedControl: 2.16.840.1.113730.3.4.4
supportedControl: 2.16.840.1.113730.3.4.5
supportedControl: 1.2.840.113556.1.4.473
supportedControl: 2.16.840.1.113730.3.4.9
supportedControl: 2.16.840.1.113730.3.4.16
supportedControl: 2.16.840.1.113730.3.4.15
supportedControl: 2.16.840.1.113730.3.4.17
supportedControl: 2.16.840.1.113730.3.4.19
supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2
supportedControl: 1.3.6.1.4.1.42.2.27.9.5.6
supportedControl: 1.3.6.1.4.1.42.2.27.9.5.8
supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1
supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1
supportedControl: 2.16.840.1.113730.3.4.14
supportedControl: 1.3.6.1.4.1.1466.29539.12
supportedControl: 2.16.840.1.113730.3.4.12
supportedControl: 2.16.840.1.113730.3.4.18
supportedControl: 2.16.840.1.113730.3.4.13
vendorName: Sun Microsystems, Inc.
vendorVersion: Sun-Java(tm)-System-Directory/6.3.1.1.2
objectClass: top
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
Re: [Studio] Apache Directory Studio can't discover base dn for old
Sun DS server [SEC=UNCLASSIFIED]
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 19/08/16 � 05:04, Joel Pearson a �crit :
> I'm using Apache Directory Studio (2.0.0.v20151221-M10) as an ldap browser, and a few years back Apache Directory Studio stopped being able to discover the Base DN of a particular (old) Sun Directory Server we have.
>
> I found this question (http://superuser.com/questions/740877/how-do-i-query-the-available-base-dns-in-an-openldap-server) that helped discover the base DN on the command line.
>
> This ldapsearch command shows the base DN:
>
> # ldapsearch -H ldap://servername-sds:389 -x -D "uid=admin,dc=company,dc=org,dc=au" -b "" -w password -s base \* +| grep namingContexts
>
> But according to the search logs tab of Apache Directory Studio, it uses this command to discover the base DN:
>
> #!SEARCH REQUEST (119) OK
> #!CONNECTION ldap://servername-sds:389
> #!DATE 2016-08-19T02:38:59.301
> # LDAP URL : ldap://servername-sds:389/?namingContexts,subschemaSubentry,supportedLDAPVersion,supportedSASLMechanisms,supportedExtension,supportedControl,supportedFeatures,vendorName,vendorVersion,+,objectClass??(objectClass=*)
> # command line : ldapsearch -H ldap://servername-sds:389 -x -D "uid=admin,dc=company,dc=org,dc=au" -W -b "" -s base "(objectClass=*)" "namingContexts" "subschemaSubentry" "supportedLDAPVersion" "supportedSASLMechanisms" "supportedExtension" "supportedControl" "supportedFeatures" "vendorName" "vendorVersion" "+" "objectClass"
> # baseObject :
> # scope : baseObject (0)
> # derefAliases : neverDerefAliases (0)
> # sizeLimit : 0
> # timeLimit : 0
> # typesOnly : False
> # filter : (objectClass=*)
> # attributes : namingContexts subschemaSubentry supportedLDAPVersion supportedSASLMechanisms supportedExtension supportedControl supportedFeatures vendorName vendorVersion + objectClass
>
> #!SEARCH RESULT DONE (119) OK
> #!CONNECTION ldap://servername-sds:389
> #!DATE 2016-08-19T02:38:59.304
> # numEntries : 1
>
> Which when run on the command line does return the namingContexts, but for some reason, Apache Directory Studio doesn't show the base DN, which is super weird.
Indeed...
Do you mind posting the result you get ?