Bugs item #1579778, was opened at 2006-10-18 15:23
Message generated for change (Comment added) made by paulz_sci
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=480577&aid=1579778&group_id=55394
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Paul Zuefeldt (paulz_sci)
Assigned to: Nobody/Anonymous (nobody)
Summary: Can't modify with userCertificate
Initial Comment:
Modification of an entry fails if a userCertificate
attribute is involved in the operation, e.g. in
objectClass=pkiUser.
This is true if I try to add the certificate to the
entry or if I just try to modify a different
attribute in an entry that had the userCertificate
attribute populated with LDIF.
Once populated using LDIF, JXplorer can read the
userCertificate and display its contents correctly.
JXplorer can even save it to file from the entry and
load it back. But when you click Submit to perform
the modify you get this:
Unable to perform Modify operation
detail:
javax.naming.directory.InvalidAttributeIdentifierExcep
tion: [LDAP: error code 17 - userCertificate:
requires ;binary transfer]; remaining
name 'cn=pkiUser,dc=my-domain,dc=com'
at com.sun.jndi.ldap.LdapCtx.mapErrorCode
(LdapCtx.java:3054)
at com.sun.jndi.ldap.LdapCtx.processReturnCode
(LdapCtx.java:2931)
at com.sun.jndi.ldap.LdapCtx.processReturnCode
(LdapCtx.java:2737)
at
com.sun.jndi.ldap.LdapCtx.c_modifyAttributes
(LdapCtx.java:1437)
at
com.sun.jndi.toolkit.ctx.ComponentDirContext.p_modifyA
ttributes(ComponentDirContext.java:255)
at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.mo
difyAttributes(PartialCompositeDirContext.java:172)
at
javax.naming.directory.InitialDirContext.modifyAttribu
tes(InitialDirContext.java:153)
at
com.ca.commons.jndi.JNDIOps.modifyAttributes
(JNDIOps.java:714)
at
com.ca.directory.jxplorer.broker.CBGraphicsOps.modifyA
ttributes(CBGraphicsOps.java:98)
at com.ca.commons.naming.DXOps.updateEntry
(DXOps.java:634)
at com.ca.commons.naming.DXOps.modifyEntry
(DXOps.java:368)
at
com.ca.directory.jxplorer.broker.JNDIBroker.unthreaded
Modify(JNDIBroker.java:972)
at
com.ca.directory.jxplorer.broker.Broker.doModifyQuery
(Broker.java:425)
at
com.ca.directory.jxplorer.broker.Broker.processRequest
(Broker.java:206)
at
com.ca.directory.jxplorer.broker.JNDIBroker.processReq
uest(JNDIBroker.java:362)
at
com.ca.directory.jxplorer.broker.Broker.processQueue
(Broker.java:158)
at
com.ca.directory.jxplorer.broker.JNDIBroker.processQue
ue(JNDIBroker.java:829)
at com.ca.directory.jxplorer.broker.Broker.run
(Broker.java:124)
at java.lang.Thread.run(Thread.java:595)
----------------------------------------------------------------------
>Comment By: Paul Zuefeldt (paulz_sci)
Date: 2006-10-23 21:26
Message:
Logged In: YES
user_id=1623969
Just a follow-up:
There is a new set of LDAP RFC's that pretty much say the ;binary option is
required
for certificates: RFC 4522 section 4, and RFC 4523 section 2.1.
But RFCs aside, I noticed that JXplorer has different behavior -- besides the
obvious --
depending on the setting of the config option you pointed me to. With
sendVerboseBinary=true, Submit seems to be intelligent and only attempt to
update what
has been changed in the entry. But when set false (the default setting), Submit
appears
to try to delete and then replace my certificate when I was attempting to
change a
different attribute. This is part of what was causing the problem.
I pasted a little snippet of a trace demonstrating this. In this example I was
changing
ipHostNumber -- you can see where JXplorer tries to replace it -- but the
modify
operation fails because it also attempts to swap out the cert, and runs into
the
original ;binary issue.
1f 0a 01 01 30 1a 04 16 75 73 65 72 43 65 72 74 ....0...userCert
69 66 69 63 61 74 65 3b 62 69 6e 61 72 79 31 00 ificate;binary1.
30 22 0a 01 02 30 1d 04 0c 69 70 48 6f 73 74 4e 0"...0...ipHostN
75 6d 62 65 72 31 0d 04 0b 31 30 2e 32 30 2e 33 umber1...10.20.3
30 2e 34 30 30 82 04 1c 0a 01 02 30 82 04 15 04 0.400\202.....0\202...
0f 75 73 65 72 43 65 72 74 69 66 69 63 61 74 65 .userCertificate
Setting the option true seems to make everything work for me, but I thought you
might
be interested in this.
Thanks again for the tip.
----------------------------------------------------------------------
Comment By: Paul Zuefeldt (paulz_sci)
Date: 2006-10-23 18:39
Message:
Logged In: YES
user_id=1623969
Just a follow-up:
There is a new set of LDAP RFC's that pretty much say the ;binary option is
required
for certificates: RFC 4522 section 4, and RFC 4523 section 2.1.
But RFCs aside, I noticed that JXplorer has different behavior -- besides the
obvious --
depending on the setting of the config option you pointed me to. With
sendVerboseBinary=true, Submit seems to be intelligent and only attempt to
update what
has been changed in the entry. But when set false (the default setting), Submit
appears
to try to delete and then replace my certificate when I was attempting to
change a
different attribute. This is part of what was causing the problem.
I pasted a little snippet of a trace demonstrating this. In this example I was
changing
ipHostNumber -- you can see where JXplorer tries to replace it -- but the
modify
operation fails because it also attempts to swap out the cert, and runs into
the
original ;binary issue.
1f 0a 01 01 30 1a 04 16 75 73 65 72 43 65 72 74 ....0...userCert
69 66 69 63 61 74 65 3b 62 69 6e 61 72 79 31 00 ificate;binary1.
30 22 0a 01 02 30 1d 04 0c 69 70 48 6f 73 74 4e 0"...0...ipHostN
75 6d 62 65 72 31 0d 04 0b 31 30 2e 32 30 2e 33 umber1...10.20.3
30 2e 34 30 30 82 04 1c 0a 01 02 30 82 04 15 04 0.400\202.....0\202...
0f 75 73 65 72 43 65 72 74 69 66 69 63 61 74 65 .userCertificate
Setting the option true seems to make everything work for me, but I thought you
might
be interested in this.
Thanks again for the tip.
----------------------------------------------------------------------
Comment By: Christopher Betts (pegacat)
Date: 2006-10-19 11:17
Message:
Logged In: YES
user_id=558207
Nope - check RFC 2251 sec 4.1.5.1 - ";binary" is a client
side *option* for when the server can't be trusted to
respect the RFC 2252 sec 4.3.1 schema definitions.
A bunch of server's don't handle this aspect of schema
correctly, hence the configuration option :-). But in
theory they should figure out from schema that they're
transferring a binary attribute and transfer it accordingly.
*shrug*. If we always used the ";binary" option we'd just
get another group of folks mad at us - hence we have to make
it a config option :-).
----------------------------------------------------------------------
Comment By: Paul Zuefeldt (paulz_sci)
Date: 2006-10-18 21:38
Message:
Logged In: YES
user_id=1623969
Yes, thank you. The config option does seem to get things
rolling. But I'm not sure I would classify it as a server
problem. I believe the ;binary requirement comes from the
RFCs.
----------------------------------------------------------------------
Comment By: Christopher Betts (pegacat)
Date: 2006-10-18 20:00
Message:
Logged In: YES
user_id=558207
This looks like a server problem - the error you are getting
is from the server where it is saying that it needs the
certificate to be sent with a ";binary" extension on the
attribute name.
You may be able to change this at the server end, or you can
set an option to 'use explicit ;binary' in the jxplorer config.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=480577&aid=1579778&group_id=55394
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Jxplorer-devel mailing list
Jxplorer-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jxplorer-devel
