This is actually a repost but adjusted of an excerpt from the post regarding using remote journaling with iCluster. This post is focused on the need to set up DDM/DRDA authorization to the server and one of the easiest methods to ensure you have kept your system secure despite opening another access point.
Did you know you can create an IBM i group profile with DDM authentication that can be used to authenticate all of your IT Admins, Users and iCluster between the iCluster nodes? That is my favorite method so that is what we will do right now. There is a 'user by user' method for authentication in the iCluster User Guide (in the section titled "Server authentication for secure DDM connections") if you prefer that method (which we will not discuss here beyond its mention) just follow those instructions. If you want to see an easier method to maintain secure access to DDM with very little maintenance required, perform the method I will show you on each node that will run iCluster to set this up. Create the user that you will authenticate all DDM/DRDA authentication with. The password for this ID on each node needs to be the same (for the easiest maintenance) and if you are replicating all users and automatically disabling users on-the-fly within iCluster preferences, this profile must be excluded from replication so it is not inadvertently become DISABLED. (same is true of the user DMCLUSTER, the iCluster running user) This authentication method can also be easily disassembled if it will not work for your site rules. Please include any feedback 'why' or 'why not' in the forum.Create our group profile on each node:This user can be modified to meet your site rules however these parameters yield the least maintenance required over time.
CRTUSRPRF USRPRF(ROCKETDDM) PASSWORD(yourdesiredpassword) PWDEXP(*NO) STATUS(*ENABLED) USRCLS(*USER) INLMNU(*SIGNOFF) LMTCPB(*YES) TEXT('DDM authentication group profile for iCluster') SPCAUT(*IOSYSCFG) PWDEXPITV(*NOMAX)A couple items of note for this sample user profile if you use it as in the example... This is a Class *USER with password expiration turned off. This user is not able to be signed on a terminal INLMNU(*SIGNOFF) and is designed specifically for DDM authentication. The user's only special authority required is *IOSYSCFG. You could also consider just adding DDM authentication to an already existing group profile however a dedicated group profile for DDM will help the team not forget what other authorities are granted and prevent extending an authority not intended. (and this profile requires a password be defined which other group profiles may be authorities only) Remember that if the password for this user is changed, the DDM authentication entrees must also be updated to reflect the change. To ease this burden a CLP could be easily created to update both the user and the DDM authentication however it would need to be run on all clustered nodes with as little gap in time as possible. Lastly, there is nothing special about the name ROCKETDDM (other than Rocket support will recognize it and your set up authentication method), you can use whatever group user profile name you wish.You can display the Authentication Entry commands on the IBM menu: GO CMDAUTE
Suppose you have already added DDM authority to individual users but you and other members don't know for certain which users have the authority and which do not. If you want to switch methods of maintaining DDR Authority Entries, this can be really helpful and locating all the entries and making the required adjustments. There is a SQL Query that can be run on the system that every user that has an authority entry can be displayed. There are 4 fields that are retrieved; Authorization Name, Server Name, Server Authorization Name, Password Stored. The command is below:
SELECT *
FROM QSYS2.DRDA_AUTHENTICATION_ENTRY_INFO
ORDER BY SERVER_NAME
As this is a new user, we can go ahead and add the Authentication entry.(since we know the entry does not already exist)ADDSVRAUTE USRPRF(ROCKETDDM) SERVER(QDDMDRDASERVER) USRID(ROCKETDDM)PASSWORD(theROCKETDDMpassword)Now add the new group profile name (ROCKETDDM) to the existing DMCLUSTER user and any users that will interact with iCluster (whether Users, Operators, Admins) You could optionally also add library authority for the library ICLUSTER if you have updated the library as authority EXCLUDE so that non-authorized users can simply add the group profile and get both library authority and DDM authority if appropriate for your site. (It can be added in the group profile or supplemental groups parameter. See the example in the included image.)
For the new group profile value to be in effect for iCluster and users, you may need to shut down iCluster controlled and restart it normally (users may need to log off and back on). (When you are adding a new group profile to an active user the new authority can be available immediately. When you remove a group profile from an active user, it seems they need to log off and back on to reflect the change. The assured way is to log them off and back on each time authority is changed to reflect the change immediately and that would include restarting iCluster completely.)
Best of luck and happy iClustering!
#IBMi
------------------------------
Mark Watts
Sr. Software Engineer
Rocket Software Inc
Waltham MA United States
------------------------------