Build Your Own Cloud Sandbox
Part 2: Configuring security options
By José De Jesús, Michael Nassar, Apurv Johar
Introduction
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 for both). This displays the Welcome screen shown below:
If for some reason you cannot log in, revisit Part 1 and make sure you did not miss any steps or important points.
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 keep track of who did what and when.
Authentication
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:
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. Here is a sample entry for each field:
Name
The name field is where you include a name for the LDAP service provider.
JNDI
The JavaTM 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:
(&(sAMAccountName={0})(objectcategory=user))
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:
(&(uniqueMember={0})(objectclass=groupOfUniqueNames))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.
Testing your LDAP authentication settings
Once you have specified your LDAP authentication settings, you can test them by clicking the Test LDAP query button:
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
Here are three steps for creating a new user:
- Select System > Users from the menu.
- 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.
- The third step is to select the permissions you wish to grant the 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.
The following figure shows the steps to create a User Group:
- Select System > User Groups from the menu.
- Within the User Groups screen, click the green plus sign to get prompted for a group name and a description.
- 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:
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.
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.
Conclusion
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.
The next article, Part 3, will cover 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.
