Which of the following is arranged in the correct Active Directory organizational Order?

Skip to main content

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

Understanding the Active Directory Logical Model

  • Article
  • 07/29/2021
  • 2 minutes to read

In this article

Applies to: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

Designing your logical structure for Active Directory Domain Services (AD DS) involves defining the relationships between the containers in your directory. These relationships might be based on administrative requirements, such as delegation of authority, or they might be defined by operational requirements, such as the need to control replication.

Before you design your Active Directory logical structure, it is important to understand the Active Directory logical model. AD DS is a distributed database that stores and manages information about network resources as well as application-specific data from directory-enabled applications. AD DS allows administrators to organize elements of a network (such as users, computers, and devices) into a hierarchical containment structure. The top-level container is the forest. Within forests are domains, and within domains are organizational units (OUs). This is called the logical model because it is independent of the physical aspects of the deployment, such as the number of domain controllers required within each domain and network topology.

Active Directory forest

A forest is a collection of one or more Active Directory domains that share a common logical structure, directory schema (class and attribute definitions), directory configuration (site and replication information), and global catalog (forest-wide search capabilities). Domains in the same forest are automatically linked with two-way, transitive trust relationships.

Active Directory domain

A domain is a partition in an Active Directory forest. Partitioning data enables organizations to replicate data only to where it is needed. In this way, the directory can scale globally over a network that has limited available bandwidth. In addition, the domain supports a number of other core functions related to administration, including:

  • Network-wide user identity. Domains allow user identities to be created once and referenced on any computer joined to the forest in which the domain is located. Domain controllers that make up a domain are used to store user accounts and user credentials (such as passwords or certificates) securely.

  • Authentication. Domain controllers provide authentication services for users and supply additional authorization data such as user group memberships, which can be used to control access to resources on the network.

  • Trust relationships. Domains can extend authentication services to users in domains outside their own forest by means of trusts.

  • Replication. The domain defines a partition of the directory that contains sufficient data to provide domain services and then replicates it between the domain controllers. In this way, all domain controllers are peers in a domain and are managed as a unit.

Active Directory organizational units

OUs can be used to form a hierarchy of containers within a domain. OUs are used to group objects for administrative purposes such as the application of Group Policy or delegation of authority. Control (over an OU and the objects within it) is determined by the access control lists (ACLs) on the OU and on the objects in the OU. To facilitate the management of large numbers of objects, AD DS supports the concept of delegation of authority. By means of delegation, owners can transfer full or limited administrative control over objects to other users or groups. Delegation is important because it helps to distribute the management of large numbers of objects across a number of people who are trusted to perform management tasks.

Feedback

Submit and view feedback for

SGD is built on the principles of directory services. Users, applications, and application servers are represented by objects in a directory. The objects are arranged into an organizational hierarchy representing your organization.

An organizational hierarchy starts with a top-level directory object, usually an organization object. Other directory objects, such as an organizational unit (OU), are containers that can be used to divide the organizational hierarchy. You can create group objects. Group objects are not containers. Groups have members that are objects located in other parts of the organizational hierarchy.

SGD also includes a number of different object types for representing users, applications, and application servers.

Each object has a number of configuration settings, known as attributes. For example, an application object has an Icon attribute that is the name of an icon to display to users.

SGD objects, and the attributes used for each object, are based on the commonly-used LDAP version 3 schema. These objects have been extended, using the standard method of doing so, to support SGD functionality. For more information on the LDAP schema, see RFC 2256.

SGD uses a local repository to store all the objects in your organizational hierarchy. Each object is distinguished from other objects in the same container by using an attribute name as a prefix, for example ou=Sales. This attribute is known as the naming attribute or the relative distinguished name (RDN). Two objects in the same container cannot have the same RDN. The complete name of the object that includes all the RDNs from the top of the hierarchy is the distinguished name (DN), for example o=Example/ou=Sales. The DN is the name that uniquely identifies an object.SGD object names are written like file system paths (slash-separated and top-down). The following table shows some example objects, their RDN, and their DN.

Object Type

Relative Distinguished Name

Distinguished Name

Organization

o=Example

