MSAD on CCMDB 7

MSAD on CCMDB 7.1 - 7.1.1 (Step by Step)

Installing MSAD

Configuring Active Directory

Create MSAD structure

Create Users and groups

Installing middleware with MWI using an MSAD

How WAS security looks

Installing CCMDB

Modifying the VMMCRONTASK.

How to disable caching for immediate synchronization between LDAP and Websphere

Installing MSAD

On a windows 2003 server bring up the Active Directory Installation wizard :

Start -> run -> and then typing "dcpromo" (without quotes) and 'ok'.

Welcome panel Click Next

You may not get the following panel, but if you get it click Next

On the Domain Controller Type panel, “Domain controller for a new domain” is already selected, clickNext

On the Create New Domain panel, “Domain in a new forest” is already selected, click Next

In the New Domain Name panel, "Full DNS name for new domain" enter something like itsm.com. This will be the domain name (DN) that will be used to connect to the LDAP. ( The example uses msadinstall1.com)

You may get an error like this one :

If you get it you can click OK and continue or you can go back and select a different Full DNS name.

On the NetBIOS Domain Name panel, a value is set by default, click Next.

On the Database and Log Folders panel, leave the default values or customize the paths and click Next

On the Shared System Volume panel, you can leave the default path or customize it and click Next

DNS Registration Diagnostics panel, you may get an error due to a firewall (lab firewall). If that is the case just select “I will correct the problem later by configuring DNS manually. (Advanced)” and click Next.

On the Permissions panel, select “Permissions compatible only with Windows 2000 or Windows Server 2003 operating systems” and click Next

On the Directory Services Restore Mode Administrator Password panel, leave the password fields blank and click Next

On the Summary panel click Next to start the installation.

On the “Complete the Active Directory Installation Wizard” panel, click Finish.

Restart the machine to complete the install.

When the system comes back the login prompt is different (it may look the same), there will be a drop down domain selection(“Log on to:”) If you don’t see it click the Options button. Log in by selecting the new domain.

Configuring Active Directory

This step configures Active Directory so that the users and other parameters required for our ISM install testing could be loaded to this system.

Bring up "Domain Security Policy". (NOT "Domain Controller Security Policy" which brings up a similar gui.)

Start -> Administrative Tools -> Domain Security Policy

Navigate to: Security Settings -> Account Policies -> 'Password Policy'

We need to relax these policy so that it will accept the current test users and passwords. e.g. u:wasadmin pw:wasadmin, (this is not a requirement for our product, customers will setup this policies as they wish. )

Right click on each policy and select 'Properties' and make changes.

The following settings are known to work in our test environment:

Policy / Policy setting / Steps
'Enforce password history / Not Defined / On the properties panel the check box for 'Define this policy setting' unchecked.
Maximum password age / Not Defined / On the properties panel the check box unchecked
Minimum password age / Not Defined / On the properties panel the check box unchecked
Minimum Passsword length / 7 characters / On the properties panel the check box 'Define this policy setting' checked and set to 7.
Password must meet complexity requirements / Disabled / On the properties panel the check box 'Define this policy setting' checked and 'Disabled' selected.
Store passwords using reversible encryption / Disabled / On the properties panel the check box 'Define this policy setting' checked and 'Disabled' selected.

Note: If shorter passwords are to be imported / used it is better to set "Minimum Passsword length" to a smaller value.

Once this is done go to a cmd prompt -- dos prompt -- and type gpupdate /force or reboot the system.

Bring up the "Active Directory Users and Computers"

Start -> Control Panel -> Administrative Tools -> "Active Directory Users and Computers"

Click on the domain name to select it: i.e" itsm.com" or whatever name you chose for your domain

On the Action Menu select “Raise Domain Functional Level…” and from the “Select an available domain functional level:” drop down menu select “Windows Server 2003” and click Raise. This step is required to be able to create users and groups with the same name for example maxadmin user and maxadmin group.

On the popup window click OK

On the completion message click ok

Create MSAD structure

It us up to the user how to organize the users and groups in LDAP, the following is just one known way of doing it.

Right click on your domain and select New -> Organizational Unit

Type the name: for example “SWG” and click OK

