Re: [API] LDAP Connection Pool - releasing/closing request

[Emmanuel Lécharny]

On 21/02/2024 22:09, Brian Demers wrote:

(Mostly thinking out loud)

Is there any downside in us wrapping the NetworkLdapConnection returned by
the LdapConnectionPool to call releaseConnection instead of close?


We could do that, to some extent. LdapNetworkConnection can be extended, 
so we could add the Closeable interface to it, overriding the close() 
method and adding something like a shutdown() method that would call the 
parent's close() method:


public class PooledLdapNetworkConnection extends LdapNetworkConnection 
implements AutoCloseable

{
LdapConnectionPool pool;
LdapConnection kdapConnection;

	public PooledLdapNetworkConnection( LdapConnection ldapConnection, 
LdapConnectionPool pool )

{
this.ldapConnection = ldapConnection;
this.pool = pool;
}

@Override   
public void close()
{
try
{
pool.releaseConnection( ldapConnection );
}
catch ( LdapException le )
{
// Nothing to do here
}
}

public void shutdown()
{
ldapConnection.close();
}
}

The problem here is that the connection is never associated to the pool 
unless you can have it pushed into the pool, which is normally done by 
the factory and specifically the makeObject() method;


Here we have an issue:
- we want to be able to get a connection from the pool, which extends 
Closeable
- such an object is created by the factory which does create 
LdapNetworkConnection instances.


So we should  create a new LdapConnectionFactory that does instanciate 
PooledLdapNetworkConnection instances in its newLdapConnection() 
function, which get called by the factory.


There is some plumbing to be done, and it will certainly not be 
straightforward, but still.


Even simpler, we could decide that the factory only creates pooleable 
instances (because all in all, this is the only reason we have such a 
factory).





On Wed, Feb 21, 2024 at 12:57 PM Emmanuel Lécharny 
wrote:


Hi Brian,

long story short: the LdapConnection interface (and implementation)
already has a close() method that shutdowns the IO connection, so it's
not possible to use the try-with-resources feature, because that would
have meant changing the LDAP API to make the close() method actually
close the LDAP session, not the IO connection...

So we added the releaseConnection() method which puts back the
connection into the pool, but needs to be called explicitly.

yes, it's a bit of a burden...

Keep in mind that the LDAP API has been defined in 2006, 8 years before
try-with-resources was included in Java 8 :/


On 21/02/2024 17:59, Brian Demers wrote:

I'm hacking away on a SCIMple + ApacheDS + LDAP API example.
I haven't used the LDAP API project before, but the docs have been a big
help!

One thing I'm struggling with is the way connection pooling _should_ be
used.

For example, a non-pooled request could be created doing something like
this:

```
try (LdapConnection connection = new LdapNetworkConnection( "localhost",
389 )) {
// do something with connection
}
```

The connection will close and everyone is fine.

When using a connection pool the pattern is a little different

I was doing something like this:

```
try (LdapConnection connection = connectionPool.getConnection()) {
// do something with connection
}
```

But after making that change, I started seeing tests hang, after a few of
them had run and used a connection (possibly connections were locked)

I stumbled on one of the connection pooling tests that looked like I

should

be calling `connectionPool.releaseConnection(connection)`
That seemed to fix my issue (this should be mentioned here,


https://directory.apache.org/api/user-guide/2.1-connection-disconnection.html
,

I submit a doc fix once this thread is resolved)

So that ends up being something like this
```
LdapConnection connection = connectionPool.getConnection()
try  {
// do something with connection
} finally {
connectionPool.releaseConnection(connection)
}
```

This solution is fine, but... I was expecting the pooled connection to
release the connection instead of closing it.

I hacked around this by extending the LdapConnectionPool and forcing a
release instead of a close.
Quick & dirty with a reflection Proxy:
https://gist.github.com/bdemers/ec2da73f8496fe1cc673619b84f3f450

After this, my pooled connections could be used the same as non-pooled
connections, which was my goal, but...

Now for the naive question.
Is this a good idea? Are there times when I would want to close the
connection instead of releasing it?
Should we think about adding something like this to LdapConnectionPool,

or

is this a doc issue?

Thanks
-Brian



--
*Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
elecha

Re: [API] LDAP Connection Pool - releasing/closing request

[Emmanuel Lécharny]

Hi Brian,

long story short: the LdapConnection interface (and implementation) 
already has a close() method that shutdowns the IO connection, so it's 
not possible to use the try-with-resources feature, because that would 
have meant changing the LDAP API to make the close() method actually 
close the LDAP session, not the IO connection...


So we added the releaseConnection() method which puts back the 
connection into the pool, but needs to be called explicitly.


yes, it's a bit of a burden...

Keep in mind that the LDAP API has been defined in 2006, 8 years before 
try-with-resources was included in Java 8 :/



On 21/02/2024 17:59, Brian Demers wrote:

I'm hacking away on a SCIMple + ApacheDS + LDAP API example.
I haven't used the LDAP API project before, but the docs have been a big
help!

One thing I'm struggling with is the way connection pooling _should_ be
used.

For example, a non-pooled request could be created doing something like
this:

```
try (LdapConnection connection = new LdapNetworkConnection( "localhost",
389 )) {
   // do something with connection
}
```

The connection will close and everyone is fine.

When using a connection pool the pattern is a little different

I was doing something like this:

```
try (LdapConnection connection = connectionPool.getConnection()) {
   // do something with connection
}
```

But after making that change, I started seeing tests hang, after a few of
them had run and used a connection (possibly connections were locked)

I stumbled on one of the connection pooling tests that looked like I should
be calling `connectionPool.releaseConnection(connection)`
That seemed to fix my issue (this should be mentioned here,
https://directory.apache.org/api/user-guide/2.1-connection-disconnection.html,
I submit a doc fix once this thread is resolved)

So that ends up being something like this
```
LdapConnection connection = connectionPool.getConnection()
try  {
   // do something with connection
} finally {
   connectionPool.releaseConnection(connection)
}
```

This solution is fine, but... I was expecting the pooled connection to
release the connection instead of closing it.

I hacked around this by extending the LdapConnectionPool and forcing a
release instead of a close.
Quick & dirty with a reflection Proxy:
https://gist.github.com/bdemers/ec2da73f8496fe1cc673619b84f3f450

After this, my pooled connections could be used the same as non-pooled
connections, which was my goal, but...

Now for the naive question.
Is this a good idea? Are there times when I would want to close the
connection instead of releasing it?
Should we think about adding something like this to LdapConnectionPool, or
is this a doc issue?

Thanks
-Brian



--
*Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
elecha...@apache.org

-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

ApacheDS official Mastodon account

[Emmanuel Lécharny]

Hi!

I just created a Mastodon account for the project at @apach...@fosstodon.org

Feel free to follow it!

It's likely to replace the apacheds twitter account in the near future.

Thanks!
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: DN comparison behavior changed after parsing ancestor

[Emmanuel Lécharny]

Fix committed.

On 13/06/2023 15:52, Emmanuel Lécharny wrote:

I confirm the issue.

I'm fixing it right away.

Thanks for the repport !

(PS: You can fill the JIRA ticket, it will be useful for the changlog)


On 13/06/2023 12:02, Thomas Gäbler wrote:

@Test
*public**void*ancestorCheck() *throws*LdapInvalidDnException
{
 DefaultSchemaManager schemaManager= *new*DefaultSchemaManager();
 Dn group= *new*Dn( schemaManager, "ou=group,ou=base");
 Dn base= *new*Dn( schemaManager, "ou=base");

 Dn ancestor= group.getAncestorOf( "ou=group");
/assertThat/( ancestor, /is/( /equalTo/( base) ) );
}




--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: DN comparison behavior changed after parsing ancestor

[Emmanuel Lécharny]

I confirm the issue.

I'm fixing it right away.

Thanks for the repport !

(PS: You can fill the JIRA ticket, it will be useful for the changlog)


On 13/06/2023 12:02, Thomas Gäbler wrote:

@Test
*public**void*ancestorCheck() *throws*LdapInvalidDnException
{
     DefaultSchemaManager schemaManager= *new*DefaultSchemaManager();
     Dn group= *new*Dn( schemaManager, "ou=group,ou=base");
     Dn base= *new*Dn( schemaManager, "ou=base");

     Dn ancestor= group.getAncestorOf( "ou=group");
/assertThat/( ancestor, /is/( /equalTo/( base) ) );
}


--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: CVE-2022-42889: Apache Commons Text

[Emmanuel Lécharny]

Hi Melissa,

