Each iControl Application Server has a default user defined—the admin user. This user has the role of super assigned to it, which means that anyone who logs in as admin has access to everything in the domain.

The default admin user also has a default password, which is also admin. This password can be changed. You might want to do this, for example, at the initial setup of an Application Server to improve security. The admin user/password can also be restored to their original state if accidentally deleted. For more information about resetting the user password, click HERE.

As shipped, an Application Server can be used by any user on the same network to open any program, view any pages, modify any device parameters, and so on. Access control, also called user authentication or privilege management, allows you to make iControl system resources (such as cards, services, and Web pages) available only to designated users.

While not meant to be a foolproof security system, access control allows you to manage users in a way that minimizes the potential for errors. For example, you can prevent a guest user from opening critical Web pages. Access control also associates user names with events, so that you can see, for example, who acknowledged a specific alarm or reset a latch.

A typical iControl configuration consists of multiple rooms, areas or groups for processing and distributing content. Each room/area/group has its own hardware equipment including Grass Valley Densité and Imaging (Symphonie/Quartet) cards and various third-party equipment. Each room/area/group also has its own private local area network (LAN). It is convenient to map these rooms to iControl domains for security considerations. The figure below illustrates a typical domain architecture.

iControl provides multiple domain- and role-based authentication based on the Lightweight Directory Access Protocol (LDAP). In a typical system, each domain has one LDAP server (i.e. LDAP running as a service on an iControl Application Server), and manages its own accounts with top down referrals. In such a configuration, users from a higher level domain can log on to a lower level one, and vice-versa. For example, in the architecture shown above, users from the ic‑projects.ic‑acme.com or ic‑acme.com domains can login directly to ic‑hdmg.ic‑projects.ic‑acme.com.

Users from a higher level domain log on to a lower level one with role inheritance. For example, a user registered as an operator at the top level ic‑acme.com could log on to ic‑projects.ic‑acme.com as an operator, but would inherit the permissions from the operator role in the lower-level domain.