Re: [SASL] SASL plan

[Alex Karasulu]

Excellent! I'll watch for commits to figure out where your SASL branch is to
add the code to return the supportedSASLMechanisms in the RootDSE.

Alex

On 3/6/07, Enrique Rodriguez <[EMAIL PROTECTED]> wrote:


On 3/6/07, Enrique Rodriguez <[EMAIL PROTECTED]> wrote:
> ...
> So, based on feedback from you and Emmanuel, I will:
> 1)  Branch the trunk to add SASL.
> 2)  Assign Alex a subtask to add supportedSASLMechanisms in the branch.

An issue is open:
https://issues.apache.org/jira/browse/DIRSERVER-867

> 3)  Start a page in Confluence.

I started this page at:

http://cwiki.apache.org/confluence/display/DIRxSBOX/SASL+Authentication+to+ApacheDS

Enrique

Re: [SASL] SASL plan

[Enrique Rodriguez]

On 3/6/07, Enrique Rodriguez <[EMAIL PROTECTED]> wrote:

...
So, based on feedback from you and Emmanuel, I will:
1)  Branch the trunk to add SASL.
2)  Assign Alex a subtask to add supportedSASLMechanisms in the branch.


An issue is open:
https://issues.apache.org/jira/browse/DIRSERVER-867


3)  Start a page in Confluence.


I started this page at:
http://cwiki.apache.org/confluence/display/DIRxSBOX/SASL+Authentication+to+ApacheDS

Enrique

[jira] Created: (DIRSERVER-867) Return populated supportedSASLMechanisms attribute

[Enrique Rodriguez (JIRA)]

Return populated supportedSASLMechanisms attribute
--

 Key: DIRSERVER-867
 URL: https://issues.apache.org/jira/browse/DIRSERVER-867
 Project: Directory ApacheDS
  Issue Type: New Feature
  Components: core
Affects Versions: 1.5.1
Reporter: Enrique Rodriguez
 Assigned To: Alex Karasulu


Some LDAP clients will query the LDAP server for the attribute 
'supportedSASLMechanisms'.  ApacheDS currently doesn't return this attribute.  
Assuming all supported mechanisms are enabled in configuration, the server 
should return:

supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: CRAM-MD5

Here's an excerpt from RFC 4512:

5.1.7.  'supportedSASLMechanisms'

   The 'supportedSASLMechanisms' attribute lists the SASL mechanisms
   [RFC4422] that the server recognizes and/or supports [RFC4513].  The
   contents of this attribute may depend on the current session state.
   If the server does not support any SASL mechanisms, this attribute
   will not be present.

  ( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
USAGE dSAOperation )

   The Directory String (1.3.6.1.4.1.1466.115.121.1.15) syntax is
   defined in [RFC4517].


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [SASL] SASL plan

[Enrique Rodriguez]

On 3/6/07, Alex Karasulu <[EMAIL PROTECTED]> wrote:

...
So basically this handles the client side generation of the digest which is
sent to the server rather than the password itself, then the server compares
this digest with the digest generated from the userPassword field?


No, typically a password is combined with some information shared by
the client and server, to prove both sides know the same password,
avoiding the need for the password to traverse the network.  There are
2-3 request-response pairs here, negotiating session setup and
responding to challenges from the server.


Stefan Zoerner last year hooked up a way to use digested passwords in the
...
If not you can just throw an exception since you cannot generate a digest
because the userPassword is not in available to do so.

I may be totally off here since I'm twice removed from this code and I may
have some misconceptions about how these mechanisms actually work but
I just thought I'd mention it here for the record.


This is the case.  In other LDAP servers you have to explicitly
configure the server to store the password plaintext.


You can actually extend AbstractServerTestCase or something like that in
server-unit.


Cool, I'll migrate to that.

So, based on feedback from you and Emmanuel, I will:
1)  Branch the trunk to add SASL.
2)  Assign Alex a subtask to add supportedSASLMechanisms in the branch.
3)  Start a page in Confluence.

Enrique

[jira] Commented: (DIRSERVER-865) errors when importing ACI from LDIF file containing tabs

[Stefan Seelmann (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRSERVER-865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478593
 ] 

Stefan Seelmann commented on DIRSERVER-865:
---

I was able to import this LDIF without an error, I tested it successfully with 
LDAP Studio and with JXplorer.

As far as i know you have to specify some attribute types for selfValue. For 
example "protectedItems { selfValue { mail } }, ". Here is the grammar of ACIs: 
http://docs.safehaus.org/display/APACHEDS/ABNF+syntax+for+LDAP+ACIItem

BTW: We a working on an editor for ACIs, both a GUI and a source editor with 
syntax highlighting. I think it will be available with the next LDAP Studio 
release.


> errors when importing ACI from LDIF file containing tabs
> 
>
> Key: DIRSERVER-865
> URL: https://issues.apache.org/jira/browse/DIRSERVER-865
> Project: Directory ApacheDS
>  Issue Type: Bug
> Environment: Windows XP
> Java 5.0 (Sun)
> JXplorer
>Reporter: Marek
> Attachments: allow John to read his name-space.error, allow John to 
> read his name-space.ldif, allow John to read his name-tab.error, allow John 
> to read his name-tab.ldif
>
>
> When I import "allow John to read his name-tab.ldif" file which contains tabs 
> I receive the following error in JXplorer and nothing is actually imported:
> javax.naming.directory.InvalidAttributeIdentifierException: [LDAP: error code 
> 17 - failed to add entry 
> cn=allowJohnToReadHisName_ACI12,o=sevenSeas,dc=example,dc=com: 
> itemoruserfirst userfirst not found in attribute registry!:
> org.apache.directory.shared.ldap.exception.LdapInvalidAttributeIdentifierException:
>itemoruserfirst userfirst not found in attribute registry!
>   at 
> org.apache.directory.server.core.schema.SchemaService.check(SchemaService.java:1598)
> When I change tabs to spaces i receive the following error, but everything is 
> imported correctly:
> javax.naming.NamingException: [LDAP: error code 54 - failed to add entry 
> cn=allowJohnToReadHisName_ACI13,o=sevenSeas,dc=example,dc=com: Unexpected 
> exception.:
> org.apache.directory.server.core.interceptor.InterceptorException: Unexpected 
> exception. [Root exception is java.lang.NullPointerException]
>   at 
> org.apache.directory.server.core.interceptor.InterceptorChain.throwInterceptorException(InterceptorChain.java:1510)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [Kerberos] Kerberos + OpenLDAP

[Quanah Gibson-Mount]

--On Tuesday, March 06, 2007 10:43 AM -0500 Jeffrey Hutzelman 
<[EMAIL PROTECTED]> wrote:





On Thursday, March 01, 2007 03:22:55 PM -0800 Enrique Rodriguez
<[EMAIL PROTECTED]> wrote:


On 3/1/07, Sam Hartman <[EMAIL PROTECTED]> wrote:

1) I'd really like to see interested individuals work on the LDAP schema
in the IETF. The effort has floundered for lack of people driving it.

2) I'd really love to see an ldap plugin that used some schema and
   called kadm5_* interfaces--I.E. a way to replace kadmind with
   openldap even in situations where the ldap kdb layer was not used.


1)  A standardized LDAP schema would be great and I'm sure we (Apache
Directory) would support it.  In the mean time we'll make our best
effort to reuse any existing schema rather than draft something new.