Now right click on the organizational Unit Just created (SWG for example) and select New -> Organizational Unit. We will basically create an Organizational Unit inside SWG called Groups and then we will repeat the same process to create an Organizational Unit called Users also under SWG.

Your structure should look like:

Create Users and groups

The wasadmin user is required for MWI to configure WAS. All other users and groups are needed by base services.

Right click on Groups and from the menu select New -> Group

Create the MAXADMIN group, it has to be upper case otherwise the base services installer will not recognize its members, also make sure you select a different pre-windows 2000 group name.

Create the MAXIMOUSERS group similar to the previous step, you can leave the pre-Windows 2000 name as MAXIMOUSERS.
Right click on the Users Organizational Unit under SWG and from the menu select New -> User
Enter information to create the wasadmin user. Make sure the “Full name” field only shows wasadmin (if you fill in the last name field, the value is automatically appended to the full name and that could create confusion on later steps when configuring the cron task in maximo, it is ok to have a last name but remove it from the Full name). Clcik Next.

On the next panel set a 7 character password, unselect “User must change password at next logon”. For our testing purposes I usually select “User cannot change password” and “Password never expires”. Click Next and on the next Panel click Finish.

Following a similar process, create maxadmin with a password “maxadmin”, create also mxintadm and maxreg
Now we need to assign users to groups as follows:

Group: maxadmin Members: maxadmin, mxintadm

Group: maximousersMembers: maxadmin, mxintadm, maxreg

Click on Groups (the Organizational Unit under SWG), the list of groups should appear on the right.

double click on the MAXADMIN group to open its properties, and do the following:
Click on the members tab
Click on the Add button

On the “ Select Users, Contacts, Computers, or Groups” window click on the “Advanced…” button

On the next window, click the “Find Now” button, the list will appear at the bottom of the window. Select maxadmin and mxintadm, (NOTE: make sure you select the maxadmin User, the list will show both the maxadmin user and MAXADMIN group). Click Ok.

Click Ok on the previous window and again Click Ok to add the members.

Follow a similar process to add maxadmin, maxreg and mxintadm to the MAXIMOUSERS group.

At this point your MSAD configuration is complete the next step is to install the remaining middleware with the J2EE server pointing to your MSAD LDAP.

Installing middleware with MWI using an MSAD

I will not list all the steps to install middleware, I will just list the relevant steps that you need to execute to use MSAD.

On the features to deploy unselect “Directory Server”

When you get to the following panel, select Secure with Active Directory

Set the values as suggested in the following panel. You may need to adjust them if you used a different MSAD structure.

As you can see on the User suffix, or the Group suffix (OU=Users,OU=SWG,DC=msadinstall1,DC=comOU=Groups,OU=SWG,DC=msadinstall1,DC=com)the OU stands for the Organizational Unit, those are the ones that were created when configuring MSAD.

On the following panel the only thing that you may need to change in the “Bind distinguished name” is the domain name (msadinstall1 in the example). The Administrator user is not contained in the structure that we created (OU=Users, OU=SWG) therefore the bind distinguished name is different.

The password should be set to the Administrator’s password of the system where MSAD is installed.

If your MWI install completed successfully that is a good sign that your configuration is correct.

How WAS security looks

You can login to your WAS console and check the security settings, The panels are shownhere for reference only, you don’t need to change anything.

Expand Security on the left navigation panel, click on “Secure administration, application and infrastructure”.

As you can see on the User account repository section, Federated repositories is currently selected.

On the “User account repository“ section, click on the Configure button.

You will notice in the next panel that the Primary administrative user name was configured as wasadmin as expected .

in the Repositories in the realmyou will see an entry for your MSADLDAP server.

Now Click on Manage repositories.

This panel shows the list of repositories, in this case there is only one, Click on ISMMSAD

The following panel contains some of the configuration information.

On the LDAP Server section you will see the Directory type is set to “Microsoft Windows Server 2003 Active Directory”

The primary host name field was set to your MSAD server.

Under the Security section, the Bind distinguished name was set to CN=Administrator,CN=Users,DC=msadinstall1,DC=com

The password is set to your MSAD Administrator login password.

Now Expand Security on the left navigation panel and click on “Secure administration, application and infrastructure”, then under the “User account repository“ section, click on the Configure button. You should be back to the following panel:

