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

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 !

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.

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.

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

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.

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

The 'account' object class is probably not very useful.