HI Eric,
This is intentional. See my previous reply.
Del
----------------------------------------------------
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 01/04/2018
09:44:42 AM:
> From: "Loon, Eric van (ITOPT3) - KLM" <Eric-van.Loon AT KLM DOT COM>
> To: ADSM-L AT VM.MARIST DOT EDU
> Date: 01/04/2018 09:46 AM
> Subject: Re: Should I upgrade to 7.1.8.x ??? (on the client end only)
> Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>
> In fact a q server f=d shows Session Security: Transitional, but
> each time I log on to the server using the admin command line, my
> admin userid is getting updated from transitional to strict! Upd
> admin transitional works but as soon as I log on it's being switched
> back to Strict.
>
> Kind regards,
>
> Eric van Loon
>
> Air France/KLM Storage Engineering
>
>
>
>
>
> -----Original Message-----
>
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On
> Behalf Of Zoltan Forray
>
> Sent: donderdag 4 januari 2018 15:03
>
> To: ADSM-L AT VM.MARIST DOT EDU
>
> Subject: Re: Should I upgrade to 7.1.8.x ??? (on the client end only)
>
>
>
> >>>admin to sessionsecurity=transitional (strange, this should be the
>
> default...) and now I could start a session successful.
>
>
>
> I concur. I remember having this same problem when I upgraded my
> test server to 8.1.3 eventhough the docs say "transitional" is the
default.
>
>
>
> On Thu, Jan 4, 2018 at 8:42 AM, Loon, Eric van (ITOPT3) - KLM <
> Eric-van.Loon AT klm DOT com> wrote:
>
>
>
> > Hi Del,
>
> > Well, not really... I'm currently installing a 7.1.8 server and
>
> > noticed that I could no longer use a 7.1.7 admin commandline:
>
> >
>
> > ANR0404W Session 22 for administrator ADMIN (Linux x86-64) refused -
>
> > client is down-level with this server version.
>
> >
>
> > So I upgraded it to 7.1.8, but it was still not working:
>
> >
>
> > On the client side: ANS1592E Failed to initialize SSL protocol.
>
> > On the server side: ANR3335W Unable to distribute certificate to
>
> > KLM35757 for session 24.
>
> >
>
> > So I updated my admin to sessionsecurity=transitional (strange, this
>
> > should be the default...) and now I could start a session successful.
>
> > I tried the same admin account on another TSM client and again On the
>
> > client
>
> > side: ANS1592E Failed to initialize SSL protocol. A q admin f=d showed
>
> > that sessionsecurity was again set to strict! I'm lost...
>
> > Kind regards,
>
> > Eric van Loon
>
> > Air France/KLM Storage Engineering
>
> >
>
> >
>
> > -----Original Message-----
>
> > From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On
> > Behalf
>
> > Of Del Hoobler
>
> > Sent: donderdag 4 januari 2018 13:45
>
> > To: ADSM-L AT VM.MARIST DOT EDU
>
> > Subject: Re: Should I upgrade to 7.1.8.x ??? (on the client end only)
>
> >
>
> > Here are a few links that might help:
>
> >
>
> > https://www.ibm.com/support/knowledgecenter/en/SSEQVQ_8.1.
>
> > 2/srv.install/r_srv_knowsec-aix.html
>
> >
>
> > http://www-01.ibm.com/support/docview.wss?uid=swg22004844
>
> >
>
> >
>
> >
>
> > Del
>
> >
>
> > ----------------------------------------------------
>
> >
>
> >
>
> > "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 01/04/2018
>
> > 03:37:53 AM:
>
> >
>
> > > From: "Loon, Eric van (ITOPT3) - KLM" <Eric-van.Loon AT KLM DOT COM>
>
> > > To: ADSM-L AT VM.MARIST DOT EDU
>
> > > Date: 01/04/2018 03:40 AM
>
> > > Subject: Re: Should I upgrade to 7.1.8.x ??? (on the client end
>
> > > only) Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>
> > >
>
> > > I too read all the previous posts, but I still don't know what to
do.
>
> > > Your mail also indicates that your upgrade planning is based on
>
> > > several assumptions and I think it is really time for IBM to jump in
>
> > > here. I think someone from development should explain a little bit
>
> > > about the new security design and tell us how we should upgrade
>
> > > without impact. Which components in which order to which recommended
>
> > level.
>
> > > Kind regards,
>
> > > Eric van Loon
>
> > > Air France/KLM Storage Engineering
>
> > >
>
> > > -----Original Message-----
>
> > > From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On
>
> > > Behalf Of Deschner, Roger Douglas
>
> > > Sent: donderdag 4 januari 2018 0:14
>
> > > To: ADSM-L AT VM.MARIST DOT EDU
>
> > > Subject: Re: Should I upgrade to 7.1.8.x ??? (on the client end
>
> > > only)
>
> > >
>
> > > Test! Test! Test! Search this forum for previous posts about this.
>
> > > There are a bunch of gotchas. Perhaps one of the most severe is what
>
> > > happens to administrator IDS. Create some dummy admin IDS to use in
>
> > > testing, because you can permanently disable your own admin ID if
>
> > > you're not careful. We also know there will be library sharing
gotchas.
>
> > >
>
> > > We're actually going to do the backup servers first - after thorough
>
> > > testing. We think we can minimize the risk to things like admin IDS
>
> > > if we upgrade the servers with NO clients yet on 7.1.8. I think that
>
> > > having 7.1.8 clients around will greatly complicate the process of
>
> > > upgrading the servers, especially if any of those 7.1.8 clients are
>
> > > the desktop workstations used by you and your coworkers. It's
>
> > > possible that when you do eventually upgrade your servers to 7.1.8,
>
> > > you'll have to backtrack to each client and manually install new SSL
>
> > > keys, on all client systems, all at once. I hope that cat-herding
>
> > > nightmare can be avoided by upgrading servers first, which will then
>
> > > manage key distribution among clients more gracefully, as they
>
> > > upgrade to 7.1.8 one at a time. If I'm wrong about any of this,
> please chime in.
>
> > >
>
> > > This thing has a big effect. Careful testing is necessary.
>
> > >
>
> > > Roger Deschner
>
> > > University of Illinois at Chicago
>
> > > "I have not lost my mind - it is backed up on tape somewhere."
>
> > > ________________________________________
>
> > > From: Skylar Thompson <skylar2 AT U.WASHINGTON DOT EDU>
>
> > > Sent: Tuesday, January 2, 2018 16:19
>
> > > Subject: Re: Should I upgrade to 7.1.8.x ??? (on the client end
>
> > > only)
>
> > >
>
> > > Content preview: I believe the incompatibility arises if you set
>
> > > SESSIONSECURITY
>
> > > to STRICT for your nodes. The default is TRANSITIONAL so you
>
> > > should be fine;
>
> > > IIRC the only communication problems we had when upgrading our
>
> > servers to
>
> > > v7.1.8 was with library sharing. [...]
>
> > >
>
> > > Content analysis details: (0.6 points, 5.0 required)
>
> > >
>
> > > pts rule name description
>
> > > ---- ----------------------
>
> > > --------------------------------------------------
>
> > > 0.7 SPF_NEUTRAL SPF: sender does not match SPF record
>
> > (neutral)
>
> > > -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover
>
> > relay
>
> > > domain
>
> > > X-Barracuda-Connect: mx.gs.washington.edu[128.208.8.134]
>
> > > X-Barracuda-Start-Time: 1514931575
>
> > > X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384
>
> > > X-Barracuda-URL: https://urldefense.proofpoint.com/v2/url?
>
> > > u=https-3A__148.100.49.
>
> > > 28-3A443_cgi-2Dmod_mark.cgi&d=DwIFAg&c=jf_iaSHvJObTbx-
>
> > >
>
> > siA1ZOg&r=0hq2JX5c3TEZNriHEs7Zf7HrkY2fNtONOrEOM8Txvk8&m=
>
> > 529NKbiDtCmhOp63H3nZmM0Pnv-
>
> > > V1fHyDWeSXJ-s-1I&s=wL7qg-bC6229Rs0MHKXxo50WnAcsl_tyXg8N0DW_oQA&e=
>
> > > X-Virus-Scanned: by bsmtpd at marist.edu
>
> > > X-Barracuda-Scan-Msg-Size: 3241
>
> > > 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.46484
>
> > > Rule breakdown below
>
> > > pts rule name description
>
> > > ---- ----------------------
>
> > > --------------------------------------------------
>
> > >
>
> > > I believe the incompatibility arises if you set SESSIONSECURITY to
>
> > > STRICT for your nodes. The default is TRANSITIONAL so you should be
>
> > > fine; IIRC the only communication problems we had when upgrading our
>
> > > servers to v7.1.8 was with library sharing.
>
> > >
>
> > > That said, v7.1.8 was a huge change so I would test it if possible
>
> > first.
>
> > >
>
> > > On Tue, Jan 02, 2018 at 05:12:44PM -0500, Tom Alverson wrote:
>
> > > > Thanks for that link, I am more worried about any "gotcha's"
>
> > > > caused by
>
> >
>
> > > > upgrading the client to 7.1.8 or 8.1.2 before the storage servers
get
>
> > > > upgraded (and start using the new authentication). What I had
not
>
> > > > realized until I saw the chart is that the new clients are NOT
>
> > > > backward compatible with old storage servers (which doesn't really
>
> > > > affect me since we have those all at 7.1.7.2 now).
>
> > > >
>
> > > >
>
> > > > *IBM SPECTRUM PROTECT CLIENT SUPPORT*
>
> > > >
>
> > > > includes the Backup-Archive, API, UNIX HSM, and Web clients that
>
> > > > are compatible with, and currently supported with, IBM Spectrum
>
> > > > Protect Servers and Storage Agents.
>
> > > > *IBM Spectrum Protect*
>
> > > > *Client Version*
>
> > > > *Supported IBM Spectrum Protect*
>
> > > > *Server and Storage Agent Versions*
>
> > > > 8.1.2
>
> > > > 8.1, 7.1
>
> > > > 8.1.0
>
> > > > 8.1, 7.1, 6.3.x 1
>
> > > > 7.1.8
>
> > > > 8.1, 7.1
>
> > > > 7.1
>
> > > > 8.1, 7.1, 6.3.x 1
>
> > > > 6.4 1
>
> > > > 8.1, 7.1, 6.3.x 1
>
> > > > 6.3 1, 2
>
> > > > 8.1, 7.1, 6.3.x 1
>
> > > >
>
> > > >
>
> > > >
>
> > > >
>
> > > >
>
> > > >
>
> > > >
>
> > > >
>
> > > >
>
> > > >
>
> > > > On Tue, Jan 2, 2018 at 4:42 PM, Skylar Thompson
>
> > > > <skylar2 AT u.washington DOT edu>
>
> > > > wrote:
>
> > > >
>
> > > > > There's pretty wide version compatibility between clients and
>
> > > > > servers; we didn't go v7 server-side until pretty recently but
>
> > > > > have been running the v7 client for a while. IBM has a matrix
>
> > > > > published
>
> > here:
>
> > > > >
>
> > > > > http://www-01.ibm.com/support/docview.wss?uid=swg21053218
>
> > > > >
>
> > > > > For basic backups and restores I think you can deviate even
>
> > > > > more, but obviously you won't get support.
>
> > > > >
>
> > > > > On Tue, Jan 02, 2018 at 03:14:24PM -0500, Tom Alverson wrote:
>
> > > > > > Our TSM storage servers were all upgraded last year to 7.1.7.2
>
> > > > > > (before
>
> > > > > this
>
> > > > > > new security update came out). Now I am wondering if I
should
>
> > start
>
> > > > > using
>
> > > > > > the updated client or not? If the servers stay at 7.1.7.2
for
>
> > now is
>
> > > > > > there any harm in using the newer client? I would have to use
>
> > > > > > 7.1.8.0 on anything older than 2012. I saw some email traffic
>
> > > > > > earlier that once you use the new authentication mode on a
>
> > > > > > node you can't go back? But it
>
> > > > > seems
>
> > > > > > that would not be possible until our storage servers get
upgraded.
>
> > > > > >
>
> > > > > > Is there any downside in my case (where the storage servers
>
> > > > > > are still at
>
> > > > > > 7.1.7.2) of using the latest client versions in the interim??
>
> > > > > > Our
>
> > > > > current
>
> > > > > > standard client versions now are 7.1.6.4 for 2008 and older,
>
> > > > > > and
>
> > > > > > 8.1.0.0 (yes the horrible buggy one) on newer servers.
>
> > > > > >
>
> > > > > > Tom
>
> > > > >
>
> > > > > --
>
> > > > > -- Skylar Thompson (skylar2 AT u.washington DOT edu)
>
> > > > > -- Genome Sciences Department, System Administrator
>
> > > > > -- Foege Building S046, (206)-685-7354
>
> > > > > -- University of Washington School of Medicine
>
> > > > >
>
> > >
>
> > > --
>
> > > -- Skylar Thompson (skylar2 AT u.washington DOT edu)
>
> > > -- Genome Sciences Department, System Administrator
>
> > > -- Foege Building S046, (206)-685-7354
>
> > > -- University of Washington School of Medicine
>
> > > ********************************************************
>
> > > For information, services and offers, please visit our web site:
>
> > > https://urldefense.proofpoint.com/v2/url?
>
> > > u=http-3A__www.klm.com&d=DwIFAg&c=jf_iaSHvJObTbx-
>
> > >
>
> > siA1ZOg&r=0hq2JX5c3TEZNriHEs7Zf7HrkY2fNtONOrEOM8Txvk8&m=
>
> > 529NKbiDtCmhOp63H3nZmM0Pnv-
>
> > > V1fHyDWeSXJ-s-1I&s=XYtqCkcBf_H0a_PotsgLeuvoQb1r1IZarPTXr5rPT6s&e=.
>
> > > 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
>
> > > ********************************************************
>
> > >
>
> > ********************************************************
>
> > For information, services and offers, please visit our web site:
>
> > https://urldefense.proofpoint.com/v2/url?
> u=http-3A__www.klm.com&d=DwIGaQ&c=jf_iaSHvJObTbx-
>
siA1ZOg&r=0hq2JX5c3TEZNriHEs7Zf7HrkY2fNtONOrEOM8Txvk8&m=8XN09ZoIl16Qv_q1NGIiVtRTgXB00ElZ5HZbmdaZiKM&s=dC8dKPm_8e0OnHDhUDMhvXVt_7cGrc4MJjBP5j2kH8c&e=
> . 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
>
> > ********************************************************
>
> >
>
>
>
>
>
>
>
> --
>
> *Zoltan Forray*
>
> Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator
> Xymon Monitor Administrator VMware Administrator Virginia
> Commonwealth University UCC/Office of Technology Services
www.ucc.vcu.edu
> zforray AT vcu DOT edu - 804-828-4807 Don't be a phishing victim - VCU and
> other reputable organizations will never use email to request that
> you reply with your password, social security number or confidential
> personal information. For more details visit https://
> urldefense.proofpoint.com/v2/url?
> u=http-3A__phishing.vcu.edu_&d=DwIGaQ&c=jf_iaSHvJObTbx-
>
siA1ZOg&r=0hq2JX5c3TEZNriHEs7Zf7HrkY2fNtONOrEOM8Txvk8&m=8XN09ZoIl16Qv_q1NGIiVtRTgXB00ElZ5HZbmdaZiKM&s=7aBr99tHGlPgXLESFJlw0baocFrUV6ZhcvLwF27qsCY&e=
>
> ********************************************************
>
> For information, services and offers, please visit our web site:
> https://urldefense.proofpoint.com/v2/url?
> u=http-3A__www.klm.com&d=DwIGaQ&c=jf_iaSHvJObTbx-
>
siA1ZOg&r=0hq2JX5c3TEZNriHEs7Zf7HrkY2fNtONOrEOM8Txvk8&m=8XN09ZoIl16Qv_q1NGIiVtRTgXB00ElZ5HZbmdaZiKM&s=dC8dKPm_8e0OnHDhUDMhvXVt_7cGrc4MJjBP5j2kH8c&e=
> . 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
>
> ********************************************************
>
|