click on Supported entity types you should get to the following panel, where you will see additional configuration information that was done by the MWI installer.

Now Expand Users and Groups on the left navigation panel and click on “Manage Users”, when the next panel is displayed click on the Search button.

You should see the list of users that exist in your MSAD LDAP Server including the ones that you created.

Now Click on Manage Groups on the left and when the panel is displayed click on the Search button. You will get the list of groups on your MSAD LDAP server.

Installing CCMDB

Now that your middleware is ready ensure that all your services are running:

DB instance

Deployment Manager

Node

MXServer

webserver1

Once all services are running kickoff the Tivoli base services installer.

Only the relevant panels will be shown. They will come after the Websphere configuration panels.

The following panel is only displayed if you installed with the platformonly=yes flag on 7.1.1, on 7.1 the panel will not be shown. You have to leave it as it is and click Next.

On the next panel you have to uncheck both boxes. This is because on MSAD the default schema is not used and the users can not be created by the installer on MSAD(that is why we created them earlier).

Navigate to the remaining panels and kickoff the install.

Modifying the VMMCRONTASK.

To be able to sync your MSAD users and groups with maximo you will need to modify the VMMCRONTASK.

Click on GoTo and select System Configuration -> Platform Configuration -> Cron Task Setup, the following panel will appear, type vmmin the Cron Task field and hit Enter.

The list will display the VMMSYNC cron task. Click on VMMSYNC.

On the next panel you will need to change the following:

Check the Active? box.

Optionally Check the Keep History? box.

On the parameters the values you need to change are marked with **

VMM Crontask Parameter / Value for MSAD
Credential** / Password for wasadmin in LDAP
GroupMapping** / On the XML file change the following:
<basedn>ou=Groups,ou=SWG,dc=msadinstall1,dc=com</basedn>
GroupSearchAttribute / Cn
Principal** / cn=wasadmin,ou=Users,ou=SWG,dc=msadinstall1,dc=com
SynchAdapter / psdi.security.vmm.DefaultVMMSyncAdapter
SynchClass / psdi.security.vmm.VMMSynchronizer
UserMapping** / On the XML file change the following:
<basedn>ou=Users,ou=SWG,dc=msadinstall1,dc=com</basedn>
UserSearchAttribute / Uid

Click on the arrow () to display the SynchClass, UserMapping and UserSearchAttributeparameters.

Your VMMSYNC cron task setup should look similar to the following panel.

Once you make this changes, save them by clicking on the save icon ( ).

The synchronization should happen every time the cron task is scheduled to run.

If the synch doesn’t happen, don’t panic, check the WAS systemOut.log usually located on Windows at

C:\Program Files\IBM\WebSphere\AppServer\profiles\ctgAppSrv01\logs\MXServer

On linux at /opt/IBM/WebSphere/AppServer/profiles/ctgAppSrv01/logs/MXServer

On AIX at /usr/IBM/WebSphere/AppServer/profiles/ctgAppSrv01/logs/MXServer

If you don’t see any errors then wait for a few more minutes. This may be due to the caching on WAS which can be disabled (See section: How to disable caching for immediate synchronization between LDAP and Websphere).

If you see errors in the log that means something is wrong with your cron task setup, check the values again.

Verify on WAS that the users or groups that you are expecting to be synchronized are already there, if they are not there then the problem is not with the cron task, the problem may be the WAS cache or a WAS configuration issue.

How to disable caching for immediate synchronization between LDAP and Websphere

(This chapter was copied from another document that is why the values on the screen captures may differ from the previous screen captures but the steps are completely valid).

By default caching is enabled in WAS. For testing purposes, we usually don’t want to wait 10 minutes or more for the synchronization to happen, if this is the case we need to disable caching in Websphere.

After caching is disabled in WAS then the synchronization time will only be controlled by the time the cron task is set to run (5 minutes by default).

Expand “Security” on the left navigation.

Click on Secure administration, applications, and infrastructure

On the User account repository section click on the “Configure” button.

Click on the Repository identifier ISMITDS

On Additional Properties Click on Performance

On the “Caches” section uncheck the “Cache the attributes” and “Cache the search results” boxes.

Click Ok.

Save the changes.

There is no need to restart the deployment manager.