>>>* 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
We have never used/turned-on SSL on any of our SP/TSM servers, so I have
very little experience with certs. That being said, the test server was
running 8.1.1 (upgraded from 7.1.7) and there was a cert256.arm file. When
we couldn't get dsmadmc to run after upgrading, I stumbled upon the dsmcert
command and after running "*dsmcert -add -server TSMTEST -file
/home/tsminst1/cert.arm*" on the server, dsmadmc now works.
>>>I read this as, "If you have SSLTCPPORT and TCPPORT as different
numbers, TCPPORT will allow non-SSL TCP/IP connections".
For SSLTCPPORT, the docs also say "*Valid values are 1024 - 32767. There
is **no default.*" - So, it is automatically making TCPPORT (1500) and
TCPADMINPORT (1500) SSL required/forced?
On Sat, Oct 7, 2017 at 5:39 PM, Andrew Raibeck <storman AT us.ibm DOT 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 | storman AT us.ibm DOT 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 AT VM.MARIST DOT EDU> wrote on 2017-10-06
> 15:30:56:
>
> > From: Zoltan Forray <zforray AT VCU DOT EDU>
> > To: ADSM-L AT VM.MARIST DOT 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 AT VM.MARIST DOT 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
> <skylar2 AT u.washington DOT 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
> rogerd AT uic DOT edu
> > > > ======I have not lost my mind -- it is backed up on tape
> somewhere.=====
> > >
> > > --
> > > -- Skylar Thompson (skylar2 AT u.washington DOT 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
> > 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 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
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/
|