o=Example

OU

ou=Sales

o=Example/ou=Sales

User profile

cn=Violet Carson

o=Example/ou=Sales/cn=Violet Carson

User profile

cn=Elizabeth Blue

o=Example/ou=Sales/cn=Elizabeth Blue

The relationships between objects are significant. For example, to deploy an application to users, you associate user profile objects with an application object. SGD calls these relationships assignments. Assignments are described in more detail in Section 3.2, “Publishing Applications”.

For more information about hierarchies and objects, see the following sections:

  • Section 3.1.1, “Organizational Hierarchies”

  • Section 3.1.2, “SGD Object Types”

  • Section 3.1.3, “Designing the Organizational Hierarchy”

  • Section 3.1.4, “Naming Objects in the Organizational Hierarchy”

  • Section 3.1.5, “Populating the SGD Organizational Hierarchy Using a Batch Script”

  • Section 3.1.6, “LDAP Mirroring”

  • Section 3.1.7, “SGD Administrators”

3.1.1. Organizational Hierarchies

SGD uses four organizational hierarchies: one each for users, applications, and application servers, and a System Objects hierarchy that contains objects for use by SGD. In the Administration Console, you use the following tabs to manage these organizational hierarchies:

  • Section 3.1.1.1, “User Profiles Tab”

  • Section 3.1.1.2, “Applications Tab”

  • Section 3.1.1.3, “Application Servers Tab”

The following sections describe these tabs, the objects that they can contain, and how they are used. The System Objects organization is also described.

On the command line, you manage your organizational hierarchies with the tarantella object command. You can also use this command to populate an organizational hierarchy using a batch script. See Section 3.1.5, “Populating the SGD Organizational Hierarchy Using a Batch Script”.

3.1.1.1. User Profiles Tab

In the Administration Console, the User Profiles tab is where you create and configure objects for managing SGD users. You use the objects on this tab to control users' SGD-related settings, and the applications that they can access through SGD.

By default, this tab contains two objects, an organization object called o=organization and a domain component object called dc=com. These are the top-level objects in the organizational hierarchy. You can rename or delete these objects, or create new top-level objects. You create all the objects you need for managing users within these top-level objects.

The following are the SGD object types that are available on the User Profiles tab:

  • Section 3.1.2.1, “Directory Object: Organization”

  • Section 3.1.2.2, “Directory (Light) Object: Domain Component”

  • Section 3.1.2.3, “Directory Object: Organizational Unit”

  • Section 3.1.2.4, “Directory (Light) Object: Active Directory Container”

  • Section 3.1.2.5, “User Profile Object”

3.1.1.2. Applications Tab

In the Administration Console, the Applications tab is where you create and configure objects that represent the applications and documents that users can access through SGD. These objects are always created within the applications organization. On the command line, this organization is called o=applications.

The following are the SGD object types that are available on the Applications tab:

  • Section 3.1.2.3, “Directory Object: Organizational Unit”

  • Section 3.1.2.6, “Group Object”

  • Section 3.1.2.8, “X Application Object”

  • Section 3.1.2.7, “Windows Application Object”

  • Section 3.1.2.9, “Character Application Object”

  • Section 3.1.2.10, “Document Object”

  • Section 3.1.2.11, “3270 Application Object”

  • Section 3.1.2.12, “5250 Application Object”

  • Section 3.1.2.13, “Dynamic Application Object”

3.1.1.4. The System Objects Organization

The System Objects organization contains objects that are essential for the running and maintenance of SGD. On the command line, the System Objects organization is displayed as o=Tarantella System Objects.

The System Objects organization contains the Global Administrators role object. This object determines who is an SGD Administrator, and who can use the SGD graphical administration tools. See Section 3.1.7, “SGD Administrators”.

The System Objects organization also contains profile objects. These are default user profile objects for use with the various SGD authentication mechanisms. For example, the profile object System Objects/LDAP Profile is the default user profile if you are using LDAP or Active Directory authentication.

You can edit objects in the System Objects organization, but you cannot create, move, rename, or delete objects.

3.1.2. SGD Object Types

