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