actually, the fix has been applied a while ago (actually, on october, 
13th 2022.: 
https://github.com/apache/directory-ldap-api/commit/261f68b5d51dca0b28bb1af2846a81a8c9b40903)/


We just need to cut a new release.
`

On 17/01/2023 14:44, Melissa Clark wrote:

Hi,

In order to resolve this vulnerability Apache Commons-Text needs to be updated 
to 1.10 – currently the Directory LDAP API is using 1.9. Are there any plans to 
release a build with this dependency fixed?

I can’t log this in Jira as I don’t have an account.

Please see https://lists.apache.org/thread/n2bd4vdsgkqh2tm14l1wyc3jyol7s1om for 
details.

Kind regards,
Melissa



--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: Apache LDAP API Release 2.1.2: web site not updated

[Emmanuel Lécharny]

Hi,

the site has been updated after Jenkins have been rebooted. All is back 
on track !


On 17/08/2022 03:48, Emmanuel Lécharny wrote:

Hi!

the latest Apache LDAP API 2.1.2 has been announced, but the website 
does not shows this version yet. We have a trouble propagating the 
website changes, but this is going to be fixed soon.


This is due to a stuck Jenkins agent that need to be restarted by infra.


--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Apache LDAP API Release 2.1.2: web site not updated

[Emmanuel Lécharny]

Hi!

the latest Apache LDAP API 2.1.2 has been announced, but the website 
does not shows this version yet. We have a trouble propagating the 
website changes, but this is going to be fixed soon.


This is due to a stuck Jenkins agent that need to be restarted by infra.
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: Need help on AdDirSyncImpl API in Apache DS 2.x

[Emmanuel Lécharny]

Hi,

we have completely rewritten this part.

You should now use the AdDirSyncRequestFactory class to get an instance 
of the AdDirSyncRequest class:


AdDirSyncRequestFactory factory = ( AdDirSyncRequestFactory ) 
codec.getRequestControlFactories().

get( AdDirSyncRequest.OID );

AdDirSyncRequest adDirSyncRequest = factory.newControl();

the you can feed the request with what you want.


and

AdDirSyncResponseFactory factory = ( AdDirSyncResponseFactory ) 
codec.getResponseControlFactories().

get( AdDirSyncResponse.OID );
AdDirSyncResponse adDirSyncResponse = factory.newControl();
factory.decodeValue( adDirSyncResponse,  );

Note that the decoding is done by the API, so you just need to fetch the 
instance that has been constructed to get the response's content.


Hope it helps...


On 19/05/2022 16:20, Hrushikesh Agrawal wrote:

Hello Apache Directory Expert,

We are using below classes from  the Apache directory 1.0.3 API. Now we are
planning to upgrade to the Apache API 2.x, and it seems below classes are
not present in 2.x. Can you please help us with the appropriate replacement
for these classes/APIs.

org.apache.directory.api.ldap.extras.controls.ad.AdDirSyncImpl
org.apache.directory.api.ldap.extras.controls.ad_impl.AdDirSyncDecorator;

Thank you in advance.

Regards,
Hrushikesh



--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: mina-core 2.1.3

[Emmanuel Lécharny]

Hi Steffen,

we are currently working on a release.

Be reassured, the LDPA API does *NOT* leverage the mina HTTP layer, so 
there is absolutely no risk on this side.



On 28/04/2022 14:47, Wartner , Steffen - SID-LRZS wrote:

Hello,

I'm using the Apache Directory LDAP API for my projects. There is the CVE 
(https://nvd.nist.gov/vuln/detail/CVE-2021-41973) for the package mina-core 
2.1.3 and it is recommended to update it to 2.1.5. I updated the package in the 
Apache Directory LDAP API 2.1.0 release for my projects. When will the package 
be updated in the next official release?


Best regards
Steffen Wartner



-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org



--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: log4j update

[Emmanuel Lécharny]

Actually, the Apache Directory LDAP API does *not* use Log4j at all, 
being an API.


It uses SLF4J and depends on whatever logger the user selects.


On 21/12/2021 16:50, Shawn McKinney wrote:



On Dec 21, 2021, at 3:18 AM, Wartner , Steffen - SID-LRZS 
 wrote:

my name is Steffen Wartner and I'm using the Apache Directory LDAP API for one 
of my projects. There are security issues with log4j (see 
https://logging.apache.org/log4j/2.x/security.html) and I wanted to ask, when 
the log4j Version 1.2.17 will be updated to 2.17.0 ?


Hello Steffen,

The LDAP API uses Log4j 1.2x which is not affected by the Log4Shell 
(CVE-2021-44228).

Thanks

—
Shawn
-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org



--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: How can I use CRYPT

[Emmanuel Lécharny]

ads-interceptorclassname: 
org.apache.directory.server.core.schema.SchemaInterceptor

ads-interceptorid: schemaInterceptor
ads-enabled: TRUE


and so on.



I know that OpenLDAP has the same mechanism, but you'll have to check 
OpenLDAP doco for that.



I hope I answer your question...


On 15/09/2021 09:33, igyu wrote:


 org.apache.directory.api
 api-all
 2.0.1
 


 
 org.apache.directory.server
 apacheds-core-api
 2.0.0.AM26
 

connection.add(new DefaultEntry(
 "uid=" + name + ",ou=people,dc=join,dc=com",
 "objectClass: account",
 "objectClass: posixAccount",
 "objectClass: shadowAccount",
 "objectClass: top",
 "cn", name,
 "gidNumber", gidNumber,
 "homeDirectory", home,
 "uidNumber", uidNumber,
 "userPassword", upassword
 ));

if I use this userPassword is plaintest

How can I use CRYPT or md5



igyu



--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: [REPOSTED FROM DEV]Issue related to TLSv3 in the LDAP API

[Emmanuel Lécharny]

We are looking at the TLSV1.3 on MINA side with Jonathan Valière.


On 05/07/2021 14:13, Shawn McKinney wrote:



On Jul 4, 2021, at 1:16 PM, Stefan Seelmann  wrote:

Oh sorry, my question regarding ApacheDS didn't make sense because in
ApacheDS only TLSv1.2 is enabled so the negotiation chose 1.2 event if
1.3 is enabled in the API.


No worries.  I needed to test LDAPS on ApacheDS anyway as it has been a while 
since I’ve last tried.  Found and solved a glitch or two so it was time well 
spent.

—
Shawn
-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org



--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: Migration to 2.0 API - RBAC Accelerator Extended Operations

[Emmanuel Lécharny]

On 25/06/2021 15:51, Shawn McKinney wrote:




On Jun 24, 2021, at 8:43 PM, Emmanuel Lécharny  wrote:

On 24/06/2021 20:38, Shawn McKinney wrote:

Moving onto the last hurdle for 2.0 migration…
To get the accelerator client talking with OpenLDAP RBAC overlay, for extended 
operations.
Emmanuel, as I recall some time ago that the RBAC accelerator client would need 
to be reworked when we moved to 2.0.
Do you recall what the issue was?


The ASN.1 encoding has been rewritten from scratch. The idea was to use a 
preallocated buffer, which get filled from the end, instead of computing the 
result size, allocate the buffer and fill it.

It saves the length computation cost most of the time (if the buffer gets too 
small, we reallocate it)


OK




As it stands, I’m getting server side assertion failure.  Before I jump to far 
into this wanted to check with you.
If you want to look at the server side log, it’s here:
https://issues.apache.org/jira/browse/FC-238?focusedCommentId=17369035=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17369035


The logs aren't helful, there is not enough data in it (typically the received 
PDU).

Do you have the extended operation code ?


The client code is locked in a private Gitlab repo but we may be able to 
convince my employer to donate it or open it up.

The RBAC overlay (server side) has recently been added to OpenLDAP contrib 
which will be part of the 2.5 codebase.

Which brings the question - where does the client belong?  Should it be in 
Fortress core, API, somewhere else?


Definitively Fortress.

The good thing is that the LDAP API is extensible, so there is no reason 
to declare extensions in the core code base.




--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: Migration to 2.0 API - RBAC Accelerator Extended Operations

[Emmanuel Lécharny]

On 24/06/2021 20:38, Shawn McKinney wrote:

Moving onto the last hurdle for 2.0 migration…

To get the accelerator client talking with OpenLDAP RBAC overlay, for extended 
operations.

Emmanuel, as I recall some time ago that the RBAC accelerator client would need 
to be reworked when we moved to 2.0.

Do you recall what the issue was?


The ASN.1 encoding has been rewritten from scratch. The idea was to use 
a preallocated buffer, which get filled from the end, instead of 
computing the result size, allocate the buffer and fill it.


It saves the length computation cost most of the time (if the buffer 
gets too small, we reallocate it)




As it stands, I’m getting server side assertion failure.  Before I jump to far 
into this wanted to check with you.

If you want to look at the server side log, it’s here:

https://issues.apache.org/jira/browse/FC-238?focusedCommentId=17369035=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17369035


The logs aren't helful, there is not enough data in it (typically the 
received PDU).


Do you have the extended operation code ?

--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: Migration to 2.0 API has moved onto something a bit more relaxing

[Emmanuel Lécharny]

On 24/06/2021 15:57, Shawn McKinney wrote:

interfaces should describe a type and hence have methods


Whatever.

There is a suppressions.xml file in src/checkstyle that list the classes 
that are to be ignred. here is its content:




checks="InterfaceIsType" />
checks="InterfaceIsType" />
files="org.apache.directory.api.ldap.extras.controls.permissiveModify" 
checks="InterfaceIsType" />
files="org.apache.directory.api.ldap.extras.controls.ppolicy" 
checks="InterfaceIsType" />
files="org.apache.directory.api.ldap.extras.controls.changeNotifications" checks="InterfaceIsType" 
/>



Add the RelaxControl in this file :



checks="InterfaceIsType" />
checks="InterfaceIsType" />
files="org.apache.directory.api.ldap.extras.controls.relax" 
checks="InterfaceIsType" />

...


--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: Migration to 2.0 API has moved onto something a bit more relaxing

[Emmanuel Lécharny]

On 24/06/2021 15:57, Shawn McKinney wrote:

interfaces should describe a type and hence have methods


Does RelaxControl extends  Control ?

--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: Migration to 2.0 API has moved onto something a bit more relaxing

[Emmanuel Lécharny]

On 24/06/2021 06:25, Stefan Seelmann wrote:

On 6/24/21 4:10 AM, Shawn McKinney wrote:

The debugger tells me that api request controls are loaded in 
[StockCodecFactoryUtil](https://github.com/apache/directory-ldap-api/blob/master/ldap/codec/core/src/main/java/org/apache/directory/api/ldap/codec/StockCodecFactoryUtil.java)

So, I added my RelaxControl into the api code space, and added this blurb to 
StockCodecFactoryUtil class:

```
ControlFactory relaxControlFactory = new RelaxControlFactory( 
apiService );
requestControlFactories.put( relaxControlFactory.getOid(), relaxControlFactory 
);
```

Once registered the control is found by the runtime and things become … well 
Relaxed ;-)


I'm not sure if the control should be placed into api-ldap-codec-core or
better api-ldap-extras-codec (there's a ExtrasCodecFactoryUtil to
register controls) which contains, well, non-core control. Feel free to
commit it, then we can include it in the next release.


Definitively in extra-codec.




The other option, if you don't want to add it to the LDAP API, is to
register it in Fortress. You can get a handle to the registries via
LdapNetworkConnection.getCodecService().registerRequestControl(). 


Indeed.  But I think it better fits the extra-codec part of the API, as 
it's not related to Fortress (it's a LDAP draft).



--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: Migrate to 2.0 API - Help w/ PW Policy Control

[Emmanuel Lécharny]

On 23/06/2021 17:32, Shawn McKinney wrote:

Next up on migration tasks, howto process password policy control returned from 
the server.

The 1.x way 
[UserDAO](https://github.com/apache/directory-fortress-core/blob/master/src/main/java/org/apache/directory/fortress/core/impl/UserDAO.java):

```
BindResponse bindResponse = bind( ld, userDn, user.getPassword() );
Control cont = bindResponse.getControls().get( (new 
PasswordPolicyRequestImpl()).getOid() );


better use PasswordPolicyRequest.OID



if ( control == null ){ … }

PasswordPolicyResponse respCtrl = ((PasswordPolicyDecorator)control 
).getDecorated();

if (respCtrl.hasResponse()){
...
if (respCtrl.getResponse().getTimeBeforeExpiration() > 0 ){
…

if (respCtrl.getResponse().getGraceAuthNRemaining() > 0 ){
…
```


The 2.x way 
[PasswordPolicyResponseTest](https://github.com/apache/directory-ldap-api/blob/master/ldap/extras/codec/src/test/java/org/apache/directory/api/ldap/extras/controls/ppolicy/PasswordPolicyResponseTest.java):

```
PasswordPolicyResponseFactory factory = ( PasswordPolicyResponseFactory ) 
codec.getResponseControlFactories().
get( PasswordPolicyResponse.OID );
PasswordPolicyResponse passwordPolicyResponse = factory.newControl();
factory.decodeValue( passwordPolicyResponse, bb.array() );

assertEquals( 1, passwordPolicyResponse.getTimeBeforeExpiration() );
assertEquals( 1, passwordPolicyResponse.getPasswordPolicyError().getValue() );
```
  
Before we passed the bind response into the factory.


In 2.0, you should be able to do something like :


  BindResponse bindResponse = connection.bind( bindRequest );

  PasswordPolicyResponse passwordPolicyResp = ( PasswordPolicyResponse 
) bindResponse.getControls().get( PasswordPolicyRequest.OID );


then access the PasswordPolicyResponse fields directly:

  passwordPolicyResp.getTimeBeforeExpiration()

etc.

Check the server-integ PasswordPolicyIT class that contains examples of 
its usage.


--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: Force password change on next login with Active Directory

[Emmanuel Lécharny]

On 19/05/2021 12:26, 4 Integration wrote:

Hi again,

I noted that when using LdapConnectionTemplate and authenticate(...) it
doesn't return any useful error codes in the exception and no
PasswordWarning.
Shouldn't this scenario return a PasswordWarning?
https://nightlies.apache.org/directory/api/2.0.1/apidocs/org/apache/directory/ldap/client/template/PasswordWarning.html


This is a class used when PasswordPolicy control is sent. It would not 
help you in this context.





If I use:
LdapNetworkConnection and connection.bind(...) it returns an LdapException with
message
80090308: LdapErr: DSID-0C090453, comment: AcceptSecurityContext error,
data 773, v3839
where 773 is what is expected.

It feels like LdapConnectionTemplate has a (few) bug(s).


So please feel free to fill JIRAs.

Thanks

--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: Force password change on next login with Active Directory

[Emmanuel Lécharny]

Hi,

On 18/05/2021 11:03, 4 Integration wrote:

Hi again,

I have had a discussion with our vendor but they have difficulties to
determine the underlying root cause more than error 49
(INVALID_CREDENTIALS). I made a simple Java application to test this and
cannot find anything more when debugging the PasswordException.
Do you have any guidance what to look for?


Error 49 is what the server sends you. It get encapsulated into a 
PasswordException, but teh essence of the error is that:

- either your user does not exist, or you have a typo in it
- or the password is inccorect
- or it has expired
- or some password policy rules out the password for some reason (and 
this is very server specific)


Now, the logs provide more information. Typically :

Message ID : 21
BindResponse
Ldap Result
Result code : (INVALID_CREDENTIALS) invalidCredentials
Matched Dn : ''
Diagnostic message : '80090308: LdapErr: DSID-0C090453,
comment: AcceptSecurityContext error, data 773, v3839'
)


and if you google that, you get :

data 773 :  user must reset password



--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: Force password change on next login with Active Directory

[Emmanuel Lécharny]

On 06/05/2021 14:08, 4 Integration wrote:

@Emmanuel, sure I have a dialogue with them as well but since I know
they use Apache Directory LDAP API and (most) the debug logs are from
`org.apache.directory` trying to understand the behavior of LDAP API
interacting with Active Directory.
I would expect many other users of LDAP API facing the same issue with
AD flag pwdLastSet=0 and if anyone have a solution for it.

Checked the LDAP API source and it says:

 /**
  * This error code is returned if the Dn or password used in a simple bind
  * operation is incorrect, or if the Dn or password is incorrect for some
  * other reason, e.g. the password has expired. This result code only
  * applies to Bind operations -- it should not be returned for other
  * operations if the client does not have sufficient permission to perform
  * the requested operation - in this case the return code should be
  * insufficientAccessRights. Applicable operations: Bind. Result code type:
  * Specific (Security)
  */
 INVALID_CREDENTIALS(49, "invalidCredentials"),

Since the user with `pwdLastSet=0` and have a
"single-password-to-use-to-change-password", I get the feeling of
INVALID_CREDENTIALS not being the correct error code.


Any error for a user trying to bind will be treated as a 
INVALID_CREDENTIALS, to avoid providing any information that could help 
a potential breach of security.


When pwdLastSet is set to 0, the user is most likely to have to provide 
a new password on login (typically for a new user).


Your product should explicitely deal with such cases, checking the error 
AD returns. Sadly, AD encapsulate the code into an error 49, so your 
solution provider should deal with that.


This is explained in this page:

https://ldapwiki.com/wiki/Common%20Active%20Directory%20Bind%20Errors

--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: Force password change on next login with Active Directory

[Emmanuel Lécharny]

ntication : '(omitted-for-safety)'

```
/ Joacim

-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org



--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: LdapNetworkConnection. add eating exceptions

[Emmanuel Lécharny]

Hi Shawn,

Stefan is correct.

There was a discussion about how to react to server's errors. We wanted 
to distinguish between technical errors and logical errors (ie server 
responses containing LdapResult which is not SUCCESS).


In these last cases, throwing an exception would have make it a bit more 
complicated for the client to handle the root cause, as we would have 
had either to map an exception by error type, or include the response 
into the exception, and expecting the client to pull it out of the 
exception to do something with it. We found it more convenient to let 
the client directly deal with the LapResult in the Response and act upon 
its need.


And I agree with Stefan too: if it's not clear, then more doco is necessary.

On 05/04/2021 21:32, Stefan Seelmann wrote:

Hi Shawn,

I can only speak for API V2 but I think for V1 it's similar.

I also was surprised by that behavior, but it's "as designed" and makes
sense and is consistent :)

The LdapConnection methods that take a raw XyzRequest object also return
a raw XyzResponse object. Those only throw an exception if a network
level exceptions happens. But if the LDAP server properly returns a
response (be is positive or negative) the raw response is returned to
the caller and the caller has to inspect it.

There are other methods like add(Entry) or delete(Dn) or modify(Dn,
Modification) which return void. For those methods it's different and
the response from the server is processed by
ResultCodeEnum.processResponse() which throws LDAP specific exceptions
for non-successfule responses.

If you use the raw request/response methods you can use that utility
method too if you like.

I agree that it looks surprising, propbably we should improve the javadoc?

Kind Regards,
Stefan


On 4/5/21 8:30 PM, Shawn McKinney wrote:

Hello,

Stumbled on this today.  The error occurs adding entry to directory and 
constraint violation occurs.  The error is expected as I’m manipulating an pw 
policy attribute that is DSA controlled.

I’ve changed the code on adds to be able to forward the DSA control:

```
AddRequest addRequest = new AddRequestImpl();
addRequest.setEntry( entry );
if ( setManagedDsa )
{
ManageDsaIT mControl =  new ManageDsaITImpl();
mControl.setCritical( true );
addRequest.addControl( mControl );
}
AddResponse response = connection.add( addRequest );
```

FWIW I’ve also done it this way:

```
addRequest.addControl( new ManageDsaITImpl(); );
```

With this newly modified code I wouldn’t expect to get an error from server, 
but let’s set that concern aside for a moment.

What I REALLY don't expect is for the server exception to be eaten by the API.

It happens line 566 of class (v1.3):


   } else {
   LOG.debug("Add failed : {}", addResponse);
 }

I’ve stepped through it, the server returns in response to the add (with 
pwpolicy operational attr):

```
Ldap Result
 Result code : (CONSTRAINT_VIOLATION) constraintViolation
 Matched Dn : ''
 Diagnostic message : 'pwdPolicySubentry: no user modification allowed’
```

A more complete excerpt of LDAP API code add method:


```
LdapNetworkConnection
 public AddResponse add(AddRequest addRequest) throws LdapException {
...

 try {
 AddResponse addResponse = (AddResponse)addFuture.get(this.timeout, 
TimeUnit.MILLISECONDS);
 if (addResponse == null) {
 LOG.error("Add failed : timeout occurred");
 throw new LdapException("TimeOut occurred");
 } else {
 if (addResponse.getLdapResult().getResultCode() == 
ResultCodeEnum.SUCCESS) {
 LOG.debug("Add successful : {}", addResponse);
 } else {
 LOG.debug("Add failed : {}", addResponse);
 }

 return addResponse;
 }
 …
```

Please advise on if you think this is a bug (eating exception).  I’ll follow-up 
with another thread on the *why* the server's returning the exception in the 
first place but I need to investigate a bit more (may be problem on server 
OpenLDAP 2.5.3 beta).

—
Shawn


-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org




-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org



--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: help on retrieving ms-ds-consistencyguid from activedirectory

[Emmanuel Lécharny]

yep, here you are:

https://issues.apache.org/jira/projects/DIRAPI


On 24/03/2021 16:50, Benner, Craig wrote:

I can fill out a JIRA ticket, can you send me the link?



thanks,

Craig Benner


My Calendar in Free/Busy View 
<https://outlook.office365.com/owa/calendar/a547b9cc00cf46ffaaf4072980708...@psu.edu/2f5004b9918c42af84647509f87d174b8638641687214814771/calendar.html>


<https://outlook.office365.com/owa/calendar/a547b9cc00cf46ffaaf4072980708...@psu.edu/2f5004b9918c42af84647509f87d174b8638641687214814771/calendar.html>

https://keybase.io/craigbenner <https://keybase.io/craigbenner>

----
*From:* Emmanuel Lécharny 
*Sent:* Wednesday, March 24, 2021 11:16 AM
*To:* Benner, Craig ; api@directory.apache.org 

*Subject:* Re: help on retrieving ms-ds-consistencyguid from 
activedirectory

Ah, snap...

We should really return an impl. can you fill a JIRA for that ?

Otherwise, cast the resturning value to
ConfigurableBinaryAttributeDetector :

((ConfigurableBinaryAttributeDetector)connection.getBinaryAttributeDetector()).addBinaryAttribute( 


"mS-DS-ConsistencyGuid" )

that should do the trick (or maybe to SchemaBinaryAttributeDetector)

On 24/03/2021 16:06, Benner, Craig wrote:

Thanks for the quick response!!

I'm using version 2.0.1 of the library, and the LdapConnection is 
returning type BinaryAttributeDetector (an interface) that doesn't have 
the method you described


https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnightlies.apache.org%2Fdirectory%2Fapi%2F2.0.1%2Fapidocs%2Forg%2Fapache%2Fdirectory%2Fapi%2Fldap%2Fcodec%2Fapi%2FBinaryAttributeDetector.htmldata=04%7C01%7Ccraig.benner%40psu.edu%7Cb5c276a67c0d4e6b797e08d8eed7d10e%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C637521957979430784%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ZbtF7WKcX5raJarL9Hxvn4HDMlviiab%2BValyq2e4Iy0%3Dreserved=0 
<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnightlies.apache.org%2Fdirectory%2Fapi%2F2.0.1%2Fapidocs%2Forg%2Fapache%2Fdirectory%2Fapi%2Fldap%2Fcodec%2Fapi%2FBinaryAttributeDetector.htmldata=04%7C01%7Ccraig.benner%40psu.edu%7Cb5c276a67c0d4e6b797e08d8eed7d10e%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C637521957979430784%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ZbtF7WKcX5raJarL9Hxvn4HDMlviiab%2BValyq2e4Iy0%3Dreserved=0> 

<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnightlies.apache.org%2Fdirectory%2Fapi%2F2.0.1%2Fapidocs%2Forg%2Fapache%2Fdirectory%2Fapi%2Fldap%2Fcodec%2Fapi%2FBinaryAttributeDetector.htmldata=04%7C01%7Ccraig.benner%40psu.edu%7Cb5c276a67c0d4e6b797e08d8eed7d10e%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C637521957979430784%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ZbtF7WKcX5raJarL9Hxvn4HDMlviiab%2BValyq2e4Iy0%3Dreserved=0 

<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnightlies.apache.org%2Fdirectory%2Fapi%2F2.0.1%2Fapidocs%2Forg%2Fapache%2Fdirectory%2Fapi%2Fldap%2Fcodec%2Fapi%2FBinaryAttributeDetector.htmldata=04%7C01%7Ccraig.benner%40psu.edu%7Cb5c276a67c0d4e6b797e08d8eed7d10e%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C637521957979430784%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ZbtF7WKcX5raJarL9Hxvn4HDMlviiab%2BValyq2e4Iy0%3Dreserved=0>>
BinaryAttributeDetector (Apache LDAP API 2.0.1 API Documentation) 
<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnightlies.apache.org%2Fdirectory%2Fapi%2F2.0.1%2Fapidocs%2Forg%2Fapache%2Fdirectory%2Fapi%2Fldap%2Fcodec%2Fapi%2FBinaryAttributeDetector.htmldata=04%7C01%7Ccraig.benner%40psu.edu%7Cb5c276a67c0d4e6b797e08d8eed7d10e%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C637521957979430784%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ZbtF7WKcX5raJarL9Hxvn4HDMlviiab%2BValyq2e4Iy0%3Dreserved=0 

<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnightlies.apache.org%2Fdirectory%2Fapi%2F2.0.1%2Fapidocs%2Forg%2Fapache%2Fdirectory%2Fapi%2Fldap%2Fcodec%2Fapi%2FBinaryAttributeDetector.htmldata=04%7C01%7Ccraig.benner%40psu.edu%7Cb5c276a67c0d4e6b797e08d8eed7d10e%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C637521957979430784%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ZbtF7WKcX5raJarL9Hxvn4HDMlviiab%2BValyq2e4Iy0%3Dreserved=0>>
An interface used to abstract the means to detect whether or not an 
attribute identifier/descriptor represents a binary attributeType.

nightlies.apache.org





thanks,

Craig Benner


My Calendar in Free/Busy View 
<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Foutlook.office365.com%

Re: help on retrieving ms-ds-consistencyguid from activedirectory

[Emmanuel Lécharny]

Answer inline...

On 24/03/2021 15:38, Benner, Craig wrote:


Thanks for replying.  I actually don't know what you exactly mean by `what type 
of AttributeType are you using for this
attribute`.  So, I'll try to show some code and explain what my code is doing 
outside of what i don't show...  I have it OO designed out to be able to manage 
our AD for multiple styles of users, so it is hard to show all at once.

Here is a snippet of our "Search" method

 SearchRequest searchRequest = new SearchRequestImpl();
 searchRequest.setBase(new Dn(searchBaseDn));
 searchRequest.setFilter(filter);
 searchRequest.setScope(SearchScope.SUBTREE);
 searchRequest.addAttributes((String[]) attributes.toArray(new 
String[0]));
 searchRequest.addControl(pagedSearchControl);

 cursor = new EntryCursorImpl(ldapConn.search(searchRequest));

 while (cursor.next()) {
   try {
 Entry result = cursor.get();
 if (offset == null || offset.equals(pagesLooped)) {
   if (processRanges) {
 processRangeAttributes(ldapConn, result, attributes, 
searchBaseDn);
   }
   results.add(result);
   sizeOfResult++;
 }
   } catch (CursorLdapReferralException clre) {
 do {
   // ignoring referrals
 } while (clre.skipReferral());
   }
 }



attributes.toArray logs out like this ==> [accountExpires, 
altSecurityIdentities, badPasswordTime, badPwdCount, cn, distinguishedName, 
extensionAttribute2, mS-DS-ConsistencyGuid, msDS-KeyVersionNumber, 
msDS-SupportedEncryptionTypes, objectClass, objectGuid, objectSid, primaryGroupId, 
pwdLastSet, sAMAccountName, uid, userAccountControl, userPrincipalName, 
whenChanged, whenCreated]

Once the search method is complete, it returns the "entry" -or collection of 
entrys to a method that runs that entry through a conversion process

Below is my current mess​ of code while trying to figure out how to manipulate 
the bytes coming back for ms-ds-consistencyguid

  for (Attribute a : entry.getAttributes()) {
  

 log.debug("Setting field [" + attributeName + "] with value [" + 
a.get().getString() + "] and field type ["
 + f.getType() + "]");

 .

 } else if (f.getType().equals(byte[].class)) {

   byte[] theValue;
   if (a.isHumanReadable()) {


Here lie dragons...

The HR flag is set based on the LDAP API knowledge of the attributeType 
characteristics. Sadly, we can't account for all the existing 
attributeType definitions, and we have based this flag on the existing 
RFCs were attributes are defined.


Bottom line, the MS AT is unknown to the API, thus the HR defaults to true.

(At some point we have to decide if the value is a String or a byte[])

There is a way to trick the API and tell it that the attribute is in 
fact binary, by adding the attribute name to the list of binary 
attributes managed by the DefaultConfigurableBinaryAttributeDetector 
instance (see 
https://nightlies.apache.org/directory/api/2.0.1/apidocs/org/apache/directory/api/ldap/codec/api/DefaultConfigurableBinaryAttributeDetector.html).


So if you call 
connection.getBinaryAttributeDetector().addBinaryAttribute( 
"mS-DS-ConsistencyGuid" ) method, that should do the trick.


Yes, I know, it's a bit tricky, it's not exactly well documented, but at 
least, it should do the job :-)


-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: help on retrieving ms-ds-consistencyguid from activedirectory

[Emmanuel Lécharny]

Hi!

just wondering: what type of AttributeType are you using for this 
attribute? It will drive the way it's exposed.


In any case, you should be able to pull the value from the UpValue 
field, as it is what is returned without any processing.


Ca you copy/paste the code you use to read this value ?


On 24/03/2021 13:50, Benner, Craig wrote:

Apache Ldap Api group,
   I'm working on some code that is using this library to pull directory 
information out of Active Directory's LDAP.  So far, the library is great and 
has helped tremendously.  But I've hit a roadblock, I'm trying to pull the 
attribute ms-ds-consistencyguid, the library is pulling the data.  But the part 
that I'm not understanding is how to convert the data into the hex value that 
other applications are showing as the value.

Some information:
It is being returned as HumanReadable, with an upValue, normValu, h, isHR, and 
bytes.  I'm trying to use the bytes and convert it but with no luck so far.

Does anyone have any knowledge with respect to this field or how to process 
this type of field?




thanks,

Craig Benner





-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: LdapConnectionPool.getConnection doing extraneous search?

[Emmanuel Lécharny]

On 23/03/2021 14:24, Shawn McKinney wrote:




On Mar 23, 2021, at 3:00 AM, Emmanuel Lécharny  wrote:


On 22/03/2021 19:41, Shawn McKinney wrote:

On Mar 22, 2021, at 11:05 AM, Emmanuel Lécharny  wrote:

LDAP connections are quite stable. Again, this check is there to respect the 
commons-pool API contract. If the connection is dead, then doing this check 
will let the pool fetching another connection, which is good. OTOH, if you 
don't want to check connections while fetching one, then you are on your own 
(ie, deal with the consequences of a bad connection).

Again, I must disagree.  Connections aren’t stable, subjected to env conditions 
and we can never assume a connection is good.


You *can* assume it's good, and react exceptionally if it's not. That the 
fastest way to deal with potential bad connections, if you want to avoid a 
check every time you pull a connection from the pool. (but see later for 
another option)


There are 150 locations in fortress core where an ldap connection is being 
pulled from the pool. No way I want to revisit all of that code.



Something in the API chain must do the job of testing and reconnect, every time 
it’s pulled from the pool.

This is exactly what the testOnBorrow does ;-) But it's costly... (see later 
for another option)


Now, having said that, that’s exactly what I’m observing currently, with the 
test on borrow flag turned off.
Let me explain the scenario:
1. Start server
2. Start client
This initializes a connection pool which creates and stores exactly 1 
connection (min 1, max1 )
3. Set breakpoint in client on pool.getConnection method
4. Restart the server.
5. Client performs ldap op which triggers the breakpoint on getConnection
6. Server at this point still hasn’t any connections with the client.  The 
client ‘thinks’ it has connections in the pool, but these were broken on step 4.
7. Step over the getConnection which then triggers the commons pool to execute:
```
GenericObjectPool._factory.activateObject(latch.getPair().value)
```
8. A connection is made with the server, along with bind
```
6058e163 conn=1000 fd=14 ACCEPT from IP=127.0.0.1:35246 (IP=127.0.0.1:389)
  [exec] 6058e163 conn=1000 op=0 BIND dn="cn=manager,dc=example,dc=com" 
method=128
  [exec] 6058e163 conn=1000 op=0 BIND dn="cn=manager,dc=example,dc=com" 
mech=SIMPLE ssf=0
  [exec] 6058e163 conn=1000 op=0 RESULT tag=97 err=0 duration=1.667ms
```
9. Client continues with its ldap op successfully and is never the wiser that 
the connections were all forcibly closed on server restart.
This is EXACTLY what I want to see all of which is done without the test on 
borrow eliminating the extraneous search on every connection retrieval.


So that would mean we have some kind of 'retry' on connection operation: if it 
fails, then let's assume the connection is broken, and redo it with a fresh 
connection.



Yes, that’s what’s happening.
In the Commons pool lib, this is the block that gets executed:

``` this._factory.activateObject(latch.getPair().value);
if (this._testOnBorrow && 
!this._factory.validateObject(latch.getPair().value)) {
throw new Exception("ValidateObject failed");
}
```

In the first line above, activateObject, this code gets called, from our 
AbstractPoolableLdapConnectionFactory class:

```
public void activateObject(LdapConnection connection) throws LdapException {
   LOG.debug("Activating {}", connection);
   if (!connection.isConnected() ||
   !connection.isAuthenticated()) {
 LOG.debug("rebind due to connection dropped on {}", connection);
 this.connectionFactory.bindConnection(connection);
}
```

The code performs a rebind which renews the connection.

All of this with testOnBorrow being false!



The second bind is pretty brutal, as it will create a brand new connection.



So, I’m still scratching my head figuring why we need this secondary level that 
is wasting a round trip to the server.


Well oh well, not sure we need it at all, considering the piece of code 
you exhumated ;-)






The problem is that the pool is passive: it does not react to any connection 
event, like a connection closure. OTOH, when a connection is properly closed by 
the server (ie an NoticeOfDisconnect - aka NoD - is generated by the server), 
the connection should process it and die. Now we have an issue: the connection 
is just lying in the pool, not being used by any client, so there is a missing 
step: removing the connection from the pool in this very case. That can be 
something we can add to the current LDAP pool.

Note that if the server does not send a NoD, you are screwed. There is no way 
to be sure that the connection is ok until you use it. OTOH, leveraging the 
setTestWhileIdle() could be a solution to partially workaround the issue.


Here you’ve lost me.  I’m running the server in debug mode, inside a bash 
shell, running in the foreground.

In my test I 

Re: LdapConnectionPool.getConnection doing extraneous search?

[Emmanuel Lécharny]

On 22/03/2021 19:41, Shawn McKinney wrote:



On Mar 22, 2021, at 11:05 AM, Emmanuel Lécharny  wrote:

LDAP connections are quite stable. Again, this check is there to respect the 
commons-pool API contract. If the connection is dead, then doing this check 
will let the pool fetching another connection, which is good. OTOH, if you 
don't want to check connections while fetching one, then you are on your own 
(ie, deal with the consequences of a bad connection).


Again, I must disagree.  Connections aren’t stable, subjected to env conditions and we can never assume a connection is good. 


You *can* assume it's good, and react exceptionally if it's not. That 
the fastest way to deal with potential bad connections, if you want to 
avoid a check every time you pull a connection from the pool. (but see 
later for another option)



 Something in the API chain must do the job of testing and reconnect, 
every time it’s pulled from the pool.


This is exactly what the testOnBorrow does ;-) But it's costly... (see 
later for another option)




Now, having said that, that’s exactly what I’m observing currently, with the 
test on borrow flag turned off.

Let me explain the scenario:

1. Start server
2. Start client

This initializes a connection pool which creates and stores exactly 1 
connection (min 1, max1 )

3. Set breakpoint in client on pool.getConnection method

4. Restart the server.

5. Client performs ldap op which triggers the breakpoint on getConnection

6. Server at this point still hasn’t any connections with the client.  The 
client ‘thinks’ it has connections in the pool, but these were broken on step 4.

7. Step over the getConnection which then triggers the commons pool to execute:

```
GenericObjectPool._factory.activateObject(latch.getPair().value)
```

8. A connection is made with the server, along with bind

```
6058e163 conn=1000 fd=14 ACCEPT from IP=127.0.0.1:35246 (IP=127.0.0.1:389)
  [exec] 6058e163 conn=1000 op=0 BIND dn="cn=manager,dc=example,dc=com" 
method=128
  [exec] 6058e163 conn=1000 op=0 BIND dn="cn=manager,dc=example,dc=com" 
mech=SIMPLE ssf=0
  [exec] 6058e163 conn=1000 op=0 RESULT tag=97 err=0 duration=1.667ms
```

9. Client continues with its ldap op successfully and is never the wiser that 
the connections were all forcibly closed on server restart.

This is EXACTLY what I want to see all of which is done without the test on 
borrow eliminating the extraneous search on every connection retrieval.


So that would mean we have some kind of 'retry' on connection operation: 
if it fails, then let's assume the connection is broken, and redo it 
with a fresh connection.


The problem is that the pool is passive: it does not react to any 
connection event, like a connection closure. OTOH, when a connection is 
properly closed by the server (ie an NoticeOfDisconnect - aka NoD - is 
generated by the server), the connection should process it and die. Now 
we have an issue: the connection is just lying in the pool, not being 
used by any client, so there is a missing step: removing the connection 
from the pool in this very case. That can be something we can add to the 
current LDAP pool.


Note that if the server does not send a NoD, you are screwed. There is 
no way to be sure that the connection is ok until you use it. OTOH, 
leveraging the setTestWhileIdle() could be a solution to partially 
workaround the issue.





-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org



-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: LdapConnectionPool.getConnection doing extraneous search?

[Emmanuel Lécharny]

On 22/03/2021 16:45, Shawn McKinney wrote:



On Mar 22, 2021, at 10:43 AM, Shawn McKinney  wrote:



The risk not doing such a check is very very tenuous.




Sorry, but asking for a clarification here.  Do you mean, not doing the check 
is risky?  Or, is OK.


LDAP connections are quite stable. Again, this check is there to respect 
the commons-pool API contract. If the connection is dead, then doing 
this check will let the pool fetching another connection, which is good. 
OTOH, if you don't want to check connections while fetching one, then 
you are on your own (ie, deal with the consequences of a bad connection).


Usually, under heavy charged systems, it's better not to check 
connections, except on exceptional conditions:

* if the connection works, well, you are good to go
* if it fails, it's time to activate contingency plans (here, try to 
borrow another connection from the pool)


You are very much likely to fell in the first situation.

-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: LdapConnectionPool.getConnection doing extraneous search?

[Emmanuel Lécharny]

On 21/03/2021 13:43, Shawn McKinney wrote:



On Mar 20, 2021, at 10:40 PM, Emmanuel Lécharny  wrote:

I guess that the very first time we create the connection, when asking for one 
from a pool, we test it beforehandd, and this is done with the less costly 
operation: a dummy search.

This is due to commons-pool logic where you can ask the pool to validate the 
connection one way or the other. We are probably using 
LookupLdapConnectionValidator for that purpose:


Hi Emmanuel,

It’s actually sending that dummy search every time, which of course isn’t good. 
 Here’s the code to create the pool:

```
// Create the Admin pool
adminPool = new LdapConnectionPool( poolFactory );
adminPool.setTestOnBorrow( true );
adminPool.setWhenExhaustedAction( GenericObjectPool.WHEN_EXHAUSTED_GROW );
adminPool.setMaxActive( max );
adminPool.setMinIdle( min );
adminPool.setMaxIdle( -1 );
adminPool.setTestWhileIdle( testWhileIdle );
adminPool.setTimeBetweenEvictionRunsMillis( timeBetweenEvictionRunMillis );
```

Notice that ‘setTestOnBorrow' being set to true.


Yes, I forgot to mention it. This is configurable.




When I flip that switch, the dummy search no longer occurs when connection is 
retrieved, which is `good.

Wonder what we lose.  Recovery from connections being timed out by server or 
reset by intermediaries like routers?


Not that much. The gain is not enormous either, just  a round trip. The 
LDAP server is not under heavy strain with such a request, it's an 
automatic answer. This is what you would use for a Health Check.


The risk not doing such a check is very very tenuous.

However, we have implemented it as commons-pool requires it to be 
implemented. The question would be to know if we should make it a default.


-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: LdapConnectionPool.getConnection doing extraneous search?

[Emmanuel Lécharny]

Hi Shawn,

I guess that the very first time we create the connection, when asking 
for one from a pool, we test it beforehandd, and this is done with the 
less costly operation: a dummy search.


This is due to commons-pool logic where you can ask the pool to validate 
the connection one way or the other. We are probably using 
LookupLdapConnectionValidator for that purpose:


public boolean validate( LdapConnection connection )
{
try
{
return connection.isConnected()
&& connection.isAuthenticated()
&& ( connection.lookup( Dn.ROOT_DSE,  << The dummy 
lookup

SchemaConstants.NO_ATTRIBUTE ) != null );
}
catch ( LdapException e )
{
return false;
}
}

whih get called from the public abstract class 
AbstractPoolableLdapConnectionFactory implements 
PooledObjectFactory

  class

with this method :



/**
 * {@inheritDoc}
 *
 * Validating a connection is done by checking the connection status.
 */
@Override
public boolean validateObject( PooledObject 
connection )

{
if ( LOG.isDebugEnabled() )
{
LOG.debug( I18n.msg( I18n.MSG_04152_VALIDATING, connection ) );
}

return validator.validate( connection.getObject() );
}

On 20/03/2021 22:57, Shawn McKinney wrote:

Hello,

I’m using LDAP API v1.0.3 inside fortress.

My question is when retrieving connections from the pool using this:

```
public LdapConnection getConnection()

Gives a LdapConnection fetched from the pool.

Returns:
 an LdapConnection object from pool
```

I noticed in the OpenLDAP logs (filter and stats enabled) an extra search comes 
through during this invocation:

Begin slapd log trace:

```
[exec] 60566cd5 begin get_filter
[exec] 60566cd5 PRESENT
[exec] 60566cd5 end get_filter 0
[exec] 60566cd5 conn=1010 op=5 SRCH base="" scope=0 deref=3 
filter="(objectClass=*)"
[exec] 60566cd5 conn=1010 op=5 SRCH attr=1.1
[exec] 60566cd5 => test_filter
[exec] 60566cd5 PRESENT
[exec] 60566cd5 <= test_filter 6
[exec] 60566cd5 conn=1010 op=5 SEARCH RESULT tag=101 err=0 duration=0.236ms 
nentries=1 text=
```

It’s performing a null base search with objectClass=* asking for attr ‘1.1'.

What’s going on here?  I expect to see a bind on that connection (the first 
time) but not a search.


Thanks,

—
Shawn
-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org



-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: Need some help with 2.0.1 LDAP API

[Emmanuel Lécharny]

Hi !

On 13/01/2021 11:09, Hrushikesh Agrawal wrote:

Hello Experts,

We are using the Apache LDAP API 1.0.3 with our product to communicate with
different LDAP servers. We are upgrading the LDAP API jars from 1.0.3 to
2.0.1.
We found that few classes like AdDirSyncImpl and AdDirSyncDecorator are
missing in the latest JAR 2.0.1. These classes must be moved with different
names or the purpose of these classes must be incorporated in another class.
We are using these classes to find th cookies like below  -








*if(cursor.isDone()){ SearchResultDone searchResultDone =
cursor.getSearchResultDone(); Control control =
searchResultDone.getControl(AdDirSyncImpl.OID);  if (control
instanceof AdDirSyncDecorator){AdDirSyncDecorator
adDirSyncDecorator = (AdDirSyncDecorator)control;cookie =
adDirSyncDecorator.getCookie();   } }*

Could you please help us on this to figure out the exact classes or way to
implement this at our end.


We have rewritten those classes, you now have to use the following 
classes and interfaces :



AdDirSyncRequestImpl and AdDirSyncRequest

AdDirSyncResponseImpl and AdDirSyncResponse


They are in the org.apache.directory.api.ldap.extras.controls.ad package.


Getting the OID is just a matter of calling AdDirSyncRequest.OID,

The request control can be created with new AdDirSyncRequestImpl(), then 
you have methods to set the cookie, and other parameters (see 
https://nightlies.apache.org/directory/api/2.0.1/apidocs/org/apache/directory/api/ldap/extras/controls/ad/AdDirSyncRequestImpl.html)



The response control can be get from the response and casted to a 
AdDirSyncResponse, then you can fetch the content with specific method 
like getCookie() (see 
https://nightlies.apache.org/directory/api/2.0.1/apidocs/)



Hope it helps.



-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: NPE doing schema-aware AD searches in LDAP API 2.0

[Emmanuel Lécharny]

FTR, it ended to be a client trying to fetch the schema from an Active 
Directory.



The LDAP API can't do that at the moment, it would require some specific 
implementation.



On 11/02/2020 23:09, Emmanuel Lécharny wrote:


On 11/02/2020 22:50, Lucas Raab wrote:

On Tue, Feb 11, 2020, at 07:41, Emmanuel Lécharny wrote:

Hi

On 11/02/2020 11:55, Lucas Raab wrote:

On Tue, Feb 11, 2020, at 02:42, Emmanuel Lécharny wrote:

Hi

On 11/02/2020 01:17, Lucas Raab wrote:

On Mon, Feb 10, 2020, at 17:37, Emmanuel Lécharny wrote:

Hi !


     Can you provide the stack trace, and the entry you are 
trying to read ?


I'm interested to know on which attribute it fails.


Thanks !

On 10/02/2020 22:36, Lucas Raab wrote:

This time with attachments :)

On Mon, Feb 10, 2020 at 03:32:36PM -0600, Lucas Raab wrote:

Hello,

I'm getting NPE's while attempting to read from a fresh AD 
install with
a 2012R2 level domain. If I don't load the schema (relaxed or 
strict),
the search runs normally. if I do load the schema, then the 
search
throws the NPE. No error is thrown when I attempted similar 
searches

against an OpenDJ 6.5 server.

It appears to come from attempting to determine if an 
LdapSyntax from
an AttributeType is human readable or not. The LdapSyntax 
object looks
to be null, but is visible when dumping the AttributeType. I'm 
not
entirely sure where the schema-aware attribute loading is 
happening to

try and fix it myself so here I am :)

Attached is a log and sample source file. I can provide 
credentials in

a private mail for any debugging.

Thanks,
Lucas

- 


To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org
- 


To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org



Hm, the log I attached seems to have been dropped...

Here's the stack trace and let me know if you need/want more

2020-02-10 15:16:24,027 DEBUG - Attribute: cn: Test Bind
2020-02-10 15:16:24,027 DEBUG - Attribute: cn: Test Bind
2020-02-10 15:16:24,027 WARN  -
java.lang.NullPointerException
 at 
org.apache.directory.api.ldap.model.entry.DefaultAttribute.(DefaultAttribute.java:424)
 at 
org.apache.directory.api.ldap.model.entry.DefaultEntry.(DefaultEntry.java:324)

Hmmm, it seems to be older revision than the last one.
DefaultAttribute.java:424 refers to a comment in the 2.0 revision.


Can you check which LDAP API revision you are using ?

Thanks !



-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org



Hi Emmanuel,

I'm using LDAP API 2.0.0 retrieved via Maven if that matters.


Can you check the ldap-model-api.jar MANIFEST.MF file ? I'd like to 
know

about the version in it.

Thanks !



-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org



Looks to be 2.0.0?

Attached is what I pulled out of .m2`


The attachement didn't made it :/

Can you use https://send.firefox.com/ and send me the link (elecharny 
at apache.org).



Thanks !




-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org


-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: NPE doing schema-aware AD searches in LDAP API 2.0

[Emmanuel Lécharny]

On 11/02/2020 22:50, Lucas Raab wrote:

On Tue, Feb 11, 2020, at 07:41, Emmanuel Lécharny wrote:

Hi

On 11/02/2020 11:55, Lucas Raab wrote:

On Tue, Feb 11, 2020, at 02:42, Emmanuel Lécharny wrote:

Hi

On 11/02/2020 01:17, Lucas Raab wrote:

On Mon, Feb 10, 2020, at 17:37, Emmanuel Lécharny wrote:

Hi !


 Can you provide the stack trace, and the entry you are trying to read ?

I'm interested to know on which attribute it fails.


Thanks !

On 10/02/2020 22:36, Lucas Raab wrote:

This time with attachments :)

On Mon, Feb 10, 2020 at 03:32:36PM -0600, Lucas Raab wrote:

Hello,

I'm getting NPE's while attempting to read from a fresh AD install with
a 2012R2 level domain. If I don't load the schema (relaxed or strict),
the search runs normally. if I do load the schema, then the search
throws the NPE. No error is thrown when I attempted similar searches
against an OpenDJ 6.5 server.

It appears to come from attempting to determine if an LdapSyntax from
an AttributeType is human readable or not. The LdapSyntax object looks
to be null, but is visible when dumping the AttributeType. I'm not
entirely sure where the schema-aware attribute loading is happening to
try and fix it myself so here I am :)

Attached is a log and sample source file. I can provide credentials in
a private mail for any debugging.

Thanks,
Lucas

-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org



Hm, the log I attached seems to have been dropped...

Here's the stack trace and let me know if you need/want more

2020-02-10 15:16:24,027 DEBUG - Attribute: cn: Test Bind
2020-02-10 15:16:24,027 DEBUG - Attribute: cn: Test Bind
2020-02-10 15:16:24,027 WARN  -
java.lang.NullPointerException
 at 
org.apache.directory.api.ldap.model.entry.DefaultAttribute.(DefaultAttribute.java:424)
 at 
org.apache.directory.api.ldap.model.entry.DefaultEntry.(DefaultEntry.java:324)

Hmmm, it seems to be older revision than the last one.
DefaultAttribute.java:424 refers to a comment in the 2.0 revision.


Can you check which LDAP API revision you are using ?

Thanks !



-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org



Hi Emmanuel,

I'm using LDAP API 2.0.0 retrieved via Maven if that matters.


Can you check the ldap-model-api.jar MANIFEST.MF file ? I'd like to know
about the version in it.

Thanks !



-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org



Looks to be 2.0.0?

Attached is what I pulled out of .m2`


The attachement didn't made it :/

Can you use https://send.firefox.com/ and send me the link (elecharny at 
apache.org).



Thanks !




-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org


-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: NPE doing schema-aware AD searches in LDAP API 2.0

[Emmanuel Lécharny]

Hi

On 11/02/2020 11:55, Lucas Raab wrote:

On Tue, Feb 11, 2020, at 02:42, Emmanuel Lécharny wrote:

Hi

On 11/02/2020 01:17, Lucas Raab wrote:

On Mon, Feb 10, 2020, at 17:37, Emmanuel Lécharny wrote:

Hi !


    Can you provide the stack trace, and the entry you are trying to read ?

I'm interested to know on which attribute it fails.


Thanks !

On 10/02/2020 22:36, Lucas Raab wrote:

This time with attachments :)