2)  I would personally participate in a standardization effort.  Is
anyone interested and who is also attending the Prague meeting?
(Prague Czech Republic - 68th IETF Meeting (March 18 - 23, 2007))


I'm glad to hear there are people actively interested in an effort to
produce a standardized LDAP schema for Kerberos.  As Sam noted, this has
been on the wish list for some time, but has received little attention
due to lack of interested parties with enough time.

I suggest that interested parties subscribe to the Kerberos working group
mailing list (ietf-krb-wg@anl.gov), and bring up this issue there.  If
there is enough interest in the working group to sustain this work, we
can consider adopting it as a work item.




has the instructions for subscribing.

--Quanah



--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

[jira] Created: (DIRSERVER-866) Initialization with another backend than JDBM for the system partition

[Emmanuel Lecharny (JIRA)]

Initialization with another backend than JDBM for the system partition
--

 Key: DIRSERVER-866
 URL: https://issues.apache.org/jira/browse/DIRSERVER-866
 Project: Directory ApacheDS
  Issue Type: New Feature
Reporter: Emmanuel Lecharny
 Fix For: 1.5.1


The initialization process statically declare a JdbmPartition in the current 
base code. If we were to use another backend, we should use a factory plus a 
configuration to initialize the alternate implementation :

in DefaultPartitionNexus.initializeSystemPartition() method, we have :
...
system = new JdbmPartition(); // using default implementation.
system.init( factoryCfg, systemCfg );
...

where system is the system backend.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DIRSERVER-855) Object class "objectClass" is called "ObjectClass" in search results

[Alex Karasulu (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRSERVER-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478466
 ] 

Alex Karasulu commented on DIRSERVER-855:
-

Thanks for testing this out.  Emmanuel was dead on with using the case of the 
attribute ID supplied in the search.  

Yes I agree that this is not too critical.  It just annoys me personally ... 
makes the server seem somewhat flaky if it's not adhering to these unspoken 
expectations.   




> Object class "objectClass" is called "ObjectClass" in search results
> 
>
> Key: DIRSERVER-855
> URL: https://issues.apache.org/jira/browse/DIRSERVER-855
> Project: Directory ApacheDS
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.0.1
> Environment: * ApacheDS 1.0.1 (SNAPSHOT, Rev. Rev. 507868)
> * Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03)
> * Windows XP Professional SP2
>Reporter: Stefan Zoerner
> Assigned To: Emmanuel Lecharny
>Priority: Minor
> Fix For: 1.0.2
>
>
> Currently it looks like this:
> $ ldapsearch -h localhost -p 389 -D "uid=admin,ou=system" -w ** -b 
> "dc=example,dc=com" -s base "(objectClass=*)"
> version: 1
> dn: dc=example,dc=com
> dc: example
> ObjectClass: domain
> ObjectClass: extensibleObject
> ObjectClass: top
> Although obviously not important: I would expect attribute "objectClass" here 
> (as it is called in the schema). The issue arises with all entries, newly 
> created ones  as well.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [SASL] SASL plan

[Alex Karasulu]

Hi Stefan,

Thanks for chimming in with the additional info.  It might come in handy for

what Enrique is working on.

Alex

On 3/6/07, Stefan Zoerner <[EMAIL PROTECTED]> wrote:


Alex Karasulu wrote:
> Stefan Zoerner last year hooked up a way to use digested passwords in
the
> userPassword field I think.  I wonder if there could be issues with SASL
> and
> this mechanism if the password value in the entry is already really a
digest
> rather than the password itself in plain text.  Just wanted to mention a
> potential
> problem here.  I guess you can just check if {SHA1} {MD5} prefixes are
> present
> in the password value before performing the test.  If it is then if the
> digest algol
> matches then just compare the supplied value with the digest values
stored.

You are right, Alex. The feature is described (from a user's point o
view) here:

http://directory.apache.org/apacheds/1.0/31-authentication-options.html

But the server does not digest passwords on his own account, the user
(or his tools) has to calculate the value and transmit it. I still plan
to write a simple interceptor as an example for the docs, which exactly
does this, but this is another story.

Digesting userPassword values in conjunction with SASL DIGEST won't
work, we should clarify this in the documentation.

Greetings from Hamburg,
 Stefan

[jira] Commented: (DIRSTUDIO-1) DSML Parser does not throw an exception when it doesn't find a requestID attribute when processing=parallel and responseOrder=unordered

[Pierre-Arnaud Marcelot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRSTUDIO-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478446
 ] 

Pierre-Arnaud Marcelot commented on DIRSTUDIO-1:


Forgot to add a test case for AbandonRequest in the last commit.

Test case added at commit 515159.

