[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#6055) Samba4 need 'name' implementation like AD (RDN-Name)

michael@stroeder.com wrote:
> 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.

Since we're dealing with something unspecified, you can:

- be "strict": only allow the creation of this attribute when the naming 
attribute's syntax is (unspecified, I understand, but we live 
in a wild world)

- be "liberal": always allow the creation of this attribute by allowing 
it to contain any value

> 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?)

not exactly, as sets do not allow a placeholder for the naming 
attribute; maybe something like "this/entryRDN.ava{0}.value" if it 


> ...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.

Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
Office:  +39 02 23998309
Mobile:  +39 333 4963172
Fax:     +39 0382 476497
Email:   ando@sys-net.it