This section describes the available SGD object types and how they are used.

The following are the object types that are used to organize users, applications, and application servers:

  • Section 3.1.2.1, “Directory Object: Organization”

  • Section 3.1.2.2, “Directory (Light) Object: Domain Component”

  • Section 3.1.2.3, “Directory Object: Organizational Unit”

  • Section 3.1.2.4, “Directory (Light) Object: Active Directory Container”

The following are the object types used to represent users, applications, and application servers.

  • Section 3.1.2.6, “Group Object”

  • Section 3.1.2.5, “User Profile Object”

  • Section 3.1.2.7, “Windows Application Object”

  • Section 3.1.2.8, “X Application Object”

  • Section 3.1.2.9, “Character Application Object”

  • Section 3.1.2.10, “Document Object”

  • Section 3.1.2.11, “3270 Application Object”

  • Section 3.1.2.12, “5250 Application Object”

  • Section 3.1.2.13, “Dynamic Application Object”

  • Section 3.1.2.14, “Application Server Object”

  • Section 3.1.2.15, “Dynamic Application Server Object”

3.1.2.1. Directory Object: Organization

Directory objects that are organization objects are used for the things that apply to your organization as a whole. Organization objects are always at the top of the organizational hierarchy and can contain OU, Active Directory container, or user profile objects.

On the command line, you create an organization object with the tarantella object new_org command.

Organization objects have an o= naming attribute.

3.1.2.2. Directory (Light) Object: Domain Component

Directory (light) objects that are domain component objects are used to replicate a directory structure, usually a Microsoft Active Directory structure, within the SGD organizational hierarchy. Domain component objects are similar to organization objects, but do not include additional SGD-specific attributes or allow you to assign applications. This is why they are called directory (light) objects.

Domain component objects can only appear at the top of the organizational hierarchy, or within another domain component object. Domain component objects can contain OU, domain component, Active Directory container, or user profile objects.

On the command line, you create a domain component object with the tarantella object new_dc command.

Domain component objects have a dc= naming attribute.

3.1.2.3. Directory Object: Organizational Unit

Directory objects that are OU objects are used to divide your users, applications, and application servers into different departments, sites, or teams.

An OU can be contained in an organization or a domain component object.

On the command line, you create a directory object with the tarantella object new_orgunit command.

Directory objects have an ou= naming attribute.

3.1.2.4. Directory (Light) Object: Active Directory Container

Active Directory container objects are used to replicate your Microsoft Active Directory structure within the SGD organizational hierarchy.

Active Directory container objects are similar to OUs, but do not include additional SGD-specific attributes or allow you to assign applications. This is why they are called directory (light) objects.

An Active Directory container object can be contained in an organization, an OU, or a domain component object.

On the command line, you create an Active Directory container object with the tarantella object new_container command.

Active Directory container objects have a cn= naming attribute.

3.1.2.5. User Profile Object

User profile objects are used to represent a user in your organization, and give that user access to applications. They also define the SGD settings associated with a user.

How SGD associates a user profile object with a user depends on the authentication mechanisms in use. For some authentication mechanisms, you might not have to create user profile objects at all. See Section 2.1, “Secure Global Desktop Authentication” for details.

On the command line, you create a user profile object with the tarantella object new_person command.

User profile objects can have a cn= (common name), a uid= (user identification), or a mail= (mail address) naming attribute.

3.1.2.6. Group Object

Group objects are used to associate groups of applications with an object on the User Profiles tab or groups of application servers with an object on the Applications tab.

Group objects are not the same as directory objects. Applications or application servers can only belong to one directory, but can be a member of many different groups.

Members of a group can be applications, application servers, or other groups. Groups can moved or renamed without affecting group membership.

Groups of application server objects can be used to associate similar application servers for load balancing. See Section 7.2, “Load Balancing” for details.

On the command line, you create a group object with the tarantella object new_group command.

Group objects have a cn= naming attribute.

3.1.2.7. Windows Application Object

Windows application objects are used to give Microsoft Windows graphical applications to users. See Section 4.1, “Windows Applications” for more details.

On the command line, you create a Windows application object with the tarantella object new_windowsapp command.