http://svn.apache.org/viewvc?view=rev&rev=515159

> DSML Parser does not throw an exception when it doesn't find a requestID 
> attribute when processing=parallel and responseOrder=unordered
> ---
>
> Key: DIRSTUDIO-1
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1
> Project: Directory LDAP Studio
>  Issue Type: Bug
>  Components: ldapstudio-dsml-parser
>Affects Versions: 0.6.0
>Reporter: Pierre-Arnaud Marcelot
> Assigned To: Pierre-Arnaud Marcelot
> Fix For: 0.7.0
>
>
> DSML Parser does not throw an exception when it doesn't find a requestID 
> attribute when a processing=parallel and responseOrder=unordered.
> In this case, we must have a requestID attribute to be able to answer it 
> correctly. See DSMLv2 specification (p. 7) 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [Kerberos] Kerberos + OpenLDAP

[Jeffrey Hutzelman]

On Thursday, March 01, 2007 03:22:55 PM -0800 Enrique Rodriguez 
<[EMAIL PROTECTED]> wrote:



On 3/1/07, Sam Hartman <[EMAIL PROTECTED]> wrote:

1) I'd really like to see interested individuals work on the LDAP schema
in the IETF. The effort has floundered for lack of people driving it.

2) I'd really love to see an ldap plugin that used some schema and
   called kadm5_* interfaces--I.E. a way to replace kadmind with
   openldap even in situations where the ldap kdb layer was not used.


1)  A standardized LDAP schema would be great and I'm sure we (Apache
Directory) would support it.  In the mean time we'll make our best
effort to reuse any existing schema rather than draft something new.

2)  I would personally participate in a standardization effort.  Is
anyone interested and who is also attending the Prague meeting?
(Prague Czech Republic - 68th IETF Meeting (March 18 - 23, 2007))


I'm glad to hear there are people actively interested in an effort to 
produce a standardized LDAP schema for Kerberos.  As Sam noted, this has 
been on the wish list for some time, but has received little attention due 
to lack of interested parties with enough time.


I suggest that interested parties subscribe to the Kerberos working group 
mailing list (ietf-krb-wg@anl.gov), and bring up this issue there.  If 
there is enough interest in the working group to sustain this work, we can 
consider adopting it as a work item.


As for Prague, if there is interest in discussing this topic further, I can 
try to provide some time in krb-wg's agenda.


-- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]>
  Chair, IETF Kerberos Working Group
  Carnegie Mellon University - Pittsburgh, PA

[jira] Closed: (DIRSTUDIO-1) DSML Parser does not throw an exception when it doesn't find a requestID attribute when processing=parallel and responseOrder=unordered

[Pierre-Arnaud Marcelot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRSTUDIO-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pierre-Arnaud Marcelot closed DIRSTUDIO-1.
--


Closed.

> DSML Parser does not throw an exception when it doesn't find a requestID 
> attribute when processing=parallel and responseOrder=unordered
> ---
>
> Key: DIRSTUDIO-1
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1
> Project: Directory LDAP Studio
>  Issue Type: Bug
>  Components: ldapstudio-dsml-parser
>Affects Versions: 0.6.0
>Reporter: Pierre-Arnaud Marcelot
> Assigned To: Pierre-Arnaud Marcelot
> Fix For: 0.7.0
>
>
> DSML Parser does not throw an exception when it doesn't find a requestID 
> attribute when a processing=parallel and responseOrder=unordered.
> In this case, we must have a requestID attribute to be able to answer it 
> correctly. See DSMLv2 specification (p. 7) 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (DIRSTUDIO-1) DSML Parser does not throw an exception when it doesn't find a requestID attribute when processing=parallel and responseOrder=unordered

[Pierre-Arnaud Marcelot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRSTUDIO-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pierre-Arnaud Marcelot resolved DIRSTUDIO-1.


Resolution: Fixed

Fixed at commit 515141.

http://svn.apache.org/viewvc?view=rev&rev=515141

> DSML Parser does not throw an exception when it doesn't find a requestID 
> attribute when processing=parallel and responseOrder=unordered
> ---
>
> Key: DIRSTUDIO-1
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1
> Project: Directory LDAP Studio
>  Issue Type: Bug
>  Components: ldapstudio-dsml-parser
>Affects Versions: 0.6.0
>Reporter: Pierre-Arnaud Marcelot
> Assigned To: Pierre-Arnaud Marcelot
> Fix For: 0.7.0
>
>
> DSML Parser does not throw an exception when it doesn't find a requestID 
> attribute when a processing=parallel and responseOrder=unordered.
> In this case, we must have a requestID attribute to be able to answer it 
> correctly. See DSMLv2 specification (p. 7) 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DIRSERVER-855) Object class "objectClass" is called "ObjectClass" in search results

[Stefan Zoerner (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRSERVER-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478434
 ] 

Stefan Zoerner commented on DIRSERVER-855:
--

I think, this is not that important. I have retested the current server, and my 
original issue is fixed (ObjectClass vanished). 

By the way, Alex: Sun Java System Directory Server 5.2 uses the attribute names 
provided in the search in the results, for instance:

$ ldapsearch -b "dc=magritte" -s base "(objectClass=*)"
version: 1
dn: dc=magritte
dc: magritte
objectClass: top
objectClass: domain

$ ldapsearch -b "dc=magritte" -s base "(objectClass=*)" OBJECTCLASS DC
version: 1
dn: dc=magritte
OBJECTCLASS: top
OBJECTCLASS: domain
DC: magritte

Currently, I have not the chance to test other servers, because I am in the 
office. But as depicted above -- Not that important.

> Object class "objectClass" is called "ObjectClass" in search results
> 
>
> Key: DIRSERVER-855
> URL: https://issues.apache.org/jira/browse/DIRSERVER-855
> Project: Directory ApacheDS
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.0.1
> Environment: * ApacheDS 1.0.1 (SNAPSHOT, Rev. Rev. 507868)
> * Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03)
> * Windows XP Professional SP2
>Reporter: Stefan Zoerner
> Assigned To: Emmanuel Lecharny
>Priority: Minor
> Fix For: 1.0.2
>
>
> Currently it looks like this:
> $ ldapsearch -h localhost -p 389 -D "uid=admin,ou=system" -w ** -b 
> "dc=example,dc=com" -s base "(objectClass=*)"
> version: 1
> dn: dc=example,dc=com
> dc: example
> ObjectClass: domain
> ObjectClass: extensibleObject
> ObjectClass: top
> Although obviously not important: I would expect attribute "objectClass" here 
> (as it is called in the schema). The issue arises with all entries, newly 
> created ones  as well.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [SASL] SASL plan

[Stefan Zoerner]

Alex Karasulu wrote:

Stefan Zoerner last year hooked up a way to use digested passwords in the
userPassword field I think.  I wonder if there could be issues with SASL 
and

this mechanism if the password value in the entry is already really a digest
rather than the password itself in plain text.  Just wanted to mention a 
potential
problem here.  I guess you can just check if {SHA1} {MD5} prefixes are 
present
in the password value before performing the test.  If it is then if the 
digest algol

matches then just compare the supplied value with the digest values stored.


You are right, Alex. The feature is described (from a user's point o 
view) here:


http://directory.apache.org/apacheds/1.0/31-authentication-options.html

But the server does not digest passwords on his own account, the user 
(or his tools) has to calculate the value and transmit it. I still plan 
to write a simple interceptor as an example for the docs, which exactly 
does this, but this is another story.


Digesting userPassword values in conjunction with SASL DIGEST won't 
work, we should clarify this in the documentation.


Greetings from Hamburg,
Stefan

Re: [SASL] SASL plan

[Alex Karasulu]

Enrique,

This is great.

On 3/5/07, Enrique Rodriguez <[EMAIL PROTECTED]> wrote:


I have SASL working; that is to say, the DIGEST-MD5, CRAM-MD5, and



So basically this handles the client side generation of the digest which is
sent to the server rather than the password itself, then the server compares
this digest with the digest generated from the userPassword field?

Stefan Zoerner last year hooked up a way to use digested passwords in the
userPassword field I think.  I wonder if there could be issues with SASL and
this mechanism if the password value in the entry is already really a digest
rather than the password itself in plain text.  Just wanted to mention a
potential
problem here.  I guess you can just check if {SHA1} {MD5} prefixes are
present
in the password value before performing the test.  If it is then if the
digest algol
matches then just compare the supplied value with the digest values stored.

If not you can just throw an exception since you cannot generate a digest
because
the userPassword is not in available to do so.

I may be totally off here since I'm twice removed from this code and I may
have some misconceptions about how these mechanisms actually work but
I just thought I'd mention it here for the record.

GSSAPI mechanisms.  The integration tests just completed (27 minutes

on a POS box).



FYI if you have enough RAM you can setup a kernel parameter for setting up
larger ram drives limit is 768MB btw.  Then you can just combine them using
mdadm with RAID 1.  I can cut down the test run time by more than half when
doing this.

New SASL integration tests are also complete.  I used

the JDK's JNDI client to test a variety of positive and negative
scenarios.  Also, I tested manually with the ldap-clients CLI tools,
eg ldapsearch.

I need to wrap up a few loose ends:
1)  My integration tests require a running server.  I just haven't
gotten around to figuring out how it's done elsewhere in ApacheDS.
I'll get on that next.



