Roger,

There has been a discussion about a few things you are asking questions
about just a day or so ago, I gave my view on the client and admin
situation.
I will use the same old and new definitions as you did.

It basically boils down to this for client and admin sessions

Once a node uses the "new" software that node goes from transitional to
strict on that server, the node cannot be logged in with the old software
from lets say a different server.
Once an administrator uses the "new" software that admin goes from
transitional strict on that server, the admin cannot be logged in with the
old software from lets say a different server or an outdated tool such as
TSMmanager, you must contact the support organisation of Servergraph to ask
whether your version is capable of using the strict sessions, TSMmanager
has a new version out that is capable of this.
You can manually set these objects to strict to ensure encryption on parts
of the session (metadata and authentication) but you can't change them from
strict to transitional.

So the lockdown is on a per admin and per node basis and happens with the
first admin and/or client login from the new software.

There is no way around the way the strict mode turns on, nodes logging in
using new clients go to strict and the same goes for admins.
Really have a look at the environment, especially where you dsmadmc from,
what tooling, scripting you use and from where and what clients share a
node in ISP that might run into issues.

At the same time I see customers that don't even read the readme, upgrade
themselves thinking it's just another patch and don't even notice anything
because of they way they run their shop.






On Fri, Oct 6, 2017 at 4:07 AM, 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.=====
>