[jira] [Resolved] (DIRSERVER-2043) SSL connection failures errors are useless
[
https://issues.apache.org/jira/browse/DIRSERVER-2043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny resolved DIRSERVER-2043.
--
Resolution: Not A Problem
WSeems like an issue with older versions of the JVM. Closing.
> SSL connection failures errors are useless
> --
>
> Key: DIRSERVER-2043
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2043
> Project: Directory ApacheDS
> Issue Type: Bug
>Affects Versions: 2.0.0-M19
>Reporter: Roy Wellington
>Priority: Minor
>
> When connecting, if StartTLS fails, you get an error such as the following:
> {noformat}
> Error while opening connection
> - SSL handshake failed.
> org.apache.directory.ldap.client.api.exception.InvalidConnectionException:
> SSL handshake failed.
> at
> org.apache.directory.ldap.client.api.LdapNetworkConnection.writeRequest(LdapNetworkConnection.java:3939)
> at
> org.apache.directory.ldap.client.api.LdapNetworkConnection.bindAsync(LdapNetworkConnection.java:1178)
> at
> org.apache.directory.ldap.client.api.LdapNetworkConnection.bind(LdapNetworkConnection.java:1076)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper$2.run(DirectoryApiConnectionWrapper.java:368)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.runAndMonitor(DirectoryApiConnectionWrapper.java:1175)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.doBind(DirectoryApiConnectionWrapper.java:460)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.bind(DirectoryApiConnectionWrapper.java:306)
> at
> org.apache.directory.studio.connection.core.jobs.OpenConnectionsRunnable.run(OpenConnectionsRunnable.java:114)
> at
> org.apache.directory.studio.connection.core.jobs.StudioConnectionJob.run(StudioConnectionJob.java:109)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
> SSL handshake failed.
> {noformat}
> But _why_ did the SSL handshake fail? I don't need the stack trace, I need to
> know what exactly failed, something like what Firefox/Chrome do on SSL
> failures. I'm trying to debug this right now, and I have absolutely no idea
> what's going on here.
--
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-2067) Password Policy Enforced for admin user
[ https://issues.apache.org/jira/browse/DIRSERVER-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRSERVER-2067: - Component/s: ppolicy > Password Policy Enforced for admin user > --- > > Key: DIRSERVER-2067 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2067 > Project: Directory ApacheDS > Issue Type: Bug > Components: ppolicy >Affects Versions: 2.0.0-M20 >Reporter: David Paulsen >Priority: Minor > > When bound to a connection using the "uid=admin,ou=system" user, it enforces > the ads-pwdInHistory in the password policy of the uid I'm changing the > password for. For example, if I'm changing the password for > uid=147547,ou=8300,ou=DVHead,dc=kewilltransport,dc=com, and that uid has a > pwdPolicySubentry=ads-pwdId=DVHead8300,ou=passwordPolicies,ads-interceptorId=authenticationInterceptor,ou=interceptors,ads-directoryServiceId=default,ou=config, > it enforces the ads-pwdId=DVHead8300 policy's ads-pwdInHistory setting even > with the admin user. > My understanding is that since it's the admin user, it should not be > enforcing any password policy rules. > Steps: > (1) Create a password policy where the ads-pwdInHistory is greater than 0 so > it enforces not reusing passwords. > (2) Create a uid and set it's pwdPolicySubentry to the above password policy. > (3) Create a connection and bind to it using the "uid=admin,ou=system" user, > and then modify password for the above uid. You will get this error: > error: invalid reuse of password present in password history -- 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-2180) BCrypt password hashing support
[ https://issues.apache.org/jira/browse/DIRSERVER-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny resolved DIRSERVER-2180. -- Resolution: Fixed Fix Version/s: 2.0.0-M24 I think it has been injected a while ago in M24 > BCrypt password hashing support > --- > > Key: DIRSERVER-2180 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2180 > Project: Directory ApacheDS > Issue Type: Improvement > Components: authn >Reporter: Thilo-Alexander Ginkel >Priority: Minor > Fix For: 2.0.0-M24 > > > At the moment, Apache DS does not support the BCrypt password hashing > algorithm. > As discussed on the dev mailinglist, I'd like to contribute support for this > algorithm and am opening this ticket as requested by [~elecharny]. An > incomplete prototype (at least OSGi tests are currently broken) is available > at [1]. > [1] > https://github.com/tgbyte/directory-shared/tree/feature/bcrypt-hash-support -- 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-2180) BCrypt password hashing support
[ https://issues.apache.org/jira/browse/DIRSERVER-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRSERVER-2180: - Component/s: authn > BCrypt password hashing support > --- > > Key: DIRSERVER-2180 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2180 > Project: Directory ApacheDS > Issue Type: Improvement > Components: authn >Reporter: Thilo-Alexander Ginkel >Priority: Minor > > At the moment, Apache DS does not support the BCrypt password hashing > algorithm. > As discussed on the dev mailinglist, I'd like to contribute support for this > algorithm and am opening this ticket as requested by [~elecharny]. An > incomplete prototype (at least OSGi tests are currently broken) is available > at [1]. > [1] > https://github.com/tgbyte/directory-shared/tree/feature/bcrypt-hash-support -- 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-2189) Replication use another folder than /tmp
[ https://issues.apache.org/jira/browse/DIRSERVER-2189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRSERVER-2189: - Component/s: replication > Replication use another folder than /tmp > > > Key: DIRSERVER-2189 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2189 > Project: Directory ApacheDS > Issue Type: Wish > Components: replication >Affects Versions: 2.0.0-M22 > Environment: Redhat 5 > Java 8 >Reporter: Mehdi S >Priority: Minor > > Hello, > We have noticed that replication instance write in /tmp while running, is > there a specific configuration to chose another tmp folder (ex: > /home/apacheds/tmp) ? > NB : We can't resize our /tmp which less than 500Mo because of our host > policies. -- 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-2053) Sometimes apacheds will throw OutOfMemoryException
[ https://issues.apache.org/jira/browse/DIRSERVER-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRSERVER-2053: - Component/s: (was: ldap) mavibot > Sometimes apacheds will throw OutOfMemoryException > -- > > Key: DIRSERVER-2053 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2053 > Project: Directory ApacheDS > Issue Type: Bug > Components: mavibot >Affects Versions: 2.0.0-M19 > Environment: CentOS 6.5 with apacheds M19 installed. >Reporter: linzhao >Priority: Blocker > > After injecting some data into apacheds and restart it. Sometimes the > apacheds can't be started, it will throw OutOfMemoryException. The data > entries will less than 600. Exception list below: > INFO | jvm 1| 2015/03/04 23:52:09 | Dumping heap to > /opt/polycom/apacheds-dumps/java_pid24024.hprof ... > INFO | jvm 1| 2015/03/04 23:52:19 | Heap dump file created [2094548383 > bytes in 9.597 secs] > INFO | jvm 1| 2015/03/04 23:52:19 | Error in WrapperListener.start > callback. java.lang.OutOfMemoryError: GC overhead limit exceeded > INFO | jvm 1| 2015/03/04 23:52:19 | java.lang.OutOfMemoryError: GC > overhead limit exceeded > INFO | jvm 1| 2015/03/04 23:52:19 | at > java.nio.HeapByteBuffer.(HeapByteBuffer.java:57) > INFO | jvm 1| 2015/03/04 23:52:19 | at > java.nio.ByteBuffer.allocate(ByteBuffer.java:335) > INFO | jvm 1| 2015/03/04 23:52:19 | at > org.apache.directory.mavibot.btree.RecordManager.fetchPage(RecordManager.java:3045) > INFO | jvm 1| 2015/03/04 23:52:19 | at > org.apache.directory.mavibot.btree.RecordManager.readPageIOs(RecordManager.java:797) > INFO | jvm 1| 2015/03/04 23:52:19 | at > org.apache.directory.mavibot.btree.RecordManager.deserialize(RecordManager.java:987) > INFO | jvm 1| 2015/03/04 23:52:19 | at > org.apache.directory.mavibot.btree.PersistedPageHolder.fetchElement(PersistedPageHolder.java:133) > INFO | jvm 1| 2015/03/04 23:52:19 | at > org.apache.directory.mavibot.btree.PersistedPageHolder.getValue(PersistedPageHolder.java:113) > INFO | jvm 1| 2015/03/04 23:52:19 | at > org.apache.directory.mavibot.btree.AbstractPage.get(AbstractPage.java:252) > INFO | jvm 1| 2015/03/04 23:52:19 | at > org.apache.directory.mavibot.btree.AbstractBTree.get(AbstractBTree.java:505) > INFO | jvm 1| 2015/03/04 23:52:19 | at > org.apache.directory.mavibot.btree.PersistedBTree.get(PersistedBTree.java:43) > INFO | jvm 1| 2015/03/04 23:52:19 | at > org.apache.directory.server.core.partition.impl.btree.mavibot.MavibotTable.get(MavibotTable.java:317) > INFO | jvm 1| 2015/03/04 23:52:19 | at > org.apache.directory.server.core.partition.impl.btree.mavibot.MavibotIndex.forwardLookup(MavibotIndex.java:305) > INFO | jvm 1| 2015/03/04 23:52:19 | at > org.apache.directory.server.core.partition.impl.btree.mavibot.MavibotIndex.forwardLookup(MavibotIndex.java:58) > INFO | jvm 1| 2015/03/04 23:52:19 | at > org.apache.directory.server.core.partition.impl.btree.AbstractBTreePartition.getEntryId(AbstractBTreePartition.java:2473) > INFO | jvm 1| 2015/03/04 23:52:19 | at > org.apache.directory.server.xdbm.search.impl.DefaultSearchEngine.computeResult(DefaultSearchEngine.java:123) > INFO | jvm 1| 2015/03/04 23:52:19 | at > org.apache.directory.server.core.partition.impl.btree.AbstractBTreePartition.search(AbstractBTreePartition.java:1141) > INFO | jvm 1| 2015/03/04 23:52:19 | at > org.apache.directory.server.core.shared.partition.DefaultPartitionNexus.search(DefaultPartitionNexus.java:624) > INFO | jvm 1| 2015/03/04 23:52:19 | at > org.apache.directory.server.core.shared.ReferralManagerImpl.init(ReferralManagerImpl.java:178) > INFO | jvm 1| 2015/03/04 23:52:19 | at > org.apache.directory.server.core.shared.ReferralManagerImpl.(ReferralManagerImpl.java:86) > INFO | jvm 1| 2015/03/04 23:52:19 | at > org.apache.directory.server.core.referral.ReferralInterceptor.init(ReferralInterceptor.java:213) > INFO | jvm 1| 2015/03/04 23:52:19 | at > org.apache.directory.server.core.DefaultDirectoryService.initInterceptors(DefaultDirectoryService.java:685) > INFO | jvm 1| 2015/03/04 23:52:19 | at > org.apache.directory.server.core.DefaultDirectoryService.initialize(DefaultDirectoryService.java:1818) > INFO | jvm 1| 2015/03/04 23:52:19 | at > org.apache.directory.server.core.DefaultDirectoryService.startup(DefaultDirectoryService.java:1244) > INFO | jvm 1| 2015/03/04 23:52:19 | at > org.apache.directory.server.ApacheDsService.initDirectoryService(ApacheDsService
[jira] [Updated] (DIRSERVER-2209) SSL handshake fails when server uses an PKCS12 keystore
[ https://issues.apache.org/jira/browse/DIRSERVER-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRSERVER-2209: - Component/s: network > SSL handshake fails when server uses an PKCS12 keystore > --- > > Key: DIRSERVER-2209 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2209 > Project: Directory ApacheDS > Issue Type: Bug > Components: network >Affects Versions: 2.0.0-M23, 2.0.0-M24 > Environment: OS: > Windows 7 Professional 64 Bit > JRE: > jre1.8.0_144 > Test-Client: > Apache Directory Studio 2.0.0.v20150606-M9 >Reporter: Mareike Täubner >Priority: Minor > Attachments: test-ldap.zip > > > I am using the apache directory server library > (or.apache.directory.server.apacheds-all 2.0.0-M23) to run a simple LDAP > instance. As I was implementing an LDAPS connection I got stuck with the > following issue: > When setting the keystore file in the LdapServer object, it makes a > difference whether it is an JKS or PKCS12 keystore. Using the JKS the client > can successfully connect via LDAPS. With the PKCS12 the client can't connect > because the SSL handshake fails. > I have added a minimal example project that reproduces the 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-2211) apacheds data recovery when servcei can not start
[ https://issues.apache.org/jira/browse/DIRSERVER-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRSERVER-2211: - Component/s: (was: ldap) tools > apacheds data recovery when servcei can not start > - > > Key: DIRSERVER-2211 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2211 > Project: Directory ApacheDS > Issue Type: Improvement > Components: tools >Affects Versions: 2.0.0-M20 > Environment: Redhat 6.7 and CentOS7.2 > apacheds 2.0.0-M20 >Reporter: cokuehuang >Priority: Critical > Labels: easyfix > Original Estimate: 96h > Remaining Estimate: 96h > > Is there any tools that can recovery data from a apacheds service that can > not start or data can not show correctly(maybe data index problems).As we met > this problem,the data can not show correctly after service restart, most data > are "missing", and now we backup data by backup default dirs, sometimes the > apacheds service can not start using backup default, this is our worrying, if > the service can not work ,how to recovery data? -- 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-2172) ApacheDS 2.0.0M12 in production, getting ERR_554 double get for block block 3,474
[ https://issues.apache.org/jira/browse/DIRSERVER-2172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRSERVER-2172: - Component/s: (was: ldap) jdbm > ApacheDS 2.0.0M12 in production, getting ERR_554 double get for block block > 3,474 > -- > > Key: DIRSERVER-2172 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2172 > Project: Directory ApacheDS > Issue Type: Bug > Components: jdbm > Environment: GNU/Linux x86_64 >Reporter: sourabh sihare >Priority: Critical > Attachments: wrapper.conf > > > We have upgraded apacheds from 2.0.0-M23 assuming that will fix the issue > with data getting corrupt but we are still facing the same issue.The apacheds > server keeps running but data does not load fully from front end like 400 > users instead of actual 3000+ users. > -> As a workaround we take backup of partition daily and when the issue > occurs we replace the partition from backed-up partition and restart the > server. > -> From apacheds.log we get below error trace- > [16:13:21] DEBUG [org.apache.directory.server.OPERATION_LOG] - << > CompareOperation successful > [16:13:21] DEBUG [org.apache.directory.server.OPERATION_TIME] - Compare > operation took 183000 ns > [16:13:21] DEBUG [org.apache.directory.server.OPERATION_LOG] - >> > CompareOperation : CompareContext for Dn 'uid=GA1346,ou=users,o=sccm', oid : > , value :'groupOfNames' > [16:13:21] DEBUG [org.apache.directory.server.OPERATION_LOG] - >> > LookupOperation : FilteringOperationContext for Dn > 'uid=GA1346,ou=users,o=sccm', +, * > [16:13:21] WARN [org.apache.directory.server.ldap.LdapProtocolHandler] - > Unexpected exception forcing session to close: sending disconnect notice to > client. > java.lang.Error: ERR_554 double get for block 3,474 > at jdbm.recman.RecordFile.get(RecordFile.java:185) > at > jdbm.recman.PhysicalRowIdManager.allocNew(PhysicalRowIdManager.java:202) > at > jdbm.recman.PhysicalRowIdManager.alloc(PhysicalRowIdManager.java:177) > at > jdbm.recman.PhysicalRowIdManager.update(PhysicalRowIdManager.java:101) > at jdbm.recman.BaseRecordManager.update(BaseRecordManager.java:281) > at > jdbm.recman.CacheRecordManager$CacheListener.cacheObjectEvicted(CacheRecordManager.java:459) > at > jdbm.recman.CacheRecordManager$CacheListener.cacheObjectEvicted(CacheRecordManager.java:444) > at jdbm.helper.MRU.purgeEntry(MRU.java:310) > at jdbm.helper.MRU.put(MRU.java:128) > at jdbm.recman.CacheRecordManager.fetch(CacheRecordManager.java:268) > at jdbm.btree.BPage.loadBPage(BPage.java:949) > at jdbm.btree.BPage.find(BPage.java:280) > at jdbm.btree.BTree.find(BTree.java:413) > at > org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmTable.get(JdbmTable.java:343) > at > org.apache.directory.server.core.partition.impl.btree.AbstractBTreePartition.fetch(AbstractBTreePartition.java:1274) > at > org.apache.directory.server.core.partition.impl.btree.AbstractBTreePartition.lookup(AbstractBTreePartition.java:1202) > at > org.apache.directory.server.core.shared.partition.DefaultPartitionNexus.lookup(DefaultPartitionNexus.java:464) > at > org.apache.directory.server.core.api.interceptor.BaseInterceptor$1.lookup(BaseInterceptor.java:161) > at > org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:483) > at > org.apache.directory.server.core.collective.CollectiveAttributeInterceptor.lookup(CollectiveAttributeInterceptor.java:143) > at > org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:483) > at > org.apache.directory.server.core.operational.OperationalAttributeInterceptor.lookup(OperationalAttributeInterceptor.java:329) > at > org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:483) > at > org.apache.directory.server.core.schema.SchemaInterceptor.lookup(SchemaInterceptor.java:1142) > at > org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:483) > at > org.apache.directory.server.core.authz.DefaultAuthorizationInterceptor.lookup(DefaultAuthorizationInterceptor.java:231) > at > org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:483) > at > org.apache.directory.server.core.authz.AciAuthorizationInterceptor.lookup(AciAuthorizationInterceptor.java:779) > at > org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:483) > at > org.apache.directory.server.core
[jira] [Updated] (DIRSERVER-2086) Can't connect to LDAP server when apache ds report ERR_554 error in log file.
[ https://issues.apache.org/jira/browse/DIRSERVER-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRSERVER-2086: - Component/s: (was: ldap) jdbm > Can't connect to LDAP server when apache ds report ERR_554 error in log file. > - > > Key: DIRSERVER-2086 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2086 > Project: Directory ApacheDS > Issue Type: Bug > Components: jdbm >Affects Versions: 2.0.0-M20 > Environment: Suse Linux 11 SP3 >Reporter: wangxinit >Priority: Critical > > Any client can't connet to LDAP server. > Check the log file , found ERR_554 Error. -- 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-2171) Creating a Custom Interceptor in Apache DS 2.0.0-M23
[ https://issues.apache.org/jira/browse/DIRSERVER-2171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRSERVER-2171: - Component/s: (was: ldap) doc > Creating a Custom Interceptor in Apache DS 2.0.0-M23 > > > Key: DIRSERVER-2171 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2171 > Project: Directory ApacheDS > Issue Type: Improvement > Components: doc >Affects Versions: 2.0.0-M23 >Reporter: Gautham Gurudatta Shet >Priority: Critical > Attachments: CustomInterceptor.PNG > > > The link > "http://directory.apache.org/apacheds/advanced-ug/6-implementing-interceptor.html"; > does not have info on how to create a custom interceptor for Apache DS > 2.0.0-M23. The info is present for Apache DS 1.5.5. Can you please provide > this info? -- 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-1830) when ads-pwdMaxIdle > 0 no more authentication possible
[ https://issues.apache.org/jira/browse/DIRSERVER-1830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRSERVER-1830: - Component/s: (was: ldap) ppolicy > when ads-pwdMaxIdle > 0 no more authentication possible > --- > > Key: DIRSERVER-1830 > URL: https://issues.apache.org/jira/browse/DIRSERVER-1830 > Project: Directory ApacheDS > Issue Type: Bug > Components: ppolicy >Affects Versions: 2.0.0-M11 > Environment: CentOS >Reporter: Michael Witzel >Priority: Major > > when I configure ads-pwdMaxIdle > 0 no authentication is possible, neither > with admin, nor with other users > Eclipse Studio: > Fehler beim Öffnen der Verbindung > - [LDAP: error code 49 - INVALID_CREDENTIALS: Bind failed: ERR_229 Cannot > authenticate user uid=admin,ou=system] > java.lang.Exception: [LDAP: error code 49 - INVALID_CREDENTIALS: Bind failed: > ERR_229 Cannot authenticate user uid=admin,ou=system] > at > org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.checkResponse(DirectoryApiConnectionWrapper.java:1279) > at > org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.access$600(DirectoryApiConnectionWrapper.java:109) > at > org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper$2.run(DirectoryApiConnectionWrapper.java:450) > at > org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.runAndMonitor(DirectoryApiConnectionWrapper.java:1174) > at > org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.doBind(DirectoryApiConnectionWrapper.java:459) > at > org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.bind(DirectoryApiConnectionWrapper.java:307) > at > org.apache.directory.studio.connection.core.jobs.OpenConnectionsRunnable.run(OpenConnectionsRunnable.java:114) > at > org.apache.directory.studio.connection.core.jobs.StudioConnectionJob.run(StudioConnectionJob.java:109) > at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53) > [LDAP: error code 49 - INVALID_CREDENTIALS: Bind failed: ERR_229 Cannot > authenticate user uid=admin,ou=system] > wrapper.log > INFO | jvm 1| 2013/04/18 14:24:06 | [14:24:06] ERROR > [org.apache.directory.server.ldap.handlers.request.UnbindRequestHandler] - > ERR_169 failed to unbind session properly > INFO | jvm 1| 2013/04/18 14:24:06 | > org.apache.directory.api.ldap.model.exception.LdapNoSuchObjectException: > ERR_268 Cannot find a partition for > INFO | jvm 1| 2013/04/18 14:24:06 | at > org.apache.directory.server.core.shared.partition.DefaultPartitionNexus.getPartition(DefaultPartitionNexus.java:927) > INFO | jvm 1| 2013/04/18 14:24:06 | at > org.apache.directory.server.core.shared.partition.DefaultPartitionNexus.unbind(DefaultPartitionNexus.java:794) > INFO | jvm 1| 2013/04/18 14:24:06 | at > org.apache.directory.server.core.api.interceptor.BaseInterceptor$1.unbind(BaseInterceptor.java:266) > INFO | jvm 1| 2013/04/18 14:24:06 | at > org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:690) > INFO | jvm 1| 2013/04/18 14:24:06 | at > org.apache.directory.server.core.authn.AuthenticationInterceptor.unbind(AuthenticationInterceptor.java:1159) > INFO | jvm 1| 2013/04/18 14:24:06 | at > org.apache.directory.server.core.DefaultOperationManager.unbind(DefaultOperationManager.java:1230) > INFO | jvm 1| 2013/04/18 14:24:06 | at > org.apache.directory.server.core.shared.DefaultCoreSession.unbind(DefaultCoreSession.java:1073) > INFO | jvm 1| 2013/04/18 14:24:06 | at > org.apache.directory.server.ldap.handlers.request.UnbindRequestHandler.handle(UnbindRequestHandler.java:50) > INFO | jvm 1| 2013/04/18 14:24:06 | at > org.apache.directory.server.ldap.handlers.request.UnbindRequestHandler.handle(UnbindRequestHandler.java:38) > INFO | jvm 1| 2013/04/18 14:24:06 | at > org.apache.directory.server.ldap.handlers.LdapRequestHandler.handleMessage(LdapRequestHandler.java:219) > INFO | jvm 1| 2013/04/18 14:24:06 | at > org.apache.directory.server.ldap.handlers.LdapRequestHandler.handleMessage(LdapRequestHandler.java:56) > INFO | jvm 1| 2013/04/18 14:24:06 | at > org.apache.mina.handler.demux.DemuxingIoHandler.messageReceived(DemuxingIoHandler.java:221) > INFO | jvm 1| 2013/04/18 14:24:06 | at > org.apache.directory.server.ldap.LdapProtocolHandler.messageReceived(LdapProtocolHandler.java:217) > INFO | jvm 1| 2013/04/18 14:24:06 | at > org.apache.mina.core.filterchain.DefaultIoFilterChain$Ta
[jira] [Updated] (DIRSERVER-2215) LDAP: Error 50 - Insufficient Access Rights
[ https://issues.apache.org/jira/browse/DIRSERVER-2215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRSERVER-2215: - Component/s: (was: ldap) jdbm > LDAP: Error 50 - Insufficient Access Rights > --- > > Key: DIRSERVER-2215 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2215 > Project: Directory ApacheDS > Issue Type: Bug > Components: jdbm >Affects Versions: 2.0.0-M23 > Environment: windows server 2012 >Reporter: taher fares >Priority: Critical > Attachments: apacheds.log > > > hello all, > I have apache Directory studio(LDAP) connected with our mobile application by > IBM mobile first (MFP), I have a problem that repeated more than once, LDAP > suddenly does not respond to any command from MFP such like Delete and Modify > of structure or person/group objects - ALL functions are causing an error and > whene i trying to apply any LDIF files the following error appears in the LOG > file "apache ldap error code 50 insufficient access rights", > Because of this we have lost many users so I hope you will cooperate to solve > this issue as soon as possible > thank you in advance -- 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-1848) Add possibility to authenticate using a client certificate for LDAPS connections
[ https://issues.apache.org/jira/browse/DIRSERVER-1848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRSERVER-1848: - Component/s: (was: ldap) authn > Add possibility to authenticate using a client certificate for LDAPS > connections > > > Key: DIRSERVER-1848 > URL: https://issues.apache.org/jira/browse/DIRSERVER-1848 > Project: Directory ApacheDS > Issue Type: New Feature > Components: authn >Affects Versions: 2.0.0-M12 >Reporter: Josef Cacek >Priority: Major > > Allow client authentication using (X.509) certificate for LDAPS connections. > I'm not sure, how the configuration should look like on the ApacheDS side, > some points which come to my mind: > - should be the truststore defined in the same way as keystore for the LDAPS? > (file or attribute in admin entry) > - is an existing user account needed (for the authentication and LdapSession > handling)? if yes, how will be the mapping (certificate -to- user LdapEntry) > configured? -- 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-1869) JMX Metrics support for ApacheDS
[ https://issues.apache.org/jira/browse/DIRSERVER-1869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRSERVER-1869: - Component/s: (was: ldap) monitoring > JMX Metrics support for ApacheDS > > > Key: DIRSERVER-1869 > URL: https://issues.apache.org/jira/browse/DIRSERVER-1869 > Project: Directory ApacheDS > Issue Type: Improvement > Components: monitoring >Affects Versions: 2.0.0 > Environment: Windows, AIX, Solaris, Linux, HP-UX >Reporter: Tou-Soua Heu >Priority: Major > > Request to expose LDAP health and performance statistics via JMX such that > monitoring tools can remotely monitor and alert on the state of the ApacheDS > server. The followings are example of live statistics that we need to be able > to capture for a production system: > 1) current number of established LDAP and LDAPS connections > 2) current number of active LDAP and LDAPS connections > 3) current number of idle LDAP and LDAPS connections > 4) minimum, maximum and average executions time of LDAP queries [read vs. > write] > 5) rate of new connections vs. closed connections -- 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-1942) Crash after restart - Failed to start the service
[
https://issues.apache.org/jira/browse/DIRSERVER-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny updated DIRSERVER-1942:
-
Component/s: (was: ldap)
jdbm
> Crash after restart - Failed to start the service
> --
>
> Key: DIRSERVER-1942
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1942
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: jdbm
>Affects Versions: 2.0.0-M12
>Reporter: Stephan Becker
>Priority: Major
>
> We encountered once again a crash after a restart of ApacheDS.
> This is unfortunately very often that we see these crashes after a couple of
> months even though the LDAP was running fine ...
> Stack trace is below
> {code}
> [19:27:55] ERROR [org.apache.directory.server.wrapper.ApacheDsTanukiWrapper]
> - Failed to start the service.
> org.apache.directory.api.ldap.model.exception.LdapOtherException
> at
> org.apache.directory.server.core.api.partition.AbstractPartition.initialize(AbstractPartition.java:84)
> at
> org.apache.directory.server.core.DefaultDirectoryService.initialize(DefaultDirectoryService.java:1808)
> at
> org.apache.directory.server.core.DefaultDirectoryService.startup(DefaultDirectoryService.java:1239)
> at
> org.apache.directory.server.ApacheDsService.initDirectoryService(ApacheDsService.java:315)
> at
> org.apache.directory.server.ApacheDsService.start(ApacheDsService.java:179)
> at
> org.apache.directory.server.wrapper.ApacheDsTanukiWrapper.start(ApacheDsTanukiWrapper.java:72)
> at
> org.tanukisoftware.wrapper.WrapperManager$12.run(WrapperManager.java:2788)
> Caused by: org.apache.directory.api.ldap.model.exception.LdapOtherException
> at
> org.apache.directory.server.core.api.partition.AbstractPartition.initialize(AbstractPartition.java:84)
> at
> org.apache.directory.server.core.shared.partition.DefaultPartitionNexus.addContextPartition(DefaultPartitionNexus.java:829)
> at
> org.apache.directory.server.core.shared.partition.DefaultPartitionNexus.doInit(DefaultPartitionNexus.java:224)
> at
> org.apache.directory.server.core.api.partition.AbstractPartition.initialize(AbstractPartition.java:79)
> ... 6 more
> Caused by:
> org.apache.directory.api.ldap.model.exception.LdapOperationErrorException
> at
> org.apache.directory.server.core.partition.impl.btree.AbstractBTreePartition.fetch(AbstractBTreePartition.java:1145)
> at
> org.apache.directory.server.core.partition.impl.btree.AbstractBTreePartition.lookup(AbstractBTreePartition.java:1058)
> at
> org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmPartition.doInit(JdbmPartition.java:235)
> at
> org.apache.directory.server.core.api.partition.AbstractPartition.initialize(AbstractPartition.java:79)
> ... 9 more
> Caused by: org.apache.directory.api.ldap.model.exception.LdapOtherException
> at
> org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmTable.get(JdbmTable.java:353)
> at
> org.apache.directory.server.core.partition.impl.btree.AbstractBTreePartition.fetch(AbstractBTreePartition.java:1119)
> ... 12 more{code}
--
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-1895) ACLs have no effect
[
https://issues.apache.org/jira/browse/DIRSERVER-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny updated DIRSERVER-1895:
-
Component/s: (was: ldap)
aci
> ACLs have no effect
> ---
>
> Key: DIRSERVER-1895
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1895
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: aci
>Affects Versions: 2.0.0-M15
> Environment: FreeBSD 9.1-RELEASE-p6
>Reporter: Christian Felsing
>Priority: Major
> Labels: acl
>
> Following ACL does not what I expected:
> {
> identificationTag "mtaAclElement",
> precedence 0,
> authenticationLevel simple,
> itemOrUserFirst userFirst:
> {
> userClasses
> {
> name { "cn=mta,dc=ip6,dc=li" }
> }
> ,
> userPermissions
> {
> {
> protectedItems
> {
> entry,
> attributeType
> {
> tsnetDomainName,
> tsnetMailHost,
> uid
> }
> }
> ,
> grantsAndDenials
> {
> grantBrowse,
> grantRead,
> grantReturnDN,
> grantCompare
> }
> }
> }
> }
> }
> This ACL should allow DN cn=mta,dc=ip6,dc=li access to attributes
> uid
> tsnetDomainName
> tsnetMailHost
> and to list all DN entries. A test (temporary allow to list all
> attributes) proved that this ACL matches.
> but
> ldapsearch -H ldap://192.168.116.29:10389 -x -D "cn=mta,dc=ip6,dc=li" -w
> VerySecretPassword -b "dc=ip6,dc=li"
> lists DN entries only:
> # p...@felsing.net, freemail, ip6.li
> dn: uid=p...@felsing.net,ou=freemail,dc=ip6,dc=li
> ...
> Attributes listed on attributeType are not shown.
--
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-1947) maxValueCount not working correctly
[
https://issues.apache.org/jira/browse/DIRSERVER-1947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny updated DIRSERVER-1947:
-
Component/s: (was: ldap)
aci
> maxValueCount not working correctly
> ---
>
> Key: DIRSERVER-1947
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1947
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: aci
>Affects Versions: 2.0.0-M15
> Environment: Server environment:
> Oracle JDK 1.7u45
> ApacheDS 2.0.0-M15
> Debian 7.3, AMD64
> Client environment:
> Apache Directory Studio 2.0.0.v20130628
> Oracle JDK 1.7u45
> OS X 10.9.1
>Reporter: Michael Przybylski
>Priority: Major
>
> I’ve been teaching myself how to use Apache Directory Server’s access control
> subsystem.
> Before getting too cute, I figured I’d try out the recipes here:
> http://directory.apache.org/apacheds/advanced-ug/4.2.7-using-acis-trail.html
> Both work as advertised, but as I’ve been reading more, some have suggested
> refining…
> http://directory.apache.org/apacheds/advanced-ug/4.2.7.2-allow-self-password-modify.html
> …to use maxValueCount to prevent (someone claiming to be) the user from
> inserting multiple userPassword values. However, as soon as I put
> maxValueCount in any protectedItems clause of my prescriptiveACI, all of my
> unprivileged user’s attributes become invisible to him.
> If I weren’t such a n00b, I’d think this was a bug.
> Here is the prescriptiveACI that I think should work:
> {
>identificationTag "userSelfModifyPassword",
>precedence 0,
>authenticationLevel none,
>itemOrUserFirst userFirst:
>{
>userClasses { thisEntry },
>userPermissions
>{
>{
>protectedItems
>{
>maxValueCount
>{
>{ type userPassword, maxCount 1 }
>}
>,
>allAttributeValues { userPassword }
>}
>,
>grantsAndDenials { grantAdd, grantRemove }
>}
>,
>{
>protectedItems { entry },
>grantsAndDenials
>{
>grantRead,
>grantBrowse,
>grantModify
>}
>}
>}
>}
> }
> Kiran Ayyagari ( kayyag...@apache.org ) was able to reproduce and asked me to
> file this bug.
--
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-2092) Java Heap Space - MultiMaster
[ https://issues.apache.org/jira/browse/DIRSERVER-2092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRSERVER-2092: - Component/s: (was: ldap) replication > Java Heap Space - MultiMaster > - > > Key: DIRSERVER-2092 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2092 > Project: Directory ApacheDS > Issue Type: Bug > Components: replication >Affects Versions: 2.0.0-M20 > Environment: Server 2008 R2 >Reporter: Tyler Neemann >Priority: Major > > We are receiving the following errors on both of our DS Instances. They are > configured in a multimaster topology. I have increased the heap size as seen > below in the wrapper.conf. Increasing the memory prolongs when the instance > needs to be restarted, but does not resolve. > INFO | jvm 1| 2015/09/12 23:43:34 | Exception in thread > "pool-2-thread-3" java.lang.OutOfMemoryError: Java heap space > INFO | jvm 1| 2015/09/12 23:43:42 | Exception in thread > "pool-2-thread-6" java.lang.OutOfMemoryError: Java heap space > INFO | jvm 1| 2015/09/12 23:43:49 | Exception in thread > "pool-2-thread-7" java.lang.OutOfMemoryError: Java heap space > INFO | jvm 1| 2015/09/12 23:43:57 | Exception in thread > "pool-2-thread-8" java.lang.OutOfMemoryError: Java heap space > INFO | jvm 1| 2015/09/12 23:44:48 | Exception in thread > "pool-3-thread-1" > INFO | jvm 1| 2015/09/12 23:44:52 | java.lang.OutOfMemoryError: Java > heap space > # Initial Java Heap Size (in MB) > #wrapper.java.initmemory=1024 > # Maximum Java Heap Size (in MB) > #wrapper.java.maxmemory=2048 -- 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-2042) Replication with StartTLS doesnt appear to work
[ https://issues.apache.org/jira/browse/DIRSERVER-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRSERVER-2042: - Component/s: (was: ldap) replication network > Replication with StartTLS doesnt appear to work > --- > > Key: DIRSERVER-2042 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2042 > Project: Directory ApacheDS > Issue Type: Bug > Components: network, replication >Affects Versions: 2.0.0-M16, 2.0.0-M19 > Environment: Linux/CentOS >Reporter: GregF >Priority: Major > > Using ApacheDS replication using StartTLS doesn't seem to establish a secure > connection. There is not much documentation available, but I have > ads-replusetls set to TRUE. Watching the network traffic, the replication > user's bind credentials seem to be transmitted in plaintext. Further traffic > is also clearly readable. I don't believe StartTLS is being used.Is there > anything additional I need to do to make things work. Issue seems to exist in > M16 and M19. -- 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-2103) how to backup apacheds
[ https://issues.apache.org/jira/browse/DIRSERVER-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRSERVER-2103: - Component/s: (was: ldap) tools > how to backup apacheds > -- > > Key: DIRSERVER-2103 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2103 > Project: Directory ApacheDS > Issue Type: New Feature > Components: tools >Affects Versions: 2.0.0-M20 > Environment: centos >Reporter: chandrasekaran >Priority: Major > > Hi, i have installed apacheds 2.0.0-m20 on centos. could you please let me > know the best way to backup the tool configuration and data to restore to > other system > -chandru -- 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-2009) "ERR_04274 Can't find an OID for the name ads-base" after configuring replication
[
https://issues.apache.org/jira/browse/DIRSERVER-2009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny updated DIRSERVER-2009:
-
Component/s: (was: ldap)
replication
> "ERR_04274 Can't find an OID for the name ads-base" after configuring
> replication
> -
>
> Key: DIRSERVER-2009
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2009
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: replication
>Affects Versions: 2.0.0-M17
>Reporter: Rubèn-Dario Castañé
>Priority: Major
> Labels: ldap, replication
> Attachments: ads-base.png, ads-replconsumer.png
>
>
> I'm working on multi-master replication between two servers, following these
> instructions: http://joacim.breiler.com/apacheds/ch08s02.html
> In a nutshell, I did the following configuration in both servers. First, I
> activated the replication handler:
> {code}
> dn:
> ads-serverId=ldapServer,ou=servers,ads-directoryServiceId=default,ou=config
> changetype: modify
> add: ads-replReqHandler
> ads-replReqHandler:
> org.apache.directory.server.ldap.replication.provider.SyncReplRequestHandler
> {code}
> Second, I created a consumer in both servers, each entry pointing to each
> other:
> {code}
> dn:
> ads-replConsumerId=1,ou=replConsumers,ads-serverId=ldapServer,ou=servers,ads-directoryServiceId=default,ou=config
>
> objectClass: ads-base
> objectClass: ads-replConsumer
> objectClass: top
> ads-replAliasDerefMode: never
> ads-replAttributes: *
> ads-replConsumerId: 1
> ads-replProvHostName: ldap-server2.engisoft.com
> ads-replProvPort: 10389
> ads-replRefreshInterval: 6
> ads-replRefreshNPersist: true
> ads-replSearchFilter: (objectClass=*)
> ads-replSearchScope: sub
> ads-replSearchSizeLimit: 0
> ads-replSearchTimeOut: 0
> ads-replUserDn: uid=repl,ou=system
> ads-replUserPassword:: xxx
> ads-searchBaseDN: dc=engisoft,dc=com
> {code}
> I restart the ApacheDS service, in order to reload the changes, but it fails
> with this stacktrace (from wrapper.log):
> {code}
> INFO | jvm 1| 2014/09/30 14:37:18 | [14:37:18] ERROR
> [org.apache.directory.server.config.ConfigPartitionReader] - An error occured
> while reading the configuration DN
> 'ou=replConsumers,ads-serverId=ldapServer,ou=servers,ads-directoryServiceId=default,ou=config'
> for the objectClass 'ads-replConsumer':
> INFO | jvm 1| 2014/09/30 14:37:18 | ERR_04274 Can't find an OID for the
> name ads-base
> INFO | jvm 1| 2014/09/30 14:37:18 | [14:37:18] DEBUG
> [org.apache.directory.CURSOR_LOG] - Closing ListCursor SetCursor :
> INFO | jvm 1| 2014/09/30 14:37:18 | Index : 0
> INFO | jvm 1| 2014/09/30 14:37:18 | Size : 1
> INFO | jvm 1| 2014/09/30 14:37:18 | IndexEntry[ null,
> 9a111f0d-cef5-4251-93ba-b06960f05af6 ]
> INFO | jvm 1| 2014/09/30 14:37:18 |
> INFO | jvm 1| 2014/09/30 14:37:18 | [14:37:18] DEBUG
> [org.apache.directory.CURSOR_LOG] - Closing ListCursor SetCursor :
> INFO | jvm 1| 2014/09/30 14:37:18 | Index : 0
> INFO | jvm 1| 2014/09/30 14:37:18 | Size : 4
> INFO | jvm 1| 2014/09/30 14:37:18 | IndexEntry[ null,
> 75244beb-84ee-4bab-8185-cffb650efa95 ]
> INFO | jvm 1| 2014/09/30 14:37:18 | IndexEntry[ null,
> 0ce41868-ad39-4af1-a027-392ddc41dead ]
> INFO | jvm 1| 2014/09/30 14:37:18 | IndexEntry[ null,
> 7f11fd1f-efb6-4ce7-9c32-377092729f08 ]
> INFO | jvm 1| 2014/09/30 14:37:18 | IndexEntry[ null,
> 9f915798-a812-4b8b-9633-104d6a33a1d6 ]
> INFO | jvm 1| 2014/09/30 14:37:18 |
> INFO | jvm 1| 2014/09/30 14:37:18 | [14:37:18] DEBUG
> [org.apache.directory.CURSOR_LOG] - Closing ListCursor SetCursor :
> INFO | jvm 1| 2014/09/30 14:37:18 | Index : 0
> INFO | jvm 1| 2014/09/30 14:37:18 | Size : 1
> INFO | jvm 1| 2014/09/30 14:37:18 | IndexEntry[ null,
> 73b98b4e-b99e-41af-9e05-e10c570d0f0f ]
> INFO | jvm 1| 2014/09/30 14:37:18 |
> INFO | jvm 1| 2014/09/30 14:37:18 | [14:37:18] ERROR
> [org.apache.directory.server.wrapper.ApacheDsTanukiWrapper] - Failed to start
> the service.
> INFO | jvm 1| 2014/09/30 14:37:18 |
> org.apache.directory.server.config.ConfigurationException: An error occured
> while reading the configuration DN
> 'ou=replConsumers,ads-serverId=ldapServer,ou=servers,ads-directoryServiceId=default,ou=config'
> for the objectClass 'ads-replConsumer':
> INFO | jvm 1| 2014/09/30 14:37:18 | ERR_04274 Can't find an OID for the
> name ads-base
> INFO | jvm 1| 2014/09/30 14:37:18 | at
> org.apache.directory.server.config.ConfigPartitionReader.read(ConfigPartitionReader.java:641)
> INFO | jvm 1| 2014/09/30 14:37:18 | at
> org.a
[jira] [Updated] (DIRSERVER-2152) entry put into replicated system is not replicated
[ https://issues.apache.org/jira/browse/DIRSERVER-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRSERVER-2152: - Component/s: (was: ldap) replication > entry put into replicated system is not replicated > -- > > Key: DIRSERVER-2152 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2152 > Project: Directory ApacheDS > Issue Type: Bug > Components: replication >Affects Versions: 2.0.0-M21 > Environment: Centos 7 >Reporter: Peter Jamieson >Priority: Major > > I created an entry in to an ApacheDS system that was replicating and the > entry was not replicated to the other side (active-active replication). > Are there any logs i need to get when this happens 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-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",
> "TLS_ECDHE_RSA_WITH_
[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&focusedCommentId=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",
> "TLS_DHE_DSS_WITH
[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
> org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseI
[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&focusedCommentId=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
