Roo J Solutions Ltd
LDAP Schema | Roo J Solutions Ltd. >>>
ldap objectclass
Roojs :: LDAP :: ObjectClasses ::

Object Class: posixGroup

ID: nisSchema.2.2

Abstraction of a group of accounts
The cn attribute, in posixGroup entries, contains the group's name.

It is suggested that uid and cn are used as the RDN attribute type for posixAccount and posixGroup entries, respectively.

An entry of class posixAccount, posixGroup, or shadowAccount without a userPassword attribute MUST NOT be used for authentication. The client should be returned a non-matchable password such as "x".

BNC Syntax: nisSchema.2.2 NAME 'posixGroup' 
SUP top 
STRUCTURAL  
MAY ( description $ memberUid $ userPassword ) 
MUST ( cn $ gidNumber )

rfc2307

Extends objectClass:

Attributes:

Must Have:
May Have:


Attribute:  cn 

(based on attribute  name)

Description:
This is the X.500 commonName attribute, which contains a name of an object. If the object corresponds to a person, it is typically the person's full name.

BNC Syntax: 2.5.4.3 NAME 'cn' SUP name EQUALITY caseIgnoreMatch

Syntax: Directory String

ID : 1.3.6.1.4.1.1466.115.121.1.15
A string in this syntax is encoded in the UTF-8 form of ISO 10646 (a superset of Unicode). Servers and clients MUST be prepared to receive encodings of arbitrary Unicode characters, including characters not presently assigned to any character set.

For characters in the PrintableString form, the value is encoded as the string value itself.

If it is of the TeletexString form, then the characters are transliterated to their equivalents in UniversalString, and encoded in UTF-8 [9].

If it is of the UniversalString or BMPString forms [10], UTF-8 is used to encode them.

Note: the form of DirectoryString is not indicated in protocol unless the attribute value is carried in binary. Servers which convert to DAP MUST choose an appropriate form. Servers MUST NOT reject values merely because they contain legal Unicode characters outside of the range of printable ASCII.

Example:

This is a string of DirectoryString containing #!%#@

 
BNC Syntax:

Equality Matching: caseIgnoreMatch

Description:

Servers SHOULD be capable of performing the following matching rules.

For all these rules, the assertion syntax is the same as the value syntax.

When performing the caseIgnoreMatch, caseIgnoreListMatch, telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match, multiple adjoining whitespace characters are treated the same as an individual space, and leading and trailing whitespace is ignored.

Clients MUST NOT assume that servers are capable of transliteration of Unicode values.

BNC Syntax: 

Substring Matching: caseIgnoreSubstringsMatch

Description:

The Substring Assertion is encoded according to the following BNF:

      substring = [initial] any [final]
      initial = value
      any = "*" *(value "*")
      final = value

The production is UTF-8 encoded string. Should the backslash or asterix characters be present in a production of , they are quoted as described in section 4.3.

Servers SHOULD be capable of performing the following matching rules, which are used in substring filters.

BNC Syntax:


 


Attribute:  description 

Description:
This attribute contains a human-readable description of the object.
A short informal explanation of special interests of a person or organisation. Overlap with businessCategory, organizationalStatus and title should be avoided.

Example:
 

Networking, distributed systems, OSI, implementation.


BNC Syntax: 2.5.4.13 NAME 'description' EQUALITY caseIgnoreMatch

Syntax: Directory String

ID : 1.3.6.1.4.1.1466.115.121.1.15
A string in this syntax is encoded in the UTF-8 form of ISO 10646 (a superset of Unicode). Servers and clients MUST be prepared to receive encodings of arbitrary Unicode characters, including characters not presently assigned to any character set.

For characters in the PrintableString form, the value is encoded as the string value itself.

If it is of the TeletexString form, then the characters are transliterated to their equivalents in UniversalString, and encoded in UTF-8 [9].

If it is of the UniversalString or BMPString forms [10], UTF-8 is used to encode them.

Note: the form of DirectoryString is not indicated in protocol unless the attribute value is carried in binary. Servers which convert to DAP MUST choose an appropriate form. Servers MUST NOT reject values merely because they contain legal Unicode characters outside of the range of printable ASCII.

Example:

This is a string of DirectoryString containing #!%#@

 
BNC Syntax:

Equality Matching: caseIgnoreMatch

Description:

Servers SHOULD be capable of performing the following matching rules.

For all these rules, the assertion syntax is the same as the value syntax.

When performing the caseIgnoreMatch, caseIgnoreListMatch, telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match, multiple adjoining whitespace characters are treated the same as an individual space, and leading and trailing whitespace is ignored.

Clients MUST NOT assume that servers are capable of transliteration of Unicode values.

BNC Syntax: 

Substring Matching: caseIgnoreSubstringsMatch

Description:

The Substring Assertion is encoded according to the following BNF:

      substring = [initial] any [final]
      initial = value
      any = "*" *(value "*")
      final = value

The production is UTF-8 encoded string. Should the backslash or asterix characters be present in a production of , they are quoted as described in section 4.3.

Servers SHOULD be capable of performing the following matching rules, which are used in substring filters.

BNC Syntax:


 


Attribute:  gidNumber 

Description: An integer uniquely identifying a group in an administrative domain


BNC Syntax: nisSchema.1.1 NAME 'gidNumber' EQUALITY integerMatch