On Mon, Feb 10, 2020 at 03:32:36PM -0600, Lucas Raab wrote:

Hello,

I'm getting NPE's while attempting to read from a fresh AD install with
a 2012R2 level domain. If I don't load the schema (relaxed or strict),
the search runs normally. if I do load the schema, then the search
throws the NPE. No error is thrown when I attempted similar searches
against an OpenDJ 6.5 server.

It appears to come from attempting to determine if an LdapSyntax from
an AttributeType is human readable or not. The LdapSyntax object looks
to be null, but is visible when dumping the AttributeType. I'm not
entirely sure where the schema-aware attribute loading is happening to
try and fix it myself so here I am :)

Attached is a log and sample source file. I can provide credentials in
a private mail for any debugging.

Thanks,
Lucas

-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org



Hm, the log I attached seems to have been dropped...

Here's the stack trace and let me know if you need/want more

2020-02-10 15:16:24,027 DEBUG - Attribute: cn: Test Bind
2020-02-10 15:16:24,027 DEBUG - Attribute: cn: Test Bind
2020-02-10 15:16:24,027 WARN  -
java.lang.NullPointerException
at 
org.apache.directory.api.ldap.model.entry.DefaultAttribute.(DefaultAttribute.java:424)
at 
org.apache.directory.api.ldap.model.entry.DefaultEntry.(DefaultEntry.java:324)


Hmmm, it seems to be older revision than the last one.
DefaultAttribute.java:424 refers to a comment in the 2.0 revision.


Can you check which LDAP API revision you are using ?

Thanks !



-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org



Hi Emmanuel,

I'm using LDAP API 2.0.0 retrieved via Maven if that matters.



Can you check the ldap-model-api.jar MANIFEST.MF file ? I'd like to know 
about the version in it.


Thanks !



-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: NPE doing schema-aware AD searches in LDAP API 2.0

[Emmanuel Lécharny]

Hi

On 11/02/2020 01:17, Lucas Raab wrote:

On Mon, Feb 10, 2020, at 17:37, Emmanuel Lécharny wrote:

Hi !


   Can you provide the stack trace, and the entry you are trying to read ?

I'm interested to know on which attribute it fails.


Thanks !

On 10/02/2020 22:36, Lucas Raab wrote:

This time with attachments :)

On Mon, Feb 10, 2020 at 03:32:36PM -0600, Lucas Raab wrote:

Hello,

I'm getting NPE's while attempting to read from a fresh AD install with
a 2012R2 level domain. If I don't load the schema (relaxed or strict),
the search runs normally. if I do load the schema, then the search
throws the NPE. No error is thrown when I attempted similar searches
against an OpenDJ 6.5 server.

It appears to come from attempting to determine if an LdapSyntax from
an AttributeType is human readable or not. The LdapSyntax object looks
to be null, but is visible when dumping the AttributeType. I'm not
entirely sure where the schema-aware attribute loading is happening to
try and fix it myself so here I am :)

Attached is a log and sample source file. I can provide credentials in
a private mail for any debugging.

Thanks,
Lucas

-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org



Hm, the log I attached seems to have been dropped...

Here's the stack trace and let me know if you need/want more

2020-02-10 15:16:24,027 DEBUG - Attribute: cn: Test Bind
2020-02-10 15:16:24,027 DEBUG - Attribute: cn: Test Bind
2020-02-10 15:16:24,027 WARN  -
java.lang.NullPointerException
   at 
org.apache.directory.api.ldap.model.entry.DefaultAttribute.(DefaultAttribute.java:424)
   at 
org.apache.directory.api.ldap.model.entry.DefaultEntry.(DefaultEntry.java:324)



Hmmm, it seems to be older revision than the last one. 
DefaultAttribute.java:424 refers to a comment in the 2.0 revision.



Can you check which LDAP API revision you are using ?

Thanks !



-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: NPE doing schema-aware AD searches in LDAP API 2.0

[Emmanuel Lécharny]

Hi !


 Can you provide the stack trace, and the entry you are trying to read ?

I'm interested to know on which attribute it fails.


Thanks !

On 10/02/2020 22:36, Lucas Raab wrote:

This time with attachments :)

On Mon, Feb 10, 2020 at 03:32:36PM -0600, Lucas Raab wrote:

Hello,

I'm getting NPE's while attempting to read from a fresh AD install with
a 2012R2 level domain. If I don't load the schema (relaxed or strict),
the search runs normally. if I do load the schema, then the search
throws the NPE. No error is thrown when I attempted similar searches
against an OpenDJ 6.5 server.

It appears to come from attempting to determine if an LdapSyntax from
an AttributeType is human readable or not. The LdapSyntax object looks
to be null, but is visible when dumping the AttributeType. I'm not
entirely sure where the schema-aware attribute loading is happening to
try and fix it myself so here I am :)