Windows application objects have a cn= naming attribute.

3.1.2.8. X Application Object

X application objects are used to give X11 graphical applications to users. See Section 4.2, “X Applications” for more details.

On the command line, you create an X application object with the tarantella object new_xapp command.

X application objects have a cn= naming attribute.

3.1.2.9. Character Application Object

Character application objects are used to give VT420, Wyse 60, or SCO Console character applications to users. See Section 4.4, “Character Applications” for more details.

On the command line, you create a character application object with the tarantella object new_charapp command.

Character application objects have a cn= naming attribute.

3.1.2.10. Document Object

Document objects are used to give documents to users. A document object can refer to any URL.

On the command line, you create a document object with the tarantella object new_doc command.

Document objects have a cn= naming attribute.

3.1.2.11. 3270 Application Object

3270 application objects are used to give 3270 (mainframe) applications to users.

On the command line, you create a 3270 application object with the tarantella object new_3270app command.

3270 application objects have a cn= naming attribute.

3.1.2.12. 5250 Application Object

5250 application objects are used to give 5250 (AS/400) applications to users.

On the command line, you create a 5250 application object with the tarantella object new_5250app command.

5250 Application objects have a cn= naming attribute.

3.1.2.13. Dynamic Application Object

Dynamic application objects are used with dynamic launch to enable users to select an application to run. See Section 4.5, “Dynamic Launch” for details.

On the command line, you create a dynamic application object with the tarantella object new_dynamicapp command. Dynamic application objects have a cn= naming attribute.

3.1.2.14. Application Server Object

Application server objects are used to represent an application server that is used to run applications through SGD.

Application servers are used with load balancing. If you assign two or more application server objects to an application object, SGD chooses which application server to use, based on the load across the application servers. See Section 7.2, “Load Balancing” for details.

On the command line, you create an application server object with the tarantella object new_host command. Application server objects have a cn= naming attribute.

3.1.2.15. Dynamic Application Server Object

Dynamic application server objects are used with dynamic launch to enable users to select the application server that runs the application. See Section 4.5, “Dynamic Launch” for details.

On the command line, you create a dynamic application server object with the tarantella object new_host --dynamic command. Dynamic application server objects have a cn= naming attribute.

3.1.3. Designing the Organizational Hierarchy

You have complete control over the objects that you create to model your organizational hierarchy. However it is important to design and test your organizational hierarchy before implementing it. The following factors affect your design:

  • Authentication mechanism. The most important influence on the design of organizational hierarchy is the Secure Global Desktop authentication mechanisms you use. For example, if you use UNIX system authentication, you can structure the hierarchy however you like. However, with LDAP authentication, you might need to mirror part of your LDAP directory structure. See Section 2.1, “Secure Global Desktop Authentication” for details.

  • Organization chart. Sometimes it is a good approach to use OUs to represent the departments or offices in your organization. However, if your organization is restructured, you might have to reorganize your hierarchy.

  • Inheritance. The settings for user profile objects and OU objects can be inherited from the object's parent in the organizational hierarchy. For example if everyone in a department needs an application, assign the application to the OU that represents the department. Every user belonging to that OU gets the applications assigned to the OU. Inheritance works best if you are not using LDAP assignments.

  • User profile objects. User profile objects can be configured to give users access to particular applications and customized settings. Depending on the authentication mechanisms you enable, a default user profile is often used and this might be sufficient for your needs. This is particularly true if you use LDAP assignments to assign applications to users.

  • Naming convention. Use a naming convention for each application or document object type. The name of the application or document object is displayed to users. For user profile objects, it is best to use the person's full name, for example "Indigo Jones".

3.1.4. Naming Objects in the Organizational Hierarchy

When you create an object in the Administration Console, you can use any characters you want for the name of the object, apart from backslash (\) or plus (+).

On the command line, if you use a forward slash in an object name, you must backslash protect, or escape, it. This is because SGD interprets the forward slash as a part of the organizational hierarchy. For example, if you try to create an object with the relative name cn=a/b beneath o=organization, SGD tries to create an object called b within o=organization/cn=a. This fails because o=organization/cn=a does not exist. To create an object with this name, type cn=a\/b.

