I spent some quality time digging through 7.1.8/8.1.3 docs yesterday and
came to similar conclusions (my first thought was that 7.1.8 was just a
maintenance release for 7.1.7 - did not realize they back-ported the TLS
1.2 enforcement from 8.1.2+)
I am a beta tester for TSMManager and am working with them to test 8.1.3.
I upgraded my test server to 8.1.3 and immediately hit the first "bump"
when I tried to use a just-installed 8.1.2 client on the test server. I
found I had to run a utility to convert/install the server cert file, just
to be able to use dsmadmc. My first thought was how was I supposed to send
this cert file to every client that upgrades to the "new" clients? Then I
read about SSLACCEPTCERTFROMSERV which SHOULD address that problem.
Further digging through online docs, I found what was previously stated -
that once you connect to an 8.1.2+ server with an 8.1.2 client, you can't
go back - even an administrator id becomes locked. Fortunately, the
TSMManager collector server uses an older dsmadmc so it could talk to the
8.1.3 server with no issues and did not lock my admin client. That would
have been a mess.
I face the same dilemma - especially with a big PCI project looming that
requires a standalone SP server, which is probably going to force going to
the latest SP. If the PCI SP server has to be a "new" version, then I have
the issue of being able to replicate to my offsite, downlevel replica
target server, which IIRC, is not a compatible scenario.
Rinse-Lather-Repeat....
Then I have the issue of the numerous downlevel, unsupported clients - some
that can't upgrade (SOLARIS SPARC 8, RHEL5-x32, Windows 2003, AS400, vendor
support appliances, etc). Have to make sure they work with the "new" SP
servers.
I have 2-Library Manager servers and 5-other SP servers I am going to have
to deal with upgrading and it might end up being a "do it all on a weekend".
So right now we are doing plenty of testing with the 8.1.3 test server and
various different client levels, to see what battles we are going to have
to fight...
On Thu, Oct 5, 2017 at 10:07 PM, Roger Deschner <rogerd AT uic DOT edu> wrote:
> Versions 7.1.8 and 8.1.3 of WDSF/ADSM/TSM/SP have now been made
> available containing substantial security upgrades. A bunch of security
> advisories were sent this week containing details of the vulnerabilities
> patched. Some are serious; our security folks are pushing to get patches
> applied.
>
> For the sake of discussion, I will simply call versions 7.1.7 and before
> and 8.1.1 "Old", and I'll call 7.1.8 and 8.1.3 "New". (Not really sure
> where 8.1.2 falls, because some of the security issues are only fixed in
> 8.1.3.)
>
> There are some totally unclear details outlined in
> http://www-01.ibm.com/support/docview.wss?uid=swg22004844. What's most
> unclear is how to upgrade a complex, multi-server, library-manager
> configuration. It appears from this document, that you must jump all in
> at once, and upgrade all servers and clients from Old to New at the same
> time. That is simply impractical. There is extensive discussion of the
> new SESSIONSECURITY parameter, but no discussion of what happens when
> connecting to an Old client or server that does not even have the
> SESSIONSECURITY parameter.
>
> We have 4 TSM servers. One is a library manager. Two of them are clients
> of the manager. The 4th server manages its tapes by itself, though it
> still communicates with all the other servers. That 4th server, the
> independent one, is what I'm going to upgrade first, because it is the
> easiest. All our clients are Old.
>
> The question is, what's going to happen next? Will this one New server
> still be able communicate with the other Old servers?
>
> Once my administrator id connects to a New server, this document says
> that my admin id can no longer connect to Old servers. (SESSIONSECURITY
> is automatically changed to STRICT.) Or does that restriction only apply
> if I connect from a New client? This could be an issue since I regularly
> connect to all servers in a normal day's work. We also have automated
> scripts driven by cron that fetch information from each of the servers.
> The bypass of creating another administrator ID is also not practical,
> because that would involve tracking down and changing all of these
> cron-driven scripts. So, the question here is, at the intermediate phase
> where some servers are Old and some New, can I circumvent this Old/New
> administrator ID issue by only connecting using dsmadmc on Old clients?
>
> This has also got to have an impact on users of software like
> Servergraph.
>
> There's also the issue of having to manually configure certificates
> between our library managers and library clients, but at least the steps
> to do that are listed in that document. (Comments? Circumventions?)
>
> We're plunging ahead regardless, because of a general policy to apply
> patches quickly for all published security issues. (Like Equifax didn't
> do for Apache.) I'm trying to figure this out fast, because we're doing
> it this coming weekend. I'm sure there are parts of this I don't
> understand. I'm trying to figure out how ugly it's going to be.
>
> Roger Deschner University of Illinois at Chicago rogerd AT uic DOT
> edu
> ======I have not lost my mind -- it is backed up on tape somewhere.=====
>
--
*Zoltan Forray*
Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator
Xymon Monitor Administrator
VMware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
www.ucc.vcu.edu
zforray AT vcu DOT edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations will
never use email to request that you reply with your password, social
security number or confidential personal information. For more details
visit http://phishing.vcu.edu/
|