Syntax: INTEGER

ID : 1.3.6.1.4.1.1466.115.121.1.27
Values in this syntax are encoded as the decimal representation of their values, with each decimal digit represented by the its character equivalent. So the number 1321 is represented by the character string "1321".
 
BNC Syntax:

Equality Matching: integerMatch

Description:

Servers SHOULD be capable of performing the following matching rules.

For all these rules, the assertion syntax is the same as the value syntax.

When performing the caseIgnoreMatch, caseIgnoreListMatch, telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match, multiple adjoining whitespace characters are treated the same as an individual space, and leading and trailing whitespace is ignored.

Clients MUST NOT assume that servers are capable of transliteration of Unicode values.

BNC Syntax: 



Attribute:  memberUid 

Description:


BNC Syntax: nisSchema.1.12 NAME 'memberUid' EQUALITY caseExactIA5Match

Syntax: IA5 String

ID : 1.3.6.1.4.1.1466.115.121.1.26
The encoding of a value in this syntax is the string value itself.
 
BNC Syntax:

Equality Matching: caseExactIA5Match

Description:

Servers SHOULD be capable of performing the following matching rules.

For all these rules, the assertion syntax is the same as the value syntax.

When performing the caseIgnoreMatch, caseIgnoreListMatch, telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match, multiple adjoining whitespace characters are treated the same as an individual space, and leading and trailing whitespace is ignored.

Clients MUST NOT assume that servers are capable of transliteration of Unicode values.

BNC Syntax: 



Attribute:  objectClass 

Description:
An LDAP server implementation SHOULD recognize the attribute types described in this section. The values of the objectClass attribute describe the kind of object which an entry represents. The objectClass attribute is present in every entry, with at least two values. One of the values is either "top" or "alias".

BNC Syntax: 2.5.4.0 NAME 'objectClass' EQUALITY objectIdentifierMatch

Syntax: OID

ID : 1.3.6.1.4.1.1466.115.121.1.38
Values in the Object Identifier syntax are encoded according to the BNF in section 4.1 for "oid".

Example:

1.2.3.4
cn

 
BNC Syntax:

Equality Matching: objectIdentifierMatch

Description:

Servers SHOULD be capable of performing the following matching rules.

For all these rules, the assertion syntax is the same as the value syntax.

If the client supplies a filter using an objectIdentifierMatch whose matchValue oid is in the "descr" form, and the oid is not recognized by the server, then the filter is Undefined.

BNC Syntax: 



Attribute:  userPassword 

Description:
from earlier rfc2256:
Passwords are stored using an Octet String syntax and are not encrypted. Transfer of cleartext passwords are strongly discouraged where the underlying transport service cannot guarantee confidentiality and may result in disclosure of the password to unauthorized parties.
from later rfc2307
An entry of class posixAccount, posixGroup, or shadowAccount without A userPassword attribute MUST NOT be used for authentication. The client should be returned a non-matchable password such as "x".

userPassword values MUST be represented by following syntax:

passwordvalue = schemeprefix encryptedpassword
schemeprefix = "{" scheme "}"
scheme = "crypt" / "md5" / "sha" / altscheme
altscheme = "x-" keystring
encryptedpassword = encrypted password

The encrypted password contains of a plaintext key hashed using the algorithm scheme.

userPassword values which do not adhere to this syntax MUST NOT be used for authentication. The DUA MUST iterate through the values of the attribute until a value matching the above syntax is found. Only if encryptedpassword is an empty string does the user have no password. DUAs are not required to consider encryption schemes which the client will not recognize; in most cases, it may be sufficient to consider only "crypt".

Below is an example of a userPassword attribute:

userPassword: {crypt}X5/DBrWPOQQaI

A future standard may specify LDAP v3 attribute descriptions to represent hashed userPasswords, as noted below. This schema MUST NOT be used with LDAP v2 DUAs and DSAs.

attributetype = attributename sep attributeoption
attributename = "userPassword"
sep = ";"
attributeoption = schemeclass "-" scheme
schemeclass = "hash" / altschemeclass
scheme = "crypt" / "md5" / "sha" / altscheme
altschemeclass = "x-" keystring
altscheme = keystring

Below is an example of a userPassword attribute, represented with an LDAP v3 attribute description:

userPassword;hash-crypt: X5/DBrWPOQQaI

A DUA MAY utilise the attributes in the shadowAccount class to provide shadow password service (getspnam() and getspent()). In such cases, the DUA MUST NOT make use of the userPassword attribute for getpwnam() et al, and MUST return a non-matchable password (such as "x") to the client instead.

BNC Syntax: 2.5.4.35 NAME 'userPassword' EQUALITY octetStringMatch

Syntax: Octet String

ID : 1.3.6.1.4.1.1466.115.121.1.40
Values in this syntax are encoded as octet strings.
Example:

secret

 
BNC Syntax:

Equality Matching: octetStringMatch

Description:
Servers which implement the extensibleMatch filter SHOULD allow the matching rule listed in this section to be used in the extensibleMatch. In general these servers SHOULD allow matching rules to be used with all attribute types known to the server, when the assertion syntax of the matching rule is the same as the value syntax of the attribute.

BNC Syntax: 







Contact me at alan@roojs.com - especially if you have some work for me :)