Designing Effective Edirectory for Security

 

            Like its Microsoft counterpart the Novell platform is LDAP compatible so users can be organized and micro organized in several different ways allowing for ease of administration. OU’s in Windows or Contexts in Netware allow users to be separated while programs like LDAP contextless login allow ease of sign on for users across the Netware platform. Using contexts or Organizational units to categorize users is a definite must for security practices not just for organization reasons but it also allows you to deploy a more effective security policy.

 

            However unlike Microsoft windows the organizational security isn’t built into the organization units. On a windows platform OU’s are the only way to apply specific group policies to specific users, however in NetWare that is not the case, the framework is present but the administrators must activate the security on there own. This is due to Netware’s more heavy emphasis on the individual users access rights whereas Microsoft is more concerned with group access rights.

The image bellow is a Microsoft group policy management console illustrating how group policy is applied to OU’s and not to individual users
img1

 

 

            In order to successfully generate and deploy a secure netware environment it is necessary to understand the information above, if the edirectory is badly designed your Zenworks implemented policies will not be enforced correctly, so therefore you must organize users in the following manor

 

TREE__
   CONTEXT (Office Locations)__
                                                          OU(Departments)__
                                                                                              GROUPS__
                                                                                                                    USERS

 

For example a company that has 4 branch offices connected with a VPN  would have 4 contexts one for each of the branch offices, then organizational units one for each of the departments and the OU’s will be nested with the contexts then inside each OU there will be groups for small workgroups followed by users

            This allows administrators the flexibility to assign permissions by branch office, department, workgroup or individual user. 

 

A good practical example is the company described above managing its payroll from one office, and having the payroll database on a volume on the server. The administrator can configure the permissions to expressly deny access to all but the single context, and also has the flexibility to insure the HR workgroup at a different office has access to the database on whatever level the administrator wishes.

 

            This feature is also necessary when installing group policy and Zenworks delivered policies; policies are flexible enough to be enforced for any section of the above modal.


 

            In small companies or installations where only one physical location is available the OU section of the Netware edirectory design modal is not implemented on such a large scale, the individual departments can be sectioned off using contexts, which allow for more flexibility when implementing the Netware environment.


            Additionally the structure where the IT objects are deployed is also necessary to consider. For security reasons IT objects (post offices, server objects and security policies) should be kept in a separate context so to prevent tampering with the objects or unnecessary damage.

A implementation of the IT context I find useful is the following

 

img2

 

 

 

            The only exception to the IT Context policy is Volumes. Volume objects should be placed in the root of there intended use context, Volumes should never be placed in Organizational Units.

 

The following screenshot is a example of a effectively designed edirectory  from a security perspective

 

 

img3

 


home