Re: 7.1.8/8.1.3 Security Upgrade Install Issues

[Sasa Drnjevic]

Thank you both :-)

Now I see what you meant.

I did that the other day when upgrading v7.1.7.0 to v8.1.0.0

And I did a test from v8.1.0.0 to v8.1.1.0 and even that small step
included new licenses, so I did "REGister LICense FILE=*.lic"

I was only doing it once per version jump before... when upgrading from
v5 to v6, and v6 to v7, but never had to do it for maintenance and patch
releases.

Tnx again.

--
Sasa Drnjevic
www.srce.unizg.hr




On 2017-11-17 21:49, Sergio O. Fuentes wrote:
> Zoltan is correct...  you have to install the license package from 8.1.0.0,
> I believe.  Otherwise you'll get nasty messages in the actlog.  Though I'm
> not sure if it actually breaks functionality.
>
> If there any IBMers browsing on a Friday afternoon, PMR 53017,082,000 is
> opened in reference to our issues with the 3rd party certificates and the
> operations center.
>
> Thank you!
> Sergio
>
> On Fri, Nov 17, 2017 at 2:36 PM, Zoltan Forray  wrote:
>
>> I would assume the server license as a minimum.  Every time we have jumped
>> a version, there is a new server licensing part/files and we have to do a
>> REGister LICense FILE=*.lic on the server after it is up-and-running.
>>
>> On Fri, Nov 17, 2017 at 2:11 PM, Sasa Drnjevic 
>> wrote:
>>
>>> First of all thank you so much for all the info!
>>>
>>> Can you please just clarify the following:
>>>
>>> "Licensing files need to be updated with the 8.1.0.x packages."
>>>
>>> Which/whose "Licensing files"? Client, server or OC? In which case
>>> (upgrade to 8.1.2.0 or 8.1.3.0?
>>>
>>>
>>> THNX!
>>>
>>> --
>>> Sasa Drnjevic
>>> www.srce.unizg.hr
>>>
>>>
>>>
>>>
>>> On 2017-11-17 19:55, Sergio O. Fuentes wrote:
 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 
>> 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 >>
> wrote:
>
>> My digicert signed certs are loaded into the server cert.kdb using
>> the
>> gsk8apicmd functions.  That's working.  My question was getting those

Re: 7.1.8/8.1.3 Security Upgrade Install Issues

[Sergio O. Fuentes]

Zoltan is correct...  you have to install the license package from 8.1.0.0,
I believe.  Otherwise you'll get nasty messages in the actlog.  Though I'm
not sure if it actually breaks functionality.

If there any IBMers browsing on a Friday afternoon, PMR 53017,082,000 is
opened in reference to our issues with the 3rd party certificates and the
operations center.

Thank you!
Sergio

On Fri, Nov 17, 2017 at 2:36 PM, Zoltan Forray  wrote:

> I would assume the server license as a minimum.  Every time we have jumped
> a version, there is a new server licensing part/files and we have to do a
> REGister LICense FILE=*.lic on the server after it is up-and-running.
>
> On Fri, Nov 17, 2017 at 2:11 PM, Sasa Drnjevic 
> wrote:
>
> > First of all thank you so much for all the info!
> >
> > Can you please just clarify the following:
> >
> > "Licensing files need to be updated with the 8.1.0.x packages."
> >
> > Which/whose "Licensing files"? Client, server or OC? In which case
> > (upgrade to 8.1.2.0 or 8.1.3.0?
> >
> >
> > THNX!
> >
> > --
> > Sasa Drnjevic
> > www.srce.unizg.hr
> >
> >
> >
> >
> > On 2017-11-17 19:55, Sergio O. Fuentes wrote:
> > > 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 
> 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  >
> > >> 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
> > >> 

Re: 7.1.8/8.1.3 Security Upgrade Install Issues

[Zoltan Forray]

I would assume the server license as a minimum.  Every time we have jumped
a version, there is a new server licensing part/files and we have to do a
REGister LICense FILE=*.lic on the server after it is up-and-running.

On Fri, Nov 17, 2017 at 2:11 PM, Sasa Drnjevic 
wrote:

> First of all thank you so much for all the info!
>
> Can you please just clarify the following:
>
> "Licensing files need to be updated with the 8.1.0.x packages."
>
> Which/whose "Licensing files"? Client, server or OC? In which case
> (upgrade to 8.1.2.0 or 8.1.3.0?
>
>
> THNX!
>
> --
> Sasa Drnjevic
> www.srce.unizg.hr
>
>
>
>
> On 2017-11-17 19:55, Sergio O. Fuentes wrote:
> > 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  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 
> >> 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 

Re: 7.1.8/8.1.3 Security Upgrade Install Issues

[Sasa Drnjevic]

First of all thank you so much for all the info!

Can you please just clarify the following:

"Licensing files need to be updated with the 8.1.0.x packages."

Which/whose "Licensing files"? Client, server or OC? In which case
(upgrade to 8.1.2.0 or 8.1.3.0?


THNX!

--
Sasa Drnjevic
www.srce.unizg.hr




On 2017-11-17 19:55, Sergio O. Fuentes wrote:
> 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  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 
>> 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  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

 

Re: 7.1.8/8.1.3 Security Upgrade Install Issues

[Sergio O. Fuentes]

One thing I forgot to mention...  if you use 3rd party CA certs anywhere,
you'll want to store the password hash prior to performing the upgrade:

TSM:> q sslkeyringpw
Copy the password to clipboard

In instance directory:
gsk8capicmd_64 -keydb -stashpw -db cert.kdb
Paste password when prompted.  cert.sth should now exist

Documentation doesn't tell you this, but the upgrade will lock you out of
the your .kdb file if you don't stash your password first.

If most of you use the self-signed certs, I'm not sure if this is much of a
concern.

SF


On Fri, Nov 17, 2017 at 1:55 PM, Sergio O. Fuentes  wrote:

> 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  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 
>> 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 
>> wrote:
>> >
>> > 

Re: 7.1.8/8.1.3 Security Upgrade Install Issues

[Sergio O. Fuentes]

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  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 
> 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  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 
> > > 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 

Re: 7.1.8/8.1.3 Security Upgrade Install Issues

[Zoltan Forray]

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 
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  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 
> > 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 <
> > skyl...@u.washington.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_NEUTRALSPF: sender does not match SPF record
> > > > (neutral)
> > > >  -0.0 RP_MATCHES_RCVDEnvelope 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 

Re: 7.1.8/8.1.3 Security Upgrade Install Issues

[Sergio O. Fuentes]

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  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 
> 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 <
> skyl...@u.washington.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_NEUTRALSPF: sender does not match SPF record
> > > (neutral)
> > >  -0.0 RP_MATCHES_RCVDEnvelope 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
> > > > 

Re: 7.1.8/8.1.3 Security Upgrade Install Issues

[Loon, Eric van (ITOPT3) - KLM]

Hi guys!
I read all the discussions with interest and I'm getting more and more 
confused. I tend to shy away from installing the latest codes on my server and 
clients after seeing all the issues you can get from them.
Let's assume I don't care about the tighter security and I only care about a 
non-disruptive upgrade of both server and client code, does anybody know if 
this can be done? So can one upgrade and disable TLS or any other (for me non 
vital) new security feature?
Kind regards,
Eric van Loon

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286

Re: 7.1.8/8.1.3 Security Upgrade Install Issues

[Zoltan Forray]

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 
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  >
> 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_NEUTRALSPF: sender does not match SPF record
> > (neutral)
> >  -0.0 RP_MATCHES_RCVDEnvelope 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 (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 http://phishing.vcu.edu/

Re: 7.1.8/8.1.3 Security Upgrade Install Issues

[Sergio O. Fuentes]

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 
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_NEUTRALSPF: sender does not match SPF record
> (neutral)
>  -0.0 RP_MATCHES_RCVDEnvelope 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 (skyl...@u.washington.edu)
> -- Genome Sciences Department, System Administrator
> -- Foege Building S046, (206)-685-7354
> -- University of Washington School of Medicine
>

Re: 7.1.8/8.1.3 Security Upgrade Install Issues

[Skylar Thompson]

 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_NEUTRALSPF: sender does not match SPF record (neutral)
 -0.0 RP_MATCHES_RCVDEnvelope 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 (skyl...@u.washington.edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S046, (206)-685-7354
-- University of Washington School of Medicine

Re: 7.1.8/8.1.3 Security Upgrade Install Issues

[Zoltan Forray]

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_NEUTRALSPF: sender does not match SPF record
> > > (neutral)
> > >  -0.0 RP_MATCHES_RCVDEnvelope 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=DwIBaQ=jf_iaSHvJObTbx-
> >
> siA1ZOg=Ij6DLy1l7wDpCbTfcDkLC_KknvhyGdCy_RnAGnhV37I=vl-75QIYV_
> QPCqd2PTVfJN6vvkPdw3imy5SDMv7Vif0=8KOXc3Ke8u4JzOpQnZinbSxSMaUTAk8-
>
> > zn1JzyjwTyQ=
> > > 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

Re: 7.1.8/8.1.3 Security Upgrade Install Issues

[Zoltan Forray]

>>>* 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 <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_NEUTRALSPF: sender does not match SPF record
> > > (neutral)
> > >  -0.0 RP_MATCHES_RCVDEnvelope sender domain matches handover
> relay
> > > domain
> &g

Re: 7.1.8/8.1.3 Security Upgrade Install Issues

[Andrew Raibeck]

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_NEUTRALSPF: sender does not match SPF record
> > (neutral)
> >  -0.0 RP_MATCHES_RCVDEnvelope 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=DwIBaQ=jf_iaSHvJObTbx-
>
siA1ZOg=Ij6DLy1l7wDpCbTfcDkLC_KknvhyGdCy_RnAGnhV37I=vl-75QIYV_QPCqd2PTVfJN6vvkPdw3imy5SDMv7Vif0=8KOXc3Ke8u4JzOpQnZinbSxSMaUTAk8-

> zn1JzyjwTyQ=
> > 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
> >

Re: 7.1.8/8.1.3 Security Upgrade Install Issues

[Andrew Raibeck]

Hello,

> Now to find out where this SESSIONSECURITY parameters is located

See the reference information for REGISTER NODE and UPDATE NODE.

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
23:41:06:

> From: "Sergio O. Fuentes" <sfuen...@umd.edu>
> To: ADSM-L@VM.MARIST.EDU
> Date: 2017-10-06 23:43
> Subject: Re: 7.1.8/8.1.3 Security Upgrade Install Issues
> Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU>
>
> Hello all!
>
> I just discovered this thread today because I had been testing 8.1.1
server
> very recently.  I had some issues with that on Thursday and then Friday I
> went further down the rabbit hole.  Now I'm finding that major portions
of
> our environment will have to be upgraded very soon.
>
> I'm just starting testing all sorts of client versions against the new
> 8.1.3 instance I have, however, I found this tidbit on "q opt tcpport":
>
> If you specify the same port number for both the SSLTCPPORT and TCPPORT
> >
> > options, only SSL connections are accepted and TCP/IP connections are
> >
> > disabled for the port.
> >
> >
> I read this as, "If you have SSLTCPPORT and TCPPORT as different numbers,
> TCPPORT will allow non-SSL TCP/IP connections".
>
> We actually do this.  Does that mean our "old" clients will still be able
> to use TCPPORT without any issues?
>
> Now to find out where this SESSIONSECURITY parameters is located
>
> Thanks!
>
> SF
>
>
> On Fri, Oct 6, 2017 at 3:30 PM, Zoltan Forray <zfor...@vcu.edu> wrote:
>
> > 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_NEUTRALSPF: sender does not match SPF record
> > > (neutral)
> > >  -0.0 RP_MATCHES_RCVDEnvelope 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=DwIBaQ=jf_iaSHvJObTbx-
> siA1ZOg=Ij6DLy1l7wDpCbTfcDkLC_KknvhyGdCy_RnAGnhV37I=ukO93-
> pLAC20rrzdR5oGl4Y3ggbt-C7QpoJC1J-g9P4=-mQcZbd_mU9Jo8Idj2qGVO-
> ef8PzRzsuE7nXhIYyqOQ=
> > > X-Barracuda-Scan-Msg-Size: 4257
> > > X-

Re: 7.1.8/8.1.3 Security Upgrade Install Issues

[Roger Deschner]

Thanks to all for this discussion of this 7.1.8/8.1.3 issue. I've heard
enough to postpone our production upgrade to 7.1.8, scheduled for
tomorrow. We've got to set up a test server and fiddle around with it
and see what it breaks in our environment.

I'm considering a strategy of upgrading all servers first, while keeping
all clients on "Old" versions. Then when we've got the Admin ID and
certificate issues ironed out between the servers, start upgrading
clients, carefully. It will be a minefield. I'm going to save copies of
"Old" dsmadmc in a very safe place.

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.

Roger Deschner  University of Illinois at Chicago rog...@uic.edu
==I have not lost my mind -- it is backed up on tape somewhere.=


On Fri, 6 Oct 2017, Sergio O. Fuentes wrote:

>Hello all!
>
>I just discovered this thread today because I had been testing 8.1.1 server
>very recently.  I had some issues with that on Thursday and then Friday I
>went further down the rabbit hole.  Now I'm finding that major portions of
>our environment will have to be upgraded very soon.
>
>I'm just starting testing all sorts of client versions against the new
>8.1.3 instance I have, however, I found this tidbit on "q opt tcpport":
>
>If you specify the same port number for both the SSLTCPPORT and TCPPORT
>>
>> options, only SSL connections are accepted and TCP/IP connections are
>>
>> disabled for the port.
>>
>>
>I read this as, "If you have SSLTCPPORT and TCPPORT as different numbers,
>TCPPORT will allow non-SSL TCP/IP connections".
>
>We actually do this.  Does that mean our "old" clients will still be able
>to use TCPPORT without any issues?
>
>Now to find out where this SESSIONSECURITY parameters is located
>
>Thanks!
>
>SF
>
>
>On Fri, Oct 6, 2017 at 3:30 PM, Zoltan Forray  wrote:
>
>> 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 > >
>> 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_NEUTRALSPF: sender does not match SPF record
>> > (neutral)
>> >  -0.0 RP_MATCHES_RCVDEnvelope 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://148.100.49.27:443/cgi-mod/mark.cgi
>> > 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 

Re: 7.1.8/8.1.3 Security Upgrade Install Issues

[Sergio O. Fuentes]

Hello all!

I just discovered this thread today because I had been testing 8.1.1 server
very recently.  I had some issues with that on Thursday and then Friday I
went further down the rabbit hole.  Now I'm finding that major portions of
our environment will have to be upgraded very soon.

I'm just starting testing all sorts of client versions against the new
8.1.3 instance I have, however, I found this tidbit on "q opt tcpport":

If you specify the same port number for both the SSLTCPPORT and TCPPORT
>
> options, only SSL connections are accepted and TCP/IP connections are
>
> disabled for the port.
>
>
I read this as, "If you have SSLTCPPORT and TCPPORT as different numbers,
TCPPORT will allow non-SSL TCP/IP connections".

We actually do this.  Does that mean our "old" clients will still be able
to use TCPPORT without any issues?

Now to find out where this SESSIONSECURITY parameters is located

Thanks!

SF


On Fri, Oct 6, 2017 at 3:30 PM, Zoltan Forray  wrote:

> 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  >
> 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_NEUTRALSPF: sender does not match SPF record
> > (neutral)
> >  -0.0 RP_MATCHES_RCVDEnvelope 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://148.100.49.27:443/cgi-mod/mark.cgi
> > 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.)
> > >

Re: 7.1.8/8.1.3 Security Upgrade Install Issues

[Zoltan Forray]

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 
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_NEUTRALSPF: sender does not match SPF record
> (neutral)
>  -0.0 RP_MATCHES_RCVDEnvelope 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://148.100.49.27:443/cgi-mod/mark.cgi
> 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 

Re: 7.1.8/8.1.3 Security Upgrade Install Issues

[Skylar Thompson]

 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_NEUTRALSPF: sender does not match SPF record (neutral)
 -0.0 RP_MATCHES_RCVDEnvelope 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://148.100.49.27:443/cgi-mod/mark.cgi
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 

Re: 7.1.8/8.1.3 Security Upgrade Install Issues

[Zoltan Forray]

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  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.) 

Re: 7.1.8/8.1.3 Security Upgrade Install Issues

[Stefan Folkerts]

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  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.=
>

7.1.8/8.1.3 Security Upgrade Install Issues

[Roger Deschner]

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.=