You can actually extend AbstractServerTestCase or something like that in
server-unit.
This puppy starts up the server with all the networking and services (even
searches for
an available port and stores that in a protected member for your test
methods to query).
Just extend this, and lookup the port the server is running on and use that
to test the
SASL capabilities.  This way your integration tests will work on all
machines regardless
of port availability.



2)  I need to add javadocs.
3)  I triplicated a lot of code to make each mechanism work, so
there's one big round of refactoring due to tighten things up.



Understood sometimes that just happens.  Perhaps as Emmanuel recommended in
another
response, you can just create a branch and work in there.  Then we can merge
the features
back into the main line.  Just stay disciplined and don't do too many things
that do not relate
to the task at hand so the diffs can easily be reviewed without clutter (for
example don't reformat
code which masks the key changes for new features)

The BindHandler is totally replaced.


Yeah I expected that.  It just selects a different work flow based on the
sasl flag of
the bind request I guess.

The execution path for the

Simple mechanism is unchanged and integration tests pass so I don't
think this is a major change.  Outside of the LDAP PP, a SaslFilter
needs to get added to the filter chains in ServerContextFactory.  The
'server-sasl' module can be deleted.



Aye you mean a MINA filter I guess.  Yeah that makes sense.

Most config is hardcoded, but I put it all in one class.  From there,

we can work it into the server.xml.



Sure this is really easy to do with the Spring stuff although a little
tedious.
I can help with these tasks.

Also, none of the advanced regex's we talked about is done.  The deal

with authentication is that:
CRAM-MD5:  looks for 'uid' under a base DN.
DIGEST-MD5:  looks for 'uid' under a base DN.  Realm must match realms
advertised by the LDAP server, but there is no multi-realm support
yet.



No problem ... small steps till we get to what the users like.  Might be a
good idea
to just get it tight and working and release the feature.  Then solicit some
feedback
from the users to see what they want to see put into the next round?  Just
an idea.

GSSAPI:  looks for a krb5PrincipalName under a base DN.  Also no

multi-realm support yet.

The ease of configuring GSSAPI/Kerberos really stands out.  Principal
configuration (user, service, krbtgt) can all occur on LDIF load,
which is really cool.  The implication, besides not relying,
server-side, on external config files, is that you also don't need to
export a service principal key from the directory, like you do with
standalone LDAP servers.



That rocks!

One last thing, the JDK's JNDI client checks the RootDSE for

'supportedSASLMechanisms', so we need to add that as the intersection
of configured mechanisms from the server.xml and the supported
mechanisms and return that from the DefaultPartitionN

[jira] Commented: (DIRSERVER-855) Object class "objectClass" is called "ObjectClass" in search results

