[jira] [Updated] (DIRSERVER-2202) pwdHistory not getting maintained when doing modify password with ldaptive client
[
https://issues.apache.org/jira/browse/DIRSERVER-2202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny updated DIRSERVER-2202:
-
Component/s: ppolicy
> pwdHistory not getting maintained when doing modify password with ldaptive
> client
> -
>
> Key: DIRSERVER-2202
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2202
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: ppolicy
>Affects Versions: 2.0.0-M23
> Environment: windows, ldaptive latest, java 8
>Reporter: Hal Deadman
>Priority: Major
>
> If I connect as a non admin user and modify my own password with directory
> studio, a new pwdHistory is added.
> If I modify the password programatically, using the old/new password
> modifyPassword extended operation that should respect history, it is deleting
> all my history (and leaving a single pwdHistory entry). The code looks like
> this:
> {noformat}
> // connecting as user that is trying to change their password
> org.ldaptive.Credential cred = new
> org.ldaptive.Credential(oldPassword);
> org.ldaptive.BindConnectionInitializer bindConnectionInit = new
> org.ldaptive.BindConnectionInitializer(userDn,cred);
> org.ldaptive.ConnectionConfig connectionConfig = new
> org.ldaptive.ConnectionConfig(ldapUrl);
> connectionConfig.setUseStartTLS(false);
> connectionConfig.setConnectionInitializer(bindConnectionInit);
> DefaultConnectionFactory userLdapConnectionFactory = new
> DefaultConnectionFactory(connectionConfig);
> try (Connection conn =
> userLdapConnectionFactory.getConnection()) {
> conn.open();
> PasswordModifyOperation modify = new
> PasswordModifyOperation(conn);
> Response response = modify.execute(new
> PasswordModifyRequest(userDn, new Credential(oldPassword), new
> Credential(plaintextPassword)));
> }
> {noformat}
> Isn't the pwdHistory being maintained by the server? Why does a different
> client determine whether pwdHistory entries are added or not? (In this case
> they are not only not added but multiple entries are replaced by a single
> one).
> Ldaptive doesn't implement ldap protocol, in this case it is using JNDI as
> the provider of ldap protocol.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSERVER-2107) ApacheDS 2.0.0M20 in production, getting ERR_554 double get for block 27
[ https://issues.apache.org/jira/browse/DIRSERVER-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRSERVER-2107: - Component/s: jdbm > ApacheDS 2.0.0M20 in production, getting ERR_554 double get for block 27 > > > Key: DIRSERVER-2107 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2107 > Project: Directory ApacheDS > Issue Type: Bug > Components: jdbm >Affects Versions: 2.0.0-M20 > Environment: Server 2008 R2 >Reporter: Tyler Neemann >Priority: Major > > In our production environment, ApacheDS was restarted. After about a minute > after restart received error in the log. During this time, no operations > could be performed. This is the third time I have seen this issue. I attached > the debug output as a file. I did replace some of the confidential info with > xxx in the log The errors we received were: > java.lang.ArrayIndexOutOfBoundsException: -23422 > and > Exception in thread "pool-4-thread-1" java.lang.Error: ERR_554 double get for > block 27,851 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSERVER-2059) Kerberos Password Change Server Failure
[
https://issues.apache.org/jira/browse/DIRSERVER-2059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny updated DIRSERVER-2059:
-
Component/s: kerberos
> Kerberos Password Change Server Failure
> ---
>
> Key: DIRSERVER-2059
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2059
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: kerberos
>Affects Versions: 2.0.0-M19
> Environment: Linux
>Reporter: Craig McLure
>Priority: Major
>
> I've been trying to get kpasswd to correctly change a users password, but it
> always failed, after doing some digging and debugging, I discovered the
> following:
> *org.apache.directory.server.kerberos.ChangePasswordConfig*
> Primary realm is never set, resulting in inheritance of default EXAMPLE.COM
> realm regardless of the realm configured. Adding:
> {{this.setPrimaryRealm( kdcConfig.getPrimaryRealm() );}}
> into the constructor resolved this.
> *org.apache.directory.server.kerberos.changepwd.service.ChangePasswordService*
> in {{extractPassword}} there's the following check:
> {{if( authenticator.getSeqNumber() != privatePart.getSeqNumber() )}}
> However, the Authenticator's Sequence Number is never set, resulting in this
> throwing a NullPointerException. Commenting out the check, admittedly unwise,
> allows the code to proceed normally.
> With both these changes, password changing via kpasswd is possible again.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSERVER-2179) Password hashing interceptor - password history entries are not hashed
[ https://issues.apache.org/jira/browse/DIRSERVER-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRSERVER-2179: - Component/s: hash interceptor > Password hashing interceptor - password history entries are not hashed > -- > > Key: DIRSERVER-2179 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2179 > Project: Directory ApacheDS > Issue Type: Bug > Components: hash interceptor, ppolicy >Reporter: Dmitry Smeliansky >Priority: Major > > Hi. > In order to use the server-side password policy validation - we have to pass > the passwords as plaintext and not hashed by the client. > Password hashing interceptor hashes the passwords according to the > configuration, BUT - the new added pwdHistory entry will contain the > plaintext value of the password. > Is there any way to have the password policy validation on the server and the > hashed password to be saved in the history at the same time? > Thanks -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSERVER-2069) Failed to change password if realm is not EXAMPLE.COM
[
https://issues.apache.org/jira/browse/DIRSERVER-2069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny updated DIRSERVER-2069:
-
Component/s: kerberos
> Failed to change password if realm is not EXAMPLE.COM
> -
>
> Key: DIRSERVER-2069
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2069
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: kerberos
>Reporter: Alexander Bersenev
>Priority: Major
> Attachments: realm.patch
>
>
> From
> verifyServiceTicket(protocol-kerberos/src/main/java/org/apache/directory/server/kerberos/changepwd/service/ChangePasswordService.java):
> ChangePasswordConfig config = changepwContext.getConfig();
> ...
> String primaryRealm = config.getPrimaryRealm();
> ...
> if ( !ticket.getRealm().equals( primaryRealm ) ||
> !serverPrincipal.getName().equals( changepwPrincipal.getName() ) )
> {
> throw new KerberosException(
> org.apache.directory.shared.kerberos.exceptions.ErrorType.KRB_AP_ERR_NOT_US );
> }
> The primary realm is always EXAMPLE.COM because an initialization of
> primaryRealm in ChangePasswordConfig was forgot.
> Attached one-string patch fixes it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSERVER-2051) Getting Password Expired Instead of Invalid Credentials
[ https://issues.apache.org/jira/browse/DIRSERVER-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRSERVER-2051: - Component/s: authn > Getting Password Expired Instead of Invalid Credentials > --- > > Key: DIRSERVER-2051 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2051 > Project: Directory ApacheDS > Issue Type: Bug > Components: authn >Reporter: David Paulsen >Priority: Major > Attachments: TMSInstance.zip > > > When I log in with invalid credentials AND the password is expired, I > would expect to get the invalid credentials error: > LDAPException: Invalid Credentials (49) Invalid Credentials > LDAPException: Server Message: INVALID_CREDENTIALS: Bind failed: ERR_229 > Cannot authenticate user > uid=admin,ou=DJPS1,ou=DVHead,dc=kewilltransport,dc=com > Instead I get the password expired error: > LDAPException: Invalid Credentials (49) Invalid Credentials > LDAPException: Server Message: INVALID_CREDENTIALS: Bind failed: paasword > expired > I would think we should get the invalid credentials error in that case. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSERVER-2088) Add the ability to specify additional fields that should be hashed by the hashing interceptors
[
https://issues.apache.org/jira/browse/DIRSERVER-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny updated DIRSERVER-2088:
-
Component/s: hash interceptor
> Add the ability to specify additional fields that should be hashed by the
> hashing interceptors
> --
>
> Key: DIRSERVER-2088
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2088
> Project: Directory ApacheDS
> Issue Type: Improvement
> Components: hash interceptor
>Reporter: lucas theisen
>Priority: Major
> Attachments: oid_map.json, oid_map.pl
>
>
> This
> [discussion|http://mail-archives.apache.org/mod_mbox/directory-dev/201507.mbox/%3cbn1pr09mb019635837eb5b0c564a0e955cd...@bn1pr09mb0196.namprd09.prod.outlook.com%3E]
> went over the topic. Per the suggestion from [~akiran], this should be done
> with some new attributes:
> {quote}
> what I would do is to add support for configuring one or more attributes in
> this interceptor
> something like, 'ads-hashAttibute' a multi valued attributes
> {quote}
> Per [~elecharny], a new {{objectClass}} should be created:
> {quote}
> The idea is to add some configuration in the HashInterceptor
> configuration. You can create a new ObjectClass for that and add some
> new AttributeType to store the OID to be hashed.
> {quote}
> And given that we will create a new {{objectClass}} with its own
> configuration attribute for {{ads-hashAttribute}} it is also reasonable to
> add {{ads-hashAlgorithm}}. With this, _ALL_ of the individual classes could
> be implemented as one simple {{HashingInterceptor}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSERVER-1927) pwdmaxfailure seems not be be respected correctly
[ https://issues.apache.org/jira/browse/DIRSERVER-1927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRSERVER-1927: - Component/s: ppolicy > pwdmaxfailure seems not be be respected correctly > - > > Key: DIRSERVER-1927 > URL: https://issues.apache.org/jira/browse/DIRSERVER-1927 > Project: Directory ApacheDS > Issue Type: Bug > Components: ppolicy > Environment: Ubuntu 12.04 64bit Server, apacheds-2.0.0-M12-default >Reporter: Stephan Becker >Priority: Major > > Goal: > is to lock an account but not allow automatic account locking by failed > attempts. > Supposed working method: > using -1 or 0 as a value or deleting the ads-pwdmaxfailure attribute to not > allow automatic account locking > Result: > using the above methods locks the account anyways > Workaround: > using the max value of works BUT using this value might cause an > issue f.e. with a technical user experiencing a connection loss or some other > issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSERVER-2094) Cleanup code duplication in tests
[
https://issues.apache.org/jira/browse/DIRSERVER-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny updated DIRSERVER-2094:
-
Component/s: test
code quality
> Cleanup code duplication in tests
> -
>
> Key: DIRSERVER-2094
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2094
> Project: Directory ApacheDS
> Issue Type: Task
> Components: code quality, test
>Reporter: Stefan Seelmann
>Priority: Major
>
> In tests there is endless duplication of setting up a JNDI LDAP connection,
> for example:
> {code}
> Hashtable env = new Hashtable();
> env.put( Context.INITIAL_CONTEXT_FACTORY,
> "com.sun.jndi.ldap.LdapCtxFactory" );
> env.put( Context.PROVIDER_URL, "ldap://; +
> InetAddress.getLocalHost().getHostName() + ":"
> + getLdapServer().getPort() );
> env.put( Context.SECURITY_AUTHENTICATION, "simple" );
> env.put( Context.SECURITY_PRINCIPAL,
> "uid=hnelson,ou=users,dc=example,dc=com" );
> env.put( Context.SECURITY_CREDENTIALS, "secret" );
> env.put( "java.naming.ldap.attributes.binary", "krb5key" );
> {code}
> That should (TM) be clean up.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSERVER-1675) ACI example allowSelfAccessAndModification not functional in 2.0.0
[ https://issues.apache.org/jira/browse/DIRSERVER-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRSERVER-1675: - Component/s: aci > ACI example allowSelfAccessAndModification not functional in 2.0.0 > -- > > Key: DIRSERVER-1675 > URL: https://issues.apache.org/jira/browse/DIRSERVER-1675 > Project: Directory ApacheDS > Issue Type: Bug > Components: aci >Affects Versions: 2.0.0-M3 > Environment: Linux k5dsi.kypride.com 2.6.32-318-ec2 #38-Ubuntu SMP > Thu Sep 1 18:09:30 UTC 2011 x86_64 GNU/Linux > openjdk-6-jre-headless 6b20-1.9.9 >Reporter: Aaron J Angel >Priority: Major > > The example listed at > http://directory.apache.org/apacheds/1.5/allowselfpasswordmodify.html does > not work. Attempts to modify the password with this example fails with an > insufficient access message. The only way I have been able to successfully > change a password when binding as the entry is if all permissions are given > on all user attributes (just giving permission on userPassword alone fails). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSERVER-2099) NOTICE and LICENSE files for DS 2.0.0-M20 are incorrect
[ https://issues.apache.org/jira/browse/DIRSERVER-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRSERVER-2099: - Priority: Critical (was: Major) > NOTICE and LICENSE files for DS 2.0.0-M20 are incorrect > --- > > Key: DIRSERVER-2099 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2099 > Project: Directory ApacheDS > Issue Type: Bug >Affects Versions: 2.0.0-M20 >Reporter: Sebb >Priority: Critical > Fix For: 2.0.0.AM26 > > > NOTICE files are for *required* notices only; they must not contain anything > that is not required. > LICENSE files must contain the text of all applicable licences, or pointers > to the license (which must be included in the distribution). > See the process described here [1] > I think that there are problems with both of these files. > The NOTICE file contains a lot of extraneous text. > The block enclosed in === should be removed entirely, as well as the > following paragraph, which is an unnecessary duplicate. > AFAICT the references to SafeHaus JUG and Clinton Begin don't need to be in > the NOTICE file either. > The LICENSE file says that JUG is licensed under AL v2. > However it does not say which version of JUG is included. > Similarly for the other 3rd party licences. > The NOTICE file mentions software by Clinton Begin, but there is no > corresponding mention in the LICENSE file. > All bundled software must be documented in the LICENSE file. > Entries in the NOTICE file must only be made if required. > [1] http://www.apache.org/dev/licensing-howto.html -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSERVER-2099) NOTICE and LICENSE files for DS 2.0.0-M20 are incorrect
[ https://issues.apache.org/jira/browse/DIRSERVER-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRSERVER-2099: - Fix Version/s: 2.0.0.AM26 > NOTICE and LICENSE files for DS 2.0.0-M20 are incorrect > --- > > Key: DIRSERVER-2099 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2099 > Project: Directory ApacheDS > Issue Type: Bug >Affects Versions: 2.0.0-M20 >Reporter: Sebb >Priority: Major > Fix For: 2.0.0.AM26 > > > NOTICE files are for *required* notices only; they must not contain anything > that is not required. > LICENSE files must contain the text of all applicable licences, or pointers > to the license (which must be included in the distribution). > See the process described here [1] > I think that there are problems with both of these files. > The NOTICE file contains a lot of extraneous text. > The block enclosed in === should be removed entirely, as well as the > following paragraph, which is an unnecessary duplicate. > AFAICT the references to SafeHaus JUG and Clinton Begin don't need to be in > the NOTICE file either. > The LICENSE file says that JUG is licensed under AL v2. > However it does not say which version of JUG is included. > Similarly for the other 3rd party licences. > The NOTICE file mentions software by Clinton Begin, but there is no > corresponding mention in the LICENSE file. > All bundled software must be documented in the LICENSE file. > Entries in the NOTICE file must only be made if required. > [1] http://www.apache.org/dev/licensing-howto.html -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSERVER-2098) Replication NullPointer at SyncReplRequestHandler.java:648
[
https://issues.apache.org/jira/browse/DIRSERVER-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny updated DIRSERVER-2098:
-
Component/s: replication
> Replication NullPointer at SyncReplRequestHandler.java:648
> --
>
> Key: DIRSERVER-2098
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2098
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: replication
>Affects Versions: 2.0.0-M19
>Reporter: Emanuele Forlano
>Priority: Major
>
> Hi
> we have some problems with SyncRepl. Following Apache documentation we set up
> two instances of embedded ApacheDs M19.
> In the provider we have:
> val replRequestHandler = new SyncReplRequestHandler()
> server.setReplicationReqHandler(replRequestHandler)
> in the consumer:
> val replicationConf = new SyncReplConfiguration
> replicationConf.setRemoteHost("localhost")
> replicationConf.setRemotePort(1389)
> replicationConf.setUseTls(false)
> replicationConf.setReplUserDn("uid=admin,ou=system")
> replicationConf.setReplUserPassword("secret".getBytes)
> replicationConf.setBaseDn(“o=myDn”) //replaced
> replicationConf.setFilter("(objectClass=*)")
> replicationConf.setRefreshInterval(6)
> replicationConf.setRefreshNPersist(true)
> replicationConf.setAliasDerefMode(AliasDerefMode.NEVER_DEREF_ALIASES)
> val consumer: ReplicationConsumer = new ReplicationConsumerImpl()
> consumer.setConfig(replicationConf)
> server.setReplConsumers(ApacheDSUtils.buildConsumers(consumer))
> When we run both the server we get this error:
> org.apache.directory.api.ldap.model.exception.LdapException:
> java.lang.RuntimeException: java.lang.NullPointerException
> at
> org.apache.directory.server.core.shared.DefaultCoreSession.search(DefaultCoreSession.java:1157)
> ~[apacheds-all-2.0.0-M19.jar:2.0.0-M19]
> at
> org.apache.directory.server.ldap.replication.provider.SyncReplRequestHandler.doSimpleSearch(SyncReplRequestHandler.java:648)
> ~[apacheds-all-2.0.0-M19.jar:2.0.0-M19]
> at
> org.apache.directory.server.ldap.replication.provider.SyncReplRequestHandler.doInitialRefresh(SyncReplRequestHandler.java:562)
> ~[apacheds-all-2.0.0-M19.jar:2.0.0-M19]
> at
> org.apache.directory.server.ldap.replication.provider.SyncReplRequestHandler.handleSyncRequest(SyncReplRequestHandler.java:311)
> ~[apacheds-all-2.0.0-M19.jar:2.0.0-M19]
> at
> org.apache.directory.server.ldap.handlers.request.SearchRequestHandler.handleReplication(SearchRequestHandler.java:240)
> [apacheds-all-2.0.0-M19.jar:2.0.0-M19]
> Note: when I use a more specific filter for example: cn=someCn it works fine.
> Any idea?
> Thanks
> ps: sorry not sure where to open this issue and I also opened DIR-319
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSERVER-2099) NOTICE and LICENSE files for DS 2.0.0-M20 are incorrect
[ https://issues.apache.org/jira/browse/DIRSERVER-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRSERVER-2099: - Affects Version/s: 2.0.0-M20 > NOTICE and LICENSE files for DS 2.0.0-M20 are incorrect > --- > > Key: DIRSERVER-2099 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2099 > Project: Directory ApacheDS > Issue Type: Bug >Affects Versions: 2.0.0-M20 >Reporter: Sebb >Priority: Major > > NOTICE files are for *required* notices only; they must not contain anything > that is not required. > LICENSE files must contain the text of all applicable licences, or pointers > to the license (which must be included in the distribution). > See the process described here [1] > I think that there are problems with both of these files. > The NOTICE file contains a lot of extraneous text. > The block enclosed in === should be removed entirely, as well as the > following paragraph, which is an unnecessary duplicate. > AFAICT the references to SafeHaus JUG and Clinton Begin don't need to be in > the NOTICE file either. > The LICENSE file says that JUG is licensed under AL v2. > However it does not say which version of JUG is included. > Similarly for the other 3rd party licences. > The NOTICE file mentions software by Clinton Begin, but there is no > corresponding mention in the LICENSE file. > All bundled software must be documented in the LICENSE file. > Entries in the NOTICE file must only be made if required. > [1] http://www.apache.org/dev/licensing-howto.html -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSERVER-2099) NOTICE and LICENSE files for DS 2.0.0-M20 are incorrect
[ https://issues.apache.org/jira/browse/DIRSERVER-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRSERVER-2099: - Component/s: legal > NOTICE and LICENSE files for DS 2.0.0-M20 are incorrect > --- > > Key: DIRSERVER-2099 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2099 > Project: Directory ApacheDS > Issue Type: Bug > Components: legal >Affects Versions: 2.0.0-M20 >Reporter: Sebb >Priority: Critical > Fix For: 2.0.0.AM26 > > > NOTICE files are for *required* notices only; they must not contain anything > that is not required. > LICENSE files must contain the text of all applicable licences, or pointers > to the license (which must be included in the distribution). > See the process described here [1] > I think that there are problems with both of these files. > The NOTICE file contains a lot of extraneous text. > The block enclosed in === should be removed entirely, as well as the > following paragraph, which is an unnecessary duplicate. > AFAICT the references to SafeHaus JUG and Clinton Begin don't need to be in > the NOTICE file either. > The LICENSE file says that JUG is licensed under AL v2. > However it does not say which version of JUG is included. > Similarly for the other 3rd party licences. > The NOTICE file mentions software by Clinton Begin, but there is no > corresponding mention in the LICENSE file. > All bundled software must be documented in the LICENSE file. > Entries in the NOTICE file must only be made if required. > [1] http://www.apache.org/dev/licensing-howto.html -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSERVER-2150) Deploy and start apacheds-osgi in karaf
[ https://issues.apache.org/jira/browse/DIRSERVER-2150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRSERVER-2150: - Component/s: osgi > Deploy and start apacheds-osgi in karaf > --- > > Key: DIRSERVER-2150 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2150 > Project: Directory ApacheDS > Issue Type: Improvement > Components: osgi >Affects Versions: 2.0.0-M22 > Environment: Linux, Java7, Karaf 4.0.4 >Reporter: Ciprian Ciubotariu >Priority: Major > Labels: osgi > Attachments: directory-server-osgi.patch, directory-shared-osgi.patch > > > I want to automate some karaf integration tests that rely on a LDAP server, > and for that purpose I thought I could use apacheds running in karaf. I found > the apacheds-osgi module and brought it to a point where one can start a LDAP > server in karaf using aries blueprints and some support code (unfortunately > duplicated with minor changes) from apacheds-service and > apacheds-service-builder. > I will attach patches for SVN to the issue, but one can review the changes on > github for > [directory-shared|https://github.com/apache/directory-shared/compare/trunk...CMoH:osgi] > and > [directory-server|https://github.com/apache/directory-server/compare/trunk...CMoH:osgi] > Thank -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSERVER-2223) JDK 9 ldaps does not work
[
https://issues.apache.org/jira/browse/DIRSERVER-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny updated DIRSERVER-2223:
-
Component/s: code quality
> JDK 9 ldaps does not work
> -
>
> Key: DIRSERVER-2223
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2223
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: code quality
>Affects Versions: 2.0.0-M24
>Reporter: Martin Choma
>Priority: Major
>
> I have migrated from JDK 8 to JDK 9. I started to get {noformat}no cipher
> suites in common{noformat}.
> I am using org.apache.directory.api as a client connecting to ApacheDS
> ldaps://localhost:10636 url.
> I get
> {code}
> *** ClientHello, TLSv1.2
> RandomCookie: random_bytes = {FD 5B C5 87 7A 4B 58 AC BB BB 1D 62 6C BB DF
> CC 12 8F F3 3D 0B 57 EA B5 AC AA 7C E0 94 C6 98 EE}
> Session ID: {}
> Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_GCM_SHA384,
> TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,
> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_DSS_WITH_AES_256_GCM_SHA384,
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,
> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256,
> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA256,
> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,
> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,
> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
> TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,
> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
> TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256,
> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,
> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
> TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,
> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
> TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,
> TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA,
> TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,
> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA,
> TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
> Compression Methods: { 0 }
> Extension elliptic_curves, curve names: {secp256r1, secp384r1, secp521r1,
> sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, secp256k1}
> Extension ec_point_formats, formats: [uncompressed]
> Extension signature_algorithms, signature_algorithms: SHA512withECDSA,
> SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA,
> SHA256withRSA, SHA256withDSA, SHA224withECDSA, SHA224withRSA, SHA224withDSA,
> SHA1withECDSA, SHA1withRSA, SHA1withDSA
> Extension status_request_v2
> CertStatusReqItemV2: ocsp_multi, OCSPStatusRequest
> ResponderIds:
> Extensions:
> CertStatusReqItemV2: ocsp, OCSPStatusRequest
> ResponderIds:
> Extensions:
> Extension status_request: ocsp, OCSPStatusRequest
> ResponderIds:
> Extensions:
> ***
> %% Initialized: [Session-4, SSL_NULL_WITH_NULL_NULL]
> NioProcessor-6, fatal error: 40: no cipher suites in common
> javax.net.ssl.SSLHandshakeException: no cipher suites in common
> %% Invalidated: [Session-4, SSL_NULL_WITH_NULL_NULL]
> NioProcessor-6, fatal: engine already closed. Rethrowing
> javax.net.ssl.SSLHandshakeException: no cipher suites in common
> 10:48:16,382 WARN [org.apache.directory.server.ldap.LdapProtocolHandler]
> (NioProcessor-6) Unexpected exception forcing session to close: sending
> disconnect notice to client.: javax.net.ssl.SSLHandshakeException: SSL
> handshake failed.
> at
> org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:519)
> {code}
> Once I specify on client side
> {code}
> tlsConfig.setEnabledCipherSuites(new String[] {
> "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384",
> "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384",
> "TLS_RSA_WITH_AES_256_CBC_SHA256",
> "TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384",
> "TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384",
> "TLS_DHE_RSA_WITH_AES_256_CBC_SHA256",
> "TLS_DHE_DSS_WITH_AES_256_CBC_SHA256",
> "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA",
>
[jira] [Commented] (DIRSERVER-2223) JDK 9 ldaps does not work
[
https://issues.apache.org/jira/browse/DIRSERVER-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16874536#comment-16874536
]
Emmanuel Lecharny commented on DIRSERVER-2223:
--
Should we assume this issue has been fixed, since we know that ApacheDS builds
properly with java 11 and 12 ?
> JDK 9 ldaps does not work
> -
>
> Key: DIRSERVER-2223
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2223
> Project: Directory ApacheDS
> Issue Type: Bug
>Affects Versions: 2.0.0-M24
>Reporter: Martin Choma
>Priority: Major
>
> I have migrated from JDK 8 to JDK 9. I started to get {noformat}no cipher
> suites in common{noformat}.
> I am using org.apache.directory.api as a client connecting to ApacheDS
> ldaps://localhost:10636 url.
> I get
> {code}
> *** ClientHello, TLSv1.2
> RandomCookie: random_bytes = {FD 5B C5 87 7A 4B 58 AC BB BB 1D 62 6C BB DF
> CC 12 8F F3 3D 0B 57 EA B5 AC AA 7C E0 94 C6 98 EE}
> Session ID: {}
> Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_GCM_SHA384,
> TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,
> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_DSS_WITH_AES_256_GCM_SHA384,
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,
> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256,
> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA256,
> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,
> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,
> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
> TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,
> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
> TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256,
> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,
> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
> TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,
> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
> TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,
> TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA,
> TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,
> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA,
> TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
> Compression Methods: { 0 }
> Extension elliptic_curves, curve names: {secp256r1, secp384r1, secp521r1,
> sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, secp256k1}
> Extension ec_point_formats, formats: [uncompressed]
> Extension signature_algorithms, signature_algorithms: SHA512withECDSA,
> SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA,
> SHA256withRSA, SHA256withDSA, SHA224withECDSA, SHA224withRSA, SHA224withDSA,
> SHA1withECDSA, SHA1withRSA, SHA1withDSA
> Extension status_request_v2
> CertStatusReqItemV2: ocsp_multi, OCSPStatusRequest
> ResponderIds:
> Extensions:
> CertStatusReqItemV2: ocsp, OCSPStatusRequest
> ResponderIds:
> Extensions:
> Extension status_request: ocsp, OCSPStatusRequest
> ResponderIds:
> Extensions:
> ***
> %% Initialized: [Session-4, SSL_NULL_WITH_NULL_NULL]
> NioProcessor-6, fatal error: 40: no cipher suites in common
> javax.net.ssl.SSLHandshakeException: no cipher suites in common
> %% Invalidated: [Session-4, SSL_NULL_WITH_NULL_NULL]
> NioProcessor-6, fatal: engine already closed. Rethrowing
> javax.net.ssl.SSLHandshakeException: no cipher suites in common
> 10:48:16,382 WARN [org.apache.directory.server.ldap.LdapProtocolHandler]
> (NioProcessor-6) Unexpected exception forcing session to close: sending
> disconnect notice to client.: javax.net.ssl.SSLHandshakeException: SSL
> handshake failed.
> at
> org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:519)
> {code}
> Once I specify on client side
> {code}
> tlsConfig.setEnabledCipherSuites(new String[] {
> "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384",
> "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384",
> "TLS_RSA_WITH_AES_256_CBC_SHA256",
> "TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384",
> "TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384",
> "TLS_DHE_RSA_WITH_AES_256_CBC_SHA256",
>
[jira] [Updated] (DIRSERVER-1966) Delete of ACI generates NPE
[
https://issues.apache.org/jira/browse/DIRSERVER-1966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny updated DIRSERVER-1966:
-
Component/s: aci
> Delete of ACI generates NPE
> ---
>
> Key: DIRSERVER-1966
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1966
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: aci
>Affects Versions: 2.0.0-M16
> Environment: Studio 2.0.0.v20130628
>Reporter: Pierre Smits
>Priority: Major
>
> I have created two ACI for a partition.
> The first ACI has following content:
> dn: cn=orrtizACISubEntry,dc=orrtiz,dc=com
> objectClass: top
> objectClass: accessControlSubentry
> objectClass: subentry
> cn: orrtizACISubEntry
> prescriptiveACI: { identificationTag "directoryManagerFullAccessACI", preced
> ence 11, authenticationLevel simple, itemOrUserFirst userFirst: { userClass
> es { name { "cn=nl04748,ou=users,dc=orrtiz,dc=com" } }, userPermissions { {
> protectedItems { allUserAttributeTypesAndValues, entry }, grantsAndDenials
> { grantReturnDN, grantFilterMatch, grantBrowse, grantCompare, grantAdd, gr
> antInvoke, grantModify, grantImport, grantDiscloseOnError, grantRename, gra
> ntRemove, grantRead, grantExport } } } } }
> prescriptiveACI: { identificationTag "allUsersACI", precedence 10, authentic
> ationLevel none, itemOrUserFirst userFirst: { userClasses { allUsers }, use
> rPermissions { { protectedItems { allUserAttributeTypesAndValues, entry },
> grantsAndDenials { grantReturnDN, grantFilterMatch, grantBrowse, grantCompa
> re, grantDiscloseOnError, grantRead } }, { protectedItems { attributeType {
> userPassword } }, grantsAndDenials { denyRead, denyFilterMatch, denyCompar
> e } } } } }
> subtreeSpecification: { }
> accessControlSubentries: 2.5.4.3=orrtizacisubentry,0.9.2342.19200300.100.1.2
> 5=orrtiz,0.9.2342.19200300.100.1.25=com
> createTimestamp: 20140325202223.905Z
> creatorsName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
> entryCSN: 20140325202223.905000Z#00#001#00
> entryDN: cn=orrtizACISubEntry,dc=orrtiz,dc=com
> entryParentId: a22442b4-f41f-46bb-89d8-e567ed1a5800
> entryUUID:: ZWE0MTQxNTMtMzdjYS00NWU5LWE2ZTItODhkZTU2YTUzYzE2
> The second ACI has following content:
> dn: cn=orrtizAuthReqACISubEntry,dc=orrtiz,dc=com
> objectClass: top
> objectClass: accessControlSubentry
> objectClass: subentry
> cn: orrtizAuthReqACISubEntry
> prescriptiveACI: { identificationTag "directoryManagerFullAccessACI", preced
> ence 11, authenticationLevel simple, itemOrUserFirst userFirst: { userClass
> es { name { "cn=nl04748,ou=users,dc=orrtiz,dc=com" } }, userPermissions { {
> protectedItems { allUserAttributeTypesAndValues, entry }, grantsAndDenials
> { grantReturnDN, grantFilterMatch, grantBrowse, grantCompare, grantAdd, gr
> antInvoke, grantModify, grantImport, grantDiscloseOnError, grantRename, gra
> ntRemove, grantRead, grantExport } } } } }
> prescriptiveACI: { identificationTag "allUsersACI", precedence 10, authentic
> ationLevel none, itemOrUserFirst userFirst: { userClasses { allUsers }, use
> rPermissions { { protectedItems { allUserAttributeTypesAndValues, entry },
> grantsAndDenials { grantReturnDN, grantFilterMatch, grantBrowse, grantCompa
> re, grantDiscloseOnError, grantRead } }, { protectedItems { attributeType {
> userPassword } }, grantsAndDenials { denyRead, denyFilterMatch, denyCompar
> e } } } } }
> subtreeSpecification: { base "dc=orrtiz,dc=com" }
> accessControlSubentries: 2.5.4.3=orrtizacisubentry,0.9.2342.19200300.100.1.2
> 5=orrtiz,0.9.2342.19200300.100.1.25=com
> createTimestamp: 20140325182443.296Z
> creatorsName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
> entryCSN: 2014032529.087000Z#00#001#00
> entryDN: cn=orrtizAuthReqACISubEntry,dc=orrtiz,dc=com
> entryParentId: a22442b4-f41f-46bb-89d8-e567ed1a5800
> entryUUID:: MWViMTQxMDktNzEzOC00NzFkLTlmYzEtZTgyMTM1NzI1ZDU1
> modifiersName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
> modifyTimestamp: 2014032529.087Z
> The difference between the two is the subtreeSpecifications whereby the first
> is {}, and the second { base "dc=orrtiz,dc=com" }
> Deleting the first ACI generates no problem. Deleting the second ACI
> generates following error:
> #!RESULT ERROR
> #!CONNECTION ldap://director.somonar.prd:389
> #!DATE 2014-03-25T20:38:04.044
> #!ERROR [LDAP: error code 80 - OTHER: failed for MessageType : DEL_REQUEST
> Message ID : 23 Del request Entry :
> 'cn=orrtizAuthReqACISubEntry,dc=orrtiz,dc=com'
> org.apache.directory.api.ldap.model.message.DeleteRequestImpl@90241f8: null:
> java.lang.NullPointerException at
> org.apache.directory.server.core.subtree.SubentryInterceptor.delete(SubentryInterceptor.java:1043)
> at
>
[jira] [Updated] (DIRSERVER-2241) Is there any tools to monitor apacheds
[ https://issues.apache.org/jira/browse/DIRSERVER-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRSERVER-2241: - Component/s: tools > Is there any tools to monitor apacheds > -- > > Key: DIRSERVER-2241 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2241 > Project: Directory ApacheDS > Issue Type: Wish > Components: tools >Reporter: cokuehuang >Priority: Major > > Can anybody help me ?Is there any tools to monitor apacheds, like cpu, > current number of connection, aviliable number of connection, request time > and so on? Sometimes we found that some java process forget to close > connection of ldap, the server crash down when no connection can be > got.Thanks a lot! -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Resolved] (DIRSERVER-2146) Using special chars in uid makes problem
[ https://issues.apache.org/jira/browse/DIRSERVER-2146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny resolved DIRSERVER-2146. -- Resolution: Fixed Fix Version/s: 2.0.0.AM26 Fixed in the LDAP API. Test added in the server. > Using special chars in uid makes problem > > > Key: DIRSERVER-2146 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2146 > Project: Directory ApacheDS > Issue Type: Bug >Affects Versions: 2.0.0-M21 >Reporter: Martin Choma >Priority: Major > Fix For: 2.0.0.AM26 > > Attachments: LdapLoginModuleSpecialNamesTestCase.ldif > > > I am trying to upgrade from version 20 to 21 and hit problem, when creating > ldap items with special characters, ApacheDS fails. In version 20 the same > entries were created seamlessly. > 14:27:42,723 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) > Adding entry: > o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org > 14:27:42,756 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) > Adding entry: > ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org > 14:27:42,862 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) > Adding entry: > ou=Roles,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org > 14:27:42,977 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) > Adding entry: > uid=jduke,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org > 14:27:43,080 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) > Adding entry: uid=Sue\, Grabbit and > Runn,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org > 14:27:43,162 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) > Adding entry: > uid=Before\0DAfter,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org > 14:27:43,163 WARN > [org.apache.directory.server.core.normalization.NormalizationInterceptor] > (pool-7-thread-1) The Rdn 'uid=Before\0DAfter' is not present in the entry > 14:27:43,255 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main) > Adding entry: > uid=#4869,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org > 14:27:43,256 ERROR [org.apache.directory.api.ldap.model.entry.AbstractValue] > (pool-7-thread-1) The 'uid' AttributeType and values must both be String or > binary > 14:27:43,257 WARN [org.apache.directory.api.ldap.model.entry.DefaultEntry] > (pool-7-thread-1) The Dn > 'uid=#4869,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org' > cannot be normalized > 14:27:43,258 WARN > [org.apache.directory.server.core.normalization.NormalizationInterceptor] > (pool-7-thread-1) The Rdn 'uid=Hi' is not present in the entry > 14:27:43,258 WARN > [org.apache.directory.api.ldap.model.entry.DefaultAttribute] > (pool-7-thread-1) ERR_04486_VALUE_ALREADY_EXISTS The value 'Hi' already > exists in the attribute (uid) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRSERVER-2146) Using special chars in uid makes problem
[
https://issues.apache.org/jira/browse/DIRSERVER-2146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16874534#comment-16874534
]
Emmanuel Lecharny commented on DIRSERVER-2146:
--
Took some time to get this fixed !
It's related to issue
[DIRAPI-349|https://issues.apache.org/jira/browse/DIRAPI-349].
The following test has been added to demonstrate that the server now handle
such requests properly :
{code:java}
@Test
public void testAddUidWithDash() throws LdapException, IOException
{
connection.setTimeOut( 0L );
connection.loadSchema();
// Use the client API
connection.bind( "uid=admin,ou=system", "secret" );
// Add a new entry with some null values
Entry entry = new DefaultEntry(
getLdapServer().getDirectoryService().getSchemaManager(),
"uid=#4869,ou=system",
"objectclass: top",
"objectclass: person",
"objectclass: inetOrgPerson",
"uid: Hi",
"cn: Java Duke",
"sn: Duke",
"userpassword: Password1" );
connection.add( entry );
// Now fetch the entry
Entry found = connection.lookup( "uid=#4869,ou=system" );
assertNotNull( found );
assertNotNull( found.get( "userPassword" ) );
assertTrue( found.contains( "uid", "Hi" ) );
connection.close();
}
{code}
> Using special chars in uid makes problem
>
>
> Key: DIRSERVER-2146
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2146
> Project: Directory ApacheDS
> Issue Type: Bug
>Affects Versions: 2.0.0-M21
>Reporter: Martin Choma
>Priority: Major
> Attachments: LdapLoginModuleSpecialNamesTestCase.ldif
>
>
> I am trying to upgrade from version 20 to 21 and hit problem, when creating
> ldap items with special characters, ApacheDS fails. In version 20 the same
> entries were created seamlessly.
> 14:27:42,723 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main)
> Adding entry:
> o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:42,756 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main)
> Adding entry:
> ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:42,862 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main)
> Adding entry:
> ou=Roles,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:42,977 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main)
> Adding entry:
> uid=jduke,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:43,080 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main)
> Adding entry: uid=Sue\, Grabbit and
> Runn,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:43,162 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main)
> Adding entry:
> uid=Before\0DAfter,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:43,163 WARN
> [org.apache.directory.server.core.normalization.NormalizationInterceptor]
> (pool-7-thread-1) The Rdn 'uid=Before\0DAfter' is not present in the entry
> 14:27:43,255 DEBUG [org.jboss.eapqe.krbldap.servers.ldap.LdapServer] (main)
> Adding entry:
> uid=#4869,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org
> 14:27:43,256 ERROR [org.apache.directory.api.ldap.model.entry.AbstractValue]
> (pool-7-thread-1) The 'uid' AttributeType and values must both be String or
> binary
> 14:27:43,257 WARN [org.apache.directory.api.ldap.model.entry.DefaultEntry]
> (pool-7-thread-1) The Dn
> 'uid=#4869,ou=People,o=LdapLoginModuleSpecialNamesTestCasebb08edb7,o=primary,dc=jboss,dc=org'
> cannot be normalized
> 14:27:43,258 WARN
> [org.apache.directory.server.core.normalization.NormalizationInterceptor]
> (pool-7-thread-1) The Rdn 'uid=Hi' is not present in the entry
> 14:27:43,258 WARN
> [org.apache.directory.api.ldap.model.entry.DefaultAttribute]
> (pool-7-thread-1) ERR_04486_VALUE_ALREADY_EXISTS The value 'Hi' already
> exists in the attribute (uid)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Resolved] (DIRAPI-349) DN with hex values aren't parsed properly when not schema aware
[
https://issues.apache.org/jira/browse/DIRAPI-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny resolved DIRAPI-349.
--
Resolution: Fixed
Fixed with commits {{f7529b6685226d35b668804a5c999b1f42c19cb9}} and
{{49621f53be1b3cf2f5777c575a389c451ca6045d}}
> DN with hex values aren't parsed properly when not schema aware
> ---
>
> Key: DIRAPI-349
> URL: https://issues.apache.org/jira/browse/DIRAPI-349
> Project: Directory Client API
> Issue Type: Bug
>Affects Versions: 2.0.0.AM4
>Reporter: Emmanuel Lecharny
>Priority: Major
> Fix For: 2.0.0.AM5
>
>
> If we create a DN like {{uid = #4869}}, it's properly handled when it's
> schema aware. However, doing the same thing without a {{SchemaManager}} meads
> to some wrong normalized name to be generated :
> {code:java}
> Dn dn = new Dn( "uid = #4869" );
> assertEquals( "uid=Hi", dn.getNormName() );
> {code}
> fails, the {{dn.getNormName()}} calls returns {{uid=}}, with no value.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Created] (DIRAPI-349) DN with hex values aren't parsed properly when not schema aware
Emmanuel Lecharny created DIRAPI-349:
Summary: DN with hex values aren't parsed properly when not schema
aware
Key: DIRAPI-349
URL: https://issues.apache.org/jira/browse/DIRAPI-349
Project: Directory Client API
Issue Type: Bug
Affects Versions: 2.0.0.AM4
Reporter: Emmanuel Lecharny
Fix For: 2.0.0.AM5
If we create a DN like {{uid = #4869}}, it's properly handled when it's schema
aware. However, doing the same thing without a {{SchemaManager}} meads to some
wrong normalized name to be generated :
{code:java}
Dn dn = new Dn( "uid = #4869" );
assertEquals( "uid=Hi", dn.getNormName() );
{code}
fails, the {{dn.getNormName()}} calls returns {{uid=}}, with no value.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSERVER-2156) ApacheDS issues TGT kerberos ticket with address on IBM java
[ https://issues.apache.org/jira/browse/DIRSERVER-2156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRSERVER-2156: - Component/s: kerberos > ApacheDS issues TGT kerberos ticket with address on IBM java > > > Key: DIRSERVER-2156 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2156 > Project: Directory ApacheDS > Issue Type: Bug > Components: kerberos >Affects Versions: 2.0.0-M20 >Reporter: Martin Choma >Priority: Major > Attachments: IBMJavaIdentityPropagation.log, > IBMJavaIdentityPropagation.pcapng, OracleJavaIdentityPropagation.log, > OracleJavaIdentityPropagation.pcapng > > > ApacheDS issues TGT kerberos ticket with address on IBM java , even if > noaddresses = true is explicitelly set in krb5.conf. > Address in ticket causing problem, because ApacheDS check address in ticket > with address of connection. And that leads to error "error 38 Incorrect net > address" > I dont see this issue on IBM java and Active Directory, for instance, so I > think it is not problem of client code. > Also note that running ApacheDS with openJDK and oracle java I also don't > see this. > Only problematic combination is is ApacheDS vs. IBM java 8 > Tested use case is identity propagation / delegation. > In attachment you can find relevant log with > org.apache.directory.server.KERBEROS_LOG set to DEBUG for oracle and ibm > java. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSERVER-2165) ApacheDS M20 database on replicating instance grows large
[ https://issues.apache.org/jira/browse/DIRSERVER-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRSERVER-2165: - Component/s: replication > ApacheDS M20 database on replicating instance grows large > - > > Key: DIRSERVER-2165 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2165 > Project: Directory ApacheDS > Issue Type: Bug > Components: replication >Affects Versions: 2.0.0-M20 >Reporter: Tomi Pietilä >Priority: Major > > Hi, > We have this issue still that on replicating ApacheDS the database grows much > larger that on primary ApacheDS. On primary the master database file is 211MB > and on the replicating ApacheDS the master can grow at least up to 14.9GB. > This obviously takes all allocated memory and eventually brings ApacheDS > down. Restarting helps but at some point reinstall is only option. After > reinstall and importing ldif -file the master on replicating ApacheDS is 305 > MB. > There is comment about mavibot in linked issue, any news on that? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
