Integrating Symphony with Microsoft Active Directory

Scope

The EGO Active Directory (AD) plug-in is available for the following platforms:


Management hosts

Compute hosts

Windows 2000, Windows 2003, and Windows 2008

All platforms supported by Symphony


Configure EGO and plug-in

  1. Edit adauth.conf in $EGO_CONFDIR to set the values of mandatory and optional parameters. Set the value of mandatory parameter AD_ADMIN as the AD account that should be mapped to the EGO 'Admin' user. Here is an example of the adauth.conf file:
    # EGO AD plug-in configuration file
    # Mandatory parameters
    # AD_ADMIN=<ad-account-name>
    #          AD account that should be mapped to EGO 'Admin' user. 
    #          Use the format <domain-name>\<username>
    # Optional parameters
    # AD_WINDOMAIN=<windows-domain1>,<windows-domain2> ...
    #          NetBIOS names of the Windows domains whose domain
    #          controllers are queried to obtain user list. If not
    #          specified, only the primary domain controller of EGO
    #          master host is queried. This parameter is not
    #          applicable if EGO master is a Linux host.
    # AD_CACHEEXPIRYTIME=<time-in-days>
    #          VEMKD caches the user list obtained from AD. This
    #          parameter specifies the expiry time of the user list
    #          cache. If not specified, default value of 1 day is
    #          used.
    AD_ADMIN=egoadmin
    #AD_WINDOMAIN=
    #AD_CACHEEXPIRYTIME=1
  2. Change the password of the 'Admin' user in EGO using the utility 'egostashpass-AD'. The password should be the same as the password of the AD_ADMIN account specified in adauth.conf (in step 1.). EGO needs to store the password of this account as it uses this password to generate a credential for the EGO Service Controller and other EGO services.
  3. Edit ego.conf on management hosts and modify the value of parameters EGO_SEC_PLUGIN and EGO_SEC_CONF as follows:
    • EGO_SEC_PLUGIN=sec_ego_ext_ad

    • EGO_SEC_CONF="C:\EGO\kernel\conf,0,INFO,C:\EGO\kernel\log"

      The format of EGO_SEC_CONF is <plugin-configuration-directory, created-ttl, plugin-log-level, plugin-log-directory>. All the server side messages will be logged to ego_ext_plugin_server.log in the plugin-log-directory.

  4. Edit ego.conf on compute hosts and modify the value of parameters EGO_SEC_PLUGIN as follows:

    EGO_SEC_PLUGIN=sec_ego_ext_co

    EGO_SEC_CONF parameter is optional on compute and client hosts. Specify this parameter if log messages are required from the client-side plug-in. The format is the same as specified in step 3. The client-side messages will be logged to ego_ext_plugin_client.log in the plugin-log-directory.

  5. Start the EGO cluster.
  6. Optionally, add 'AD_ADMIN' user (see step 1) as Cluster Administrator after logging in as 'Admin'; otherwise, the ‘AD_ADMIN’ user will not have a role in the cluster.

Usage

Users can log into EGO using the same <domain>\<username> and password they use to log into a Windows machine in your organization. The EGO cluster administrator can log into EGO by using the username 'Admin' and the password of the mapping account specified in adauth.conf.

Note:

If you are logging into EGO on Unix, you must use two backslashes between the domain and user name, i.e., <domain>\\<username>.

Note:

For enhanced security, you can access the Platform Management Console using https. Refer to Configure a secure Platform Management Console (https) for details.

Disable the AD plug-in

  1. Unassign roles for all AD accounts in the cluster.

  2. Edit ego.conf on management hosts and compute hosts by modifying the value of parameters EGO_SEC_PLUGIN and EGO_SEC_CONF as follows:

    • EGO_SEC_PLUGIN=sec_ego_ext_default

    • EGO_SEC_CONF=C:\EGO\kernel\conf (Windows)

      EGO_SEC_CONF=/opt/ego/kernel/conf (Linux/UNIX)

  3. Restart EGO on the master hosts.

    Note:

    When logging on with Admin, use the new password. The new password is the same as AD_ADMIN after you run the egostashpass-AD command. You can change this password through the PMC or CLI.

Limitations

  1. Operating Systems of all management hosts must use the same authentication mechanism.

  2. Operating Systems of all management hosts must be Windows.

  3. Before changing the security plug-in from non-AD plug-in to AD plug-in, roles for all users, with the exception of the built-in Admin user, should be unassigned in order to remove these users from the cluster. Although there is no impact to the cluster if roles remain assigned to these users, they will no longer be able to log on to the cluster.

  4. The AD Plug-in does not support the Symphony GUI/CLI ability to add/delete/modify users.