Today I’m going to show you how to keep your passwords synchronized across multiple systems using some simple commands provided with IBM PowerHA SystemMirror for i. The IBM PowerHA SystemMirror for i LP was introduced in release 6.1 as the IBM i disk-based high availability and disaster-recovery solution. Part of that solution includes the application known as cluster administrative domain. Even if you aren’t ready for a full-blown HA/DR configuration, you can use cluster administrative domain as a simplified management tool for managing resources across multiple systems, including your user profiles and passwords.
PoweHA Cluster Administrative Domain
The PowerHA cluster administrative domain application provides the capability to maintain a consistent operational environment across multiple systems. A consistent operational environment, along with data and application resilience, is the cornerstone of a highly available application. The operational environment is defined to be the set of resources and attributes that are used by an active application – resources such as user profiles or system values. On IBM i, the cluster administrative domain maintains resources consistently across the nodes in an HA cluster by synchronizing changes to the resources. These resources are called monitored resources within the cluster administrative domain.
Setting Up a Cluster Administrative Domain in 6 Easy Steps
I’m going to show you how to manage your user profiles across multiple systems using the CL commands provided with the PowerHA SystemMirror for i licensed product. In addition to the individual commands used in my example, you can find these steps as options within the WRKCLU command, or you can use one of the PowerHA Web applications that are integrated into IBM Systems Director Navigator for i.
1. Set the QRETSVRSEC System Value
It’s important that the QRETSVRSEC system value be set to 1 before adding any user profiles to your cluster administrative domain. In addition, you should change the password for any user profile you want managed by the administrative domain after changing the system value. This allows the cluster administrative domain to synchronize the password across the nodes in the domain. To change the system value, use this command:
CHGSYSVAL SYSVAL(QRETSVRSEC) VALUE('1')
2. Create the Cluster
Now we’re going to create a one-node cluster and start the node. The cluster name is a 10-character name of your choosing. It’s recommended that the eight-character node name be the same as your system name, for easier management. Using this command, the cluster MYCLUSTER will get created on your first system, represented by the IP address on that system, with a node name of NODEA and the node will be started:
CRTCLU CLUSTER(MYCLUSTER) NODE((NODEA ('9.5.114.142')))
3. Add a Second Node to the Cluster
Next we’re going to add a second node to the MYCLUSTER. This command will result in a cluster node called NODEB, represented by its IP address, being created and started on your second system.
ADDCLUNODE CLUSTER(MYCLUSTER) NODE(NODEB ('9.5.111.151'))
You can repeat this command to add more nodes to your cluster.
4. Create the Cluster Administrative Domain
Now we’re going to create a cluster administrative domain on the two nodes in our cluster using this command:
CRTCAD CLUSTER(MYCLUSTER) ADMDMN(MYDOMAIN) DMNNODL(NODEA NODEB)
5. Start the Cluster Administrative Domain
Next we’ll start the cluster administrative domain, which starts the synchronization process. Since we don’t have any monitored resources in our administrative domain yet, there’s nothing to synchronize yet. By starting the domain first, any resources we add as monitored-resource entries will get synchronized as they get added. We’ll use the following command to start the domain MYDOMAIN in cluster MYCLUSTER.
STRCAD CLUSTER(MYCLUSTER) ADMDMN(MYDOMAIN)
6. Add a User Profile to the Administrative Domain
Finally, we need to add our user profile to the cluster administrative domain as a monitored resource. The user profile must exist on the system where we’re running the ADDCADMRE command. It may or may not exist on the other node. If it doesn’t exist on the other node, the cluster administrative domain will create it, based on the user profile from the originating system.
For our example, we only want the administrative domain to synchronize our password, so we will specify PASSWORD as the attribute to monitor.
ADDCADMRE CLUSTER(MYCLUSTER) ADMDMN(MYDOMAIN)
RESOURCE(MYPROFILE)
RSCTYPE(*USRPRF) ATTRIBUTE(PASSWORD)
I now have an active cluster with an active cluster administrative domain monitoring for password changes to MYPROFILE. This means that any time the password is changed on any node, it will be changed on all nodes in the administrative domain. If I change some other attribute of the user profile, such as its job description, the new job description won’t be propagated and changed on the other nodes. I’m not replicating the complete *USRPRF object, only those attributes that I want synchronized; in this case, just the password. I could specify *ALL for the ATTRIBUTE parameter to synchronize all of the supported attributes for user profiles.
You’re now ready to test drive your cluster administrative domain setup. Change the password for your user profile on either one of the nodes in your domain. Now go to second system and sign on with new password. There you go! You have a synchronized password in six simple steps!
There are a couple of neat features with this application that may not be obvious. First of all, you don’t need a central site from which to manage your passwords. Once you have the cluster administrative domain set up, you can make changes from any node, and they will be propagated to the other nodes. Second, and probably even more important, you don’t have to have all of your nodes active in order to maintain consistency. If one or more of the nodes in your domain aren’t active when you make a change to the monitored resource, the change will be applied on the inactive node when it rejoins the cluster.
If you’re interested in reading more about IBM PowerHA SystemMirror for i and the cluster administrative domain application, here are some useful links:
This blog article was written by Lilo Bucknell. Lilo is a member of the IBM i Power HA design and development team.Thanks, Lilo!
This blog post was originally published on IBMSystemsMag.com and is reproduced here by permission of IBM Systems Media.