I initially found it hard to set up the AT-TLS configuration for MQ. The easiest way was to use the sample configurations provided by MQ. See here for an overview. I used Scenario 5 – Between an IBM MQ for z/OS queue manager and a client application running on IBM MQ for Multiplatforms.
Using the MQ samples, this took about 10 minutes once I had PAGENT and SYSLOGD set up.
I thought I would try to use the TCP provided facilities. There is a lot of documentation, but it is not easy to find what you need. It has been written as an IBM developer, rather than from an end user or task based perspective.
I then thought I would try to use the “way of the future” and the z/OS configuration tool z/OSMF. You use a browser to connect to z/OSMF and do your work through the browser interface. The z/OSMF interface has configuration tools, and workflow tools which guide you step by step through configuration.
I’ve blogged Using z/OSMF workflows for TCPIP. Using the workflow was not very successful.
The Network Configuration Assistance is used to configure the PAGENT, and I used it to define a AT-TLS configuration. Initially this was a struggle as there was no documentation to tell me how to do it. Once I had been through the configuration a couple of times, I found the correct path through the configuration progress and it is relatively painless.
My mission.
My mission was to configure AT-TLS and to provide two ports for use with MQ.
I wanted to do this using two people (me with two userids) and do the typical steps when changing systems, such as saving configurations before changing them, and deploying them, when I had a “change window”.
Using the Network configuration assistant (CA)
AT-TLS concepts
You need to be aware of the AT-TLS concepts when defining the configuration. From an administrator’s perspective:
- What ports you want to protect? This is known by the CA as Traffic Descriptors. You can specify
- An IP port
- A range of IP ports
- What IP addresses you want to protect.
- The IP address. A TCP/IP stack can support different IP addresses. You can use a specific IP address. You can select on all IPV4, or all IPV6, or all addresses.
- The name of a group of IP addresses. z/OSMF CA calls these Address Groups.
- How do you want to protect the session. For example what levels of TLS, and what cipher specs do you want to use. This is known by the CA as Security levels.
- The mapping of ports to protecting the session. z/OSMF calls this Requirement Maps.
- You configure at the TCPIP stack level.
- z/OSMF has groups of z/OS instances, with one or more z/OS instances, and you can have multiple TCPIP stacks in a z/OS instance.
Backing store
The configuration assistant(CA), stores configuration in a backing store. You can use tools to copy the current store. I found a copy of the file in /global/zosmf/data/app/CAV2R4/backingStore/save Data. I should be able to use standard backup procedures to keep a copy of the file. The resulting configuration is created in a file which is used by PAGENT.
You can copy a backing store within the CA, and so go back to the original one if you need to.
Before you start.
You should collect the information that you will be used to configure PAGENT. For example
- Which systems and IP stacks will be used.
- Which keyrings and certificates will be used?
- For each port you want to protect.
- What rules do you want, for example which cipher specs.
I found the terms used when creating the rules manually – did not map to the CA concepts, but once you understood the difference in terminology it was ok.
How to define the resources
If you define the configuration bottom up. You define all of the rules, then when you get to configure the TCPIP stack, the rules and other components should all be there, you just have to select them.
If you define the configuration top down, you define the TCPIP stack, then the rules for the stack. You have to define the TCPIP stack, then the rules, then go back and reconfigure the TCPIP stack to add the rules.
I think bottom up configuration is better while you gain experience of the tool. Once you are familiar with the tool then the top down approach will work ok, and may be how you update the configuration.
Getting started
- Double click on the Network Configuration Assistant icon.
- You get a page Welcome to V2R4 Configuration Assistant for z/OS Communications Server. On this page you can specify the name of the backing store. The pull down lists the existing backing stores. If you do not have a backing store create one. You can use “tools”button to copy the backing store.
- The “getting started” gives you information on how to use the panels. I found it a little confusing at times. It displays the help in a separate window. In the Table of Contents, it has “AT/TLS – getting started”. I didn’t find the help or tutorials much use.
- On the Welcome page, press Proceed.
- I sometimes get “The backing store is locked by your id.” I got this after I had shutdown down z/OSMF without logging off.
- You can use “Tools” to manage your backing store, and configuration.
- “Select a TCP/IP technology to configure” : AT-TLS
- The layout of the panels, make me think you create the definitions from top to bottom, and so the tabs are defined left to right. I think it is easier to define resources then create the group/image/stack.
Define the rules for which ports to be protected
In the page Network Configuration Assistant (Home) -> AT-TLS page, click on the Traffic Descriptors tab.
- Actions -> New…
- Name COLINTD
- Actions-> New…
- Under the Details tab, specify the port or port range and any other information
- Under the KeyRing tab, specify the keyring and the Certificate label or let it default to the TCPIP stack level keyring.
- Under the Advanced tab, I let everything default.
- Click OK
- You can define a second port within this Traffic Descriptor
- Click OK
You can press Save to save the current definitions.
Define which IP addresses you want to protect (optional)
In the page Network Configuration Assistant (Home) -> AT-TLS page, click on the Address Groups tab.
By default it has
- All_IPv4_Addresses
- All_IPv6_Addresses
- All_IP_Addresses
A TCPIP stack can host different IP addresses, one for each connector coming in. If you want to limit rules to particular stack owned IP addresses, create a definition.
- Actions-> New
- Name: COLINAG
- IP Address: 10.1.1.2
- IP Address: 10.1.1.3
- OK
You can press Save to save the current definitions.
How do you want to protect the session.
For example what levels of TLS, and what cipher specs do you want to use.
In the page Network Configuration Assistant (Home) -> AT-TLS page, click on the Security Levels tab.
- Actions: -> New…
- Name: COLINSL
- Select levels of TLS you want to use
- Next, then select cipher specs. I used “Use 2019 suggested values”
- Next – I took the default (“Do not generate FIPS 140 support“)
- Click on Advanced settings.
- If you want to use client authentication click the “Use client authentication” box
- OK
- Finish
Your definition should be in the list.
You can press Save to save the current definitions.
Mapping of ports to Session protection
In the page Network Configuration Assistant (Home) -> AT-TLS page, click on the Requirement Maps tab.
- Actions: -> New…
- Name: COLINMAP .
- In the mappings table,
- use the Traffic Descriptor pull down and select the Traffic Descriptor you created above. For example COLINTD.
- Under Security Level pull down select the security definition you created above. For example COLINSL.
- OK
If I changed an existing definition, I had a pop-up
Modify Requirement Map.
The requirement map you are changing may be referenced in at least one connectivity rule.
Prior to making this change you may want to see which connectivity rules are referencing this requirement map. Click OK to show where used. Click Proceed to proceed with the Modify; otherwise, click Cancel.
Click OK to show where it is used.
Click Proceed
You can press Save to save the current definitions.
Create the group, z/OS instance and TCPIP Stack
In the page Network Configuration Assistant (Home) -> AT-TLS page, click on the Systems tab.
- Action: -> Add z/OS group…
- Name: COLINGR
- Click OK
- Action: -> Add z/OS system image…
- Name: COLMVSA
- Keyring: START1.COLINRING
- Press OK
- I get a pop-up Proceed to the next step? Connectivity rules are configured for each TCP/IP stack. To continue with configuration you need to add a TCP/IP stack to the new z/OS system image. Do you want to add a TCP/IP stack now? Click on Proceed.
- This gets to the Add TCP/IP stack
- Name:TCPIP
- OK
- I get a pop-up. Proceed to the next Step? o continue with the configuration you should add connectivity rules to the TCP/IP stack. Do you want to be directed to the TCP/IP stack rules panel? Proceed.
- If you cancel you can use the Actions -> rules to define the rules.
- I get a pop-up Proceed to the Next Step? Do you want to start a wizard to create a connectivity rule? Click Proceed.
- This gets to the Data End points where you associate the IP addresses to the stack instance.
- Name: COLINRN
- Select from the address group pull-down, or let it default.
- Press Next
- This gets to the Requirement Mapping to Stack association.
- You can select from the existing requirements map see Mapping of ports to Session protection above, or create a new mapping.
- You can create a new map, for example Name: COLINMP
- Select from the Traffic Descriptor pull down
- Select from the Security level pull down.
- Press Next
- You can specify advanced settings, such as Tracing, Tuning, Environment, Effective times, Handshake
- Finish
- Close
You can press Save to save the current definitions.
Join the bits up
In the page Network Configuration Assistant (Home) -> AT-TLS page, click on the Systems tab.
- Select a group instance
- Actions: Install All files for this group
- This will list the configuration files.
- On the Configured File Name,
- right click on the file name value, and ->Show Configuration File. This will show you the configuration as it might be deployed.
- right click on the file name value and -> Install … . Specify the a file name and click GO.
- Close
- You can use
- Actions: Install to create the configuration file
- Actions: Show configuration file to see the generated configuration
You can now use the configuration file as input to PAGENT.
You can press Save to save the current definitions.
Extending the configuration to add a new rule
It took a while to work out how to do this, but it is really easy.
In the page Network Configuration Assistant (Home) -> AT-TLS page, click on the Traffic Descriptors tab.
- Create a new Traffic descriptor as above
- Get back to Network Configuration Assistant (Home) -> AT-TLS page, and click on the Systems tab.
- Select a TCPIP instance, and click Actions: -> Rules..
- Actions: -> New
- Connectivity rule name: rule2
- Press Next
- You can select from the existing requirements map see Mapping of ports to Session protection above, or create a new mapping. If you have just created a new rule, then you may not have defined a mapping, and create it “inline”.
Then install it.
Use the configuration
You need to change the PAGENT JCL to use the created configuration file. You may want to copy it to a backup, as the next time you reconfigure it can overwrite the file. Or just create a new file perhaps with a date in the filename.
If you have problems with a newly reconfigured file you need a copy of the previous, working, definitions.
Display the configuration
On many items, you can use right click -> Show where used. This will then display the group, image, stack, connectivity rules and data end points where the item is used.
Should I use this just to get started, or every time.
When I created my definitions by hand, I could put definitions in to a “Common” section, and have multiple TCPIP stacks in one configuration file. I could have small files with bits of configuration in them.
If you use the CA, “common” definitions are copied into the configuration file, and you have one configuration file per TCPIP stack instance, so you do not need to have a common section etc.
As a configuration tool, now I know how to use it, I might continue to use it – but it is slightly more complex than this.
I want to enable trace for one definition. To do so means I have to…
- Change the configuration to set the trace. This can be difficult if someone else is in the middle of changing the configuration.
- Deploy the whole configuration. You may pick up incomplete changes which have been made, but not deployed.
- If a second TCPIP stack is using the configuration, this may get trace enabled if the configuration file is recreated.
Overall (my views may change tomorrow), I would use the CA to create my configuration. Then not use it again – or use it again to generate definitions which I can copy into my master configuration files. I would restructure the configuration so create small files with specific content.