On the command line, if the name of an object includes spaces, make sure you enclose the name in quotes, for example ".../_ens/o=Example".

With the tarantella object command, any name in the local repository is treated as case insensitive. When you create or rename an object, the case used is preserved. However, other commands, such as the tarantella webtopsession and tarantella emulatorsession commands, are case sensitive.

3.1.5. Populating the SGD Organizational Hierarchy Using a Batch Script

If you want to populate your organizational hierarchy with a large number of objects, using the Administration Console to do this is not very efficient. The solution is to use the batch scripting functionality of the tarantella object command.

Once you have designed the structure of your SGD organizational hierarchy, you create a file for each type of object you want. Each file contains one line per object, with the correct syntax for creating the object from the appropriate tarantella object command. For example, to create five OUs you might have a file called orgunits.txt containing the following:

--name "o=Example/ou=IT" \
--name "o=Example/ou=Sales" \
--name "o=Example/ou=Marketing" \
--name "o=Example/ou=Finance" \
--name "o=Example/ou=Finance/ou=Administration"

Do not include the actual tarantella object command name, for example object new_orgunit, as part of each line.

Remember the following:

  • Application objects, including their groups and OUs, must be created in the o=applications organization.

  • Application server objects, including their groups and OUs, must be created in the o=appservers organization.

  • Every application must have an application object.

  • Every application server must have an application server object.

Once all your files are complete, use the tarantella object script command to process them all at once, for example:

#!/bin/sh
tarantella object script << EOF
new_orgunit --file orgunits.txt
new_group --file groups.txt
new_host --file hosts.txt
new_person --file people.txt
new_xapp --file xapps.txt
new_windowsapp --file windowsapps.txt
new_charapp --file charapps.txt
EOF

The tarantella object script command runs each command in order. Each command reads and processes the specified file.

You can use any tarantella object subcommand with the tarantella object script command. You do not have to read in object details from other files.

Many other commands, for example the tarantella passcache command, accept --file arguments so you can perform multiple related actions at once.

3.1.6. LDAP Mirroring

When a user is authenticated with either LDAP authentication, Active Directory authentication, or third-party authentication using the LDAP search, SGD establishes the user profile for a user by searching the local repository, allowing for differences between the LDAP and SGD naming systems. SGD searches for the following until a match is found:

  • A user profile with the same name as the user's LDAP object.

    For example, if the LDAP object is cn=Emma Rald,cn=Sales,dc=example,dc=com, SGD searches the local repository for dc=com/dc=example/cn=Sales/cn=Emma Rald.

  • A user profile in the same organizational unit as the LDAP object but with the name cn=LDAP Profile.

    For example, dc=com/dc=example/cn=Sales/cn=LDAP Profile.

  • A user profile in any parent organizational unit with the name cn=LDAP Profile.

    For example, dc=com/dc=example/cn=LDAP Profile.

If there is no match, the profile object o=System Objects/cn=LDAP Profile is used for the user profile.

Typically LDAP and Active Directory users use the default LDAP profile, and applications and documents are assigned to them using LDAP assignments. See Section 3.2.2, “LDAP Assignments”. However, user profile objects can also be used to control a user's SGD-specific settings, such as the ability to use copy and paste or to edit client profiles. If you want to customize an LDAP or Active Directory user's SGD settings, you might have to mirror some of your LDAP structure in the local repository.

When you mirror your LDAP structure, remember the following:

  • Do not mirror your entire LDAP structure in the local repository. Only create as much of the structure as you need.

  • Inherit as much as possible from other objects in the organizational hierarchy.

  • Do not create user profile objects for all users. Only create user profile objects for users that must have individual settings. Creating cn=LDAP Profile objects is sufficient in most cases.

You can configure service objects that specify a base DN (a search root) as part of the LDAP URL, see Section 2.8.4, “Using Service Objects”. The base DN can be used as the starting point when mirroring your LDAP structure. SGD only permits an organization object (o=) or domain component (dc=) object as the top-level object. If your LDAP structure uses other objects, such as country (c=) or location (l=) objects, you must ensure the base DN for the service object enables you to mirror from an organization or domain component object. SGD also constrains the objects you can use as directory containers. For example, you cannot nest an organization object inside an organization object. This means you might have to create service objects with different base DNs in order to mirror everything you need.

