Re: schema design and schema restrictions
Yeah Andrew, I read the document you linked to before posting to this
list. Away from the subject, thank you for providing this info.
Now, another page:
http://ldap.akbkhome.com/index.php/objectclass/posixAccount.html
It says:
"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". "
I am not sure if the whole problem is due to comma (punctiaion). The way
I understood this statement was:
"An object class that doesn't have userPassword as MUST, is not be used
for authentication"
After you guys pointed this out, it might have been:
"An object class that doesn't have userPassword, "Should not" be used
for authentication".
But this is obvious. So I took the first one.
This is the reason I didn't want to use a shadowAccount as AUX to
inetOrgPerson. Hope this clarifies the matter.
Andrew Findlay wrote:
On Wed, Nov 26, 2008 at 05:31:59PM +0200, Buchan Milne wrote:
> On Wednesday 26 November 2008 17:03:55 Mansour Al Akeel wrote:
>
>> Thank you Michael, but posixAccount doesn't require the password, which
>> makes it not suitable for authentication.
>>
> But, inetOrgPerson (as it inherits from person) allows userPassword, so this
> is irrelevant.
>
It is also worth pointing out that making attributes mandatory
(using MUST in schema files) is usually a bad idea. It can
severely restrict your flexibility when creating entries, and
often leads to silly workarounds like creating objects with
dummy attribute values just to satisfy the rules.
This mistake was made in several of the early objectclass
definitions. One example is groupOfNames where the definition
makes it impossible to have an empty group.
You may find my Schema Design paper helpful:
http://www.skills-1st.co.uk/papers/ldap-schema-design-feb-2005/index.html
Andrew