You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Stefan Zoerner (JIRA)" <di...@incubator.apache.org> on 2005/10/24 11:38:56 UTC
[jira] Created: (DIREVE-284) Simple bind fails for entries with certain partition suffix names
Simple bind fails for entries with certain partition suffix names
-----------------------------------------------------------------
Key: DIREVE-284
URL: http://issues.apache.org/jira/browse/DIREVE-284
Project: Directory Server
Type: Bug
Reporter: Stefan Zoerner
Assigned to: Alex Karasulu
Fix For: 0.9.3
Sometimes users (i.e. person entries with userPassword attribute) can't authenticate to the server via simple bind. The problem does not exist with entries located in ou=system or dc=apache,dc=org. To give an example:
I used the default server.xml from
http://svn.apache.org/viewcvs.cgi/directory/apacheds/trunk/main/server.xml
to start the server and added the following entry:
dn: cn=Kate Bush,dc=apache,dc=org
cn: Kate Bush
objectclass: top
objectclass: person
sn: Bush
userPassword: Aerial
After that, the following works as expected:
$ ldapsearch -h magritte -p 10389 -D "cn=Kate Bush,dc=apache,dc=org" -w Aerial -b "dc=apache,dc=org" "(sn=Bush)" cn
cn=Kate Bush,dc=apache,dc=org
cn=Kate Bush
$
and providing a wrong password leads to an "invalid credentials".
But if I use "dc=aPache,dc=org" as suffix within the partition configuration, i.e.
<property name="suffix"><value>dc=aPache,dc=org</value></property>
adjust other occurrences of dc=apache as well and import the person entry above with DN "cn=Kate Bush,dc=aPache,dc=org", the following happens:
$ ldapsearch -h magritte -p 10389 -D "cn=Kate Bush,dc=aPache,dc=org" -w Aerial -b "dc=aPache,dc=org" "(sn=Bush)" cn
ldap_simple_bind: Invalid credentials
$
But this still works:
$ ldapsearch -h magritte -p 10389 -D "uid=admin,ou=system" -w secret -b "dc=aPache,dc=org" "(sn=Bush)"
cn=Kate Bush,dc=aPache,dc=org
sn=Bush
cn=Kate Bush
objectclass=person
objectclass=top
userPassword=Aerial
$
I have the same problem with suffix "o=sevenSeas" (actually it was the first occurrence I found), and the defect disappears with "o=sevenseas".
I therefore assume that the authenticator used for simple binds has problems with the mixed characters in the suffices.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DIREVE-284) Simple bind fails for entries with certain partition suffix names
Posted by "Stefan Zoerner (JIRA)" <di...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/DIREVE-284?page=all ]
Stefan Zoerner updated DIREVE-284:
----------------------------------
Description:
Some users (i.e. person entries with userPassword attribute) can't authenticate to the server via simple bind. The problem does not exist with entries located in ou=system or dc=apache,dc=org. To give an example:
I used the default server.xml from
http://svn.apache.org/viewcvs.cgi/directory/apacheds/trunk/main/server.xml
to start the server and added the following entry:
dn: cn=Kate Bush,dc=apache,dc=org
cn: Kate Bush
objectclass: top
objectclass: person
sn: Bush
userPassword: Aerial
After that, the following works as expected:
$ ldapsearch -h magritte -p 10389 -D "cn=Kate Bush,dc=apache,dc=org" -w Aerial -b "dc=apache,dc=org" "(sn=Bush)" cn
cn=Kate Bush,dc=apache,dc=org
cn=Kate Bush
$
and providing a wrong password leads to an "invalid credentials".
But if I use "dc=aPache,dc=org" as suffix within the partition configuration, i.e.
<property name="suffix"><value>dc=aPache,dc=org</value></property>
adjust other occurrences of dc=apache as well and import the person entry above with DN "cn=Kate Bush,dc=aPache,dc=org", the following happens:
$ ldapsearch -h magritte -p 10389 -D "cn=Kate Bush,dc=aPache,dc=org" -w Aerial -b "dc=aPache,dc=org" "(sn=Bush)" cn
ldap_simple_bind: Invalid credentials
$
But this still works:
$ ldapsearch -h magritte -p 10389 -D "uid=admin,ou=system" -w secret -b "dc=aPache,dc=org" "(sn=Bush)"
cn=Kate Bush,dc=aPache,dc=org
sn=Bush
cn=Kate Bush
objectclass=person
objectclass=top
userPassword=Aerial
$
I have the same problem with suffix "o=sevenSeas" (actually it was the first occurrence I found), and the defect disappears with "o=sevenseas".
I therefore assume that the authenticator used for simple binds has problems with the mixed characters in the suffices.
was:
Sometimes users (i.e. person entries with userPassword attribute) can't authenticate to the server via simple bind. The problem does not exist with entries located in ou=system or dc=apache,dc=org. To give an example:
I used the default server.xml from
http://svn.apache.org/viewcvs.cgi/directory/apacheds/trunk/main/server.xml
to start the server and added the following entry:
dn: cn=Kate Bush,dc=apache,dc=org
cn: Kate Bush
objectclass: top
objectclass: person
sn: Bush
userPassword: Aerial
After that, the following works as expected:
$ ldapsearch -h magritte -p 10389 -D "cn=Kate Bush,dc=apache,dc=org" -w Aerial -b "dc=apache,dc=org" "(sn=Bush)" cn
cn=Kate Bush,dc=apache,dc=org
cn=Kate Bush
$
and providing a wrong password leads to an "invalid credentials".
But if I use "dc=aPache,dc=org" as suffix within the partition configuration, i.e.
<property name="suffix"><value>dc=aPache,dc=org</value></property>
adjust other occurrences of dc=apache as well and import the person entry above with DN "cn=Kate Bush,dc=aPache,dc=org", the following happens:
$ ldapsearch -h magritte -p 10389 -D "cn=Kate Bush,dc=aPache,dc=org" -w Aerial -b "dc=aPache,dc=org" "(sn=Bush)" cn
ldap_simple_bind: Invalid credentials
$
But this still works:
$ ldapsearch -h magritte -p 10389 -D "uid=admin,ou=system" -w secret -b "dc=aPache,dc=org" "(sn=Bush)"
cn=Kate Bush,dc=aPache,dc=org
sn=Bush
cn=Kate Bush
objectclass=person
objectclass=top
userPassword=Aerial
$
I have the same problem with suffix "o=sevenSeas" (actually it was the first occurrence I found), and the defect disappears with "o=sevenseas".
I therefore assume that the authenticator used for simple binds has problems with the mixed characters in the suffices.
> Simple bind fails for entries with certain partition suffix names
> -----------------------------------------------------------------
>
> Key: DIREVE-284
> URL: http://issues.apache.org/jira/browse/DIREVE-284
> Project: Directory Server
> Type: Bug
> Reporter: Stefan Zoerner
> Assignee: Alex Karasulu
> Fix For: 0.9.3
>
> Some users (i.e. person entries with userPassword attribute) can't authenticate to the server via simple bind. The problem does not exist with entries located in ou=system or dc=apache,dc=org. To give an example:
> I used the default server.xml from
> http://svn.apache.org/viewcvs.cgi/directory/apacheds/trunk/main/server.xml
> to start the server and added the following entry:
> dn: cn=Kate Bush,dc=apache,dc=org
> cn: Kate Bush
> objectclass: top
> objectclass: person
> sn: Bush
> userPassword: Aerial
> After that, the following works as expected:
> $ ldapsearch -h magritte -p 10389 -D "cn=Kate Bush,dc=apache,dc=org" -w Aerial -b "dc=apache,dc=org" "(sn=Bush)" cn
> cn=Kate Bush,dc=apache,dc=org
> cn=Kate Bush
> $
> and providing a wrong password leads to an "invalid credentials".
> But if I use "dc=aPache,dc=org" as suffix within the partition configuration, i.e.
> <property name="suffix"><value>dc=aPache,dc=org</value></property>
> adjust other occurrences of dc=apache as well and import the person entry above with DN "cn=Kate Bush,dc=aPache,dc=org", the following happens:
> $ ldapsearch -h magritte -p 10389 -D "cn=Kate Bush,dc=aPache,dc=org" -w Aerial -b "dc=aPache,dc=org" "(sn=Bush)" cn
> ldap_simple_bind: Invalid credentials
> $
> But this still works:
> $ ldapsearch -h magritte -p 10389 -D "uid=admin,ou=system" -w secret -b "dc=aPache,dc=org" "(sn=Bush)"
> cn=Kate Bush,dc=aPache,dc=org
> sn=Bush
> cn=Kate Bush
> objectclass=person
> objectclass=top
> userPassword=Aerial
> $
> I have the same problem with suffix "o=sevenSeas" (actually it was the first occurrence I found), and the defect disappears with "o=sevenseas".
> I therefore assume that the authenticator used for simple binds has problems with the mixed characters in the suffices.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: Convo with Adrew Bartlett (Samba 4 guy) about ADS and Kerberos
Posted by Enrique Rodriguez <en...@gmail.com>.
Emmanuel Lecharny wrote:
...
> abartlet : but Kerberos, NTP and everything else?
> ele-office : these are sub-projects
> ele-office : they are built beside ADS
> abartlet : other than love of java, any reason for re-impelemting those?
> abartlet : I found just the mods I made to Heimdal painful enough,
> reimplementing looked like a nightmare...
> ele-office : doing it in java seems one of the reason that led to a
> reimplementation.
The main reason is to have a common configuration mechanism, leading to
a unified management experience for enterprise IT admins. Specifically,
I am thinking of DIT-backed configuration data, full hot-swap using OSGi
for protocol-providers, dynamic notification of changes using the
EventDirContext, and well-known management interfaces such as LDAP, JMX,
and an embedded web UI.
> abartlet : anyway, I'm mainly just trying to get good contracts with
> various ldap directory implementors, because I expect there to be strong
> demand for Samba4 as a frontend to various ldap backends
> ele-office : it could be interesting to see how samb4 can use ads as an
> ldap backend.
> ele-office : and I think it should be really easy.
> abartlet : yes and no, Samba4 has some very particular requirements for
> it's LDAP backends
> ele-office : like ?
> abartlet : hosting the AD schema
> abartlet : and behaving like AD in general
> abartlet : (there are certain operations, such as an add, which are
> filled out by a server-side template)
> abartlet : and various operational attributes to be generated etc
> ele-office : I see.
> ele-office : AD use a lot of operationnal attributes
> ele-office : Sorry, I don't know enough about Samba to be able to broing
> you some lights about the way to use ADS as a ldap backend :(
We will do whatever we can to behave more like AD. Just let us know!
My talk at ApacheCon US 2005 in December will cover as much as we have
working by then w.r.t. using ApacheDS for SSO in MS/Mac/Linux
environments and the aforementioned OSGi-based configuration.
> abartlet : I'm also just trying to find out where this project is at
> ele-office : currentlmy, we are trying to deliver the 1.0 version of the
> core Ldap Server.
> ele-office : DNS and Kerberos sub-projects will be delivered almost at
> the same date.
> ele-office : their are other sub-projects, too (Penrose, Mitosis, ...)
> abartlet : how compliant it the kerberos server?
> ele-office : it is supposed to be fully compliant
> ele-office : so does Ldap
> abartlet : the small amount of stuff I looked at looked like it was
> hardcoded for the old des enc types
Other than admittedly inflexible config, Kerberos does work for SSO.
And MS only supports RFC 1510 and the "old des enc types." I use it
regularly for Linux and MS SSO. Also, Changepw works, too. I know,
Changepw seems minor, but if you are going to do SSO you should have a
secure way to set/change passwords. Admittedly, NTP is the stepchild
here, but it was easy to do and, again, will use the same config
mechanisms and NTP is require for Kerberos/Changepw. Further down the
road, I'd like to add NTP authentication which will further benefit from
the re-implementation. Similarly, DNS gains from a re-impl w.r.t
Kerberos-secured DNS and the aforementioned config mechanisms.
DNS currently serves record out of a single DIT subtree. I hope this
week to release multi-zone catalog capability and then quickly add
multi-realm capability to Kerberos. DNS will serve SRV records so I'd
like to work before ApacheCon to make sure KDC Discovery is working. It
should work but I haven't had a chance to try it. Right now with
Windows 2003 you have to configure on each workstation the KDC and
Changepw servers but we should be able to serve this using SRV records.
Much of the config is defaulted to "old enc types" but certainly we know
how to make configuration more flexible. In fact, I am reworking all
the config, as we speak, with an audit to ensure flexibility and to have
the option of putting all config in the DIT. OSGi provides a standard
service called Config Admin, which is DIT backed in the sandbox. I
admit some of the p-p config is not very flexible, but I delayed such
work since I knew we'd be reworking things for the Config Admin's
dynamic semantics. But first, I had to implement the Config Admin
backed with the DIT and Alex had to add the EventDirContext, so changes
would work in the dynamic model that OSGi uses. Yesterday and today's
DIREVE issues (from me to Alex hehe) were all from DIT-backed config
problems I found.
Also, some of the enc types are subject to US export control (abartlet
is AU), for example AES, but they are impl'd in the JDK or Bouncy
Castle. There are interfaces for trivially adding new enc types, so,
again, I have not totally completed this work but it is easy to add. I
have a JIRA issue open to audit Kerberos for the RFC 4120 update which
came out in July.
> ele-office : The target is to deliver a server that can pass the
> Compliance tests of the OpenGroup
> ele-office : http://www.opengroup.org/certification/directory-home.html
> ele-office : Kerberos is still a work in progress ;)
> ele-office : it's version 0.5.1
> abartlet : are the developers on the kitten lists?
> abartlet : (the kerberos working group)
> ele-office : I don't know ;) I'm not working on kerberos, and Enrique,
> the one who is working on it with Alex
> (http://directory.apache.org/community/who/erodriguez.html) is not
> currently connected ...
Yes, I follow Kitten, GUAM, and other related IETF working groups such
as SAM and I am a representative to OATH where I either follow the email
or dial-in on the calls. Kerberos currently supports SAM types (with
even more heinous config) but you can actually use Kerberos and mobile
phone tokens to do 2-factor authentication.
>
> -- Emmanuel
>
>
Re: Convo with Adrew Bartlett (Samba 4 guy) about ADS and Kerberos
Posted by Alex Karasulu <ao...@bellsouth.net>.
David Boreham wrote:
> Alex Karasulu wrote:
>
>> They certainly do have a challenge in front of them though by
>> embedding a forked version of Heimdhal Kerberos and OpenLDAP. The
>> combination however is irresistible.
>
>
> The Samba4 LDAP server is not based on OpenLDAP : AFAIK it's all new
> code.
Interesting... thanks for the correction. I'd love to look at any links
related to this if you have it handy.
Alex
Re: Convo with Adrew Bartlett (Samba 4 guy) about ADS and Kerberos
Posted by David Boreham <da...@bozemanpass.com>.
Alex Karasulu wrote:
> They certainly do have a challenge in front of them though by
> embedding a forked version of Heimdhal Kerberos and OpenLDAP. The
> combination however is irresistible.
The Samba4 LDAP server is not based on OpenLDAP : AFAIK it's all new code.
Re: Convo with Adrew Bartlett (Samba 4 guy) about ADS and Kerberos
Posted by Alex Karasulu <ao...@bellsouth.net>.
Emmanuel Lecharny wrote:
...
Looks like Samba4 peeps are going after the big pie in the sky. This
time they really want to replace all of the Microsoft stack it seems
rather than just integrate with it or mimic it. My hat's off to them
and I hope they can pull it off. Many things now are making sense to
me: all those AD schema appearing for OpenLDAP are for this goal. I was
wondering why they were popping up and being heavily worked on.
They certainly do have a challenge in front of them though by embedding
a forked version of Heimdhal Kerberos and OpenLDAP. The combination
however is irresistible.
Thanks for the transcript.
Alex
Convo with Adrew Bartlett (Samba 4 guy) about ADS and Kerberos
Posted by Emmanuel Lecharny <el...@gmail.com>.
abartlet : what timezone is good to find 'apache directory' developers
in?
ele-office : abartlet : any TZ.
ele-office : there are people in Korea, in Turkey, Germany, France, and
USA
abartlet : I'm trying to find out a little where this project has come
from, and what it's aims are.
abartlet : In particular, I come as a Samba4 developer, which has a
rather large play in the directories space
ele-office : look at :
http://directory.apache.org/community/who/akarasulu.html
ele-office : this is where apacheDS is coming from !
abartlet : it seems to be a very, very large scope of work
ele-office : basically, it's a LDAP server
abartlet : that's not the bit that worries me, because I have seen how
that can be done
abartlet : (Samba4 has it's own ldap server, and it really was not that
bitterly painful to build)
abartlet : but Kerberos, NTP and everything else?
ele-office : these are sub-projects
ele-office : they are built beside ADS
abartlet : other than love of java, any reason for re-impelemting those?
abartlet : I found just the mods I made to Heimdal painful enough,
reimplementing looked like a nightmare...
ele-office : doing it in java seems one of the reason that led to a
reimplementation.
abartlet : anyway, I'm mainly just trying to get good contracts with
various ldap directory implementors, because I expect there to be strong
demand for Samba4 as a frontend to various ldap backends
ele-office : it could be interesting to see how samb4 can use ads as an
ldap backend.
ele-office : and I think it should be really easy.
abartlet : yes and no, Samba4 has some very particular requirements for
it's LDAP backends
ele-office : like ?
abartlet : hosting the AD schema
abartlet : and behaving like AD in general
abartlet : (there are certain operations, such as an add, which are
filled out by a server-side template)
abartlet : and various operational attributes to be generated etc
ele-office : I see.
ele-office : AD use a lot of operationnal attributes
ele-office : Sorry, I don't know enough about Samba to be able to broing
you some lights about the way to use ADS as a ldap backend :(
abartlet : I'm also just trying to find out where this project is at
ele-office : currentlmy, we are trying to deliver the 1.0 version of the
core Ldap Server.
ele-office : DNS and Kerberos sub-projects will be delivered almost at
the same date.
ele-office : their are other sub-projects, too (Penrose, Mitosis, ...)
abartlet : how compliant it the kerberos server?
ele-office : it is supposed to be fully compliant
ele-office : so does Ldap
abartlet : the small amount of stuff I looked at looked like it was
hardcoded for the old des enc types
ele-office : The target is to deliver a server that can pass the
Compliance tests of the OpenGroup
ele-office : http://www.opengroup.org/certification/directory-home.html
ele-office : Kerberos is still a work in progress ;)
ele-office : it's version 0.5.1
abartlet : are the developers on the kitten lists?
abartlet : (the kerberos working group)
ele-office : I don't know ;) I'm not working on kerberos, and Enrique,
the one who is working on it with Alex
(http://directory.apache.org/community/who/erodriguez.html) is not
currently connected ...
-- Emmanuel
[jira] Closed: (DIREVE-284) Simple bind fails for entries with certain partition suffix names
Posted by "Stefan Zoerner (JIRA)" <di...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/DIREVE-284?page=all ]
Stefan Zoerner closed DIREVE-284:
---------------------------------
I have rebuilt the server and retested the functionality with the problematic partition suffix names I encountered ("dc=aPache,dc=org" and "o=sevenSeas"). Bind ops from users within these partitions have worked as expected. Hence I close this one. Thanks Alex for fixing it!
> Simple bind fails for entries with certain partition suffix names
> -----------------------------------------------------------------
>
> Key: DIREVE-284
> URL: http://issues.apache.org/jira/browse/DIREVE-284
> Project: Directory Server
> Type: Bug
> Reporter: Stefan Zoerner
> Assignee: Alex Karasulu
> Fix For: 0.9.3
>
> Some users (i.e. person entries with userPassword attribute) can't authenticate to the server via simple bind. The problem does not exist with entries located in ou=system or dc=apache,dc=org. To give an example:
> I used the default server.xml from
> http://svn.apache.org/viewcvs.cgi/directory/apacheds/trunk/main/server.xml
> to start the server and added the following entry:
> dn: cn=Kate Bush,dc=apache,dc=org
> cn: Kate Bush
> objectclass: top
> objectclass: person
> sn: Bush
> userPassword: Aerial
> After that, the following works as expected:
> $ ldapsearch -h magritte -p 10389 -D "cn=Kate Bush,dc=apache,dc=org" -w Aerial -b "dc=apache,dc=org" "(sn=Bush)" cn
> cn=Kate Bush,dc=apache,dc=org
> cn=Kate Bush
> $
> and providing a wrong password leads to an "invalid credentials".
> But if I use "dc=aPache,dc=org" as suffix within the partition configuration, i.e.
> <property name="suffix"><value>dc=aPache,dc=org</value></property>
> adjust other occurrences of dc=apache as well and import the person entry above with DN "cn=Kate Bush,dc=aPache,dc=org", the following happens:
> $ ldapsearch -h magritte -p 10389 -D "cn=Kate Bush,dc=aPache,dc=org" -w Aerial -b "dc=aPache,dc=org" "(sn=Bush)" cn
> ldap_simple_bind: Invalid credentials
> $
> But this still works:
> $ ldapsearch -h magritte -p 10389 -D "uid=admin,ou=system" -w secret -b "dc=aPache,dc=org" "(sn=Bush)"
> cn=Kate Bush,dc=aPache,dc=org
> sn=Bush
> cn=Kate Bush
> objectclass=person
> objectclass=top
> userPassword=Aerial
> $
> I have the same problem with suffix "o=sevenSeas" (actually it was the first occurrence I found), and the defect disappears with "o=sevenseas".
> I therefore assume that the authenticator used for simple binds has problems with the mixed characters in the suffices.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (DIREVE-284) Simple bind fails for entries with certain partition suffix names
Posted by "Alex Karasulu (JIRA)" <di...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/DIREVE-284?page=all ]
Alex Karasulu resolved DIREVE-284:
----------------------------------
Resolution: Fixed
Committed fix changes on revision 328236 here:
http://svn.apache.org/viewcvs.cgi?rev=328236&view=rev
Looks like lookups were being made against a bare nexus without normalizing the principals name. I started using the present operation's proxy object with bypasses where normalization was still allowed.
Added test case in MiscTest for Stefan's Kate Bush user.
> Simple bind fails for entries with certain partition suffix names
> -----------------------------------------------------------------
>
> Key: DIREVE-284
> URL: http://issues.apache.org/jira/browse/DIREVE-284
> Project: Directory Server
> Type: Bug
> Reporter: Stefan Zoerner
> Assignee: Alex Karasulu
> Fix For: 0.9.3
>
> Some users (i.e. person entries with userPassword attribute) can't authenticate to the server via simple bind. The problem does not exist with entries located in ou=system or dc=apache,dc=org. To give an example:
> I used the default server.xml from
> http://svn.apache.org/viewcvs.cgi/directory/apacheds/trunk/main/server.xml
> to start the server and added the following entry:
> dn: cn=Kate Bush,dc=apache,dc=org
> cn: Kate Bush
> objectclass: top
> objectclass: person
> sn: Bush
> userPassword: Aerial
> After that, the following works as expected:
> $ ldapsearch -h magritte -p 10389 -D "cn=Kate Bush,dc=apache,dc=org" -w Aerial -b "dc=apache,dc=org" "(sn=Bush)" cn
> cn=Kate Bush,dc=apache,dc=org
> cn=Kate Bush
> $
> and providing a wrong password leads to an "invalid credentials".
> But if I use "dc=aPache,dc=org" as suffix within the partition configuration, i.e.
> <property name="suffix"><value>dc=aPache,dc=org</value></property>
> adjust other occurrences of dc=apache as well and import the person entry above with DN "cn=Kate Bush,dc=aPache,dc=org", the following happens:
> $ ldapsearch -h magritte -p 10389 -D "cn=Kate Bush,dc=aPache,dc=org" -w Aerial -b "dc=aPache,dc=org" "(sn=Bush)" cn
> ldap_simple_bind: Invalid credentials
> $
> But this still works:
> $ ldapsearch -h magritte -p 10389 -D "uid=admin,ou=system" -w secret -b "dc=aPache,dc=org" "(sn=Bush)"
> cn=Kate Bush,dc=aPache,dc=org
> sn=Bush
> cn=Kate Bush
> objectclass=person
> objectclass=top
> userPassword=Aerial
> $
> I have the same problem with suffix "o=sevenSeas" (actually it was the first occurrence I found), and the defect disappears with "o=sevenseas".
> I therefore assume that the authenticator used for simple binds has problems with the mixed characters in the suffices.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira