On registration, the sponsor ID should be stored

[benel]

... in the member's profile (in LDAP).

[Darkheir]

To store the sponsor ID, we could consider 2 options:

The first one is to use an existing attribute with a meaning close to the sponsor ID.

• There is an attribute called "owner" existing in LDAP. Looking to its definition in the RFC4519 (LDAP: Schema for User Applications) we find: attributetype ( 2.5.4.32 NAME 'owner' SUP distinguishedName ) The 'owner' attribute type contains the distinguished names of objects that have an ownership responsibility for the object that is owned. Each owner's name is one value of this multi-valued attribute.
• An other attribute define in the RFC4524 is the "manager" : attributetype ( 0.9.2342.19200300.100.1.10 NAME 'manager' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) The 'manager' attribute specifies managers, by distinguished name, of the person (or entity).

For the sponsor ID, I think that the owner attribute is closer to what we want.

The other option that we have is to define a new attribute.

To define a new attribute, we need to obtain an unique OID (the id of the object) through a process via IANA (Internet Assigned Numbers Authority). Now lets see the syntax to define a new attribute with an example: attributetype ( 2.5.4.3 NAME ( 'cn' 'commonName' ) SUP name )

• attributetype indicate that we are defining an attribute.
• 2.5.4.3 is the OID of the attribute.
• NAME ( 'cn' 'commonName' ) is the name(s) of the attribute
• SUP name indicate that the attribute has a PARENT (or SUPerior) attribute (name in this example). The child always inherits the properties of the parent (or SUPerior) attribute (and itself may have additional properties). The SUP entry can use either a 'name' or an OID.

Let's have a look to the superior attribute "name" to know its properties : attributetype ( 2.5.4.41 NAME 'name' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )

• EQUALITY caseIgnoreMatch indicates how this (and any child attributes) will behave when used in a search filter e.g. (cn=jimbob) and no wildcards exist in the search.
• SUBSTR caseIgnoreSubstringsMatch indicates how this (and any child attributes) will behave when used in a search filter which uses a substring e.g. (cn=jim*) (cn is a child of name) and contains one or more wildcards.
• SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} is an OID which defines the data type and what rules (data validation) are applied to the data. In this case the OID defines it to be a Directory String type in the UTF-8 form

We can find all the parameters to define an attribute in the rfc2252 section 4.2.

Sources

• Source of the rfc4519 : http://www.networksorcery.com/enp/rfc/rfc4519.txt
• Source of the rfc4524 : http://www.networksorcery.com/enp/rfc/rfc4524.txt
• Source of the rfc2252 : http://www.zytrax.com/books/ldap/apc/rfc2252.txt
• List of attributes defines by the IANA: http://www.iana.org/assignments/ldap-parameters

[moulabba]

owner is an attribute of the device class. manager is an attribute of the inetOrgPerson class. LDAP servers don't check that there is an account owner.