Build your own cloud sandbox, Part 2: Configuring security options

ESX Server Edition

This article continues our discussion from Part 1 on how to build and configure your own cloud sandbox using a Workload Deployer virtual appliance. If you successfully completed the steps outlined in Part 1, which cover a complete installation up to the point of logging in, you are now ready to configure the appliance. This article shows you how to configure your security options. As illustrated in Part 1, the terms Virtual Pattern Kit for Developers, IWD, and Workload Deployer are used interchangeably throughout this series. This series complements the Navigating the IBM Cloud article series.


José De Jesús (, Executive Architect, IBM

Photo of Jose De JesusJosé De Jesús is an Executive Architect on the IBM Software Services for WebSphere for IBM (I4I) team. José is a member of the IBM Academy of Technology and leads the I4I Cloud Strategic Initiative. He is also the ISSW Certification Lead, and a member of the Distributed Management Task Force (DMTF). José has a B.S. degree in Computer Science from Fordham University, and an M.S. degree in Management of Technology from the University of Miami.

developerWorks Contributing author

Michael Nassar (, Enterprise Architect and Senior Manager, Wipro Limited

Photo of Michael NassarMichael Nassar is a Senior IT Consultant and Certified Enterprise Integration Architect with experience in the full life cycle management of solution oriented software development. He works with client leaders to understand their needs and develops roadmaps to address business pain points and realized value. Michael designs, develops, and delivers engagements for a variety of industries and clients. He has experience leading onsite and offshore development teams.

Apurv Johar (, Senior Software Engineer, IBM

Photo of Apurv JoharApurv Johar is a Senior Software Engineer and Solution Architect on the IBM Software Services for WebSphere for IBM (I4I) team. Apurv is an IBM Certified IT Architect and IBM Certified SOA Solution Designer. Apurv has over 17 years of experience as a software engineer and architect in the IT industry, including 14 years at IBM. In his current project, Apurv is the technical lead and development lead for the Integrated Sales Portal (ISP) application, which is available to all IBM sellers and sales managers worldwide via the IBM OnDemand Workplace (ODW).

December 2013 (First published 13 November 2013)

Also available in Russian


In this article, we start exactly where Part 1 ends. To start preparing your cloud environment, log in to the Virtual Pattern Kit for Developers (VPKD) using the default user name and password, cbadmin. This displays the Welcome screen shown in Figure 1. If for some reason you cannot log in, revisit Part 1 and make sure you did not miss any steps or important points.

Figure 1. The VPKD Welcome screen
The VPKD Welcome screen

Configuring security

After logging in, one of the first things you should do is configure your security options. For example, if the virtual appliance will be shared, you need to change the default cbadmin values and also define your user accounts and user groups. Doing so allows you to establish permissions and also keeps track of who did what and when.


IBM Workload Deployer (IWD) offers two types of authentication mechanisms: local and external.

  • Local authentication uses a built-in repository to manage users and groups. This is what you get by default and where the cbadmin administrator account gets created.
  • External authentication allows you to configure IWD against an LDAP server.

You can use both local and external authentication, as needed. For example, it is considered good practice to create at least one administrator account that uses both types, so that you always have access to the system even if LDAP is down.

Configuring IWD to work with an external LDAP directory

Choosing the menu option of System > Security brings up the System Security configuration screen shown in Figure 2.

Figure 2. Enabling LDAP Authentication
Enabling LDAP Authentication

Notice how you get options to allow users to create their own accounts and to reset their passwords from the serial console. You can also set timeouts for automatically logging out inactive users.

Enabling LDAP authentication tells Workload Deployer to use a specific LDAP server to authenticate users at login. You just need to click the Enable LDAP Authentication checkbox and fill in the required fields. Table 1 provides a sample entry for each filed.


The name field is where you include a name for the LDAP service provider.


The Java™ Naming and Directory Interface (JNDI) is an API used to access naming and directory services in Java. In this case, JNDI allows IWD to look up user profiles defined in the LDAP directory. The provider URL points to the server that provides the directory service. The format of this field is: ldap://hostname:port.

The hostname denotes the hostname or IP address of the LDAP server, and port denotes the TCP port being used. Port 389 is the default LDAP port, whereas 636 is used for LDAP over SSL.

JNDI base DN (users)

LDAP directory servers store their data hierarchically, with a top-down structure similar to DNS trees and UNIX file directories. The top level of an LDAP directory tree is called the "base", and is referred to as the "base DN." DN, which stands for Distinguished Name, is simply the short name for an LDAP record. All LDAP entries have a DN. The JNDI base DN for users, therefore, refers to the point in the LDAP tree at which the search for users begins. Any objects above that base will not be part of the search.

A base DN can take one of three forms:

  • base DN in X.500 format
    o="company name", c="country"
  • base DN derived from the company's Internet presence
    o="company's Internet domain name"
    ou="company's organizational unit"
    o stands for organization while ou stands for organizational unit. An ou entry is used to logically separate LDAP data. For example, while o refers to a company, ou can refer to a specific business unit or a group within that company. For these entries, you need to find the information pertinent to your specific organization.
  • base DN derived from the company's DNS domain components
    dc="domain component"
    dc stands for domain component and provides for a way to split things by domain components for better flexibility.

JNDI base DN (groups)

This field represents the top level entry of the LDAP tree at which the search for groups begins. Using a base DN derived from a company's Internet presence, for example, the format would be one or more of: ou=logical group, o=company's Internet domain name. Again, you must contact your company's LDAP administrator to get the right entries for this field. In other words, you need to find out what is the base DN used for groups.

Search filters (users)

Search filters allow you to specify which attributes to search for in a search operation. This field allows you to specify the search filter for users. The supported format is:

or uid={0}

The LDAP property sAMAccountName refers to the Security Accounts Manager (SAM) Account Name. The entry objectcategory is used to query the organizational unit.

The search filter for groups is fixed and not configurable. It has the following format:


An object class specifies a set of attributes that describe an object. For example, an object class called "ibmPerson" can contain attributes associated with an IBM employee, in which case the entry objectclass=ibmPerson returns any objectclass that uses ibmPerson in its hierarchy. That means the search filter returns any person who is classified in LDAP as an IBM employee.

An entry of "mail={0}" says that the mail attribute must be equal to the value specified in the {0} placeholder. The {0} placeholder is replaced by the login user ID. Finally, "&" means to find the entries that meet the criteria specified in all the search filters.

JNDI security authentication

This field allows you to specify the common name (CN) of the persons authorized to make LDAP queries, in which case you also have to include the password. Unless the LDAP server does not allow anonymous LDAP queries, this field is optional.

Table 1. Sample entries to enable external authentication in IWD
Name My Company LDAP
JNDI provider URL ldap://
JNDI base DN (users) ou=mycompany,
JNDI base DN (groups) ou=memberlist,ou=ibmgroups,
Search filter (users) (&(mail={0})(objectclass=ibmPerson))
JNDI security authentication CN=Admin,CN=users,DC=ibm,DC=com

Testing your LDAP authentication settings

As Figure 3 shows, once you have specified your LDAP authentication settings, you can test them by clicking the Test LDAP query button.

Figure 3. Testing your LDAP authentication settings
Testing your LDAP authentication settings

If your settings are correct, clicking the Test button should show "Found" messages for the corresponding user and group names. If your queries are not successful, review your entries under "External Authentication". If everything seems right to you, but things are still not working, you may have to contact your company's LDAP administrator for help.

The LDAP group name assumes you previously created the group name using whatever tool your company makes available to create LDAP groups. If you are configuring your own LDAP server, you can use an LDAP script or a utility, such as LDAPAdmin for Windows® or Linux, to create the LDAP groups.

Creating users

Figure 4 illustrates how to create a new user. The steps are as follows:

  1. Select System > Users from the menu.
  2. Within the Users screen, click the green plus sign to get prompted for user information. Notice that, if LDAP authentication is enabled and you select account type LDAP, the system does not prompt you for a password because it already exists in the LDAP system.
  3. The third step is to select the permissions you wish to grant the new user.
    Figure 4. Steps for creating a new user
    Steps for creating a new user

The “Deploy patterns in the cloud” permission is automatically set for all users. This allows them to deploy patterns onto the cloud. You can manually assign additional permissions by clicking the corresponding checkboxes.

Creating user groups

If you enabled LDAP authentication, and created a user group within your LDAP system, you can use that group name to create the user group in Workload Deployer. This automatically brings in all the members of that group.

Figure 5. Steps for creating a user group
Steps for creating a user group

As illustrated in Figure 5, the steps to create a User Group are as follows:

  1. Select System > User Groups from the menu.
  2. Within the User Groups screen, click the green plus sign to get prompted for a group name and a description.
  3. Enter a name and a description for the group name. If you use a group name that was previously created in your company's LDAP system and you have LDAP authentication enabled, Workload Deployer automatically adds the group's members to the Workload Deployer group.

You cannot modify the membership of an LDAP group within Workload Deployer. If you wish to make changes, you can do so directly in the LDAP system, in which case you have to delete and re-add the group to see the updated membership list.

If you do not have LDAP authentication enabled, you see an entry for manually adding members to your group, as shown in Figure 6. User groups created directly in Workload Deployer that do not exist in LDAP are initially empty. Clicking Add more… allows you to select which users will belong to that group. This, of course, assumes you have already created those users.

Figure 6. Adding members to groups
Adding members to groups

User groups allow you to classify users into groups with different access levels to help protect your environment from internal and external threats.

When assigning permissions to users and user groups, keep in mind the Separation of Duties (SoD) principles. These ensure that users can only perform tasks that correspond to their roles. It is also a good idea to create one or more auditors that have full permissions to the system.


This concludes our second article in this series. You learned how to configure security options for your IWD virtual appliance, including how to connect IWD to an LDAP server for authentication.

Part 3 covers how to configure cloud resources such as IP groups, cloud groups, hypervisors, and environment profiles. You will also learn how cloud groups and environment profiles can help you further restrict the use of certain cloud resources and activities.


The authors would like to thank Tendai Chinoda for his help in reviewing this article.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into WebSphere on developerWorks

Zone=WebSphere, Cloud computing
ArticleTitle=Build your own cloud sandbox, Part 2: Configuring security options