Attached is a log and sample source file. I can provide credentials in
a private mail for any debugging.

Thanks,
Lucas

-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org


-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: Is it time to release apacheds-test-framework

[Emmanuel Lécharny]

Hi Maxim,

I'll be in vacation around december 18th, so I may have some time to 
commit the changes I have once the tests will be green. So, yes, end of 
this year is an option.


I'm sorry for those delays, having a new day job since August was quite 
taxing my free time, I was just able to get the LDAP API 2.0 released, 
plus some extra work on Mavibot...



On 29/11/2019 06:55, Maxim Solodovnik wrote:

Hello Emmanuel,

Are there any chances apacheds-test-framework can be released this year?

On Thu, 17 Oct 2019 at 11:24, Maxim Solodovnik <mailto:solomax...@gmail.com>> wrote:


Can the API be released with `apacheds-test-framework`?
Otherwise all tests will be broken :(

On Wed, 16 Oct 2019 at 02:28, Emmanuel Lécharny
mailto:elecha...@gmail.com>> wrote:

Hi guys !

On 15/10/2019 18:50, Stefan Seelmann wrote:
> Let's discuss what's missing to get the next LDAP API and
Server release
> out, I should have some free time to help.

Regarding LDAP API, I really think we are good to go.


The server is another story. There are a few things that need
to be
addressed :

- Password Policy tests that need some improvements, plus a
bunch of fixes

- Mac OSX packaging is not working anymore, because the tool
we used
does not exist anymore on the latest versions.

- There are also a few annoying issues that need to be addressed.


If nobody objects, we can probably cut the LDAP API release
right away.


>
> Kind Regards,
> stefan
>
> On 10/15/19 5:15 PM, Richard Sand wrote:
>> I second the motion! Can't use the latest API because now
the embedded
>> DS tests fail.
>>
>> -Richard
>>
>>
>> -- Original Message --
>> From: "Maxim Solodovnik" mailto:solomax...@gmail.com>>
>> To: "Emmanuel Lécharny" mailto:elecha...@gmail.com>>
>> Cc: api@directory.apache.org <mailto:api@directory.apache.org>
>> Sent: 10/15/2019 11:06:39 AM
>> Subject: Re: Is it time to release apacheds-test-framework
>>
>>> Hello Emmanuel,
>>>
>>> Are there any plans for release? :))
>>>
>>> On Thu, 5 Sep 2019 at 15:58, Maxim Solodovnik
mailto:solomax...@gmail.com>>
>>> wrote:
>>>
>>>>   Thanks for the update :)
    >>>>
