If you don't already
have a central person or group of people responsible for the OID
namespace for your organization, you need to form such a group. This
OID Managers group is responsible for obtaining an OID namespace,
designing a structure for the namespace that makes sense to your
organization, managing that namespace by maintaining a diagram of the
structure and a list of the allocated OIDs, and issuing appropriate
OIDs for new classes from that structure as required. Whenever a new
class of attribute or object is to be created in your
organization's forest, the OID Managers provide a
unique OID for that new class, which is then logged by the OID
Managers with a set of details about the reason for the request and
the type of class that it is to be used for. All these details need
to be defined by the OID Managers group.
The Schema Managers, by comparison,
are responsible for designing and creating proper classes in the
schema for a forest. They are responsible for actually making changes
to the schema via requests from within the organization, for ensuring
that redundant objects doing the same thing are not created, that
inheritance is used to best effect, that the appropriate objects are
indexed, and that the GC contains the right attributes.
The Schema Managers need to decide on the membership of the Schema
Admins universal group that resides in the Forest Root Domain of a
particular forest. One possibility is that the Schema Managers wish
to keep a set of user accounts as members of Schema Admins by default
all the time. Instead, they may decide to remove every member of the
Schema Admins group so that no unintentional changes can be made to
the schema. In this case, the Schema Managers need to be given
permissions to add and remove members of the Schema Admins group to
enable any of the Schema Managers to add themselves to the Schema
Admins group whenever changes are to be made to the schema.
If you are designing code that will modify some other
organization's schema, the documentation
accompanying that code should make it explicitly clear exactly what
classes are being created and why. The documentation also should
explain that the code needs to be run with the privilege of a member
of the Schema Admins group, since some organizations may have an
Active Directory in which the Schema Admins group is empty most of
the time, as mentioned earlier.
Note that the membership of OID Managers does not necessarily
coincide with that of Schema Managers, although it is a possibility.