When working with LDAP mirroring in the Administration Console, it is useful to display the naming attribute for the objects you work with. By default the Administration Console does not display naming attributes. You enable the display of naming attributes in the Preferences for the Administration Console.

When working with user profiles in the Administration Console, select Local + LDAP from the Repository list on the User Profiles tab. LDAP objects that are mirrored in the local repository are indicated by the following icon:

Which of the following is arranged in the correct Active Directory organizational Order?

The following is an example of how to mirror your LDAP organization to give users different SGD settings.

3.1.6.1. An Example of LDAP Mirroring

The company example.com has five departments: IT, Sales, Marketing, Finance, and Administration. The Finance and Marketing departments need different SGD settings to the other departments. Sid Cerise in the Finance department needs different SGD settings to the other users in the Finance department.

The objects you create depend on the type of LDAP directory server used, as described in the following sections.

3.1.6.1.1. Oracle Directory Server Enterprise Edition

For Oracle Directory Server Enterprise Edition (formerly Sun Java System Directory Server), the following are the LDAP names of the objects you need to mirror in the local repository and the object types to use:

  • o=example.com

    Use an organization object.

  • ou=Finance,o=example.com

    Use an OU object.

  • ou=Marketing,o=example.com

    Use an OU object.

Note

In the Administration Console, create Directory objects. The naming attribute is set automatically.

Figure 3.1, “Example Mirrored LDAP Objects for Oracle Directory Server” shows the mirrored objects in the Administration Console.

Figure 3.1. Example Mirrored LDAP Objects for Oracle Directory Server

Which of the following is arranged in the correct Active Directory organizational Order?

With this structure in place, create the following user profile objects in the local repository:

  • o=example.com/ou=Finance/cn=LDAP Profile

  • o=example.com/ou=Marketing/cn=LDAP Profile

  • o=example.com/ou=Finance/uid=Sid Cerise

Note

In the Administration Console, remember to select uid as the naming attribute for the user profile object o=example.com/ou=Finance/uid=Sid Cerise.

With this organizational hierarchy, users receive settings as follows:

  • Sid Cerise receives the settings defined for the following user profile object, including any settings inherited from parent objects in the organizational hierarchy:

    o=example.com/ou=Finance/uid=Sid Cerise

  • Users in the Finance department receive the settings defined for the following user profile object, including any settings inherited from parent objects in the organizational hierarchy:

    o=example.com/ou=Finance/cn=LDAP Profile

  • Users in the Marketing department receive the settings defined for the following user profile object, including any settings inherited from parent objects in the organizational hierarchy:

    o=example.com/ou=Marketing/cn=LDAP Profile

  • All other users receive the settings defined for the default LDAP user profile, System Objects/cn=LDAP Profile

3.1.6.1.2. Microsoft Active Directory

For Microsoft Active Directory, the following are the LDAP names of the objects you need to mirror in the local repository and the object types to use:

  • dc=example,dc=com

    Use a domain component object.

  • cn=Finance,dc=example,dc=com

    Use an Active Directory container object.

  • cn=Marketing,dc=example,dc=com

    Use an Active Directory container object.

Note

In the Administration Console, you create domain components and Active Directory containers by creating Directory (light) objects, and then selecting the correct naming attribute.

Figure 3.2, “Example Mirrored LDAP Objects for Microsoft Active Directory” shows the mirrored objects in the Administration Console.

Figure 3.2. Example Mirrored LDAP Objects for Microsoft Active Directory

Which of the following is arranged in the correct Active Directory organizational Order?

With this structure in place, create the following user profile objects in the local repository:

  • dc=com/dc=example/cn=Finance/cn=LDAP Profile

  • dc=com/dc=example/cn=Marketing/cn=LDAP Profile

  • dc=com/dc=example/cn=Finance/cn=Sid Cerise

