Hello all, I an new to LDAP, and I have a need to migrate the existing system to ldap as this will ease a bit the management for the new system implementation. I need to authenticate users for a web site, and for the internal system ( linux, windows stations .... etc). Now the available account objectclass is structural so I can not user inetorgperson with account as both are structural. In this case I decided to extend inetOrgPerson, and add username and password as a MUST attributes. This is because all the users have access to the web site and they need authentication, but some users will need to have access to the machines. In this case I will create a new objectClass (ie. accountInfo) which containts the info I need (home directory, shell, loginScript, .... etc).
The issue here is how do I restrict the accountInfo to be added under User ? This is in fact not only specific to this senario. I couldn't find any docs about how to prevent objectClass domain to be added under group ! Finally, how do other ldap admin deal with similar cases ? Any advice ?
thank you.
On Wednesday 26 November 2008 06:07:28 Mansour Al Akeel wrote:
Hello all, I an new to LDAP, and I have a need to migrate the existing system to ldap as this will ease a bit the management for the new system implementation. I need to authenticate users for a web site, and for the internal system ( linux, windows stations .... etc). Now the available account objectclass is structural
Sou you shouldn't use it, but intead the hostObject auxiliary objectclass provided in the ldapns.schema file shipped with pam_ldap.
[...]
This is in fact not only specific to this senario. I couldn't find any docs about how to prevent objectClass domain to be added under group !
There are two interpretations of this statement, please be more clear about this matter.
Regards, Buchan
Buchan Milne wrote:
On Wednesday 26 November 2008 06:07:28 Mansour Al Akeel wrote:
Hello all, I an new to LDAP, and I have a need to migrate the existing system to ldap as this will ease a bit the management for the new system implementation. I need to authenticate users for a web site, and for the internal system ( linux, windows stations .... etc). Now the available account objectclass is structural
Sou you shouldn't use it, but intead the hostObject auxiliary objectclass provided in the ldapns.schema file shipped with pam_ldap.
[...]
This is in fact not only specific to this senario. I couldn't find any docs about how to prevent objectClass domain to be added under group !
There are two interpretations of this statement, please be more clear about this matter.
Ok, let's say I have an entery MyBusiness with objectClass Organization. I don't want any entry of type account to be added under this Organization. The only thing I want to add is OrganizationalUnit under MyBusiness. How do I specify this ? As I can see, any object type can be cascaded in any object (directory entry). I need to tell LDAP through the schema (or any other way) not to allow Person or account to be a direct child of Organization. I hope this example makes things clear.
Regards, Buchan
On Wednesday 26 November 2008 08:54:18 Mansour Al Akeel wrote:
Buchan Milne wrote:
On Wednesday 26 November 2008 06:07:28 Mansour Al Akeel wrote:
Hello all, I an new to LDAP, and I have a need to migrate the existing system to ldap as this will ease a bit the management for the new system implementation. I need to authenticate users for a web site, and for the internal system ( linux, windows stations .... etc). Now the available account objectclass is structural
Sou you shouldn't use it, but intead the hostObject auxiliary objectclass provided in the ldapns.schema file shipped with pam_ldap.
[...]
This is in fact not only specific to this senario. I couldn't find any docs about how to prevent objectClass domain to be added under group !
There are two interpretations of this statement, please be more clear about this matter.
Ok, let's say I have an entery MyBusiness with objectClass Organization. I don't want any entry of type account to be added under this Organization. The only thing I want to add is OrganizationalUnit under MyBusiness. How do I specify this ? As I can see, any object type can be cascaded in any object (directory entry). I need to tell LDAP through the schema (or any other way) not to allow Person or account to be a direct child of Organization. I hope this example makes things clear.
This is not schema design, but DIT structure rules, which OpenLDAP doesn't support (http://www.openldap.org/faq/data/cache/649.html). You could implement some of these aspects via ACLs though.
Regards, Buchan
Mansour Al Akeel wrote:
Hello all, I an new to LDAP, and I have a need to migrate the existing system to ldap as this will ease a bit the management for the new system implementation. I need to authenticate users for a web site, and for the internal system ( linux, windows stations .... etc). Now the available account objectclass is structural so I can not user inetorgperson with account as both are structural. In this case I decided to extend inetOrgPerson, and add username and password as a MUST attributes. This is because all the users have access to the web site and they need authentication, but some users will need to have access to the machines. In this case I will create a new objectClass (ie. accountInfo) which containts the info I need (home directory, shell, loginScript, .... etc).
I'd recommend to use inetOrgPerson together with posixAccount for the users which need shell access.
Ciao, Michael.
Michael Ströder wrote:
Mansour Al Akeel wrote:
Hello all, I an new to LDAP, and I have a need to migrate the existing system to ldap as this will ease a bit the management for the new system implementation. I need to authenticate users for a web site, and for the internal system ( linux, windows stations .... etc). Now the available account objectclass is structural so I can not user inetorgperson with account as both are structural. In this case I decided to extend inetOrgPerson, and add username and password as a MUST attributes. This is because all the users have access to the web site and they need authentication, but some users will need to have access to the machines. In this case I will create a new objectClass (ie. accountInfo) which containts the info I need (home directory, shell, loginScript, .... etc).
I'd recommend to use inetOrgPerson together with posixAccount for the users which need shell access.
Ciao, Michael.
Thank you Michael, but posixAccount doesn't require the password, which makes it not suitable for authentication.
On Wednesday 26 November 2008 17:03:55 Mansour Al Akeel wrote:
Michael Ströder wrote:
Mansour Al Akeel wrote:
Hello all, I an new to LDAP, and I have a need to migrate the existing system to ldap as this will ease a bit the management for the new system implementation. I need to authenticate users for a web site, and for the internal system ( linux, windows stations .... etc). Now the available account objectclass is structural so I can not user inetorgperson with account as both are structural. In this case I decided to extend inetOrgPerson, and add username and password as a MUST attributes. This is because all the users have access to the web site and they need authentication, but some users will need to have access to the machines. In this case I will create a new objectClass (ie. accountInfo) which containts the info I need (home directory, shell, loginScript, .... etc).
I'd recommend to use inetOrgPerson together with posixAccount for the users which need shell access.
Ciao, Michael.
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.
You only need account (or hostObject) if you want the host attribute.
Regards, Buchan
Buchan Milne wrote:
On Wednesday 26 November 2008 08:54:18 Mansour Al Akeel wrote:
Buchan Milne wrote:
On Wednesday 26 November 2008 06:07:28 Mansour Al Akeel wrote:
Hello all, I an new to LDAP, and I have a need to migrate the existing system to ldap as this will ease a bit the management for the new system implementation. I need to authenticate users for a web site, and for the internal system ( linux, windows stations .... etc). Now the available account objectclass is structural
Sou you shouldn't use it, but intead the hostObject auxiliary objectclass provided in the ldapns.schema file shipped with pam_ldap.
[...]
This is in fact not only specific to this senario. I couldn't find any docs about how to prevent objectClass domain to be added under group !
There are two interpretations of this statement, please be more clear about this matter.
Ok, let's say I have an entery MyBusiness with objectClass Organization. I don't want any entry of type account to be added under this Organization. The only thing I want to add is OrganizationalUnit under MyBusiness. How do I specify this ? As I can see, any object type can be cascaded in any object (directory entry). I need to tell LDAP through the schema (or any other way) not to allow Person or account to be a direct child of Organization. I hope this example makes things clear.
This is not schema design, but DIT structure rules, which OpenLDAP doesn't support (http://www.openldap.org/faq/data/cache/649.html). You could implement some of these aspects via ACLs though.
Buchan, thank you. This is the magical word "dit structure rules". That's what I wanted for google. Now, I am left with one problem. I couldn't find an example, about this. I can see how to write ACL rules for user access but not to restrict the DIT structure.
I am reading now http://www.openldap.org/doc/admin24/access-control.html. In the mean while, if you have any example, it will be big help, or a link to a tutorial.
Regards, Buchan
Buchan Milne wrote:
On Wednesday 26 November 2008 17:03:55 Mansour Al Akeel wrote:
Michael Ströder wrote:
Mansour Al Akeel wrote:
Hello all, I an new to LDAP, and I have a need to migrate the existing system to ldap as this will ease a bit the management for the new system implementation. I need to authenticate users for a web site, and for the internal system ( linux, windows stations .... etc). Now the available account objectclass is structural so I can not user inetorgperson with account as both are structural. In this case I decided to extend inetOrgPerson, and add username and password as a MUST attributes. This is because all the users have access to the web site and they need authentication, but some users will need to have access to the machines. In this case I will create a new objectClass (ie. accountInfo) which containts the info I need (home directory, shell, loginScript, .... etc).
I'd recommend to use inetOrgPerson together with posixAccount for the users which need shell access.
Ciao, Michael.
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.
True, but it's not required (MUST). the password is optional (MAY). I will consider extending inetOrgPerson and make the password MUST.
You only need account (or hostObject) if you want the host attribute.
I couldn't find objectClass: hostObject any where. What do you mean by host attribute? I am going to need additional AUX objectClass for the home directory, login scripts, .... etc. AFAIK account is structural and not to be combined with inetOrgPerson.
Regards, Buchan
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
On Wed, Nov 26, 2008 at 01:47:31PM -0400, Mansour Al Akeel wrote:
True, but it's not required (MUST). the password is optional (MAY). I will consider extending inetOrgPerson and make the password MUST.
I would advise against it - see my earlier message. Remember that the lack of a password atribute means that the account *cannot* authenticate: it is not the same as having an empty password field in a passwd file.
You only need account (or hostObject) if you want the host attribute.
I couldn't find objectClass: hostObject any where. What do you mean by host attribute? I am going to need additional AUX objectClass for the home directory, login scripts, .... etc. AFAIK account is structural and not to be combined with inetOrgPerson.
RFC2307 defines posixAccount:
( nisSchema.2.0 NAME 'posixAccount' SUP top AUXILIARY DESC 'Abstraction of an account with POSIX attributes' MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory ) MAY ( userPassword $ loginShell $ gecos $ description ) )
There is your AUX class containing the Unix attributes.
I would expect to define an AUX class of your own as well, to permit attributes of local significance.
The 'account' object class is probably not very useful. It is one of the very early COSINE classes, defined before anyone had much experience of LDAP/X.500 in production.
Andrew
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
Mansour Al Akeel wrote:
Buchan Milne wrote:
On Wednesday 26 November 2008 17:03:55 Mansour Al Akeel wrote:
Michael Ströder wrote:
I'd recommend to use inetOrgPerson together with posixAccount for the users which need shell access.
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.
True, but it's not required (MUST). the password is optional (MAY). I will consider extending inetOrgPerson and make the password MUST.
You can do so but the question is whether this makes sense. During user registration process you might create the user's entry but the user account is still not activated with a password yet. Depending on your processes setting userPassword to MUST can be an obstacle you have to work around.
Your mileage may vary.
Ciao, Michael.
openldap-technical@openldap.org
-
Andrew Findlay -
Buchan Milne -
Mansour Al Akeel -
Michael Ströder