ando@sys-net.it wrote:

----- abartlet@samba.org wrote:

...

Active Directory always presents an attribute 'name' that is always equal to the relative distinguished name. AD allows only one RDN, but I don't mind if this can be multi-valued for the multi-RDN case. It is equal to the value of the RDN as presented in the RDN.

This is not simply the subtype 'CN -> name', but a new attribute unrelated to the existing definition of 'name'.

I don't care what name is assigned to 'name', as I can easily remap attributes.

It would be great if this could be constructed such that it may be declared to be unique for a particular one-level search (also an AD requirement, but not one Samba4 requires or enforces at this time).

The only problem I see in defining such an attribute is that its syntax should allow the value of any syntax, so it should probably be octetString or something like that.

Why? IMO such an attribute type could be declared like any other attribute type. If its syntax does not match the syntax of the characteristic attribute invalidAttributeSyntax should be returned.

I wonder what the exact requirements for the implementation within slapd are and some very rough ideas as food for thought:

1. slapd shall enforce uniqueness on one-level => I'd vote for an additional feature of slapo-unique to define the scope of uniqueness in a very flexible way

2. Value of 'name' has to match the value of the characteristic attribute. Does this 1. has to be enforced within slapd or 2. could this be enforced within smbd? If 1. maybe the functionality/configuration of slapo-constraint could be extended to define things like this. (I've stumbled across ITS#5704. Isn't that already something like this?)

...more...?

In web2ldap's plugin classes I have implemented special treatment for non-compliant notation for the DN part of LDAP URLs to reference a DN based on an entry's DN:

. the entry's DN .. the entry's parent DN _ the best matching namingContext for the entry's DN

This strings can be appended to DNs. For example:

'ou=Users,_' would always refer to entry ou=Users below an arbitrary naming context.

'ou=My Stuff,.' could refer to a container below a user's entry

Maybe something like this could be helpful for an extended configuration of slapo-unique and slapo-constraint.

Hmm, also

As said only very rough ideas...

Ciao, Michael.