>>>>   last release was about a year ago :(
>>>>
>>>>
https://en.wikipedia.org/wiki/Release_early,_release_often :
>>>>
>>>>   On Thu, 5 Sep 2019 at 15:54, Emmanuel Lécharny
mailto:elecha...@gmail.com>>
>>>>   wrote:
>>>>
>>>>>   Hi Maxim !
>>>>>
>>>>>   Sadly, august was very unproductive :/
>>>>>
>>>>>
>>>>>   I do think that we may force a release no matter what,
even if we have
>>>>>   some features we would like to add into the package,
by just
>>>>> post-poning
>>>>>   those features to a new release.
>>>>>
>>>>>   I'll have a thought about this option this week-end.
>>>>>
>>>>>   On 05/09/2019 10:36, Maxim Solodovnik wrote:
>>>>>   > Hello Emmanuel,
>>>>>   >
>>>>>   > Any plans on this release?
>>>>>   >
>>>>>   > On Tue, 16 Jul 2019 at 13:54, Emmanuel Lécharny
mailto:elecha...@gmail.com>
>>>>>   > <mailto:elecha...@gmail.com
<mailto:elecha...@gmail.com>>> wrote:
>>>>>   >
>>>>>   > Hi Maxim,
>>>>>   >
>>>>>   >
>>>>>   > we have to deal with some changes in the Mac OSX
packaging. This
>>>>>   > is the
>>>>>   > one last show stopper atm.
>>>>>   >
>>>>>   > On 16/07/2019 08:25, Maxim Solodovnik wrote:
>>>>>   > > Hello All,
>>>>>   > >
>>>>>   > > Are there any ETA for
`apacheds-t

Re: ERR_03039 : the given requestID is not an integer

[Emmanuel Lécharny]

Hi Malo

On 29/11/2019 11:16, Malo Toudic wrote:

Hi all,

Is there any reason why the requestID need to be an integer in a 
batchRequest ? When using a string the following error is returned :


"ERR_03039 the given requestID is not an integer"



The requestID has to be an integer, but inside a string, like "12345".

The error you're getting is due to some bad string, like "12AGH", for 
instance.



The code that produces this error :

    /**
 * Parses and verify the parsed value of the requestID
 *
 * @param attributeValue the value of the attribute
 * @param xpp the XmlPullParser
 * @return the int value of the resquestID
 * @throws XmlPullParserException if RequestID isn't an Integer and 
if requestID is below 0

 */
    public static int parseAndVerifyRequestID( String attributeValue, 
XmlPullParser xpp ) throws XmlPullParserException

    {
    try
    {
    int requestID = Integer.parseInt( attributeValue );

    if ( requestID < 0 )
    {
    throw new XmlPullParserException( I18n.err( 
I18n.ERR_03038, requestID ), xpp, null );

    }

    return requestID;
    }
    catch ( NumberFormatException nfe )
    {
    throw new XmlPullParserException( I18n.err( I18n.ERR_03039 
), xpp, nfe );

    }
    }

As you can see, we expect a string containing an integer.

You have to check the content of your DSML request.



I'm using org.apache.directory.api:api-all:1.0.0 from Maven. I also 
verified the source code of the last version of api-all and the method 
verifying the requestID format is the same.



FTR, the 1.0.3 version is out since april, and it contains many fixes 
since 1.0.0, which is 2 years old already...




-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: Is it time to release apacheds-test-framework

[Emmanuel Lécharny]

Hi guys !

On 15/10/2019 18:50, Stefan Seelmann wrote:

Let's discuss what's missing to get the next LDAP API and Server release
out, I should have some free time to help.


Regarding LDAP API, I really think we are good to go.


The server is another story. There are a few things that need to be 
addressed :


- Password Policy tests that need some improvements, plus a bunch of fixes

- Mac OSX packaging is not working anymore, because the tool we used 
does not exist anymore on the latest versions.


- There are also a few annoying issues that need to be addressed.


If nobody objects, we can probably cut the LDAP API release right away.




Kind Regards,
stefan

On 10/15/19 5:15 PM, Richard Sand wrote:

I second the motion! Can't use the latest API because now the embedded
DS tests fail.

-Richard


-- Original Message --
From: "Maxim Solodovnik" 
To: "Emmanuel Lécharny" 
Cc: api@directory.apache.org
Sent: 10/15/2019 11:06:39 AM
Subject: Re: Is it time to release apacheds-test-framework


Hello Emmanuel,

Are there any plans for release? :))

On Thu, 5 Sep 2019 at 15:58, Maxim Solodovnik 
wrote:


  Thanks for the update :)

  last release was about a year ago :(

https://en.wikipedia.org/wiki/Release_early,_release_often :

  On Thu, 5 Sep 2019 at 15:54, Emmanuel Lécharny 
  wrote:


  Hi Maxim !

  Sadly, august was very unproductive :/


  I do think that we may force a release no matter what, even if we have
  some features we would like to add into the package, by just
post-poning
  those features to a new release.

  I'll have a thought about this option this week-end.

  On 05/09/2019 10:36, Maxim Solodovnik wrote:
  > Hello Emmanuel,
  >
  > Any plans on this release?
  >
  > On Tue, 16 Jul 2019 at 13:54, Emmanuel Lécharny  <mailto:elecha...@gmail.com>> wrote:
  >
  > Hi Maxim,
  >
  >
  > we have to deal with some changes in the Mac OSX packaging. This
  > is the
  > one last show stopper atm.
  >
  > On 16/07/2019 08:25, Maxim Solodovnik wrote:
  > > Hello All,
  > >
  > > Are there any ETA for `apacheds-test-framework` release?
  > >
  > > On Tue, 21 May 2019 at 16:49, Maxim Solodovnik
  > mailto:solomax...@gmail.com>> wrote:
  > >> Hello,
  > >>
  > >> directory API 2.0.0.AM3 has been released and introduce an
API
  > break: method Value.getValue() has been replaced with
getString()
  > >>
  > >> Could you please release apacheds-test-framework ?
  > >> Right now I'm getting "No such method error" during test
  > execution :(
  > >>
  > >> --
  > >> WBR
  > >> Maxim aka solomax
  > >
  > >
  >
  >
   -
  > To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
  > <mailto:api-unsubscr...@directory.apache.org>
  > For additional commands, e-mail: api-h...@directory.apache.org
  > <mailto:api-h...@directory.apache.org>
  >
  >
  >
  > --
  > WBR
  > Maxim aka solomax



  --
  WBR
  Maxim aka solomax



--
WBR
Maxim aka solomax


-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org



-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org



-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: Is it time to release apacheds-test-framework

[Emmanuel Lécharny]

Hi Maxim !

Sadly, august was very unproductive :/


I do think that we may force a release no matter what, even if we have 
some features we would like to add into the package, by just post-poning 
those features to a new release.


I'll have a thought about this option this week-end.

On 05/09/2019 10:36, Maxim Solodovnik wrote:

Hello Emmanuel,

Any plans on this release?

On Tue, 16 Jul 2019 at 13:54, Emmanuel Lécharny <mailto:elecha...@gmail.com>> wrote:


Hi Maxim,


we have to deal with some changes in the Mac OSX packaging. This
is the
one last show stopper atm.

On 16/07/2019 08:25, Maxim Solodovnik wrote:
> Hello All,
>
> Are there any ETA for `apacheds-test-framework` release?
>
> On Tue, 21 May 2019 at 16:49, Maxim Solodovnik
mailto:solomax...@gmail.com>> wrote:
>> Hello,
>>
>> directory API 2.0.0.AM3 has been released and introduce an API
break: method Value.getValue() has been replaced with getString()
>>
>> Could you please release apacheds-test-framework ?
>> Right now I'm getting "No such method error" during test
execution :(
>>
>> --
>> WBR
>> Maxim aka solomax
>
>

-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
<mailto:api-unsubscr...@directory.apache.org>
For additional commands, e-mail: api-h...@directory.apache.org
<mailto:api-h...@directory.apache.org>



--
WBR
Maxim aka solomax


-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: Can't paginate with OpenLDAP

[Emmanuel Lécharny]

Hi,

On 27/08/2019 16:19, Jeremy Sweetman wrote:

Hi,

I've successfully used the Apache Directory API to load in paged user data from 
Active Directory. It's similar to the example code by 'oers' found in this 
stackoverflow question: 
https://stackoverflow.com/questions/17963975/apache-directory-ldap-paged-searches

Some differences I have are:
*   I'm coding it with Nashorn (Javascript running in Java)
*   I'm using the PagedResultsImpl class instead of PagedResultsDecorator
*   I'm saving the cookie as a string between calls by using a Base64 encoding 
of the byte[] cookie.
*   I'm using Apache Directory API with the following maven import (The links 
to the version 2 javadoc on the website were broken so I stuck with version 1):
 
 org.apache.directory.api
 api-all
 1.0.3
 

Here's some of the important bits:

var pageCursor = "";  /** or some Base64 encoded byte[] cookie if I'm 
trying to start from where i left off last time. */
...
pagedSearchControl = new PagedResultsImpl();
pagedSearchControl.setSize(pageSize);

pagedSearchControl.setCookie(Base64.getEncoder().encodeToString(pageCursor.getBytes()));


Any reason you encode the empty byte[] ? Just pass Strings.EMPTY_BYTES.



...
var searchRequest = new SearchRequestImpl();
...
searchRequest.addControl(pagedSearchControl);
...
var cursor = new EntryCursorImpl(connection.search(searchRequest));
...
pagingResults = 
cursor.getSearchResultDone().getControl(PagedResults.OID);
if (pagingResults != null){
nextPageCursor = 
Base64.getEncoder().encodeToString(pagingResults.getCookie());



Same thing. Don't encode using Base64.



-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: Is it time to release apacheds-test-framework

[Emmanuel Lécharny]

Hi Maxim,


we have to deal with some changes in the Mac OSX packaging. This is the 
one last show stopper atm.


On 16/07/2019 08:25, Maxim Solodovnik wrote:

Hello All,

Are there any ETA for `apacheds-test-framework` release?

On Tue, 21 May 2019 at 16:49, Maxim Solodovnik  wrote:

Hello,

directory API 2.0.0.AM3 has been released and introduce an API break: method 
Value.getValue() has been replaced with getString()

Could you please release apacheds-test-framework ?
Right now I'm getting "No such method error" during test execution :(

--
WBR
Maxim aka solomax





-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: Directory project big maneuvers...

[Emmanuel Lécharny]

Just FTR,

on my mac, the server-integ tests are taking forever to be completed 
(around 10s per class). It seems it's due to the 
InetAddress.getLocalHost() call done in the CertificateUtil.setInfo() 
method, which now takes around 5 seconds to complete. It's related to 
some change made in the JDK for Mac OSX 
(https://bugs.openjdk.java.net/browse/JDK-8136913 and 
https://bugs.openjdk.java.net/browse/JDK-8080819).


We probably can speed these tests up by changing the way we generate the 
certificate.



On 20/06/2019 17:31, Emmanuel Lécharny wrote:

Hi !


for those who are following what's going on at Directory, and 
especially those trying to extend the project (thinking about Raju), 
we are currently working hard trying to close a LDAP API release, 
ApacheDS release, and Studio release. This comes with a price to pay: 
a bit of instability, a lot of git pull and some associated burden.


The LDAP API project is pretty much in good shape. We had a release a 
couple of weeks ago, and some other changes are under way. We could 
pretty well be able to cut a 2.0.0-RC1 soon.


ApacheDS is in a more complex situation. There are 391 opened issues 
(most of them are already postponed to 2.1: 250 actually). If we focus 
on issues opened for 2.0.0.AM26, we are taking about 30 issues, 121 if 
we include 2.0.0-RC1. This is a loty of work, but we have already 
fixed more or less 30 issues in the last 2 weeks.


Stefan is trying his best to follow up - and is pretty successful in 
that, considering all the pain we create for him ;-) -and Studio is 
also in a good shape.Hopefully, it will be released very soon after 
ApacheDS and LDAP-API will be released.


Fortress migration to 2.0 should not be that problematic.


I expect that in the coming weeks we will be able to have a decent 
ApacheDS release, with fixed installers (this is the main burden atm).


That's it, feel free to add something to what I just wrote, Stefan, 
Colm, Shawn or anyone !



Emmanuel



-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Directory project big maneuvers...

[Emmanuel Lécharny]

Hi !


for those who are following what's going on at Directory, and especially 
those trying to extend the project (thinking about Raju), we are 
currently working hard trying to close a LDAP API release, ApacheDS 
release, and Studio release. This comes with a price to pay: a bit of 
instability, a lot of git pull and some associated burden.


The LDAP API project is pretty much in good shape. We had a release a 
couple of weeks ago, and some other changes are under way. We could 
pretty well be able to cut a 2.0.0-RC1 soon.


ApacheDS is in a more complex situation. There are 391 opened issues 
(most of them are already postponed to 2.1: 250 actually). If we focus 
on issues opened for 2.0.0.AM26, we are taking about 30 issues, 121 if 
we include 2.0.0-RC1. This is a loty of work, but we have already fixed 
more or less 30 issues in the last 2 weeks.


Stefan is trying his best to follow up - and is pretty successful in 
that, considering all the pain we create for him ;-) -and Studio is also 
in a good shape.Hopefully, it will be released very soon after ApacheDS 
and LDAP-API will be released.


Fortress migration to 2.0 should not be that problematic.


I expect that in the coming weeks we will be able to have a decent 
ApacheDS release, with fixed installers (this is the main burden atm).


That's it, feel free to add something to what I just wrote, Stefan, 
Colm, Shawn or anyone !



Emmanuel


-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

LDAP API 2.0.0.AM3 release...

[Emmanuel Lécharny]

Hi !


I tried my best to get all the pending JIRA closed to be able to cut a 
2.0-GA, but it seems there are too many of them pending, and we kind of 
urgently need a release, in order to be able to cut a new release of 
ApacheDS and Studio.



I suggest we cut another milestone (2.0.0.AM3) asap, with whatever has 
been fixed (39 JIRAs so far).



Thoughts ?

Preparing LDAP API 2.0-GA release

[Emmanuel Lécharny]

Hi !


I'm currently reviewing the existing JIRAs in order to prepare the 
release of the 2.0-GA release. There will probably be a couple of fixes, 
but I think we could  postpone most of them. I expect this process to 
take a few days.


Let me know if you have some JIRA you really want to have fixed in this 
release.



Thanks !

Ldap connect() method improvements

[Emmanuel Lécharny]

Hi !

Stefan has committed some changes for the 
LdapNetworkConnection.connect() method. We had some NPE (fixed) and also 
were incapable to tell  what were the root causes of a connection 
failure. Typical reasons were :


o timeout

o SSL/TLS handshake error (with various root causes)


Stefan's commit are fixing those aspects.

Now, the method is 275 lines long, which makes it very difficult to 
maintain. I will move out some parts of it in separate private methods 
to make it clearer.



Thanks !

Re: LDAP API Enhancement Suggestions

[Emmanuel Lécharny]

Hi Nick,


thanks for the suggested improvement !


Sadly, the attached code has been striped of by the spam filter. May I 
suggest you create a JIRA 
(https://issues.apache.org/jira/projects/DIRAPI) and attach the patch 
into it ?



Many thanks !

Re: How to do a sorted search using Apache Directory API

[Emmanuel Lécharny]

On 07/03/2019 10:40, Tamsin Slinn wrote:

Hi,
I hope this is an OK question to post to the list.



That's fine.




I'm running the code below against OpenLDAP 2.4.40. I based the code on an
integration test for SortRequestControl. However, this code does not return
the entries in the order I expect (alphabetical by sn). Can you tell me
what I am missing?
Thanks for any help!

 SearchRequest req = new SearchRequestImpl();
 req.setScope(SearchScope.ONELEVEL);
 req.addAttributes("*");
 req.setTimeLimit(0);
 req.setBase(searchDn);
 req.setFilter("(objectclass=posixAccount)");

 SortRequest sortRequest = new SortRequestControlImpl();
 sortRequest.addSortKey(new SortKey("sn"));
 req.addControl(sortRequest);

try (SearchCursor cursor = connection.search(req)) {
  while (cursor.next()) {
 SearchResultEntry se = (SearchResultEntry) cursor.get();
 Entry entry = se.getEntry();
 System.out.println("sn: " + entry.get("sn").getString());

 }
 }


First, which version of the API are you using ?


Then, can you provide the result you get ?


Last, not least, are you sure your OpenLDAP server has the slapo-sssvlv 
overlay installed ?


If so, can you provide its configuration ?

Re: Toward a 2.0 GA

[Emmanuel Lécharny]

On 17/01/2019 15:14, Shawn McKinney wrote:

On Jan 16, 2019, at 3:54 PM, Emmanuel Lécharny  wrote:

The Server, when started, will try to load the Keystore content:

o If there is no provided KeyStore file, the server will use create its own 
Keystore, based on the default SUN provider.
o Otherwise, the server will try to load the provided KeyStore, using the 
paswword that has to be provided too. There are two parameters used to 
configure the server : ads-keystoreFile that will contain tha path to the 
KeyStore and ads-certificatePassword (which should most certainly be renamed 
ads_keyStorePassword)

Hi Emmanuel,

Thinking out loud here so forgive the naive comment, but shouldn’t the server 
use the a. default Java keystore (if found), or b. what’s passed to it, and 
only if not (a or b) c. create a new?



The server is currently trying to load a keystore that is passed to it 
as a parameter, and if not, it creates an internal keystore that fetches 
the admin user Certificate. There is no such thing as a 'default java 
keystore', unless you mean the one you manage using keytool - but then 
you have to tell the app where this keystore is -. Correct me if I'm wrong.


The rational, when this part of the server was implemented, was to make 
dead simple to have TLS working: wze create the certificate 'on the 
fly', and store it in a keystore that is wrapped around the server 
itself, for the storage. Somehow, it makes sense. There is even an 
extended operation that allows a client to create a certificate 
(CertGenerationRequest).


So passing an existing Keystore is a way to use signed certificates, 
instead of self-signed ones generated by teh server at startup. Funny 
enough, you can also reconfigure the server to use a signed certificate 
without using a keytstore, but it's a 2 steps init :


- first start the server as is

- change the admin certificate/public/private key to replace them with 
the signed one


- restart the server


In any case, I do think we have to have a serious conversation about all 
those aspects which are critically important from a security PoV !!!



FTR, I'm checking the code provided by Daniel Fisher (DIRAPI-72) which 
point to the code that can be used to verify the server name on the 
startTLS extended operation. It's based on the 
sun.security.util.HostnameChecker class.

Re: Toward a 2.0 GA

[Emmanuel Lécharny]

On 11/01/2019 20:03, Stefan Seelmann wrote:

On 1/11/19 11:09 AM, Emmanuel Lécharny wrote:

Hi guys,


I'm currently checking all the pending JIRAs, trying to evaluate those
that need to be closed in the coming release, those that are invalid,
and those that need to be postponed.

While doing that, I see there are quite a few important ones related to
TLS and security checks that probably need to be addressed before we cut
a 2.0 GA (which means the next release with still be a milestone).

Here are the JIRA I'm interested in, ordered accordingly to some release
roadmap (mine ;-) :

To be fixed for the next milestone
--
DIRAPI-69, API does not allow StartTLS hostname verification
DIRAPI-72, Provide a default TrustManager for hostname verification to
comply with RFC 2830 Section 3.6
DIRAPI-298, Inconsistent SASL bind API : add the missing bindGssApi()
method
DIRAPI-299, Unable to change expired password unless logging in as admin.

I promised a mail regarding TLS some while ago but never wrote it. But
that are the points.



Here are some thoughts about Certificate handling in both the server and 
the API:



Server
--

The Server, when started, will try to load the Keystore content:

o If there is no provided KeyStore file, the server will use create its 
own Keystore, based on the default SUN provider.
o Otherwise, the server will try to load the provided KeyStore, using 
the paswword that has to be provided too. There are two parameters used 
to configure the server : ads-keystoreFile that will contain tha path to 
the KeyStore and ads-certificatePassword (which should most certainly be 
renamed ads_keyStorePassword)


NOTE: there is no test in the server that check the use of an external 
keystore


Internal KeyStore
-

To make it simple for the user, the server implements its own KeyStore 
which contains one single KeyPair. The implementation is done through 
the CoreKeyStoreSpi class.



Client
--

Validating the server means we have a copy of the CA locally in a 
KeyStore. We don't have that by default. We have options here :

- don't validate the server certificate (this is the default)
- use a local KeyStore. It's possible, as soon as we set the connection 
config to use a Trustmanager that leverage this keyStore
- we could also use the file containing the CA certificate, leaving the 
plumbing to the API (ie creating a in-memory KeyStore).


I do think we must implement one of the 2 last options - or even both of 
them -. We can reuse what Fortress is using, that would cover the second 
option. This should also be the default when using TLS on the client side.


We should also make it so that the client can be configured to validate 
the server certificate with various options :

- never: don't verify the server certificate
- allow: check the server certificate if it's provided, but don't block 
if it's not verified
- try: check the server certificate if provided, and if so, terminate 
the session if the verification failed
- demand: check the serrver certificate and terminate the session if 
it's not sent or if it's invalid


I guess that would be for a future version.

Another thing that need to be fixwed is a mean to verify the server 
HostName when using the startTLS extended operation. This will take a 
bit of time, I would suggest to do that for 2.0 GA.




Anyway, at this point, I'd like to get the API milestone released, in 
order to be able to release ApacheDS (and probably Studio and Fortress 
too). Just because there are many fixes and improvements in it.



We have a 2.0 GA pending, that should come shortly after, so I think we 
are fine with the milestone.



WDYT ?

Toward a 2.0 GA

[Emmanuel Lécharny]

Hi guys,


I'm currently checking all the pending JIRAs, trying to evaluate those 
that need to be closed in the coming release, those that are invalid, 
and those that need to be postponed.


While doing that, I see there are quite a few important ones related to 
TLS and security checks that probably need to be addressed before we cut 
a 2.0 GA (which means the next release with still be a milestone).


Here are the JIRA I'm interested in, ordered accordingly to some release 
roadmap (mine ;-) :


To be fixed for the next milestone
--
DIRAPI-69, API does not allow StartTLS hostname verification
DIRAPI-72, Provide a default TrustManager for hostname verification to 
comply with RFC 2830 Section 3.6

DIRAPI-298, Inconsistent SASL bind API : add the missing bindGssApi() method
DIRAPI-299, Unable to change expired password unless logging in as admin.



To be fixed for 2.0GA
-
DIRAPI-136, Add the TLS closure alert support in the API
DIRAPI-149, LdapNetworkConnection should not create user-Threads
DIRAPI-202, Can't get LdapConnectionTemplate working
DIRAPI-237, Make the API threadsafe
DIRAPI-299, Unable to change expired password unless logging in as admin.
DIRAPI-300, Weird batchResponse when batchRequest contains grammar error
DIRAPI-320, ClassCastException on Objects.equals(Value,Value) for 
userPassword attribute



Postponed to 3.0

DIRAPI-61, We don't support referral chasing on the API
DIRAPI-73, Creating new schema and injecting schema elements into it
DIRAPI-104, Schema registries are not getting updated after adding a new 
AT to an ObjectClass entry present in the Schema partition

DIRAPI-111, Move some Subentry classes from core-API
DIRAPI-115, LdifEntry should expose methods to manipulate attributes.
DIRAPI-179, Referral Hop Count
DIRAPI-209, Failover configuration for 2 ldap servers: master and slave
DIRAPI-222, Make the LdifReader accept changes *and* entries in the same 
file

DIRAPI-256, We need to implement the SASLPrep RFC (RFC 4013)
DIRAPI-281, Unable to connect LDAP server via proxy
DIRAPI-327, Add stream support to Entry and Attribute


Long term issues

DIRAPI-116, Review the API to have the method trhow meaningful exceptions
DIRAPI-216, Improvements in OSGi tests
DIRAPI-259, Add support for some missing Microsoft AD controls and 
extended operations: will be added on the fly, when needed.


I would add I want to review the way we manage schema elements. We have 
two flavors of AT, OC and MR: a mutable one, and a immutable one. This 
does not make a lot of sense. I'd rather have immutable elements, with a 
factory to create new ones. I still have to investigate the impact of 
such change, it will be covered in a coming mail.



In the mean time, please feel free to comment, give your input about 
this list of JIRA. I'd like to be able to cut the milestone next week, 
if possible.



Many thanks !

Re: ApacheDS

[Emmanuel Lécharny]

Le 11/10/2018 à 17:51, Andres Falla a écrit :
> Good day ApacheDS team.
Hi,

> 
> I have been working with the ApacheDS version 2.0.0.M24 and the performance
> is acceptable with around 5000 records, but when I upgrade to ApacheDS
> version 2.0.0.AM25 with the same memory and cache features, it is quite
> degraded. , giving a latency of up to 10 times more.

Hmmm.

What are the operations you find are slower ? Can you provide a precise
description (with time) on both servers ?

> 
> I have observed that the file system of the partitions has changed to
> improve the integrity of the data, but I would like to know if this affects
> the performance when the data is consulted

Actually, the file system hasn't changed, we just have set up
transaction across B-trees, which means updates are either committed
globally, or rollbacked. In M24 and previous versions, transaction was
B-tree based, which means you may end with some dandling references in
some corner cases.

By all means, as transactions are handled in memory, we found that
additions are currently faster thant it was, search should be as fast
(or slow ;-) as it was before.

I'll be interested to know more !


-- 
Emmanuel Lecharny

Symas.com
directory.apache.org



pEpkey.asc
Description: application/pgp-keys

Re: Using jar with OpenOffice Base

[Emmanuel Lécharny]

Le 10/08/2018 à 09:30, FR web forum a écrit :
> 
>> The thing is that it's a LDAP API, but the applicatio  has to be
>> written
>> to use the API properly. I don't know if OpenOffice has already done
>> that.
> 
> As I said first, I try to use it.
> But I would like to know what is the fully qualified class name.

The FQCN of what ?

I'm sorry, but I need to get a bit more information about what exactly
you are trying to do, and how you do it to help you.

In any

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org



pEpkey.asc
Description: application/pgp-keys

Re: Using jar with OpenOffice Base

[Emmanuel Lécharny]

Le 09/08/2018 à 18:34, FR web forum a écrit :
> I think this jar could be used as LDAP driver.
> So I'm wrong, never mind.

I don't know. Maybe.


The thing is that it's a LDAP API, but the applicatio  has to be written
to use the API properly. I don't know if OpenOffice has already done that.

In any case, it's totally unrelated to JDBC, which is a SQL database API.

At this point, I suggest you contact the OpenOffice mailing list.

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org



pEpkey.asc
Description: application/pgp-keys

Re: Using jar with OpenOffice Base

[Emmanuel Lécharny]

Can you please tell me why ou are trying to connect with a JDBC wizard
when you use a LDAP library ???


Le 09/08/2018 à 17:40, FR web forum a écrit :
> Hello list,
> I installed your ldap.jar into %APPDATA%/OpenOffice 4/program/classes
> Now I try to connect with JDBC in database Wizard.
> I stopped at step 2
> 
> Did you know class name and jdbc connection string to using?
> 

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org



pEpkey.asc
Description: application/pgp-keys

Releasing Apache LDAP API 2.0.0-AM1

[Emmanuel Lécharny]

Hi guys,

I think we are ready for a release of teh LDAP API 2.0.0 first milestone.

Keep in mind that the 'A' in AM1 is just for the sake of keeping OSGi
happy, so that AM1 < GA (lexycographically speaking).

So starting the release process now...

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org



pEpkey.asc
Description: application/pgp-keys

Re: Fast openldap schema parser : completed

[Emmanuel Lécharny]

Le 22/06/2018 à 14:04, Radovan Semancik a écrit :
> Hi,
> 
> Good news. It works with AD! ... Of course, for full schema support
> there is still a need for some ugly hacks on client side, as AD does not
> declare matching rules in the schema. I have just lowered log level of
> "no syntax"  log message in Value, as AD cannot be bothered to even
> declare syntaxes and therefore the log files got filled up quite quickly.
> 
> API almost worked with OpenDJ. Looks like someone missed a space in
> OpenDJ schema (just before EQUALITY):
> 
> ( 1.3.6.1.4.1.42.2.27.5.1.10 NAME 'SolarisProfileType' DESC 'Type of
> object defined in profile'EQUALITY caseIgnoreIA5Match SYNTAX
> 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE X-ORIGIN 'Solaris Specific' )
> 
> ... therefore I have "fixed" the parser to tolerate this (in relaxed mode).
> 
> OpenLDAP was without any problems (as expected).
> 
> My 389ds and eDir test environment is broken right now. I'll test those
> later.


Many thanks, Radovan ! This is very encouraging !

Hopefully, it will do the job, and way faster than with the antlr parser ;-)

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org



pEpkey.asc
Description: application/pgp-keys

Re: Support commons-pool2 for monitoring

[Emmanuel Lécharny]

Le 25/05/2018 à 14:23, Yudhi Karunia Surtan a écrit :
> Hi Guys,
> 
> 
> Is there any plan to using commons-pool2 for ldap api?

We have switched to commons-pool2 2.5.0 on may, 18th (see commit
c895bd2d449be550a71dd512d1fc3e815c07)


-- 
Emmanuel Lecharny

Symas.com
directory.apache.org



pEpkey.asc
Description: application/pgp-keys

Fast openldap schema parser : completed

[Emmanuel Lécharny]

Hi !

I finally committed the new parser. I did my best to have the same API, 
so ou can use it as if it were the previous version, except that it does 
not use AntLR anymore.


The final performance results :

new parser, core schema parsed 100 000 times : 31s
old parser, core schema parsed  10 000 times : 100s

ratio : 32 times faster (it's a bit slower than what I said in my 
previous mails, but I have added various checks that slow down the 
parser - mainly checks on OID validity -.



Radovan, you are free to check with your various LDAP server if the code 
is ok for you, and if not, I'm ready to fix it.


Side notes :
- I'm now using static methods for the various schema parsers, so there 
is no synchronization anymore

- I found *many* errors in the previous implementation...
- the Strict mode is not as strict as it could be : we typically accept 
OID macros (that allows us to have things like "attributeType ( 
MyRootOid:2.3.4 ...)" to be used, where 'MyRootOid' is defined using a 
ObjectIdentifier element. This is ultra convenientt, and does not put us 
at risk.

- The code has been pushed in the API 2.0 branch.

I haven't yet tested Studio with this new code, this is soemthing I'll 
do soon.


Hope you'll find that convenient !
--
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: Qustion regarding schema quirk mode

[Emmanuel Lécharny]

Ok, I'm almost done with the new parsers.

i'm currently implementing the other Schema Elements (DitContentRule,
DirStructureRule, LdapComparator, LdapSyntax, MatchingRule,
MatchingRuleUse, Normalizer, NomrForm and SyntxChecker), which are
pretty trivial now that AT and OC are done.

For the record, here are the checks we do when quirkMode is not enabled
(ie, in strict mode), beside the ones I listed in a previous mail :

AT :
* must have at least a Syntax or a SUP
* COLLECTIVE requires USAGE userApplications
* NO-USER-MODIFICATION requires an operational USAGE

MR :
* SYNTAX is required

MRU :
* APPLIES is required

DSR :
* FORM is required

NF :
* MUST is required
* OC is required

LC :
* FQCN is required
* BYTECODE is required

N:
* FQCN is required
* BYTECODE is required

SC :
* FQCN is required
* BYTECODE is required


For all the SchemaObjects, we also check that we don't use each element
more than once (like NAME tice, or DESC twice...)

Beside those semantic tests, quickMode is also relaxing many constraints
on underscores, hyphen, etc.


Beside being faster (40x now that I have added some more checks), it
will also be thread safe. Antlr parser is not thread safe, so we had to
add synchronized methods in the server to access to the SchemaObjects
parsers. Not that it makes a lot of difference in term of performance,
as we don't frequently call those parsers, but it removes one of the
existing burden.

I have to polish the parsers hierarchy, and add some 'negative' tests
which are lacking (ie tests that prove the parsers correctly reject
wrong descriptions, on both strict or quicks mode).

I hope to be done by the end of this week.

Le 23/04/2018 à 18:07, Emmanuel Lecharny a écrit :
> That will be when I’ll be back from vacations :-)
> 
> 
> Le lun. 23 avr. 2018 à 12:40, Radovan Semancik <
> radovan.seman...@evolveum.com> a écrit :
> 
>> Hi,
> 
>> As far as I remember it should also contain:
> 
>> * Allow (pretty much any) string as OID. E.g. "whatever-oid" is often
>> used instead of real OID by Sun/Oracle servers. And I have even see it
>> recommended practice.
> 
>> * Do not die when some of the schema parts is not there at all. E.g.
>> Active Directory does not have SYNTAX definitions at all. It is OK to
>> have these parts as null in the parsed schema, just the schema parser
>> must not die on NPE or similar error during parsing.
> 
>> Once you have the new parser working for your scenarios I can update my
>> connector to a new Dir API version. And the I can run the tests with my
>> private directory server ZOO.
> 
>> -- 
>> Radovan Semancik
>> Software Architect
>> evolveum.com
> 
> 
> 
>> On 04/15/2018 11:03 PM, Emmanuel Lécharny wrote:
>> > Hi guys,
>> >
>> > I'm trying to speedup the schema parsing (it's currently quite slow,
>> due
>> > to the 3 embedded Antlr parsers we use).
>> >
>> > We use a quirksMode to be able to process more than just the RFC 4512
>> > syntax. AFAICT, here are the relaxed rules :
>> >
>> > o Allow prefixed numericOID, like attributeType ( DUAConfSchemaOID:1.0
>> > NAME 'defaultServerList' (assuming we have a DUAConfSchemaOID
>> > definedusing an objectidentifier definition)
>> >
>> > o Avoid checking references (SUP, SYNTAX) between schema elements
>> >
>> > o Allow the presence of special chars like '.', '_', ';', ':' and
>> '#' in
>> > a NAME
>> >
>> > o Null OID are accepted for DitStructureRules
>> >
>> >
>> > Is there anything I'm missing ?
>> >
>> > Thanks !
>> >
> 
> 
>> -- 
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org



pEpkey.asc
Description: application/pgp-keys

Re: Qustion regarding schema quirk mode

[Emmanuel Lécharny]

Le 17/04/2018 à 07:33, Stefan Seelmann a écrit :
> On 04/16/2018 11:40 PM, Emmanuel Lécharny wrote:
>> Hi guys,
>>
>> I'm trying to speedup the schema parsing (it's currently quite slow, due
>> to the 3 embedded Antlr parsers we use).
>>
>> We use a quirksMode to be able to process more than just the RFC 4512
>> syntax. AFAICT, here are the relaxed rules :
>>
>> o Allow prefixed numericOID, like attributeType ( DUAConfSchemaOID:1.0
>> NAME 'defaultServerList' (assuming we have a DUAConfSchemaOID
>> definedusing an objectidentifier definition)
> 
> I think that's for OpenLDAP OID macros
> 
>> o Avoid checking references (SUP, SYNTAX) between schema elements
>>
>> o Allow the presence of special chars like '.', '_', ';', ':' and '#' in
>> a NAME
> 
> Yes, because some LDAP servers allow such characters in names
> 
>> o Null OID are accepted for DitStructureRules
> 
> Hm, this is not quirk mode, DitStructureRules don't have an OID, right?

Well, they do have a ruleId, so my question would be : can it be null ?

> 
>> Is there anything I'm missing ?
> I think that's it. I hope we have tests to cover all those special cases.

If we don't, I'll add them.

Thanks Stefan  !

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org



pEpkey.asc
Description: application/pgp-keys

Qustion regarding schema quirk mode

[Emmanuel Lécharny]

Hi guys,

I'm trying to speedup the schema parsing (it's currently quite slow, due
to the 3 embedded Antlr parsers we use).

We use a quirksMode to be able to process more than just the RFC 4512
syntax. AFAICT, here are the relaxed rules :

o Allow prefixed numericOID, like attributeType ( DUAConfSchemaOID:1.0
NAME 'defaultServerList' (assuming we have a DUAConfSchemaOID
definedusing an objectidentifier definition)

o Avoid checking references (SUP, SYNTAX) between schema elements

o Allow the presence of special chars like '.', '_', ';', ':' and '#' in
a NAME

o Null OID are accepted for DitStructureRules


Is there anything I'm missing ?

Thanks !

--   Emmanuel Lecharny

Symas.com
directory.apache.org





pEpkey.asc
Description: application/pgp-keys

Qustion regarding schema quirk mode

[Emmanuel Lécharny]

Hi guys,

I'm trying to speedup the schema parsing (it's currently quite slow, due
to the 3 embedded Antlr parsers we use).

We use a quirksMode to be able to process more than just the RFC 4512
syntax. AFAICT, here are the relaxed rules :

o Allow prefixed numericOID, like attributeType ( DUAConfSchemaOID:1.0
NAME 'defaultServerList' (assuming we have a DUAConfSchemaOID
definedusing an objectidentifier definition)

o Avoid checking references (SUP, SYNTAX) between schema elements

o Allow the presence of special chars like '.', '_', ';', ':' and '#' in
a NAME

o Null OID are accepted for DitStructureRules


Is there anything I'm missing ?

Thanks !

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org



pEpkey.asc
Description: application/pgp-keys

Re: [ApacheDS]

[Emmanuel Lécharny]

Le 01/04/2018 à 18:45, Юлия Дудышева a écrit :
> Hi!
> 
> I'm trying to set up ldap server so that clients could authenticate using
> certificates.
> I tried to follow the guide, however pkinit page is empty
> http://directory.apache.org/apacheds/kerberos-ug/2.5-pkinit.html
> Is there any way to configure apacheds for pkinit usage?

You can have a look at this page :

http://directory.apache.org/apacheds/kerberos-ug/4.1-authenticate-kinit.html

and this other page :

http://directory.apache.org/apacheds/kerberos-ug/4.2-authenticate-studio.html

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: Using Directory API Under Security Manager

[Emmanuel Lécharny]

Le 08/03/2018 à 06:55, George S. a écrit :
> Never mind. The problem is I'm trying to use this from a JSP which is
> untrusted. I got through it, but what a pain.

SecurityManager has always been a pain...

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Fwd: Re: LdapConnection.search() Help

[Emmanuel Lécharny]

Transfering the mail to the list, I wrongly replied to George directly...


 Message transféré 
Delivered-To: elecha...@gmail.com
Received: by 10.74.89.138 with SMTP id k10csp5256341ood;Wed, 7
Mar 2018 07:34:15 -0800 (PST)
X-Google-Smtp-Source:
AG47ELuBKBRbZd39urfnGs0cFwHBOKH1PpuyzbwKkgWnrd7ILew2InXuQsW0i2Kko5myIGHyrbZC
X-Received: by 10.36.98.195 with SMTP id
d186mr23436935itc.88.1520436855183;Wed, 07 Mar 2018 07:34:15
-0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1520436855; cv=none;d=google.com;
s=arc-20160816;
b=SJkpAosxfiHg6uhlkNqd2WORu4QCmQySwSCNW9ubEDNx6h20632OB294WbTfNQTcQV
9/xg4Lw7U0oGA8knGvcrPpozdcQ+VDgAZXebGwbQRURa/s6tU7D1Y8nQdJesCs5vDERh

HoZd0haeYIEGYLALToVSoSlJi26d/lNg0jIg0tUuQinp0KK+n44H6UJkhwQKFGuo3sKH
WYm6ro+mvQKOq1L8DxToPVxxPl8B5j9ia7801YYqOXV+Ybkewt+nSmJyBuW+9pqizSN1

y+ZZhk0dLPgoB/unUqfvZirULfICPsEEBo+KFA4ja3ylPiLz4qx5pyRKU6PhkLL+5A5v
m5wg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=arc-20160816;
h=content-language:in-reply-to:mime-version:user-agent:date
:message-id:from:references:to:subject:arc-authentication-results;
 bh=gaN9v+1ST2YnYxFchkHEnlO3FZ4i5oOFtNJlB2rL0GQ=;
b=H014lBolj+v7V2/UKGUhLI/THfpI2b7xyq08vdzt5N6wtC7JHHK5zOWm8pl1PQYZ6R
6eC5Nz3RD9wgMWm6xuyP7FsK6VVj2jVA7fJaKneoyJjYsjeO0BAuTLJR6kMPm45dKp2t

tT5bWJCGz0dI1NvPBROd4V1+SH+R6Ia2cvYk3OIgLY5aL6HbKS475jzR4DWVeUDKBoYy
ovXr1O9WEYk2ws5nGgGuuu26upBMXSr1FctPp2IscsJiBLp7Kw3bvAlMWetLuo6Sos3H

oQWdcQN1MOleVf2BlI8s9q+g1AlHqXjAxMOzDkzDNw8REA3wKMjSnfOmgnRPgltzwaDX
j7+A==
ARC-Authentication-Results: i=1; mx.google.com;   spf=pass
(google.com: domain of geor...@mhsoftware.com designates 204.144.128.66
as permitted sender) smtp.mailfrom=geor...@mhsoftware.com
Return-Path: <geor...@mhsoftware.com>
Received: from mail.mhsoftware.com (mail.mhsoftware.com.
[204.144.128.66])by mx.google.com with ESMTPS id
x132si5364717iod.40.2018.03.07.07.34.14for <elecha...@gmail.com>
   (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
   Wed, 07 Mar 2018 07:34:15 -0800 (PST)
Received-SPF: pass (google.com: domain of geor...@mhsoftware.com
designates 204.144.128.66 as permitted sender) client-ip=204.144.128.66;
Authentication-Results: mx.google.com;   spf=pass (google.com:
domain of geor...@mhsoftware.com designates 204.144.128.66 as permitted
sender) smtp.mailfrom=geor...@mhsoftware.com
Received: from localhost (localhost [127.0.0.1]) by mail.mhsoftware.com
(Postfix) with ESMTP id 1B02430091D for <elecha...@gmail.com>; Wed,  7
Mar 2018 08:34:14 -0700 (MST)
X-Virus-Scanned: amavisd-new at mhsoftware.com
Received: from mail.mhsoftware.com ([127.0.0.1]) by localhost
(mail.mhsoftware.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
id Stw0M0HWx-Q3 for <elecha...@gmail.com>; Wed,  7 Mar 2018 08:34:10
-0700 (MST)
Received: from [192.168.1.120] (c-67-190-58-109.hsd1.co.comcast.net
[67.190.58.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256
(128/128 bits)) (Client did not present a certificate) by
mail.mhsoftware.com (Postfix) with ESMTPSA id 8952330091C for
<elecha...@gmail.com>; Wed,  7 Mar 2018 08:34:10 -0700 (MST)
Subject: Re: LdapConnection.search() Help
To: Emmanuel Lécharny <elecha...@gmail.com>
References: <a79dc37c-f730-06bf-b78e-1776de6b8...@mhsoftware.com>
<452c958c-1182-62fa-5ea5-716725808...@gmail.com>
<c5b99d86-d9fb-6352-59a3-7974b0859...@mhsoftware.com>
<e9f7376a-b227-b1ee-015c-594ba95cf...@gmail.com>
<e8fa95a1-e838-ca39-148a-43953c779...@mhsoftware.com>
<56806966-dffc-711a-4db0-d04dcfd72...@mhsoftware.com>
<523805e1-eefb-06ab-da26-722e7b2fe...@gmail.com>
From: George S. <geor...@mhsoftware.com>
Message-ID: <8da5b63e-949d-9b9a-e6d9-251ade97a...@mhsoftware.com>
Date: Wed, 7 Mar 2018 08:33:50 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <523805e1-eefb-06ab-da26-722e7b2fe...@gmail.com>
Content-Type: multipart/alternative;
boundary="26CF65067D378379E4A0FED9"
Content-Language: en-US

Using 1.0.0 If I run this code:

EntryCursor cursor=lc.search(base,"(objectclass=*)",SearchScope.ONELEVEL);
for  (Entry entry : cursor){
   entries.add(entry);
} I get this exception:

Exception in thread "main" java.lang.RuntimeException:
ERR_02002_FAILURE_ON_UNDERLYING_CURSOR Failure on underlying Cursor.
 at
org.apache.directory.api.ldap.model.cursor.CursorIterator.next(CursorIterator.java:89)
 at
com.mhsoftware.ldap.BoundConnection.search(BoundConnection.java:360)
 at
com.mhsoftware.ldap.LDAPConnectionFactory.main(LDAPConnectionFactory.java:265)
Caused by:
org.apache.directory.api.ldap.model.cursor.CursorLdapReferralException
 at
org.apache.directory.ldap.client.api.EntryCursorImpl.get(EntryCursorImpl.java:174)
\   ldaat
org.apache.directory.ldap.clie

Re: LdapConnection.search() Help

[Emmanuel Lécharny]

So I have it working fine with this code :

EntryCursor cursor = connection.search( "ou=system",
"(objectclass=*)",
SearchScope.ONELEVEL,
"*", "+" );
int count = 0;

for ( Entry entry : cursor )
{
assertNotNull( entry );
count++;
}

SearchResultDone done = cursor.getSearchResultDone();

As you can see, I also use an iterator, I don't user a SearchRequest,
and I get 5 entries back (count == 5 at the end).

EntryCursorImpl is Iterable, and uses a CursorIterator to handle
iteration, which move forward immediately when created, so that the
first get() works (available() will succeed).

AFAICT, it works properly.

The only annoying problem is that a cursor is never going to give you a
result if you don't move forward beforehand : its position is always
*before* the first element. It may sound weird, but it's because we need
to be able to move forward and backward properly.


Le 07/03/2018 à 01:53, George S. a écrit :
> It's definitely a problem.
> 
> 
> On 3/6/2018 5:03 PM, George S. wrote:
>> I looked at
>> LdapNetworkConnection.search(String,String,SearchScope,String...) and
>> it's a wrapper around a call to search using a SearchRequest, and
>> constructing a EntryCursorImpl from the SearchCursor.
>>
>> There seems to be something wrong in EntryCursorImpl. If I change my
>> code to use a SearchRequest, then I get results in a SearchCursor and
>> I can iterate over them.
> 
> Looking at the code, EntryCursorImpl implicitly calls
> searchCursor.available(), which is returning false because it appears
> response is not set until a call to next(). See SearchResultImpl line
> 117 or so.
> 
> 
>>
>> public  Collectionsearch(String  base,String...
>> attributeNames)throws  LdapException{
>>
>>     if  (attributeNames.length ==0){
>>     attributeNames =new  String[]{
>> "distinguishedName","objectClass","name",
>> prop.getProperty("emailAddress","mail")};
>>     }
>>     Collection entries =new  ArrayList<>();
>>     SearchRequest sr=new  SearchRequestImpl();
>>     sr.setBase(new  Dn(base));
>>     sr.setTimeLimit(Integer.MAX_VALUE);
>>     sr.setFilter("(objectclass=*)");
>>     sr.addAttributes(attributeNames);
>>     sr.setScope(SearchScope.ONELEVEL);
>>     sr.setDerefAliases(AliasDerefMode.DEREF_ALWAYS);
>>
>>     SearchCursor cursor = lc.search(sr);
>>     // EntryCursor cursor=new EntryCursorImpl(scursor);
>>
>>     if  (isDebugMode()){
>>     System.err.print("search(\""+base+"\"");
>>     for  (String  s : attributeNames){
>>     System.err.print(",\""+s+"\"");
>>     }
>>     System.err.println(");");
>>     }
>>         if  (true  || cursor.available()){
>>     for  (Response entry: cursor){
>>     entries.add(entry);
>>     }
>>     }  else  {
>>     if  (isDebugMode()){
>>     System.err.println("SearchResults came back null!");
>>     }
>>     }
>>     try  {
>>     cursor.close();
>>     }  catch  (IOException ioeClose){
>>     ioeClose.printStackTrace(System.err);
>>     }
>>     return  entries;
>> }
>>
>>
>> On 3/6/2018 4:27 PM, Emmanuel Lécharny wrote:
>>>
>>> Le 07/03/2018 à 00:08, George S. a écrit :
>>>> and, just to throw in another point, I've got some other code using the
>>>> Novell LDAP API library and it is able to do the query, and I can use
>>>> JXplorer to browse the tree.
>>>>
>>>> It's really looking like there's something wrong in the library.
>>> Sorry, I missed the point. Removed the 'if ( cursor.available() )', it
>>> should work.
>>>
>>
> 

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: LdapConnection.search() Help

[Emmanuel Lécharny]

Le 07/03/2018 à 01:53, George S. a écrit :
> It's definitely a problem.

Ok. Can you fill a JIRA ? I'll have a deeper look at teh code later this
week.


-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: LdapConnection.search() Help

[Emmanuel Lécharny]

Le 07/03/2018 à 00:08, George S. a écrit :
> and, just to throw in another point, I've got some other code using the
> Novell LDAP API library and it is able to do the query, and I can use
> JXplorer to browse the tree.
> 
> It's really looking like there's something wrong in the library.

Sorry, I missed the point. Removed the 'if ( cursor.available() )', it
should work.

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: LdapConnection.search() Help

[Emmanuel Lécharny]

Hi,

are you sure you have entries below the point you are searching from ?
You are doing a search using a ONE_LEVEL scope, which will return oly
the children entries.


Le 06/03/2018 à 22:32, George S. a écrit :
> I'm trying to use the API library and i'm running into a problem. I'm
> trying to do a search (see method below). Using this bound connection, I
> can do a lookup. For example, I can do .lookup(base,"objectClass"),
> .lookup(base,"dc"), etc. However search isn't working.
> 
> Can anyone give me an idea of what I'm doing wrong. I've looked through
> the docs and I'm just not getting it.
> 
> public  Collectionsearch(String  base,String...
> attributeNames)throws  LdapException{
> 
> if  (attributeNames.length ==0){
>     attributeNames =new  String[]{ 
> "distinguishedName","objectClass","name",
> prop.getProperty("emailAddress","mail")};
> }
> Collection entries =new  ArrayList<>();
> // LC is LdapNetworkConnection
>  EntryCursor cursor = lc.search(new  Dn(base),"(objectclass=*)",
> SearchScope.ONELEVEL,attributeNames);
> 
> if  (isDebugMode()){
>     System.err.print("search(\""+base+"\"");
>     for  (String  s : attributeNames){
>     System.err.print(",\""+s+"\"");
>     }
>     System.err.println(");");
>     System.err.println("cursor.available()="  + cursor.available());
> }
> 
> if  (cursor.available()){
>     for  (Entry entry: cursor){
>     entries.add(entry);
>     }
> }  else  {
>     if  (isDebugMode()){
>     System.err.println("SearchResults came back null!");
>     }
> }
> try  {
>     cursor.close();
> }  catch  (IOException ioeClose){
>     ioeClose.printStackTrace(System.err);
> }
> return  entries;
> }
> 
> The output is:
> 
> getAttribute() entry=[Entry
>     dn: DC=somedistrict,DC=k12,DC=local
> 
>     dc: somedistrict
> ]
>     dc
>     somedistrict
> 
> search("DC=somedistrict,DC=k12,DC=local","objectClass");
> cursor.available()=false
> SearchResults came back null!
> 
>  
> 

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: Operational Attributes

[Emmanuel Lécharny]

Le 19/02/2018 à 16:10, Kevin Hale Boyes a écrit :
> On Mon, Feb 19, 2018 at 7:42 AM, Emmanuel Lécharny <elecha...@gmail.com>
> wrote:
>>
>> Le 19/02/2018 à 15:18, Kevin Hale Boyes a écrit :
>>> So what I did was write a test program using JNDI and see if I could get
>>> the operational attributes that way.
>>> It didn't work either.  I'm able to get the same set of attributes as
>> using
>>> the API library.
>>
>> Ok, so it seems that your LDAP server does not properly handle the
>> special "+" attribute.
>>
> 
> Yeah, that's what it looks like but the curious thing is Directory Studio
> is able to get the operational attributes.

It checks if the server supports the feature, and if not, if constructs
an explicit lits of ttributes (as you just did) :


InitializeAttributesRunnable :


public static synchronized void initializeAttributes( IEntry entry,
StudioProgressMonitor monitor )
{
// get user attributes or both user and operational attributes
String[] returningAttributes = null;
LinkedHashSet raSet = new LinkedHashSet();
raSet.add( SchemaConstants.ALL_USER_ATTRIBUTES );
boolean initOperationalAttributes =
entry.getBrowserConnection().isFetchOperationalAttributes()
|| entry.isInitOperationalAttributes();

if ( initOperationalAttributes )
{
if (
entry.getBrowserConnection().getRootDSE().isFeatureSupported(
SchemaConstants.FEATURE_ALL_OPERATIONAL_ATTRIBUTES ) )
{
raSet.add( SchemaConstants.ALL_OPERATIONAL_ATTRIBUTES );
}
else
{
Collection opAtds =
SchemaUtils.getOperationalAttributeDescriptions( entry
.getBrowserConnection().getSchema() );
Collection atdNames = SchemaUtils.getNames(
opAtds );
raSet.addAll( atdNames );
}
}




>> Which server it is ?
>>
> 
> Looks like Active Directory. The attributes shown on the Root DSE show V51,
> V60, V61R2 and ADAM.


Probably the worst so called LDAP servers. The M$ way : embrace, extend
and estinguish...



-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: Operational Attributes

[Emmanuel Lécharny]

Le 19/02/2018 à 15:18, Kevin Hale Boyes a écrit :
> On Sat, Feb 17, 2018 at 5:57 AM, Emmanuel Lécharny <elecha...@gmail.com>
> wrote:
> 
>> Hi,
>>
> 
> Thanks for your help!
> 
>> When I iterate over the results and inspect the attributes of an entry
>>> I don't find the operational attributes.
>>
>> Weird. You hsould have them.
>>
>> You can try using ALL_OPERATIONAL_ATTRIBUTES instead of
>> ALL_ATTRIBUTES_ARRAY to see if it's any better.
> 
> 
> When I give just ALL_OPERATIONAL_ATTRIBUTES the call is successful but
> there are no attributes in the Entry.
> What ended up helping is listing all the attribute names.
> While that's not ideal it makes some sense for my application because it's
> only prepared to deal with certain attributes anyway.

That is an option. It will work.



> 
> 
>> Actually, Studio uses the API, so it should work.
>>
> 
> I was looking at the source code for Studio and, while it's a lot to
> absorb, I thought it also used JNDI calls.

It defaults to use teh API, but if you tell it to use JNDI, it will.


> So what I did was write a test program using JNDI and see if I could get
> the operational attributes that way.
> It didn't work either.  I'm able to get the same set of attributes as using
> the API library.

Ok, so it seems that your LDAP server does not properly handle the
special "+" attribute.

Which server it is ?

> 
> I might not go that far since I have a working solution of specifying all
> attribute names.
> 
> Thanks for you time and effort!!

My plaisure.

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: Operational Attributes

[Emmanuel Lécharny]

Hi,


Le 16/02/2018 à 15:25, Kevin Hale Boyes a écrit :
> I've been unable to retrieve operational attributes using the API.
> I think the server is microsoft AD but I'm not sure.
> 
> I give more detail about what I'm doing below but my question is simple:
> How do I retrieve operational attributes using this API?
> 
> 
> Here's my search call:
> 
> connection.search(dn, LdapConstants.OBJECT_CLASS_STAR,
> SearchScope.OBJECT, SchemaConstants.ALL_ATTRIBUTES_ARRAY);

Sounds correct.


> 
> When I iterate over the results and inspect the attributes of an entry
> I don't find the operational attributes.

Weird. You hsould have them.

You can try using ALL_OPERATIONAL_ATTRIBUTES instead of
ALL_ATTRIBUTES_ARRAY to see if it's any better.


> 
> I was looking at the API code a bit and it seems that operational
> attributes are somehow associated with a schema manager so that's the
> next thing I tried.  I put this before the search call:
> 
> connection.setSchemaManager(new DefaultSchemaManager());


Actually, no, there is no relation with the SchemaManager. If you inject
a SchemaManager, then it has to know about the OperationalAttributes you
will get. In this very case, you'll get an error because they are unknown.

> 
> But this fails now with an exception:
> 
> 2018-02-16 07:18:52,034 WARN  [NioProcessor-1] - The attribute
> 'usncreated' cannot be stored-DefaultEntry.330
> 2018-02-16 07:18:52,034 WARN  [NioProcessor-1] - ERR_04269
> ATTRIBUTE_TYPE for OID usncreated does not
> exist!-LdapNetworkConnection.exceptionCaught1973
> org.apache.directory.api.ldap.model.exception.LdapNoSuchAttributeException:
> ERR_04269 ATTRIBUTE_TYPE for OID usncreated does not exist!
> at 
> org.apache.directory.api.ldap.model.schema.registries.DefaultAttributeTypeRegistry.lookup(DefaultAttributeTypeRegistry.java:304)
> at 
> org.apache.directory.api.ldap.model.schema.registries.DefaultAttributeTypeRegistry.lookup(DefaultAttributeTypeRegistry.java:47)
> at 
> org.apache.directory.api.ldap.schema.manager.impl.DefaultSchemaManager.lookupAttributeTypeRegistry(DefaultSchemaManager.java:1756)
> at 
> org.apache.directory.api.ldap.model.entry.DefaultEntry.(DefaultEntry.java:318)
> at 
> org.apache.directory.ldap.client.api.LdapNetworkConnection.messageReceived(LdapNetworkConnection.java:2311)
> at 
> org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:858)
> 
> I've also downloaded Apache Directory Studio and connected to the same
> server and enabled the 'Fetch operational attributes while browsing'
> feature on the connection.  I can see the operational attributes when
> I inspect a DN.  I just can't seem to do it using this API.

Actually, Studio uses the API, so it should work.

Try with ALL_OPERATIONAL_ATTRIBUTES, see if it's any better. If you get
the operational attribute, I would say we have a problem in the way we
process a request might be buggy.

Otherwise, it woud be interesting to get a wireshark capture of the
dialogue, to see if the problem is in the request or in the response.

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: Questions about Referrals

[Emmanuel Lécharny]

Le 21/01/2018 à 22:25, Nick Couchman a écrit :
> Hey, there, everyone,
> Over at the ASF Guacamole project we're trying to migrate to the Apache
> Directory API from the legacy/unmaintained Novell Java API.  We're most of
> the way there, but trying to deal correctly with referral following in the
> Apache API, so I have a couple of questions regarding how the Apache
> Directory Client functions...

Hi ! Responses inline...


> 
> First, if I want to following referrals when retrieving search results, is
> it as simple as doing:
> 
> request.followReferrals();
> 
> (where request is an instance of SearchRequestImpl) and the client
> automatically follows the referrals?  Or do I need to implement the
> referral following manually by detecting if a referral occurs and then
> writing the code to follow that referral?


Referral following is not yet included in teh LDAP API (cf
https://issues.apache.org/jira/browse/DIRAPI-61?jql=text%20~%20referral%20ORDER%20BY%20key%20ASC)

So the only solution for you, atm, is to implement it on your side :/


> 
> Second, with regard to following referrals, assuming the above works to
> just make the client follow referrals, is there any way to limit the number
> of hops the client takes in following referrals?  In the Novell API you can
> set a variety of controls, and one of them is the maximum number of "hops"
> taken when following referrals, which prevents the client from getting into
> a bad situation, like a recursive referral or an endless loop of
> referrals.  I do not see anything similar in the Apache API for limiting -
> am I missing it?

No, you aren't missing anything. Cf
https://issues.apache.org/jira/browse/DIRAPI-179?jql=text%20~%20referral%20ORDER%20BY%20key%20ASC


> 
> Finally, assuming there isn't anything built-in to the API to limit
> referral hops, I see that there is a getReferralLength() method in the
> ReferralImpl class, but it's unclear what is meant by "referral length?"
> Is this referring to the number of hops, or some other "length" associated
> with referrals?

Oh, it's a purely interal method that is used by the message encoder. It
contains the length of the BER encoded URL.



-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Internal dev guide on going effort...

[Emmanuel Lécharny]

Hi guys,

I'm working on pushing some new pages on the web site about the internal
API design. The idea is to give some clue to people wanting to work on
the API (extending it by adding controls/extended operations, or people
just curious about its design).

Those pages describe how it all works, from the developper point of
view. It should be accurate, as I started to work on them 2 weeks ago :-)

It's not completed yer, but at least some pages are available :

- 1- Introduction
- 2- General structure
- 3- Building
- 4- ASN/1 (not completed yet)
- 5 - Network
- 13 - controls
- 14 Extended Operations (not completed yet)

The pages are available on the staging site, I haven't yet pushed the
site. You can access them using the 'Internal Guide' Menu that has also
been added.


Feel free to comment or report typoes/errors.

Thanks !

Re: Ldap API Custom Controls

[Emmanuel Lécharny]

Le 04/12/2017 à 19:19, Chris Pike a écrit :
> Emmanuel,
> 
> We have created a pull request
> 
> https://github.com/apache/directory-ldap-api/pull/1
> 
> Let us know if anything needs changed.

Thanks !

I'll have a look today.


-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: Ldap API Custom Controls

[Emmanuel Lécharny]

Hi Chris,

do you need any more information to get the code pushed ?


Many thanks !



Le 05/10/2017 à 21:18, Chris Pike a écrit :
> Emmanuel,
>
> We got this working. Is there a git repo for the directory api, or do we have 
> to use subversion to provide the code back?
>
> Thanks,
>
> ~Chris Pike
>
>
>
>
> - Original Message -
> From: "Emmanuel Lecharny" 
> To: "api" 
> Sent: Monday, September 11, 2017 6:57:38 PM
> Subject: Re: Ldap API Custom Controls
>
> The control value (3003020101) is a PDU which has teh following meaning :
>
> 0x30 0x03 : SEQ length 3
>   0x02 0x01 0x01 : INTEGER length 1 value 1
>
> So you have sent a correct Control, but the OID has changed :
> 1.2.840.113556.1.4.20669 was for ancient versions of Windows Server (up to
> Windows 2012) and the OID you are using is a new one
> (1.2.840.113556.1.4.2239).
>
> I can only bet that the OID is not understood by the Windows machine you
> are talking to.
>
>
> On Fri, Sep 8, 2017 at 4:11 PM, CRAIG BENNER  wrote:
>
>> Thanks Shawn, I was going to ask that.  But I got wireshark working.
>> Below is the packet I'm assuming we want to see.  In concept it looks
>> correct, but i'm not sure what the controlValue is suppose to be on the
>> wire.
>>
>> Frame 9: 295 bytes on wire (2360 bits), 295 bytes captured (2360 bits) on
>> interface 0
>> Ethernet II, Src: PcsCompu_f5:e8:94 (08:00:27:f5:e8:94), Dst:
>> PcsCompu_4b:a3:17 (08:00:27:4b:a3:17)
>> Internet Protocol Version 4, Src: 192.168.33.10, Dst: 192.168.33.11
>>
>> Transmission Control Protocol, Src Port: 44766, Dst Port: 389, Seq: 45,
>> Ack: 46, Len: 229
>> Lightweight Directory Access Protocol
>> LDAPMessage modifyRequest(7) "cn=model_ouadmin,ou=PSU-OU-
>> Admin-Accounts,ou=PSU-AD-OU-Administration,ou=PSU-AD-
>> Administration,dc=develop,dc=local"
>> messageID: 7
>> protocolOp: modifyRequest (6)
>> modifyRequest
>> object: cn=model_ouadmin,ou=PSU-OU-
>> Admin-Accounts,ou=PSU-AD-OU-Administration,ou=PSU-AD-
>> Administration,dc=develop,dc=local
>> modification: 1 item
>> [Response In: 10]
>> controls: 1 item
>> Control
>> controlType: 1.2.840.113556.1.4.2239 (ISO assigned OIDs,
>> USA.113556.1.4.2239)
>> criticality: True
>> controlValue: 3003020101
>>
>> Thanks.
>> Craig Benner
>>
>> - Original Message -
>> From: "Shawn McKinney" 
>> To: "api" 
>> Sent: Friday, September 8, 2017 9:58:56 AM
>> Subject: Re: Ldap API Custom Controls
>>
>>> On Sep 7, 2017, at 8:41 PM, CRAIG BENNER  wrote:
>>>
>>> It will take some changes to get a wireshark capture, since Password's
>> can only be managed over a secure connection.  Hopefully tomorrow I can get
>> you the wireshark capture
>>
>> Wonder if it would be easier to just enable the API logger containing the
>> BER request/response traces?  That’s typically how I debug.  Saves the
>> trouble of setting up wireshark.
>>
>> > additivity="false">
>> 
>> 
>> 
>>
>
>

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: SASL/EXTERNAL binding

[Emmanuel Lécharny]

Le 16/11/2017 à 18:35, Frank Crow a écrit :
> About four years ago, I started on a project using OpenLDAP and Apache LDAP
> API for ldap client applications.   Due to requirements we moved away from
> using stored passwords and configured for client-side certificates
> (SASL/EXTERNAL).   That is when I discovered that the Apache LDAP API did
> not support SASL/EXTERNAL and that there was an outstanding bug
> (DIRAPI-105) against that feature.

It's not a bug, but a missing feature( although it's wrongly qualified
as 'bug' ;-)
>
> We undid the SASL/EXTERNAL requirement and failed our requirements with a
> promise to implement when available.   Now I'm off of that project and onto
> a new one.   Again, we have similar requirements.   And still, after all
> these years DIRAPI-105 keeps getting kicked down the road.

Indeed :/
>
> So, after that ticket being open for nearly 7 years, I'm just wondering if
> I should give up hope?  It's been quite a long road from the Mxx releases
> into the RC1 and RC2 and now 1.0.0 and still not supported.   I'm really
> wanting to implement this authentication mechanism (actually, I am anyway)
> and I'd really like to use the Apache LDAP API but I'm stuck with simple
> binds if I do.
Implementing EXTERNAL in the LDAP API should be quite simple : it should
be as simple as extending the AbstractSaslRequest class, and to pass teh
EXTERNAL machanism as a String, plus an optional authzID parameter (whch
is a part of teh AbstractSaslRequest class). Adding the EXTERNAL value
in the SupportedSaslMechanisms class would help :

public final class SupportedSaslMechanisms
{
    /** CRAM-MD5 mechanism */
    public static final String CRAM_MD5 = "CRAM-MD5";
 ...
    /** The EXTERNAL mechanism */
    public static final String EXTERNAL = "EXTERNAL";
...

and

package org.apache.directory.ldap.client.api;


import
org.apache.directory.api.ldap.model.constants.SupportedSaslMechanisms;


/**
 * Holds the data required to complete the EXTERNAL SASL operation
 *
 * @author mailto:d...@directory.apache.org;>Apache Directory
Project
 */
public class SaslExternalRequest extends AbstractSaslRequest
{
    /**
 * Creates a new instance of SaslExternalRequest.
 */
    public SaslExternalRequest()
    {
    super( SupportedSaslMechanisms.EXTERNAL );
    }

   
    /**
 * Creates a new instance of SaslExternalRequest.
 */
    public SaslExternalRequest( String authzId )
    {
    super( SupportedSaslMechanisms.EXTERNAL );
    this.authorizationId = authzId;
    }
}


Last, not least, adding the appropriate function in
LdapNetworkConnection is needed :




    /**
 * Bind to the server using a SaslExternalRequest object.
 *
 * @param request The SaslExternalRequest POJO containing all the
needed parameters
 * @return A LdapResponse containing the result
 * @throws LdapException if some error occurred
 */
    public BindResponse bind( SaslExternalRequest request ) throws
LdapException
    {
    if ( request == null )
    {
    String msg = "Cannot process a null request";
    LOG.debug( msg );
    throw new IllegalArgumentException( msg );
    }

    BindFuture bindFuture = bindAsync( request );

    // Get the result from the future
    try
    {
    // Read the response, waiting for it if not available
immediately
    // Get the response, blocking
    BindResponse bindResponse = bindFuture.get( timeout,
TimeUnit.MILLISECONDS );

    if ( bindResponse == null )
    {
    // We didn't received anything : this is an error
    LOG.error( "Bind failed : timeout occurred" );
    throw new LdapException( TIME_OUT_ERROR );
    }

    if ( bindResponse.getLdapResult().getResultCode() ==
ResultCodeEnum.SUCCESS )
    {
    authenticated.set( true );

    // Everything is fine, return the response
    LOG.debug( "Bind successful : {}", bindResponse );
    }
    else
    {
    // We have had an error
    LOG.debug( "Bind failed : {}", bindResponse );
    }

    return bindResponse;
    }
    catch ( Exception ie )
    {
    // Catch all other exceptions
    LOG.error( NO_RESPONSE_ERROR, ie );

    throw new LdapException( NO_RESPONSE_ERROR, ie );
    }
    }


That should be enough to get it working. Now, it requires some test.

Would you like to give it a little run ? If you validate that this code
works, I can easily inject it into the API and cut a release.

>
> I'm talking about projects which are pretty big US Navy programs of record
> where this feature would be very valuable.   But I'm just thinking that I
> need to move on with life.   Maybe look at Oracle Unified Directory or
> something else.
>
> Any ideas on that?

I gave you what I have from the top of my head. I 

Re: Apache LDAP API for building simple LDAP Server

[Emmanuel Lécharny]

Le 12/09/2017 à 17:20, Angel Angelov a écrit :
> Hi, can I use the LDAP API for building simple LDAP Server?
No. This is a client API.

> Do you have some example how to build a simple LDAP Server?

Have a look at the Apache Directory Server (directory.apache.org/apacheds)
> For example just print the client request on the in a log file and
> send OK response back.
You can use ApacheDS for that purpose, and write an interceptor that
does what you need.

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: Ldap API Custom Controls

[Emmanuel Lécharny]

Le 07/09/2017 à 22:20, Chris Pike a écrit :
> So I added the controls, but they don't seem to be working. We are getting a 
> error code 53 (unwilling to preform) when we add the control to our request, 
> so assuming there is something wrong with the control, but don't know enough 
> about ldap or the library to know what. Any ideas on what to try or what 
> might be wrong?

We need more info to be able to understand what's wrong :
- a capture of the messages being exchanged (wireshark)
- the server you use
>
>
>
> - Original Message -
> From: "Chris Pike" <clp...@psu.edu>
> To: "api" <api@directory.apache.org>
> Sent: Monday, September 4, 2017 6:50:37 PM
> Subject: Re: Ldap API Custom Controls
>
> Thanks for the suggestions and code examples. I'll work on adding this new 
> control and let you know if I have any issues.
>
> ~Chris Pike
>
>
>
> - Original Message -
> From: "Emmanuel Lécharny" <elecha...@gmail.com>
> To: "api" <api@directory.apache.org>
> Sent: Monday, September 4, 2017 3:46:49 AM
> Subject: Re: Ldap API Custom Controls
>
> Le 04/09/2017 à 09:16, Radovan Semancik a écrit :
>> On 09/04/2017 09:02 AM, Emmanuel Lécharny wrote:
>>> Actually, the tricky part is the grammar, which is a state engine
>>> description.
>> Oh, that is usually not that difficult either. Most of those "custom"
>> controls are very simple. Just a couple of fields. Complex data
>> structures seem to be very rare. If you start with existing control
>> that is somehow similar it is not difficult to implement a new control.
> FTR, the code I provided yesterday night in one of my previous mail took
> me around 30 mins, all included. For a more complex control, like
> syncrepl, that would have takne a bit more time, mainly because you want
> to add unit tests to cover teh various cases.
>
> Now, I think that we should provide a bit of documentation about how to
> implement a control...
>

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: Ldap API Custom Controls

[Emmanuel Lécharny]

Le 04/09/2017 à 08:49, Radovan Semancik a écrit :
> Hi,
>
> I have implemented a couple of controls myself. Perhaps the best
> approach is to do it right in the Apache Directory API source code.
> And contribute it back, of course :-)
> Start from any existing control. E.g. you can have a look at my AD
> DirSync control
> (org.apache.directory.api.ldap.extras.controls.ad.AdDirSync). It is
> enough to have some basic idea how LDAP protocol works and how the API
> works. Most of the work is mostly copy There are 3-4 classes to
> create. It is not difficult to figure out.

Actually, the tricky part is the grammar, which is a state engine
description.

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: Ldap API Custom Controls

[Emmanuel Lécharny]

Le 03/09/2017 à 20:57, Chris Pike a écrit :
> Trying to get Active Directory to honor password history when changing a 
> password. 
>
> https://blogs.technet.microsoft.com/fieldcoding/2013/01/09/resetting-passwords-honoring-password-history-or-whats-happening-under-the-hood-when-changing-resetting-passwords/

Ok, the control is :

 PolicyHintsRequestValue ::= SEQUENCE {
 Flags    INTEGER
 }


You need many elements :

- An interface in the api-ldap-extra-codec-api module which exposes the
'flags' (a getter and setter is enough). Something like :

import org.apache.directory.api.ldap.model.message.Control;

public interface LdapServerPolicyHintsOid extends Control
{
    /** This control OID */
    String OID = "1.2.840.113556.1.4.20669";

    int getFlags();
   
    void setFlags( int flags );
}

- An implementation of this interface in the same package. Something like :


import org.apache.directory.api.ldap.model.message.controls.AbstractControl;

public class LdapServerPolicyHintsOidImpl extends AbstractControl
implements LdapServerPolicyHintsOid
{
    /** This control OID */
    private int flags;

    public LdapServerPolicyHintsOidImpl()
    {
    super( OID );
    }

    public int getFlags()
    {
    return flags;
    }
   
    public void setFlags( int flags )
    {
    this.flags = flags;
    }
}


- A decorator in the api-ldap-extras-codec module :


import org.apache.directory.api.asn1.Asn1Object;
import org.apache.directory.api.asn1.DecoderException;
import org.apache.directory.api.asn1.EncoderException;
import org.apache.directory.api.asn1.ber.Asn1Decoder;
import org.apache.directory.api.asn1.ber.tlv.BerValue;
import org.apache.directory.api.asn1.ber.tlv.TLV;
import org.apache.directory.api.asn1.ber.tlv.UniversalTag;
import org.apache.directory.api.i18n.I18n;
import org.apache.directory.api.ldap.codec.api.ControlDecorator;
import org.apache.directory.api.ldap.codec.api.LdapApiService;


/**
 * The LdapServerPolicyHintsOid decorator
 *
 */
public class LdapServerPolicyHintsOidDecorator extends
ControlDecorator implements
LdapServerPolicyHintsOid
{
    private int seqLength;

    private static final Asn1Decoder DECODER = new Asn1Decoder();


    /**
 * Creates a new instance of LdapServerPolicyHintsOidDecorator.
 *
 * @param codec The LDAP Service to use
 */
    public LdapServerPolicyHintsOidDecorator( LdapApiService codec )
    {
    this( codec, new LdapServerPolicyHintsOidImpl() );
    }


    /**
 * Creates a new instance of LdapServerPolicyHintsOidDecorator.
 *
 * @param codec The LDAP Service to use
 * @param vlvRequest The VLV request to use
 */
    public LdapServerPolicyHintsOidDecorator( LdapApiService codec,
LdapServerPolicyHintsOid vlvRequest )
    {
    super( codec, vlvRequest );
    }


    /**
 * {@inheritDoc}
 */
    @Override
    public int computeLength()
    {
    seqLength = 1 + 1 + BerValue.getNbBytes( getFlags() );

    valueLength = 1 + TLV.getNbBytes( seqLength ) + seqLength;

    return valueLength;
    }


    /**
 * {@inheritDoc}
 */
    @Override
    public ByteBuffer encode( ByteBuffer buffer ) throws EncoderException
    {
    if ( buffer == null )
    {
    throw new EncoderException( I18n.err( I18n.ERR_04023 ) );
    }

    buffer.put( UniversalTag.SEQUENCE.getValue() );
    buffer.put( TLV.getBytes( seqLength ) );

    BerValue.encode( buffer, getFlags() );

    return buffer;
    }


    /**
 * {@inheritDoc}
 */
    @Override
    public byte[] getValue()
    {
    if ( value == null )
    {
    try
    {
    computeLength();
    ByteBuffer buffer = ByteBuffer.allocate( valueLength );

    value = encode( buffer ).array();
    }
    catch ( Exception e )
    {
    return null;
    }
    }

    return value;
    }


    /**
 * {@inheritDoc}
 */
    @Override
    public Asn1Object decode( byte[] controlBytes ) throws DecoderException
    {
    ByteBuffer buffer = ByteBuffer.wrap( controlBytes );
    LdapServerPolicyHintsOidContainer container = new
LdapServerPolicyHintsOidContainer( this, getCodecService() );
    DECODER.decode( buffer, container );
   
    return this;
    }


    /**
 * {@inheritDoc}
 */
    @Override
    public int getFlags()
    {
    return getDecorated().getFlags();
    }


    /**
 * {@inheritDoc}
 */
    @Override
    public void setFlags( int flags )
    {
    getDecorated().setFlags( flags );
    }
}


- A container in the api-ldap-extras-codec module :


import org.apache.directory.api.asn1.ber.AbstractContainer;
import org.apache.directory.api.ldap.codec.api.LdapApiService;


/**
 * A container for the LdapServerPolicyHintsOid request control.
 */
public class LdapServerPolicyHintsOidContainer extends AbstractContainer
{
    

Re: LDAP API 1.0.0 - support for Java 6?

[Emmanuel Lécharny]

I would also add that the last version that support Java 6 - would you
really need it - is LDAP API 1.0.0-M31.


Le 28/06/2017 à 10:57, Emmanuel Lécharny a écrit :
> Thanks for the response, Stefan.
>
>
> Christian, FTR, the LDAP API now requires java 7, and won't build with
> Java 6, unless we revert numerous changes we have introduced (mainly
> about the diamond <> operator being widely used in the code). I don't
> mean it would be impossible, but it would be tedious... In any case,
> that would be on you, we don't support anymore Java 6.
>
>
> There are also other reasons, like the cryptography supported by Java 6
> vs Java 7 (see
> http://docs.oracle.com/javase/7/docs/technotes/guides/security/enhancements-7.html)
>
>
> Hope it helps
>
>
> Le 28/06/2017 à 09:44, Cristian Senchiu a écrit :
>> Thank you Stefan!
>> Somehow I totally overlooked that part.
>>
>> Regards,
>> Cristian.
>>
>>
>> Cristian Senchiu
>> Software Research & Development
>>
>> Viamedici Software GmbH
>> Herzstr. 14
>> 76275 Ettlingen
>> Germany
>>
>> Phone:+49/7243/9498-59
>> Fax:+49/7243/9498-99
>>
>> e-mail:c.senc...@viamedici.de
>> URL:www.viamedici.de
>>
>> HRB 362615, Amtsgericht Mannheim
>> Geschaeftsfuehrer: Juergen Mueller
>> -Original Message-
>> From: Stefan Seelmann [mailto:m...@stefan-seelmann.de]
>> Sent: Tuesday, June 27, 2017 9:06 PM
>> To: api@directory.apache.org
>> Subject: Re: LDAP API 1.0.0 - support for Java 6?
>>
>> On 06/27/2017 12:31 PM, Cristian Senchiu wrote:
>>> Hello,
>>>
>>> Just a short question: is there any distribution that can be used for Java 
>>> 6?
>> No, LDAP API 1.0.0 only works with Java 7 and 8 (and maybe 9?).
>>
>>> In the "Developer Guide > Coding standards" 
>>> (http://directory.apache.org/api/developer-guide.html) that Java 6 is used 
>>> to build the project.
>> This just talks about "new" language features to use :)
>>
>> Otherwise https://directory.apache.org/api/java-api.html says "This API 
>> requires Java 7 or upper."
>>
>> Kind Regards,
>> Stefan
>>

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: LDAP API 1.0.0 - support for Java 6?

[Emmanuel Lécharny]

Thanks for the response, Stefan.


Christian, FTR, the LDAP API now requires java 7, and won't build with
Java 6, unless we revert numerous changes we have introduced (mainly
about the diamond <> operator being widely used in the code). I don't
mean it would be impossible, but it would be tedious... In any case,
that would be on you, we don't support anymore Java 6.


There are also other reasons, like the cryptography supported by Java 6
vs Java 7 (see
http://docs.oracle.com/javase/7/docs/technotes/guides/security/enhancements-7.html)


Hope it helps


Le 28/06/2017 à 09:44, Cristian Senchiu a écrit :
> Thank you Stefan!
> Somehow I totally overlooked that part.
>
> Regards,
> Cristian.
>
>
> Cristian Senchiu
> Software Research & Development
>
> Viamedici Software GmbH
> Herzstr. 14
> 76275 Ettlingen
> Germany
>
> Phone:+49/7243/9498-59
> Fax:+49/7243/9498-99
>
> e-mail:c.senc...@viamedici.de
> URL:www.viamedici.de
>
> HRB 362615, Amtsgericht Mannheim
> Geschaeftsfuehrer: Juergen Mueller
> -Original Message-
> From: Stefan Seelmann [mailto:m...@stefan-seelmann.de]
> Sent: Tuesday, June 27, 2017 9:06 PM
> To: api@directory.apache.org
> Subject: Re: LDAP API 1.0.0 - support for Java 6?
>
> On 06/27/2017 12:31 PM, Cristian Senchiu wrote:
>> Hello,
>>
>> Just a short question: is there any distribution that can be used for Java 6?
> No, LDAP API 1.0.0 only works with Java 7 and 8 (and maybe 9?).
>
>> In the "Developer Guide > Coding standards" 
>> (http://directory.apache.org/api/developer-guide.html) that Java 6 is used 
>> to build the project.
> This just talks about "new" language features to use :)
>
> Otherwise https://directory.apache.org/api/java-api.html says "This API 
> requires Java 7 or upper."
>
> Kind Regards,
> Stefan
>

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: Immutable SyntexCheckers

[Emmanuel Lécharny]

Le 20/03/2017 à 08:20, Stefan Seelmann a écrit :
> On 03/20/2017 08:12 AM, Emmanuel Lécharny wrote:
>>
>> Le 20/03/2017 à 07:37, Stefan Seelmann a écrit :
>>> On 03/20/2017 02:10 AM, Emmanuel Lécharny wrote:
>>>> public class BooleanSyntaxChecker extends SyntaxChecker
>>>> {
>>>> /**
>>>>  * A static instance of BooleanSyntaxChecker
>>>>  */
>>>> public static final BooleanSyntaxChecker INSTANCE = new
>>>> BooleanSyntaxChecker( SchemaConstants.BOOLEAN_SYNTAX );
>>>>
>>>> /** A static instance of the builder */
>>>> private static final Builder BUILDER_INSTANCE = new Builder();
>>>> /**
>>>>  * @return An instance of the Builder for this class
>>>>  */
>>>> public static Builder builder()
>>>> {
>>>> return BUILDER_INSTANCE;
>>>> }
>>> Hm, why a static builder? As it is not immutable there's a chance of
>>> race condition in case two threads use it concurrently.
>> That can't happen, because we have :
>>
>> private static final Builder BUILDER_INSTANCE = new Builder();
>>
>> that is guaranteed to be built during the class loading.
> I agree about the creation of the builder instance.
>
> But if two threads *use* it:
> 1. thread 1 calls builder()
> 2. thread 2 calls builder() and gets the same builder instance
> 3. thread 1 calls setOid("1.1.1")
> 4. thread 2 calls setOid("2.2.2")
> 5. thread 1 calls build() and may get an SC with OID "2.2.2"!

Good catch...

/**
 * @return An instance of the Builder for this class
 */
public static Builder builder()
{
return new Builder();
}

would solve the issue, correct ?

(somtime, trying to verdue is wrong).


>
>

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: Immutable SyntexCheckers

[Emmanuel Lécharny]

Le 20/03/2017 à 07:37, Stefan Seelmann a écrit :
> On 03/20/2017 02:10 AM, Emmanuel Lécharny wrote:
>> public class BooleanSyntaxChecker extends SyntaxChecker
>> {
>> /**
>>  * A static instance of BooleanSyntaxChecker
>>  */
>> public static final BooleanSyntaxChecker INSTANCE = new
>> BooleanSyntaxChecker( SchemaConstants.BOOLEAN_SYNTAX );
>>
>> /** A static instance of the builder */
>> private static final Builder BUILDER_INSTANCE = new Builder();
>> /**
>>  * @return An instance of the Builder for this class
>>  */
>> public static Builder builder()
>> {
>> return BUILDER_INSTANCE;
>> }
> Hm, why a static builder? As it is not immutable there's a chance of
> race condition in case two threads use it concurrently.

That can't happen, because we have :

private static final Builder BUILDER_INSTANCE = new Builder();

that is guaranteed to be built during the class loading.

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: Immutable SyntexCheckers

[Emmanuel Lécharny]

Le 19/03/2017 à 17:47, Emmanuel Lecharny a écrit :
> Thanks, Stefan.
>
> I'll have a look at generics tonite.
>
> Regarding the need of a builder for each class, I think it would help
> habing a consistent system across all the SCs.
>
> Otherwise, this idea should apply to the other schema objects.
>
>
> Le dim. 19 mars 2017 à 10:58, Stefan Seelmann <m...@stefan-seelmann.de> a
> écrit :
>
>> On 03/17/2017 11:00 AM, Emmanuel Lécharny wrote:
>> > The only requirement is that each SC has its own builder (we can't put
>> > this code in the abstract SC, because it's abstract...)
>
>> With some generics magic it should at least be possible to move common
>> stuff (setOid) to the parent.

I come with that :

in SyntaxChecker base class :

   
public abstract class SyntaxChecker extends LoadableSchemaObject
{
...
/**
 * A static Builder for this class
 */
public abstract static class SCBuilder
{
/** The SyntaxChecker OID */
protected String oid;
   
/**
 * The Builder constructor
 */
protected SCBuilder( String oid )
{
this.oid = oid;
}
   
   
/**
 * Set the SyntaxChecker's OID
 *
 * @param oid The OID
 * @return The Builder's Instance
 */
public SCBuilder setOid( String oid )
{
this.oid = oid;
   
return this;
}
   
public abstract SC build();
}


In BooleanSyntaxChecker inherited class :

public class BooleanSyntaxChecker extends SyntaxChecker
{
/**
 * A static instance of BooleanSyntaxChecker
 */
public static final BooleanSyntaxChecker INSTANCE = new
BooleanSyntaxChecker( SchemaConstants.BOOLEAN_SYNTAX );
   
/** A static instance of the builder */
private static final Builder BUILDER_INSTANCE = new Builder();
   
/**
 * A static Builder for this class
 */
public static class Builder extends SCBuilder
{
/**
 * The Builder constructor
 */
private Builder()
{
super( SchemaConstants.BOOLEAN_SYNTAX );
}
   
   
/**
 * Create a new instance of BooleanSyntaxChecker
 * @return A new instance of BooleanSyntaxChecker
 */
@Override
public BooleanSyntaxChecker build()
{
return new BooleanSyntaxChecker( oid );
}
}

   
/**
 * Creates a new instance of BooleanSyntaxChecker.
 */
private BooleanSyntaxChecker( String oid )
{
super( oid );
}

   
/**
 * @return An instance of the Builder for this class
 */
public static Builder builder()
{
return BUILDER_INSTANCE;
}

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Immutable SyntexCheckers

[Emmanuel Lécharny]

Hi guys,


last week-end, I worked on adding a way to get a static instance of
SyntaxCheckers, instead of having to create a new instance every now and
then. As most of those SC aren't going to be modified during the
lifetime of an application, it makes a lot fo sense to have it
constructed once, and only once.


First let me summarize their lifecycle.


SC (SyntaxChecker) are associated with a LDAP Syntax, and are helper
classes used to check that a value is correct, accordingly to the
AttributeType syntax. We have more or less a hundred of such objects.
Most of them are defined in the code base, and will never change, but a
few can take a parameter, like teh TelephoneNumber that can use a regexp
as a matcher.

We wanted to be able to 'inject' some new SC dynamiclaly in the server,
by using a Java class that implements a new checker (this actually
works, but it's not really use as of today). The whole idea was to make
it dead simple - sort of - to extend the Schema, adding application
driven Schema elements. Bottom line, the mechanism is in place.


Now, when do we use those SC ? When we need to check a value. In this
case, we know about the value' AttributeType, and this AT knwos about
its Syntax, which is associated with a SC. The instance are created when
we load the schema at startup, as we store the FQCN of each SC in the
Schema :


dn: m-oid=1.3.6.1.4.1.1466.115.121.1.7,ou=syntaxCheckers,cn=system,ou=schema
m-oid: 1.3.6.1.4.1.1466.115.121.1.7
m-fqcn:
org.apache.directory.api.ldap.model.schema.syntaxCheckers.BooleanSyntaxChecker
objectclass: metaSyntaxChecker
objectclass: metaTop
objectclass: top
creatorsname: uid=admin,ou=system

The relation between a Ldap Syntax and its associated SC is the OID :
they have the same. So when we load the LdapSyntax, we class load its
associated SC. As a matter of fact, LdapSyntax are just descriptive,
when SC are executable.


That being said, there is not much of a reason to have the SC being
mutable. Even for the very few ones that can use a configuration - like
a regexp -, once created, they don't change.


So I changed the existing SC code by adding a static INSTANCE, which is
a reference to the instanciated SC. You don't need anymore to create a
new instance when you need it, you just pull the INSTANCE.


That caused some issue in some tests, that were creating new instances
of a SC, but with a different OID. Using INSTANCE was breaking the
tests, because those tests were expecting a different OID. Actually, the
test was faulty, we should have created a totally new SC instead of
redefining and existing one, but well, that life and it raised a
concern. And this concern was even more important in the tests using teh
TelephoneNumber SC, because you can inject new regexp into it...

So we fixed the tests, and now, it's time to think about a better
solution, where the SC are completely immutable.


The idea is to use internal Builders :


public class BooleanSyntaxChecker extends SyntaxChecker
{

/**
 * A static instance of BooleanSyntaxChecker
 */
public static final BooleanSyntaxChecker INSTANCE = new
BooleanSyntaxChecker( SchemaConstants.BOOLEAN_SYNTAX );

/** A static instance of the builder */
private static final Builder BUILDER_INSTANCE = new Builder();

/**
 * A static Builder for this class
 */
public static class Builder
{
/** The BooleanSyntaxChecker OID */
private String oid = SchemaConstants.BOOLEAN_SYNTAX;
   
/**
 * The Builder constructor
 */
private Builder()
{
// Nothing to do
}
   
   
/**
 * Set the SyntaxChecker's OID
 *
 * @param oid The OID
 * @return The Builder's Instance
 */
public Builder setOid( String oid )
{
this.oid = oid;
   
return this;
}
   
   
/**
 * Create a new instance of BooleanSyntaxChecker
 * @return A new instance of BooleanSyntaxChecker
 */
public BooleanSyntaxChecker build()
{
return new BooleanSyntaxChecker( oid );
}
}
   
/**
 * Creates a new instance of BooleanSyntaxChecker.
 */
private BooleanSyntaxChecker( String oid )
{
super( oid );
}

   
/**
 * @return An instance of the Builder for this class
 */
public static Builder builder()
{
return BUILDER_INSTANCE;
}

The constructor is now private, so you can't instanciate the class. What
you have to do is either to get the static INSTANCE, and you get an
immutable and static version of the class, or you 'build' a completely
new instance using code like :


BooleanSyntaxChecker checker = BooleanSyntaxChecker.builder().build();

(which is actually the same as the static INSTANCE, but as a different
object), or :

BooleanSyntaxChecker checker =
BooleanSyntaxChecker.builder().setOid( 

AttriuteType/ObjectClass mutable/immutable status

[Emmanuel Lécharny]

Hi !

last week, while looking at the AttributeType class, I realized that it
comes with two flavors : immutable (AttributeType) and mutable
(MutableAttribuetType). The problem being that the immutable class
cannot be initialized at all, except if you just want to set its OID.

This is problematic, especially since we don't have a factory to
generate an immutable instance (remember that such object is very
unlikely to be changed).


I think there is a design issue here, and this is also true for the
ObjectClass/MutableObjectClass classes. There are some solutions :


1) Create a SchemaObject factory, that creates immutable classes.
Mutable classes can still be created directly

2) Get rid of the immutable classes, that aren't used anywhere. We
currently use the MutableAttributeType/MutableObjectClass when we parse
schema elements strings anyway.


In order to limit the visibility of setters, we could also make the
mutable class an interface, and only expose getters.


IMHO, I don't think that having immutable classes is really a must, and
it makes everything a bit too complex. We could add a factory, for the
sake of simplicity. This factory can take a schema object description (a
String) as a parameter, or a set of parameters :

SchemaObjectFactory.create( "attributetype ( 1.2.3.4 NAME
'name0'\n\tEQUALITY matchingRule0\n\tSYNTAX
2.3.4.5{512}\n\tCOLLECTIVE\n\tUSAGE userApplications )" )


or


SchemaObjectFactory.createAttributeType( "1.2.3.4", "matchingRule0",
"2.3.4.5{512}", TypeEnum.COLLECTIVE, UsageEnum.USER_APPLICATION, "name0" );


(you get the idea).

wdyt ?

Side note : that would be for 2.0

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

MIA for a bit...

[Emmanuel Lécharny]

Hi !


just for you to know, I may be MIA for a while, or at least way less
responsive : My wife just gave birth to our wonderful daughter today,
and I'm afraid it's going to be our priority number one in the next few
weeks :-)


Thanks !

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Apache Directory/Studio/Fortress/Kerby/... blog

[Emmanuel Lécharny]

Hi guys,


we have the possibility to ask for a dedicated Apache blog for our
projects (https://www.apache.org/dev/project-blogs). I think it would
help a bit gaining some exposure for them, at least in a more extended
way than siply tweeting about what we do.


I'd like to ask for such a blog, any objection ?


Thanks !


-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: Apacheds

[Emmanuel Lécharny]

Le 06/02/2017 à 07:52, surabhi.sha...@non.keysight.com a écrit :
> Hi,
>
> Please help with the java code to copy an existing user to a new existing 
> group.
>
> I can move the user to new group but I want that user to reside in both the 
> groups.

Hi,

you probably need to read those pages first :

http://www.catb.org/esr/faqs/smart-questions.html#beprecise
http://www.catb.org/esr/faqs/smart-questions.html#explicit

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: partition question

[Emmanuel Lécharny]

Le 03/02/2017 à 14:04, Ralph Carlson Jr a écrit :
> I have a question about creating partitions. Is there any way to create a
> partition in apacheds using java api like (
> http://directory.apache.org/apacheds/gen-docs/2.0.0-M23/apidocs/) or the
> standard java ldap api's. I understand I will have to restart the service.
> I know and have created them using Apache Directory Studio but I assume
> that program must be using some java api to create the partitions. The only
> examples I can find online are using older versions of the api and supply
> local folder paths which I never give Apache Directory Studio when I use it
> to create partitions.
Hi Raph,

this is not exactly a question for the API mailing list, but I can see
why you are asking there. The answer is not straight forward : the API
is somehow Server agnostic, so, no, there is no *simple* way to create
an ApacheDS partition using the api.

Having said that, it is be possible to create a partition in a ApacheDS
config using the API. FTR, Studio can do that routinely. The class in
charge of loading teh configuration in Studio is ;

http://svn.apache.org/viewvc/directory/studio/trunk/plugins/apacheds.configuration/src/main/java/org/apache/directory/studio/apacheds/configuration/jobs/LoadConfigurationRunnable.java?revision=1686070=markup

and teh one in charge of saving it is

http://svn.apache.org/viewvc/directory/studio/trunk/plugins/apacheds.configuration/src/main/java/org/apache/directory/studio/apacheds/configuration/jobs/SaveConfigurationRunnable.java?revision=1670493=markup

The entry point can be either readSingleFileConfiguration( File ) if you
have all teh config stored in a single file, and
readMultiFileConfigureation( File ) if it's a hierarchy of LDIF files.

Once the partition has been loaded, you have access to any part of it as
Java objects (xxxBean), like PartitionBean, IndexBean, etc. (the
complete list is available here :
http://svn.apache.org/viewvc/directory/apacheds/trunk/server-config/src/main/java/org/apache/directory/server/config/beans/).
Adding a partition is all about feeding  a new instance of a
Jdbm/MavibotPartition :

JdbmPartitionBean newPartitionBean = new JdbmPartitionBean();
newPartitionBean.setPartitionId( newId );
try
{
newPartitionBean.setPartitionSuffix( new Dn( "dc=" + newId +
",dc=com" ) ); //$NON-NLS-1$ //$NON-NLS-2$
}
catch ( LdapInvalidDnException e1 )
{
// Will never happen
}

// Default values
newPartitionBean.setPartitionCacheSize( 100 );
newPartitionBean.setJdbmPartitionOptimizerEnabled( true );
newPartitionBean.setPartitionSyncOnWrite( true );
newPartitionBean.setContextEntry( getContextEntryLdif(
newPartitionBean.getPartitionSuffix() ) );
List indexes = new ArrayList();
indexes.add( createJdbmIndex( "apacheAlias", 100 ) ); //$NON-NLS-1$
indexes.add( createJdbmIndex( "apacheOneAlias", 100 ) );
//$NON-NLS-1$
indexes.add( createJdbmIndex( "apacheOneLevel", 100 ) );
//$NON-NLS-1$
indexes.add( createJdbmIndex( "apachePresence", 100 ) );
//$NON-NLS-1$
indexes.add( createJdbmIndex( "apacheRdn", 100 ) ); //$NON-NLS-1$
indexes.add( createJdbmIndex( "apacheSubAlias", 100 ) );
//$NON-NLS-1$
indexes.add( createJdbmIndex( "apacheSubLevel", 100 ) );
//$NON-NLS-1$
indexes.add( createJdbmIndex( "dc", 100 ) ); //$NON-NLS-1$
indexes.add( createJdbmIndex( "entryCSN", 100 ) ); //$NON-NLS-1$
indexes.add( createJdbmIndex( "entryUUID", 100 ) ); //$NON-NLS-1$
indexes.add( createJdbmIndex( "krb5PrincipalName", 100 ) );
//$NON-NLS-1$
indexes.add( createJdbmIndex( "objectClass", 100 ) ); //$NON-NLS-1$
indexes.add( createJdbmIndex( "ou", 100 ) ); //$NON-NLS-1$
indexes.add( createJdbmIndex( "uid", 100 ) ); //$NON-NLS-1$
newPartitionBean.setIndexes( indexes );


and then add the newly created partition into the DirectoryServiceBean :

List partitions =
directoryServiceBean.getPartitions();
   
// Adding the partition
partitions.add( newPartitionBean );
   
directoryServiceBean.setPartitions( partitions );



-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

LDAP API 1.0 status

[Emmanuel Lécharny]

Hi guys,


a quick update on what's going on:  there is not much change in the
current code, beside a few modifications done in the Ldap


- Relaxed the Filter parser to allow spaces to be present when it's not
ambiguous (like '(  &  (...' is now accepted)

- The PersistentSearch codec was buggy

- Added a isSecured() metod in the LdapNetworkConnection class

- Made it so every operation connect to the ldap server if it's not
already connected. This is important for people wanting to apply an
operation over an anonymous connection

- Fixed the TrustmanagerFactory

- Added a LdapNetworkConnection that takes a TrustManager as a
parameter, to allow users to create a SSL connection immediately

- Made ApacheDS working with the API (it was broken for quite some time)


Some effort has been put on teh API documentation - thanks to Shawn for
the proof reading - but there is stilla  lot to do. I'm currently
working on the Security pages
(http://directory.staging.apache.org/api/user-guide/5-ldap-security.html
and the associated pages). My current focus is on SASL, the SSL and
StartTLS pages are complete - well, unless we have something to add ;-)...


Feel free to review them !


TODO before 1.0 :

We need to improve the Trustmanagerfactory to check the server's
certificate by default, currently we don't check anything, this is not
good. Stefan already mailed about the issue.


Many thanks !


-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: cURRENT uSER gUID XTATUS

[Emmanuel Lécharny]

I'm currently reworking the Security part, and AFAICT, here are the
chapters that need to be written :


*  [5.1 - SSL (e)](user-guide/5.1-ssl.html)
*  [5.2 - StartTLS (e)](user-guide/5.2-start-tls.html)
*  [5.3 - Password handling](user-guide/5.3-password-handling.html)
*  [5.4 - SASL Bind](user-guide/5.4-sasl-bind.html)
*  [5.5 - Certificates](user-guide/5.5-certificates.html)
*  [5.6 - ACI and ACLs (e)](user-guide/5.6-aci-and-acls.html)

The last one on ACL/ACIs will only be an introduction, as there is
nothing really available atm in the API.


- SSL is about...SSL ;-)

- StartTLS will explain hw to start a TLS communication and what it implies

- Password section is about the changePassword operation

- Certificates is about authent using certificates


I may not add some of those sections if there is not enough meat in teh
API to cover them properly, so consider that to be just a proposal.


Please feel free to comment or add anything that you think should be
covered.

Here is the introduction on security :
http://directory.staging.apache.org/api/user-guide/5-ldap-security.html


Le 01/01/2017 à 16:31, Shawn McKinney a écrit :
>> On Jan 1, 2017, at 5:04 AM, Emmanuel Lécharny <elecha...@gmail.com> wrote:
>>
>> now that you have spent some time reading and fixing the current (and
>> incomplete) DLAP API User Guide, do you have any general remark related
>> to its content, structure, or whatever ?
>>
> Overall structure is pretty good.  It’s broken down in a reasonable way -- 
> basic, advanced, etc, and the subsections are ordered well.  Nav is easy 
> enough although a (master) table of contents listing all of the pages, 
> descriptions and status (finished or not) would be helpful.
>
> Content is mixed.  What’s there is quite good but many things not covered.  
> For example, security isn't covered.  Of course I suggest it be completed 
> ASAP.  To be fair authN’s covered in the bind/unbind section but SSL/TLS & 
> authZ isn't. 
>
> We need our code samples to be downloadable.  One of my fav LDAP books, “LDAP 
> Programming with Java” (Weltman, Dahbura) was released before Internet code 
> dist was the norm but nevertheless included a CD containing all of the code 
> samples.  I literally built my first 5 LDAP programs with these examples.  
> The book is probably one of the reasons the Netscape Java LDAP API gained 
> popularity.
>
> Perhaps we start a github project that includes samples such as this.  Or, 
> even manage a new repo in our project?
>
> Thanks,
> Shawn

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: cURRENT uSER gUID XTATUS

[Emmanuel Lécharny]

Le 01/01/2017 à 16:31, Shawn McKinney a écrit :
>> On Jan 1, 2017, at 5:04 AM, Emmanuel Lécharny <elecha...@gmail.com> wrote:
>>
>> now that you have spent some time reading and fixing the current (and
>> incomplete) DLAP API User Guide, do you have any general remark related
>> to its content, structure, or whatever ?
>>
> Overall structure is pretty good.  It’s broken down in a reasonable way -- 
> basic, advanced, etc, and the subsections are ordered well.  Nav is easy 
> enough although a (master) table of contents listing all of the pages, 
> descriptions and status (finished or not) would be helpful.
>
> Content is mixed.  What’s there is quite good but many things not covered.  
> For example, security isn't covered.  Of course I suggest it be completed 
> ASAP.  To be fair authN’s covered in the bind/unbind section but SSL/TLS & 
> authZ isn't. 

On my list for next week. Call it a new year good resolution :-)

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: LDAP API 1.0-GA preparation

[Emmanuel Lécharny]

Le 01/01/2017 à 16:47, Shawn McKinney a écrit :
>> On Jan 1, 2017, at 3:47 AM, Pierre Smits  wrote:
>>
>> First of all: Happy New Year. May it be an exciting and interesting one!
>>
>> It seems to me that having user guides as static pages we create the
>> impression that they are applicable to any version available to the
>> adopters of our products (old, superseded versions and the latest
>> available). We know that that isn't true. As our products evolve, so do our
>> user guides.
>>
>> Would it not be better to recreate the pages in our wiki and per page state
>> to which page they are applicable?
> Thanks Pierre, same to you!
>
> wrt recreation of pages:
>
> It’s good to have content available both online/offline and that’s easy to 
> use.  If we were to move away from the website I’d point towards the markdown 
> format (.md), popularized on github projects rather than yet another HTML 
> website format (wiki).

The current format is markdown, even if the file extension is .mdtext.
>
> But, the act of moving a document this large will consume a lot of time and 
> I’m not convinced it’s where we should be spending our time.

I'd rather complete what we have, then try t produce a pdf out of it
should be easy.
>
> The most important thing is the content is captured in one place, and usable, 
> we can move it later, if need be.

indeed !

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org