[Emmanuel Lecharny (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRSERVER-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478416
 ] 

Emmanuel Lecharny commented on DIRSERVER-855:
-

well, atm, the requested attributes are returned as they were provided, except 
for objectClass which is treated differently, because SchemaService has been 
modified to handle such cases as adding missing objectClasses.

The test you added to check that the casing is respected works well for all the 
attributeTypes, otherwise.

Does it worth the pain to deal with people trying to insert OBJECTCLASS as an 
attribuetType, and expecting to get back OBJECTCLASS? I bet no. For other 
attributeTypes, like organizationalPerson (for instance), keeping the user's 
casing seems important, and in fact this is what we have currently implemented.

May be someone would dedicate a few hours writing some complete test cases to 
check that we respect this contract ? Anyone ?

> Object class "objectClass" is called "ObjectClass" in search results
> 
>
> Key: DIRSERVER-855
> URL: https://issues.apache.org/jira/browse/DIRSERVER-855
> Project: Directory ApacheDS
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.0.1
> Environment: * ApacheDS 1.0.1 (SNAPSHOT, Rev. Rev. 507868)
> * Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03)
> * Windows XP Professional SP2
>Reporter: Stefan Zoerner
> Assigned To: Emmanuel Lecharny
>Priority: Minor
> Fix For: 1.0.2
>
>
> Currently it looks like this:
> $ ldapsearch -h localhost -p 389 -D "uid=admin,ou=system" -w ** -b 
> "dc=example,dc=com" -s base "(objectClass=*)"
> version: 1
> dn: dc=example,dc=com
> dc: example
> ObjectClass: domain
> ObjectClass: extensibleObject
> ObjectClass: top
> Although obviously not important: I would expect attribute "objectClass" here 
> (as it is called in the schema). The issue arises with all entries, newly 
> created ones  as well.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DIRSERVER-855) Object class "objectClass" is called "ObjectClass" in search results

[Alex Karasulu (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRSERVER-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478413
 ] 

Alex Karasulu commented on DIRSERVER-855:
-

Interesting idea regarding using the user supplied attributes list.  I wonder 
if other servers respect this and return the attribute ID as it was asked for.  
However note that for the most general case where no requested attribute is 
supplied (all userApplication attributes are returned) we still have the 
problem.  I guess this is a cute feature to have ... sounds appealing at first 
but I think just making sure for now that attribute Ids are returned as given 
on add and modify add/replace operations is preserved.

> Object class "objectClass" is called "ObjectClass" in search results
> 
>
> Key: DIRSERVER-855
> URL: https://issues.apache.org/jira/browse/DIRSERVER-855
> Project: Directory ApacheDS
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.0.1
> Environment: * ApacheDS 1.0.1 (SNAPSHOT, Rev. Rev. 507868)
> * Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03)
> * Windows XP Professional SP2
>Reporter: Stefan Zoerner
> Assigned To: Emmanuel Lecharny
>Priority: Minor
> Fix For: 1.0.2
>
>
> Currently it looks like this:
> $ ldapsearch -h localhost -p 389 -D "uid=admin,ou=system" -w ** -b 
> "dc=example,dc=com" -s base "(objectClass=*)"
> version: 1
> dn: dc=example,dc=com
> dc: example
> ObjectClass: domain
> ObjectClass: extensibleObject
> ObjectClass: top
> Although obviously not important: I would expect attribute "objectClass" here 
> (as it is called in the schema). The issue arises with all entries, newly 
> created ones  as well.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (DIRSTUDIO-41) Add an Overview page on the Schema Editor that displays all ATs and OCs of the schema

