I wanted to update this email thread with some of the gotchas that we have
or are experiencing due to our upgrade from 7.1.7 to 8.1.3:
- Watch out when using configuration management or a library manager. I
don't have it documented very carefully, but if you're in a configuration
management environment or a shared scsi library environment, be very
careful on how you plan the upgrade. Firstly, if you don't do SSL between
TSM servers prior to the upgrade, don't turn it on in the middle of the
upgrade process. We have 4 servers in a config management/library manager
configuration. We had the bright idea to just turn on SSL before all
servers were upgraded and we subsequently broke communication somewhere.
Config management died, library manager died and now we have to remediate
all that configuration again. The best thing to do.... do all servers
exactly the same way with as few changes as necessary. Turn on SSL
wherever desired in a later plan.
- The biggest headache so far has been the interoperability with the
Operations Center. The Operations Center was upgraded to 8.1.2 and we
expected the SSL handshake to go without a hitch. Incorrect: our 3rd party
CA certs don't appear to be compatible with the OC configuration files and
we have a ticket open up with IBM to figure out what the issue is.
Documentation on how to use 3rd party CA certs between the User Browser ->
OC -> Hub Server -> Spokes is very spotty and not well documented at all.
This is a very big gap in my opinion on true adoption for the Operations
Center. Our Operation Centers are down until we can figure out what's
wrong with the 3rd party certs. There is only true documentation of
OC->Hub, but what we really need is User Browser -> OC so we get that green
lovey-dovey secure feeling when we show our bosses. I had this working in
previous versions of the O.C.
- Client transitions to SSL indeed won't occur until later. However, we
made it a plan to test any client versions that were out of IBM support.
Those tests went fine and so far we have minimal core functionality
issues. Some clients are locking themselves out and our TSM admins keep
locking themselves out depending on where they log into the admin client
from, so that's a little headache.
- Licensing files need to be updated with the 8.1.0.x packages.
Thanks!
Sergio
On Tue, Oct 10, 2017 at 1:22 PM, Zoltan Forray <zforray AT vcu DOT edu> wrote:
> That is probably due to:
>
> SSLACCEPTCERTFROMSERV - The default value Yes enables the client to
> automatically accept a self-signed public certificate from the server, and
> to automatically configure the client to use that certificate when the
> client connects to a V8.1.2 or later server.
>
>
> On Tue, Oct 10, 2017 at 11:58 AM, Sergio O. Fuentes <sfuentes AT umd DOT edu>
> wrote:
>
> > My digicert signed certs are loaded into the server cert.kdb using the
> > gsk8apicmd functions. That's working. My question was getting those
> > non-existent root and intermediate CA certs loaded into the client.
> > Normally, in order to get SSL working, you need the whole signing chain
> on
> > the client (not the private TSM server signed cert). In prior versions
> to
> > 8.1.2 you had to manually add any commercial root certs that were not
> > included in the original dsmcert.kdb.
> >
> > I just did a quick test on a new client, and it looks like the whole
> public
> > cert chain is negotiated correctly with a CA signed certificate.
> >
> > Initial environment was with the admin client (dsmadmc) and admin
> > sessionsecurity=transitional. Both server and client are on the same
> > machine 8.1.3 server and 8.1.2 client. I'm not sure if that factored
> into
> > the negotiation.
> >
> > So far, I think we're in good shape to have this pushed out in the next
> two
> > weeks to production. We'll be upgrading the servers first and the ops
> > center shortly thereafter. Then we'll be recommending that all clients
> > start the upgrade process (providing SSL guidance where necessary).
> > Therefore, most of our admins and nodes will be in the transitional state
> > for quite some time.
> >
> > Thanks!
> > Sergio
> >
> >
> > On Tue, Oct 10, 2017 at 10:43 AM, Zoltan Forray <zforray AT vcu DOT edu>
> > wrote:
> >
> > > As I read it, "vendor-acquired certificates" need to be loaded/added to
> > the
> > > server using the gsk8capicmd function. This link, while it's for
> 7.1.1,
> > > talks about it:
> > >
> > > https://www.ibm.com/support/knowledgecenter/en/SSGSG7_7.1.
> > > 1/com.ibm.itsm.tshoot.doc/r_pdg_ssl_comm.html
> > >
> > > On Tue, Oct 10, 2017 at 10:00 AM, Sergio O. Fuentes <sfuentes AT umd DOT
> > > edu>
> > > wrote:
> > >
> > > > I have one other question for any IBMers or people who may have had
> > > > experience with this:
> > > >
> > > > If 8.1.2 clients can negotiate certificates with a 8.1.3 TSM server,
> > does
> > > > this mean that for users who use third-party signed certificates (not
> > > > loaded by default in the TSM client) that the certificate chain will
> > > > automatically be loaded to an 8.1.2 client? For example, we use
> > digicert
> > > > signed certs. Digicert is not one of the pre-loaded root certificates
> > in
> > > > the TSM client (Verisign and Thawte are). Can an 8.1.2 client
> > negotiate
> > > > the entire cert chain or will we be required to load the root and
> > > > intermediate digicert certs into the client?
> > > >
> > > > To ask more directly, how can I petition IBM to release a client with
> > > > pre-loaded DigiCert CA certificates?
> > > >
> > > > Thanks!
> > > > Sergio
> > > >
> > > > On Mon, Oct 9, 2017 at 12:14 PM, Skylar Thompson <
> > > skylar2 AT u.washington DOT edu
> > > > >
> > > > wrote:
> > > >
> > > > > Content preview: I definitely agree with this; at least for TSM
> v7
> > it
> > > > > would
> > > > > have been far better to call it v7.2.0 to make it clear that
> > it's a
> > > > > huge
> > > > > change with lots of caveats and potential failure points. We've
> > just
> > > > > now discovered
> > > > > that TSM v7.1.8 does not play nicely with GPFS/mmbackup due to
> a
> > > > > change in
> > > > > how SSL certificates are loaded - hopefully it's a simple fix
> but
> > > who
> > > > > knows...
> > > > > [...]
> > > > >
> > > > > 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: 1507565699
> > > > > X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384
> > > > > X-Barracuda-URL: https://148.100.49.27:443/cgi-mod/mark.cgi
> > > > > X-Barracuda-Scan-Msg-Size: 1182
> > > > > 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.43739
> > > > > Rule breakdown below
> > > > > pts rule name description
> > > > > ---- ---------------------- ------------------------------
> > > > > --------------------
> > > > >
> > > > > I definitely agree with this; at least for TSM v7 it would have
> been
> > > far
> > > > > better to call it v7.2.0 to make it clear that it's a huge change
> > with
> > > > lots
> > > > > of caveats and potential failure points. We've just now discovered
> > that
> > > > TSM
> > > > > v7.1.8 does not play nicely with GPFS/mmbackup due to a change in
> how
> > > SSL
> > > > > certificates are loaded - hopefully it's a simple fix but who
> > knows...
> > > > >
> > > > > On Sat, Oct 07, 2017 at 02:36:13PM -0500, Roger Deschner wrote:
> > > > > > This difficulty comes up while there are open, now-published
> > security
> > > > > > vulnerabilities out there inviting exploits, and making our
> > Security
> > > > > > people very nervous. But the considerations described in
> > > > > > http://www-01.ibm.com/support/docview.wss?uid=swg22004844 make
> it
> > > very
> > > > > > difficult and risky to proceed with 7.1.8/8.1.3 as though it was
> > > just a
> > > > > > patch. It's a major upgrade, requiring major research and
> planning,
> > > > with
> > > > > > the threat of an exploit constantly hanging over our heads. I
> > really
> > > > > > wish this had been handled differently.
> > > > >
> > > > > --
> > > > > -- 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 http://phishing.vcu.edu/
> > >
> >
>
>
>
> --
> *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/
>
|
