directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Mattmann <>
Subject Re: Help connecting phpldapadmin to ApacheDS 1.5.1
Date Sat, 16 May 2009 17:24:51 GMT

Hi Kiran,

Thanks. I've attached my server.xml and my custom EDRN schema file. Comments

ayyagarikiran wrote:
> As you mentioned these are not operational attributes.
> Did you try using any other LDAP client( e.x Apache Directory Studio)?
> If not can you try any other and see the difference

Interestingly enough Apache Directory Studio seems to work fine. That is,
when I bind as Directory Studio and try to modify my entry attributes it
allows me to, and AFAICT, it only allows me to edit the attributes and
entries that I should be able to. PLA; however, is reporting something

We've also instrumented PLA all over. Here is what one of our developers,
Andrew Hart, made me aware of:

> PLA has a class called LdapServer basically defines a buncha ways to talk
> to the ldap server. There are 4 functions for getting attributes for a dn,
> they are:
> * getDnSysAttrs: gets the operational attributes for a nentry... stuff
> that is automatically set by ldap server.... createTimestamp,
> creatorsName, etc
> * getCustomDnSysAttrs: gets the 'user-defined' operational attributes for
> an entry. these attributes should be treaded as internal attributes
> (nsroleDN, passwordExpirationTime,passwordAllowChangeTime, etc
> * getCustomDnAttrs: gets the user defined operational attributes for an
> entry, these should be treated as regular attributes
> * getDnAttrs: gets the attributes/values of an entry... cn sn dn etc
> The results of each of those calls is placed into its own array so its
> like:
> $dnsysattrs = ldapserver->getDnSysAttrs(this->dn)
> and so on for the other 3. Then they are all merged into a single array
> called attrs_vals. That array gets iterated on... each attr-val pair is
> checked. Tf the current value came from the 'internal/system' array then
> it should naturally be marked as readonly since you don't want users
> setting their own password expiration time and so on. 
> Theoretically then these 4 arrays should contain different information
> (ie: the result of the sys/int array should not look like the result of
> the regular attr call). In practice, thats not whats happening. The
> getDnSysAttrs has information which looks great and is differrent from the
> other 3. So it is not the problem, its working fine.
> The other three however have exactly the same output thus when the array
> check comes around it sees that every regular attribute 'came from' the
> sys/int call in PLA and thus gets marked private.

So that's a detailed description of what we are seeing via PLA. Any clue?
Thanks to Andrew Hart for the detailed description.

Chris edrn.ldif server.xml 
View this message in context:
Sent from the Apache Directory Project mailing list archive at

View raw message