[Pierre-Arnaud Marcelot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRSTUDIO-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pierre-Arnaud Marcelot closed DIRSTUDIO-41.
---


Closed.

> Add an Overview page on the Schema Editor that displays all ATs and OCs of 
> the schema
> -
>
> Key: DIRSTUDIO-41
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-41
> Project: Directory LDAP Studio
>  Issue Type: New Feature
>  Components: ldapstudio-schemas
>Reporter: Pierre-Arnaud Marcelot
> Assigned To: Pierre-Arnaud Marcelot
> Fix For: 0.7.0
>
>
> Add an Overview page on the Schema Editor that displays all ATs and OCs of 
> the schema

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (DIRSTUDIO-41) Add an Overview page on the Schema Editor that displays all ATs and OCs of the schema

[Pierre-Arnaud Marcelot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRSTUDIO-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pierre-Arnaud Marcelot resolved DIRSTUDIO-41.
-

Resolution: Fixed

Fixed at commit 515078.

http://svn.apache.org/viewvc?view=rev&rev=515078

> Add an Overview page on the Schema Editor that displays all ATs and OCs of 
> the schema
> -
>
> Key: DIRSTUDIO-41
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-41
> Project: Directory LDAP Studio
>  Issue Type: New Feature
>  Components: ldapstudio-schemas
>Reporter: Pierre-Arnaud Marcelot
> Assigned To: Pierre-Arnaud Marcelot
> Fix For: 0.7.0
>
>
> Add an Overview page on the Schema Editor that displays all ATs and OCs of 
> the schema

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DIRSERVER-858) Allow subclassing LdapDN

[Emmanuel Lecharny (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRSERVER-858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478354
 ] 

Emmanuel Lecharny commented on DIRSERVER-858:
-

Parsing a DN is a pretty fast operation : on my desktop (pentium 3Ghz), I can 
parse 120 000 dc=example, dc=com DN per second. 

Your example is not correct. I assume it will work for "dc=example, dc=com" if 
you do a 
bytes = StringTools.getBytesUtf8(dn); 
but if you have a DN like : sn=lécharny, dc=example, dc=com, it's simply not 
enough. The 'é'  should be handled and escaped, and this is what the parser is 
doing.

Last point : LdapDN is not intended to be used out of the server.

However, if you propose a patch, we may consider to apply it. Don't forget to 
propose a patch for 1.0 and 1.5 version.

> Allow subclassing LdapDN
> 
>
> Key: DIRSERVER-858
> URL: https://issues.apache.org/jira/browse/DIRSERVER-858
> Project: Directory ApacheDS
>  Issue Type: Improvement
>  Components: ldap
>Affects Versions: 1.0.1, 1.5.0
>Reporter: Endi S. Dewata
>
> Currently when you create an LdapDN object from a given DN string the code 
> will always parse the string into its RDN components.
> LdapDN dn = new LdapDN("dc=example,dc=com");
> The parsing code, however, depending on your application, could take up to 5% 
> of the time.
> For applications that require high performance, it would be great if we could 
> create a subclass of LdapDN that will bypass the DN parsing code, or lazily 
> parse the DN only when needed. See the following code:
> LdapDN dn = new MyLdapDN("dc=example,dc=com");
> SearchResponseEntry response = new 
> SearchResponseEntryImpl(request.getMessageId());
> response.setObjectName(dn);
> response.setAttributes(attributes);
> The MyLdapDN class would be very simple:
> public class MyLdapDN extends LdapDN {
> public MyLdapDN(String dn) throws Exception {
> bytes = StringTools.getBytesUtf8(dn);
> }
> }
> Unfortunately this code is currently doesn't work because the the "bytes" 
> field of LdapDN is private and the LdapDN.getNbBytes() and LdapDN.getBytes() 
> methods require direct access to the field.
> The solution is simple, here are some alternatives:
> 1. Change the field access to protected.
> 2. Add LdapDN.setBytes() method.
> 3. Add LdapDN.getBytes() that can be overridden by the subclass, and change 
> the LdapDN.getNbBytes() and LdapDN.getBytes() to call this method.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DIRSERVER-855) Object class "objectClass" is called "ObjectClass" in search results

[Emmanuel Lecharny (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRSERVER-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478346
 ] 

Emmanuel Lecharny commented on DIRSERVER-855:
-

Partially fixed in 1.0.2 :
http://svn.apache.org/viewvc?view=rev&rev=515053
http://svn.apache.org/viewvc?view=rev&rev=515055
http://svn.apache.org/viewvc?view=rev&rev=515056
http://svn.apache.org/viewvc?view=rev&rev=515057
http://svn.apache.org/viewvc?view=rev&rev=515058


> Object class "objectClass" is called "ObjectClass" in search results
> 
>
> Key: DIRSERVER-855
> URL: https://issues.apache.org/jira/browse/DIRSERVER-855
> Project: Directory ApacheDS
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.0.1
> Environment: * ApacheDS 1.0.1 (SNAPSHOT, Rev. Rev. 507868)
> * Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03)
> * Windows XP Professional SP2
>Reporter: Stefan Zoerner
> Assigned To: Emmanuel Lecharny
>Priority: Minor
> Fix For: 1.0.2
>
>
> Currently it looks like this:
> $ ldapsearch -h localhost -p 389 -D "uid=admin,ou=system" -w ** -b 
> "dc=example,dc=com" -s base "(objectClass=*)"
> version: 1
> dn: dc=example,dc=com
> dc: example
> ObjectClass: domain
> ObjectClass: extensibleObject
> ObjectClass: top
> Although obviously not important: I would expect attribute "objectClass" here 
> (as it is called in the schema). The issue arises with all entries, newly 
> created ones  as well.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DIRSERVER-855) Object class "objectClass" is called "ObjectClass" in search results

[Emmanuel Lecharny (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRSERVER-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478340
 ] 

Emmanuel Lecharny commented on DIRSERVER-855:
-

Another step would be to return the attributes the user is waiting using the 
names he gave to the server in the attributes list to be returned. For 
instance, if the user specify that he wants OBJECTCLASS, then he adds 
OBJECTCLASS to the list of wanted attributes, and we return all the 
objectClasses using OBJECTCLASS.



> Object class "objectClass" is called "ObjectClass" in search results
> 
>
> Key: DIRSERVER-855
> URL: https://issues.apache.org/jira/browse/DIRSERVER-855
> Project: Directory ApacheDS
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.0.1
> Environment: * ApacheDS 1.0.1 (SNAPSHOT, Rev. Rev. 507868)
> * Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03)
> * Windows XP Professional SP2
>Reporter: Stefan Zoerner
> Assigned To: Emmanuel Lecharny
>Priority: Minor
> Fix For: 1.0.2
>
>
> Currently it looks like this:
> $ ldapsearch -h localhost -p 389 -D "uid=admin,ou=system" -w ** -b 
> "dc=example,dc=com" -s base "(objectClass=*)"
> version: 1
> dn: dc=example,dc=com
> dc: example
> ObjectClass: domain
> ObjectClass: extensibleObject
> ObjectClass: top
> Although obviously not important: I would expect attribute "objectClass" here 
> (as it is called in the schema). The issue arises with all entries, newly 
> created ones  as well.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [jira] Resolved: (DIRSTUDIO-64) Unable to modify an Attribute Type's OID

[Stefan Seelmann]

Damn, I will never learn it. I forgot to clear the cache. Sorry for that.

Thanks,
Stefan

Pierre-Arnaud Marcelot wrote:


Hi Stefan.

Did you clear Ivy repository cache ("/home/YourUser/.ivy") ?

Since I have updated the jar in the dependency repository (and it's 
not a new dependency), Ivy may not have updated its own.


P-A M.


On 3/5/07, *Stefan Seelmann* <[EMAIL PROTECTED] 
> wrote:


PAM, could you please check apache-ds-plugin? I updated but the class
AttributeTypeLiteral doesn't contain a setOid(String) method.

[javac] symbol  : method setOid( java.lang.String)
[javac] location: class
org.apache.directory.server.core.tools.schema.AttributeTypeLiteral
[javac] literal.setOid( oid );
[javac]^
---

Thanks,
Stefan

Pierre-Arnaud Marcelot (JIRA) schrieb:
>  [

https://issues.apache.org/jira/browse/DIRSTUDIO-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel


]
>
> Pierre-Arnaud Marcelot resolved DIRSTUDIO-64.
> -
>
> Resolution: Fixed
>
> Resolved at commit 514644 & 514647.
>
> http://svn.apache.org/viewvc?view=rev&rev=514644