With this organizational hierarchy, users receive settings as follows:

  • Sid Cerise receives the settings defined for the following user profile object:

    o=example.com/ou=Finance/cn=Sid Cerise

  • Users in the Finance department receive the settings defined for the following user profile object:

    o=example.com/ou=Finance/cn=LDAP Profile.

  • Users in the Marketing department receive the settings defined for the following user profile object:

    o=example.com/ou=Marketing/cn=LDAP Profile.

  • All other users receive the settings defined for the default LDAP user profile, System Objects/cn=LDAP Profile

Note

It is not possible to inherit SGD settings from domain component and Active Directory container objects.

3.1.7. SGD Administrators

In SGD, administration privileges are managed using the Global Administrators role object in the System Objects organization.

The Global Administrators role object has a list of members, and a list of assigned applications. All SGD Administrators are defined as members of the Global Administrators role object. The list of assigned applications is used to assign administration tools to SGD Administrators. SGD Administrators are assigned these applications in addition to any other applications assigned to them.

Only SGD Administrators can configure SGD using the SGD graphical administration tools, Administration Console and Profile Editor. To use the SGD command-line tools, the following conditions apply:

  • Commands that control the SGD server and SGD web server can be run only by superuser (root).

  • Commands for creating and managing arrays of SGD servers can only be run by SGD Administrators.

  • All other commands can be run by any user in the ttaserv group.

Use the usermod -G command to make a user a member of the ttaserv group. The ttaserv group does not have to be the users primary or effective group.

You can use the SGD Administration Console or the tarantella role command to add or remove SGD Administrators.

If no user profile objects are defined as members of the Global Administrators role object, the UNIX or Linux system root user has administration privileges.

Note

If you want SGD Administrators to authenticate using an LDAP directory or Active Directory authentication, you must create user profiles for them. See Section 3.1.6, “LDAP Mirroring” for details.

3.1.7.1. How To Add an SGD Administrator

  1. In the Administration Console, go to the User Profiles tab.

  2. Select the Global Administrators role object.

    1. In the navigation tree, click System Objects.

      The System Objects table is displayed.

    2. In the System Objects table, click the Global Administrators role object.

      The Members tab is displayed.

  3. Add a user profile object to the Members tab.

    1. In the Editable Members table, click Add.

      The Add User Assignment window is displayed.

    2. Locate the user profile object.

      Use the Search field or the navigation tree to find the object you want.

    3. Select the check box next to a user profile object.

      To add several SGD Administrators, select more than one user profile object.

    4. Click Add Assignment.

      The Members tab is displayed, showing the selected user profile object.

    Tip

    You can also use the tarantella role add_member --role global --member pobj command.

3.1.7.2. How To Remove an SGD Administrator

  1. In the Administration Console, go to the User Profiles tab.

  2. Select the Global Administrators role object.

    1. In the navigation tree, click System Objects.

      The System Objects table is displayed.

    2. In the System Objects table, click the Global Administrators role object.

      The Members tab is displayed.

  3. Remove a user profile object from the Members tab.

    1. In the Editable Members table, select the check box next to a user profile object.

      To remove several SGD Administrators, select more than one user profile object.

    2. Click Delete.

      A warning message is displayed.

    3. Click OK.

      The Members tab is displayed.

    Tip

    You can also use the tarantella role remove_member --role global --member pobj command.

What is an organizational unit in Active Directory?

Organizational units (OUs) in an Active Directory Domain Services (AD DS) managed domain let you logically group objects such as user accounts, service accounts, or computer accounts. You can then assign administrators to specific OUs, and apply group policy to enforce targeted configuration settings.

Which of the following protocols is Active Directory based upon?

Active Directory uses Lightweight Directory Access Protocol (LDAP) versions 2 and 3, Microsoft's version of Kerberos, and DNS.

Which is not of the 4 divisions or container structures in Active Directory?

Which is not one of the four divisions or container structures in Active Directory? Forests - The collection of every object, its attributes and attribute syntax in the Active Directory.

Which of the following are the logical components of Active Directory?

The logical parts of Active Directory include forests, trees, domains, OUs and global catalogs.