Would it surprise you to know there’s an MQ V8 System Administration certification? Normally I run down and take the test as soon as it’s available but this one has been out since January 14th and somehow I missed the announcement. So yesterday I stopped by at my local Pearson Vue affiliate and sat for Test C2180-410: IBM MQ V8.0, System Administration to earn my certification. Did I pass? You betcha! Was it what I was expecting? Sort of.
About the test
The test is structured like the others. There’s 57 questions of which you need 36 to pass. Presumably the pool of questions is larger than needed and the selection is slightly randomized so you won’t get the same exact set on two sittings. There are 8 categories represented:
- Planning, Installation, and Migration (11%)
- Configuration (18%)
- Security (11%)
- Administration (16%)
- Availability (9%)
- Monitoring (14%)
- Performance Tuning (9%)
- Problem Determination (14%)
As a candidate you are penalized a bit for specializing on mainframe or distributed since many of the questions are platform-specific. I had no idea how to answer the mainframe questions but amazingly I scored 100% on Performance Tuning which I know included a couple questions on buffer sets and SMF statistics. I guess my days as an operator and COBOL coder are still paying dividends.
Damned if you do, damned if you don’t…
Amazingly, my lowest scores were in the Security and Administration sections where I got 4 out of 6 and 6 out of 9, respectively. Which brings me to why I said the test was “sort of” what I expected. There were several questions for which no correct answer was given. Maybe it’s my autism, but I do not tend to do well being forced to select the least of multiple evils. This is especially true with respect to security because being “moderately secure” is like being “moderately pregnant.” The tag line for my blog The Odd is Silent is “because if I don’t write, I’ll explode.” Being forced to designate an example of broken security as “correct” is an example of where that tag line came from.
One question in particular had me steaming mad. It asked how to meet a requirement for encryption in transit when the remote node was an (S)FTP server outside the firewall. There were a couple of choices for non-existant product features which I ruled out immediately. One choice mentioned actual product capabilities but didn’t address the requirement. The one I picked said to use AMS and FTE. Given the wording, TLS channels would have worked internally and if we talk about FTE I’d ideally want to see the Protocol Bridge mentioned but more importantly the mandatory use of SFTP or FTPS when connecting to a server that also supports plaintext connections.
I picked the answer that I did knowing it was wrong but basing my decision on the notion that it was the least wrong of the bunch. Given my grade, I now believe that the question is incorrectly scored on IBM’s side, which is not surprising given that there’s no right answer to begin with. In fact, if I had access to the master to see which answers were supposed to be “correct” I’m guessing part of my low scores on the Security and Admin sections is that the test is wrong.
Normally I give myself half an hour for any MQ certification test. This one took me slightly longer because I stopped on about 10 questions to provide feedback. (When will IBM stop using setmqaut -p on UNIX-based systems? This was another question that had no correct answer but at least the correct wrong answer was obvious. Lost time to feedback on this, naturally.) I will drop Helene a line to let her know about the feedback I left and offer to review the test. I’ll let you know if I hear that anything’s been fixed.
If you plan to take the test I recommend spending some time in the What’s new in WebSphere MQ Version 8.0 section of the Knowledge Center, however even here you need to step around the cow patties.
KC Cow patty: CERTLABL
For example, there’s a section describing the channel’s CERTLABL attribute which is a new feature for multiple configurable certificates. This feature allows you to configure the queue manager to present a different certificate per-channel. A typical use case for this is that the queue manager is known by an internally-signed certificate on internal-facing channels and by a commercially signed certificate on the externally-facing channels. CERTLABL is an exciting new feature for anyone who has queue managers connecting to external business partners. Prior to its appearance in MQ you would have had to use MQ Internet Pass-Thru to get this feature.
The KC content describes CERTLABL, but only just barely, in the first paragraph. The next three paragraphs talk about SSLPEERMAP and its SSLCERTI attribute. My issue with this is that CERTLABL is a security control applied to the identity the QMgr presents while SSLPEERMAP and SSLCERTI are controls for the identity of remote entities. Furthermore, the need for SSLPEERMAP and SSLCERTI is raised any time the queue manager has to resolve certificates from different Certificate Authorities and we had that requirement long before CERTLABL was added.
It is tough to define something in terms of something else it is barely related to but that’s what we have, for now. The SSLPEERMAP and SSLCERTI content needs to be removed from this section and the CERTLABL content expanded with a much better explanation of how it helps to specify the identity presented by the QMgr, and yes I’ll report it.
KC Cow patty: REVDNS
The Knowledge Center sections describing the REVDNS feature seem sparse to me. Maybe you’ll feel different. If so, please let me know. Here’s the text from the What’s New item describing the feature:
The WebSphere MQ CHLAUTH rules have been enhanced so that CHLAUTH definitions can use Domain Name Server (DNS) host names instead of IP addresses. The queue manager REVDNS attribute controls whether reverse lookup of the hostname from a Domain Name Server is done for the IP address from which a channel has connected. If this attribute is enabled, DNS host names are reverse looked-up for the IP addresses of inbound channels when this information is required. If the REVDNS attribute is not enabled, DNS host names are not reverse looked-up for the IP addresses of inbound channels. For more information about the REVDNS attribute, see ALTER QMGR.
And here’s the text I believe they left out:
Treat REVDNS like a gun that has a hair trigger and only fires when it is pointed at your foot.
And, yes, they need to make it big, bold and red in the KC whenever they get around to adding it. I could write a whole book on why REVDNS is bad in general and why when used as a security control does the opposite of what it claims. But I’ll try to summarize.
- Too many DNS hacks to list here. Whether or not your internal DNS is secure is less of a question than whether you will enable REVDNS without actually verifying the security of the internal DNS.
- DNS is a blocking call and by default the TCP timeout is set to 2 hours. Let’s hope the DNS and every cable, switch, router, and device between it and the QMgr is rock solid and highly available.
- DNS results are ambiguous and a single IP address can resolve to multiple names. When that happens, which do you use? What is the behavior if more than one name matches more than one CHLAUTH rule?
- The hosts that the MQ community most want to use this feature for have dynamic IP addresses and register their DNS names when they connect with DHCP. The hosts the MQ community most want protection from also have dynamic IP addresses and register your DNS name when they connect.
So REVDNS will work as expected in most cases but it isn’t necessarily protecting you from anyone but honest users. Bad as that is, there’s worse news hidden in the ALTER QMGR entry for when REVDNS is set to ENABLED:
DNS host names are reverse looked-up for the IP addresses of inbound channels when this information is required. This setting is required for matching against CHLAUTH rules that contain host names, and to include the host name in error messages. The IP address is still included in messages that provide a connection identifier.
So let’s say you want to use a DNS name in a CHLAUTH record, on one channel, just for the administrators connecting over VPN. To do this you must enable REVDNS at the queue manager which means it now performs a reverse DNS lookup every time the queue manager needs to print a CONNAME in an error message. Presumably “error messages” refers to anything in AMQERR01.LOG but it could also mean event messages and FDDC files. Either way, “authenticating” that one administrative SVRCONN has just imposed an external network call on all inbound channel connection requests.
There was no CERTLABL question in the version of the test I took but you might get one. I can already anticipate a situation where there is no correct answer and you’ll have to choose among the least of 4 evils.
KC Cow patty: MFT Security
The KC section on MFT security is deliciously vague. Here it is verbatim:
WebSphere MQ Managed File Transfer Version 8.0 supports the security features of WebSphere MQ Version 8.0 with the default mode of disabled. If the associated queue manager has security enabled and requires credential details (user ID and password), you must enable this feature before you can successfully connect to a queue manager. For more information, see Working with WebSphere MQ security and Connection authentication.
MQ V8 has a lot of security features. Could you be a bit more specific, IBM? The context suggests this refers to CONNAUTH but when it says “If the associated queue manager has security enabled and requires credential details” it sounds like these are two different things. “Security disabled” can mean OAM is turned off, CHLAUTH is turned off, TLS is turned off, or most likely here, CONNAUTH is turned off. As an MQ admin, the ambiguity in this section turns me off.
I didn’t see this on the test but if you do you can probably assume it refers to CONNAUTH. Now I dare you to find the section describing how to enable AMS for MFT agent control messages. (There’s a great article on enabling AMS for agent data messages but of course if you can spoof command messages it’s kind of a useless exercise.)
Enough with the cow patties. You’ve been warned and if you step in one at this point, it’s your own fault. Tread lightly in the v8 Knowledge Center, it’s just a baby.
For purposes of comparison, I’m posting my scores. If you want to go head-to-head, limit yourself to half an hour to complete the test. I’m rather fond of telling the proctor to come get me in 30 minutes because I have frozen food in the car and need to get home. The tests come out so infrequently you can do this every time and not see the same proctor twice, and the look on their faces is priceless.
On the other hand, if you need more time, take it. Don’t squander the $200 on my account. If you really want to go head-to-head on MQ Admin topics, meet me in Sandusky any evening after the conference sessions end for the day.
|Overall||75% (43 out of 57)|
|Planning, Installation, and Migration||83% (5 out of 6)|
|Configuration||70% (7 out of 10)|
|Security||67% (4 out of 6)|
|Administration||67% (6 out of 9)|
|Availability||80% (4 out of 5)|
|Monitoring||75% (6 out of 8)|
|Performance Tuning||100% (5 out of 5)|
|Problem Determination||75% (6 out of 8)|
One last thought…however good the Pearson Vue folks may be at proctoring tests, mine STINKS as a portrait photographer. Good luck on the test!