> http://svn.apache.org/viewvc?view=rev&rev=514647

>
>
>
>> Unable to modify an Attribute Type's OID
>> 
>>
>> Key: DIRSTUDIO-64
>> URL:
https://issues.apache.org/jira/browse/DIRSTUDIO-64
>> Project: Directory LDAP Studio
>>  Issue Type: Bug
>>  Components: ldapstudio-schemas
>>Affects Versions: 0.6.0
>>Reporter: Pierre-Arnaud Marcelot
>> Assigned To: Pierre-Arnaud Marcelot
>> Fix For: 0.7.0
>>
>>
>> It's impossible to change the OID of an attribute type.
>> The current version of the shared LDAP jar doesnt include a
method to change the oid of an AT. Current trunk version of shared
LDAP includes it.
>> It would be great to generate a new version of the shared LDAP
dependency to be able to change the OID of an AT in the UI of the
Attribute Type Editor.
>>
>
>

Re: [SASL] SASL plan

[Emmanuel Lecharny]

Enrique Rodriguez a écrit :


I have SASL working; that is to say, the DIGEST-MD5, CRAM-MD5, and
GSSAPI mechanisms.  


Great ! This is one excellent news !


The integration tests just completed (27 minutes
on a POS box).  New SASL integration tests are also complete.  I used
the JDK's JNDI client to test a variety of positive and negative
scenarios.  Also, I tested manually with the ldap-clients CLI tools,
eg ldapsearch.

I need to wrap up a few loose ends:
1)  My integration tests require a running server.  I just haven't
gotten around to figuring out how it's done elsewhere in ApacheDS.
I'll get on that next.


I think the best solution would be to look at server-unit tests, where 
an embedded ADS is launched, so you don't have to launch the server before.



2)  I need to add javadocs.
3)  I triplicated a lot of code to make each mechanism work, so
there's one big round of refactoring due to tighten things up.


