HI Eric, This is intentional. See my previous reply.
Del ---------------------------------------------------- "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> wrote on 01/04/2018 09:44:42 AM: > From: "Loon, Eric van (ITOPT3) - KLM" <eric-van.l...@klm.com> > To: ADSM-L@VM.MARIST.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@VM.MARIST.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@VM.MARIST.EDU] On > Behalf Of Zoltan Forray > > Sent: donderdag 4 januari 2018 15:03 > > To: ADSM-L@VM.MARIST.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.l...@klm.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@VM.MARIST.EDU] On Behalf > > > Of Del Hoobler > > > Sent: donderdag 4 januari 2018 13:45 > > > To: ADSM-L@VM.MARIST.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@VM.MARIST.EDU> wrote on 01/04/2018 > > > 03:37:53 AM: > > > > > > > From: "Loon, Eric van (ITOPT3) - KLM" <eric-van.l...@klm.com> > > > > To: ADSM-L@VM.MARIST.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@VM.MARIST.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@VM.MARIST.EDU] On > > > > Behalf Of Deschner, Roger Douglas > > > > Sent: donderdag 4 januari 2018 0:14 > > > > To: ADSM-L@VM.MARIST.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 <skyl...@u.washington.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 > > > > > <skyl...@u.washington.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 (skyl...@u.washington.edu) > > > > > > -- Genome Sciences Department, System Administrator > > > > > > -- Foege Building S046, (206)-685-7354 > > > > > > -- University of Washington School of Medicine > > > > > > > > > > > > > > -- > > > > -- Skylar Thompson (skyl...@u.washington.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 > zfor...@vcu.edu - 804-828-4807 Don't be a phishing victim - VCU and > other reputable organizations will never use email to request that > you reply with your password, social security number or confidential > personal information. For more details visit https:// > urldefense.proofpoint.com/v2/url? > u=http-3A__phishing.vcu.edu_&d=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 > > ******************************************************** >
