Also, since SSLACCEPTCERTFROMSERV is on by default for 8.1.2 clients (*Specifies that the backup-archive client does automatically accept the IBM Spectrum Protect server's public certificate. Yes is the default.)* I thought it should just work without any intervention from me.
On Sat, Oct 7, 2017 at 5:39 PM, Andrew Raibeck <stor...@us.ibm.com> wrote: > Hi Zoltan, > > I know you referenced > http://www.ibm.com/support/docview.wss?uid=swg22004844 earlier, but have > you gone back and revisited it? A couple of possible questions covered in > that document: > > * If you have an existing cert.kdb database and cert.arm file that were > created before V7.1.8 or V8.1, then V7.1.8, V8.1.2, and V8.1.3 clients and > the Operations Center are unable to connect to a V7.1.8, V8.1.2, V8.1.3 > server > > * Restrictions apply when you specify the SSL-only server ports (SSLTCPPORT > and SSLTCPADMINPORT) > > (Sergio also covered the latter item in his recent post..) > > Best regards, > > Andy > > ____________________________________________________________ > ________________ > > Andrew Raibeck | IBM Spectrum Protect Level 3 | stor...@us.ibm.com > > IBM Tivoli Storage Manager links: > Product support: > https://www.ibm.com/support/entry/portal/product/tivoli/ > tivoli_storage_manager > > Online documentation: > http://www.ibm.com/support/knowledgecenter/SSGSG7/ > landing/welcome_ssgsg7.html > > Product Wiki: > https://www.ibm.com/developerworks/community/wikis/home/wiki/Tivoli% > 20Storage%20Manager > > "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> wrote on 2017-10-06 > 15:30:56: > > > From: Zoltan Forray <zfor...@vcu.edu> > > To: ADSM-L@VM.MARIST.EDU > > Date: 2017-10-06 15:32 > > Subject: Re: 7.1.8/8.1.3 Security Upgrade Install Issues > > Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> > > > > Well, my testing of upgrading to 8.1.2/3 is not going well. Sure glad I > am > > doing this on a test server, since it doesn't bode well for a production > > system. This is what we did in our testing. > > > > 1. Server was upgraded from 8.1.1 to 8.1.3 > > 2. Created a new node. Installed 7.1.6 client on a W10E workstation. > > Connected to the 8.1.3 server with no issues. Performed backups, etc. > > Even tried the webGUI/client with no issues. > > 3. Upgraded workstation client to 8.1.2 and now we can't connect to the > > server. Keeps giving us an SSL error. Checked all configuration for the > > node and opt file. Everything was set to SESSIONSECURITY Transitional. > > Now all we get (using the default client) is: 10/06/2017 15:09:25 > ANS1592E > > Failed to initialize SSL protocol. > > > > I thought you were supposed to be able to upgrade the server to 8.1.2+ > and > > then all of the clients would automagically get the cert/key from the > > server once they upgraded to 8.1.2+ > > > > What am I missing? > > > > On Fri, Oct 6, 2017 at 10:00 AM, Skylar Thompson > <skyl...@u.washington.edu> > > wrote: > > > > > Content preview: We recently went from 7.1.7.300 to 7.1.8 in a > 3-server > > > environment > > > (one library manager, two library clients). As always, do the > library > > > manager > > > before any of the clients. We had some communication problems with > one > > > of > > > the library clients that we ended up solving like so: [...] > > > > > > Content analysis details: (0.7 points, 5.0 required) > > > > > > pts rule name description > > > ---- ---------------------- ------------------------------ > > > -------------------- > > > 0.7 SPF_NEUTRAL SPF: sender does not match SPF record > > > (neutral) > > > -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover > relay > > > domain > > > X-Barracuda-Connect: mx.gs.washington.edu[128.208.8.134] > > > X-Barracuda-Start-Time: 1507298431 > > > X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 > > > X-Barracuda-URL: https://urldefense.proofpoint.com/v2/url? > > u=https-3A__148.100.49. > > 27-3A443_cgi-2Dmod_mark.cgi&d=DwIBaQ&c=jf_iaSHvJObTbx- > > > siA1ZOg&r=Ij6DLy1l7wDpCbTfcDkLC_KknvhyGdCy_RnAGnhV37I&m=vl-75QIYV_ > QPCqd2PTVfJN6vvkPdw3imy5SDMv7Vif0&s=8KOXc3Ke8u4JzOpQnZinbSxSMaUTAk8- > > > zn1JzyjwTyQ&e= > > > X-Barracuda-Scan-Msg-Size: 4257 > > > X-Virus-Scanned: by bsmtpd at marist.edu > > > X-Barracuda-BRTS-Status: 1 > > > X-Barracuda-Spam-Score: 0.00 > > > X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of > > > TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.5 tests= > > > X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.43662 > > > Rule breakdown below > > > pts rule name description > > > ---- ---------------------- ------------------------------ > > > -------------------- > > > > > > We recently went from 7.1.7.300 to 7.1.8 in a 3-server environment (one > > > library manager, two library clients). As always, do the library > manager > > > before any of the clients. We had some communication problems with one > of > > > the library clients that we ended up solving like so: > > > > > > 1. Make sure SSL certificates are distributed: > > > https://www.ibm.com/support/knowledgecenter/SSGSG7_7.1.8/ > > > srv.admin/t_ssl_srvcfg_s2s.html > > > 2. Delete and redefine server definitions on both the client and > manager > > > using CROSSDEFINE > > > > > > The other library client was fine. I agree with Zoltan that the bigger > > > problem is actually admin account access; make sure that the systems > you > > > make admin connections from already have the 7.1.8/8.1.3 client > installed. > > > > > > On Thu, Oct 05, 2017 at 09:07:19PM -0500, Roger Deschner 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 > rog...@uic.edu > > > > ======I have not lost my mind -- it is backed up on tape > somewhere.===== > > > > > > -- > > > -- Skylar Thompson (skyl...@u.washington.edu) > > > -- Genome Sciences Department, System Administrator > > > -- Foege Building S046, (206)-685-7354 > > > -- University of Washington School of Medicine > > > > > > > > > > > -- > > *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 > > zfor...@vcu.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 https://urldefense.proofpoint.com/v2/url? > > u=http-3A__phishing.vcu.edu_&d=DwIBaQ&c=jf_iaSHvJObTbx- > > > siA1ZOg&r=Ij6DLy1l7wDpCbTfcDkLC_KknvhyGdCy_RnAGnhV37I&m=vl-75QIYV_ > QPCqd2PTVfJN6vvkPdw3imy5SDMv7Vif0&s=UHFHVxi_HK- > > > bDGfzASgP7lNeKd4IAmkmqWxE8NF1ZHM&e= > > > -- *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 zfor...@vcu.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/