What about pushing the code in a branch so that we can help without 
breaking the serve r(we are currently in the process to close a 1.5.0 
version) ? Not that we really care to break the server, but we want to 
tag this one, before adding new features. Let say that SASL can be 
introduced in 1.5.1 (FYI, 1.5.0 is expected in the next two weeks, and 
it's pretty much about fixing some bugs)




The BindHandler is totally replaced.  The execution path for the
Simple mechanism is unchanged and integration tests pass so I don't
think this is a major change.  Outside of the LDAP PP, a SaslFilter
needs to get added to the filter chains in ServerContextFactory.  The
'server-sasl' module can be deleted.


It would be very appreciated if you can add a 'big-picture' somwhere in 
confluence. The new site is now directly linked to confluence, and in 
the 1.5.0 page, you can add this page somewhere in 
http://directory.apache.org/apacheds/1.5/apacheds-v15-advanced-users-guide.html 
(the little light grey icone on the upper right side of the main frame 
is used to edit the page)




Most config is hardcoded, but I put it all in one class.  From there,
we can work it into the server.xml.

Also, none of the advanced regex's we talked about is done.  The deal
with authentication is that:
CRAM-MD5:  looks for 'uid' under a base DN.
DIGEST-MD5:  looks for 'uid' under a base DN.  Realm must match realms
advertised by the LDAP server, but there is no multi-realm support
yet.
GSSAPI:  looks for a krb5PrincipalName under a base DN.  Also no
multi-realm support yet.

The ease of configuring GSSAPI/Kerberos really stands out.  Principal
configuration (user, service, krbtgt) can all occur on LDIF load,
which is really cool.  The implication, besides not relying,
server-side, on external config files, is that you also don't need to
export a service principal key from the directory, like you do with
standalone LDAP servers.

One last thing, the JDK's JNDI client checks the RootDSE for
'supportedSASLMechanisms', so we need to add that as the intersection
of configured mechanisms from the server.xml and the supported
mechanisms and return that from the DefaultPartitionNexus.


hmmm... My bet is that it would be better to configure such things using 
ADS itself. We are now trying to figure out a way to store all the 
configuration into the server as Ldap entries, instead of having a giant 
server.xml file. This is a work in progress, but certainly a way to go.




I could use some guidance on how to proceed.  Mostly I'm wondering if
it's worth branching or not.  


IMHO, yes. As your great work is pretty much parrallel (except for 
BindHandler), branching won't harm.



Only the BindHandler in the
protocol-ldap module is affected, but we haven't started in on any
regex processing or moving authentication to actual Authenticators.

Enrique


Thanks Enrique, we were expecting this SASL for a very long time, this 
is such a feature which make ADS a better server !


Emmanuel

Re: [jira] Resolved: (DIRSTUDIO-64) Unable to modify an Attribute Type's OID

[Pierre-Arnaud Marcelot]

Hi Stefan.

Did you clear Ivy repository cache ("/home/YourUser/.ivy") ?

Since I have updated the jar in the dependency repository (and it's not a
new dependency), Ivy may not have updated its own.

P-A M.


On 3/5/07, Stefan Seelmann <[EMAIL PROTECTED]> wrote:


PAM, could you please check apache-ds-plugin? I updated but the class
AttributeTypeLiteral doesn't contain a setOid(String) method.

[javac] symbol  : method setOid(java.lang.String)
[javac] location: class
org.apache.directory.server.core.tools.schema.AttributeTypeLiteral
[javac] literal.setOid( oid );
[javac]^
---

Thanks,
Stefan

Pierre-Arnaud Marcelot (JIRA) schrieb:
>  [
https://issues.apache.org/jira/browse/DIRSTUDIO-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
>
> Pierre-Arnaud Marcelot resolved DIRSTUDIO-64.
> -
>
> Resolution: Fixed
>
> Resolved at commit 514644 & 514647.
>
> http://svn.apache.org/viewvc?view=rev&rev=514644
> http://svn.apache.org/viewvc?view=rev&rev=514647
>
>
>
>> Unable to modify an Attribute Type's OID
>> 
>>
>> Key: DIRSTUDIO-64
>> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-64
>> Project: Directory LDAP Studio
>>  Issue Type: Bug
>>  Components: ldapstudio-schemas
>>Affects Versions: 0.6.0
>>Reporter: Pierre-Arnaud Marcelot
>> Assigned To: Pierre-Arnaud Marcelot
>> Fix For: 0.7.0
>>
>>
>> It's impossible to change the OID of an attribute type.
>> The current version of the shared LDAP jar doesnt include a method to
change the oid of an AT. Current trunk version of shared LDAP includes it.
>> It would be great to generate a new version of the shared LDAP
dependency to be able to change the OID of an AT in the UI of the Attribute
Type Editor.
>>
>
>

[jira] Commented: (DIRSERVER-865) errors when importing ACI from LDIF file containing tabs

[Marek (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRSERVER-865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478306
 ] 

Marek commented on DIRSERVER-865:
-

Before I exected "the ldif file with spaces", I executed other file contining 
something like this

dn: o=sevenSeas,dc=example,dc=com
changetype: modify
add: administrativeRole
administrativeRole: accessControlSpecificArea


> errors when importing ACI from LDIF file containing tabs
> 
>
> Key: DIRSERVER-865
> URL: https://issues.apache.org/jira/browse/DIRSERVER-865
> Project: Directory ApacheDS
>  Issue Type: Bug
> Environment: Windows XP
> Java 5.0 (Sun)
> JXplorer
>Reporter: Marek
> Attachments: allow John to read his name-space.error, allow John to 
> read his name-space.ldif, allow John to read his name-tab.error, allow John 
> to read his name-tab.ldif
>
>
> When I import "allow John to read his name-tab.ldif" file which contains tabs 
> I receive the following error in JXplorer and nothing is actually imported:
> javax.naming.directory.InvalidAttributeIdentifierException: [LDAP: error code 
> 17 - failed to add entry 
> cn=allowJohnToReadHisName_ACI12,o=sevenSeas,dc=example,dc=com: 
> itemoruserfirst userfirst not found in attribute registry!:
> org.apache.directory.shared.ldap.exception.LdapInvalidAttributeIdentifierException:
>itemoruserfirst userfirst not found in attribute registry!
>   at 
> org.apache.directory.server.core.schema.SchemaService.check(SchemaService.java:1598)
> When I change tabs to spaces i receive the following error, but everything is 
> imported correctly:
> javax.naming.NamingException: [LDAP: error code 54 - failed to add entry 
> cn=allowJohnToReadHisName_ACI13,o=sevenSeas,dc=example,dc=com: Unexpected 
> exception.:
> org.apache.directory.server.core.interceptor.InterceptorException: Unexpected 
> exception. [Root exception is java.lang.NullPointerException]
>   at 
> org.apache.directory.server.core.interceptor.InterceptorChain.throwInterceptorException(InterceptorChain.java:1510)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DIRSERVER-865) errors when importing ACI from LDIF file containing tabs

[Marek (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRSERVER-865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478310
 ] 

Marek commented on DIRSERVER-865:
-

I also get NPE while importing such an ACI, which I copy pasted (and changed a 
little bit) from "ApacheDS Access Control Administration; The X.500 Way", 
Presented by Ersin Er

dn: 
cn=sevenSeasAuthorizationRequirementsACISubentry,o=sevenSeas,dc=example,dc=com
objectclass: top
objectclass: subentry
objectclass: accessControlSubentry
cn: sevenSeasAuthorizationRequirementsACISubentry
subtreeSpecification: {}
prescriptiveACI: {
 identificationTag 
"allowAllUsersToSubscribeToUnsubscribeFromAMailingList_ACI",
 precedence 14, 
 authenticationLevel simple,
 itemOrUserFirst userFirst: 
 {
 userClasses 
 {
allUsers
 },
 userPermissions 
 {
 { 
   protectedItems { entry },
   grantsAndDenials { grantModify }
 },
 { 
   protectedItems { selfValue },
   grantsAndDenials { grantRemove, grantAdd }
 }
 }
  }
  }

I discovered, that if I change selfValue->entry, everything works fine. 
Otherwise I get NPE while importing this by JXplorer.


> errors when importing ACI from LDIF file containing tabs
> 
>
> Key: DIRSERVER-865
> URL: https://issues.apache.org/jira/browse/DIRSERVER-865
> Project: Directory ApacheDS
>  Issue Type: Bug
> Environment: Windows XP
> Java 5.0 (Sun)
> JXplorer
>Reporter: Marek
> Attachments: allow John to read his name-space.error, allow John to 
> read his name-space.ldif, allow John to read his name-tab.error, allow John 
> to read his name-tab.ldif
>
>
> When I import "allow John to read his name-tab.ldif" file which contains tabs 
> I receive the following error in JXplorer and nothing is actually imported:
> javax.naming.directory.InvalidAttributeIdentifierException: [LDAP: error code 
> 17 - failed to add entry 
> cn=allowJohnToReadHisName_ACI12,o=sevenSeas,dc=example,dc=com: 
> itemoruserfirst userfirst not found in attribute registry!:
> org.apache.directory.shared.ldap.exception.LdapInvalidAttributeIdentifierException:
>itemoruserfirst userfirst not found in attribute registry!
>   at 
> org.apache.directory.server.core.schema.SchemaService.check(SchemaService.java:1598)
> When I change tabs to spaces i receive the following error, but everything is 
> imported correctly:
> javax.naming.NamingException: [LDAP: error code 54 - failed to add entry 
> cn=allowJohnToReadHisName_ACI13,o=sevenSeas,dc=example,dc=com: Unexpected 
> exception.:
> org.apache.directory.server.core.interceptor.InterceptorException: Unexpected 
> exception. [Root exception is java.lang.NullPointerException]
>   at 
> org.apache.directory.server.core.interceptor.InterceptorChain.throwInterceptorException(InterceptorChain.java:1510)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.