You are viewing a plain text version of this content. The canonical link for it is here.
Posted to api@directory.apache.org by Kevin Hale Boyes <kh...@surgeforward.com> on 2018/02/16 14:25:09 UTC
Operational Attributes
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);
When I iterate over the results and inspect the attributes of an entry
I don't find the operational attributes.
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());
But this fails now with an exception:
2018-02-16 07:18:52,034 WARN [NioProcessor-1] - The attribute
'usncreated' cannot be stored-DefaultEntry.<init>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.<init>(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.
Help would be appreciated.
Thanks,
Kevin.
Re: Operational Attributes
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 19/02/2018 à 16:10, Kevin Hale Boyes a écrit :
> On Mon, Feb 19, 2018 at 7:42 AM, Emmanuel Lécharny <el...@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<String> raSet = new LinkedHashSet<String>();
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<AttributeType> opAtds =
SchemaUtils.getOperationalAttributeDescriptions( entry
.getBrowserConnection().getSchema() );
Collection<String> 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
Posted by Kevin Hale Boyes <kh...@surgeforward.com>.
On Mon, Feb 19, 2018 at 7:42 AM, Emmanuel Lécharny <el...@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.
I just needed to check the "Fetch operational attributes while browsing"
feature.
I was looking at the source to figure out how it does it but couldn't quite
piece it all together without more time.
> Which server it is ?
>
Looks like Active Directory. The attributes shown on the Root DSE show V51,
V60, V61R2 and ADAM.
Kevin.
Re: Operational Attributes
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 19/02/2018 à 15:18, Kevin Hale Boyes a écrit :
> On Sat, Feb 17, 2018 at 5:57 AM, Emmanuel Lécharny <el...@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
Posted by Kevin Hale Boyes <kh...@surgeforward.com>.
On Sat, Feb 17, 2018 at 5:57 AM, Emmanuel Lécharny <el...@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.
> 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.
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.
> 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.
>
See above - didn't work.
> 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.
I might not go that far since I have a working solution of specifying all
attribute names.
Thanks for you time and effort!!
Kevin.
Re: Operational Attributes
Posted by Emmanuel Lécharny <el...@gmail.com>.
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.<init>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.<init>(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