Regarding CA directory server extended schema/advance authentication

[Anon Anon]

Hi,

CA Directory server in our environment is configured as Hierarchical. There are set of

application specific attributes wihich needs to be added on to schema. As a best practice i don't

want to add application specific attributes to current schema. I know there are two ways to do.

Option 1 : creating objectclass with those specific attributes and assign it to user

Option 2 : creating extended schema(creating another instance with new schema with ONLY

application specific attributes).

My questions are

(1) As my setup is hierarchical, which opition would best and why?

(2) With hierarchical structure, implementing extending would work?

(3) If i implement option 2, how data will be fetched from extended schema and what would be the

common attribute between these two schemas.

-JK

[mcdju01]

There are a number of different methods for extending the standard schema to include application specific attributes. The best method to use depends on the use case.

 

(1) The most common method is to create a new auxiliary object class (type = auxiliary) containing the custom attributes. When the auxiliary object class is added to an entry's object class list, the custom attributes become available. The reason for using an auxiliary object class is that they are not structural, that is, don't occupy a node in the hierarchy and don't require a naming attribute.

 

(2) Just to check terminology, when you say extending the schema, do you mean storing your custom attributes as a subordinates to the base entry? For example, if we have entry "uid=1234,ou=users,c=au" including custom attributes as a subordinate object say "cn=appData,uid=1234,ou=users,c=au". This method is often used when the relationship between the base entry and custom data is one-to-many or if there are a number of applications and separation is required. (3) Retrieving such data requires two searches (retrieve object and performing a one-level scoped search on the retrieved object). We do have a feature called "views" to return both objects in one hit but that is a different topic entirely.

 

Extension of (2), We have some applications that store custom information in a separate part of the hierarchy and link to the main object via an attribute of distinguishedName syntax. This is typically performed when the underlying schema cannot be modified, for example, creating a session store for an existing deployment. It is then up to the application to maintain the separate store and take care of referential integrity (maintaining the link between the base entry and the custom entry).

[Anon Anon]

Hi,

 

Thanks for reply. Before i proceed further, wanted to get opinion as which directory structure is good? Is it Hierarchical or Flat file mode? Which is best practice?

 

Thanks,

Jagadeesh.K

[mcdju01]

The directory information tree (DIT) layout depends on  number of factors including use case, access controls, number of entries, load, topology, data model etc.

 

Typically, objects of a particular type (object class) would be grouped together under a node. Within a grouping objects, storing in a flat structure is the most efficient and can allow for horizontal scalability.

[Anon Anon]

Thanks for the explanation.