[jira] Commented: (DIRSERVER-865) errors when importing ACI from LDIF file containing tabs
[
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.
[jira] Commented: (DIRSERVER-865) errors when importing ACI from LDIF file containing tabs
[ 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.
Re: [jira] Resolved: (DIRSTUDIO-64) Unable to modify an Attribute Type's OID
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=revrev=514644 http://svn.apache.org/viewvc?view=revrev=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
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
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] mailto:[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 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=revrev=514644 http://svn.apache.org/viewvc?view=revrev=514644 http://svn.apache.org/viewvc?view=revrev=514647 http://svn.apache.org/viewvc?view=revrev=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-855) Object class objectClass is called ObjectClass in search results
[ 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.
[jira] Commented: (DIRSERVER-855) Object class objectClass is called ObjectClass in search results
[ 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=revrev=515053 http://svn.apache.org/viewvc?view=revrev=515055 http://svn.apache.org/viewvc?view=revrev=515056 http://svn.apache.org/viewvc?view=revrev=515057 http://svn.apache.org/viewvc?view=revrev=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-858) Allow subclassing LdapDN
[
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
[ 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.
Re: [SASL] SASL plan
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: (DIRSERVER-855) Object class objectClass is called ObjectClass in search results
[ 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.
[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
[ 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=revrev=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] Closed: (DIRSTUDIO-1) DSML Parser does not throw an exception when it doesn't find a requestID attribute when processing=parallel and responseOrder=unordered
[ 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.
Re: [SASL] SASL plan
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: (DIRSERVER-855) Object class objectClass is called ObjectClass in search results
[ 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.
[jira] Created: (DIRSERVER-866) Initialization with another backend than JDBM for the system partition
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.
Re: [Kerberos] Kerberos + OpenLDAP
--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. http://www3.ietf.org/proceedings/05nov/krb-wg.html 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] Commented: (DIRSERVER-865) errors when importing ACI from LDIF file containing tabs
[
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: [SASL] SASL plan
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
Re: [SASL] SASL plan
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
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
