Comments on: Remote Location Not Secure

By: alamrashid

alamrashid — Fri, 10 Feb 2012 01:08:51 +0000

Hi….is remote location probelm being resolve? I’m having similar problem where getting same message “Password Require”. Would you please let me know what change did you make in order to by-pass log-in screen?

Thanks and appreciated

By: ucoldasice

ucoldasice — Thu, 26 Aug 2010 14:04:13 +0000

Thank you all for your help! I will have to try the change over the weekend when our devices are not in use.

By: tomliotta

tomliotta — Thu, 26 Aug 2010 06:59:33 +0000

But still need resolution on the issue.

Find the APPC *DEVD for remote location (SYSNAME). The attribute would be SECURELOC(*NO). It would need to be SECURELOC(*YES).

This could only be recommended if access is only allowed through direct-attached terminals and passthru from the other AS/400(s). If PCs may connect or if SNA-over-IP is allowed, then you are potentially removing any security from that system. If you have system responsibility, your career might be at stake.

Make certain that passthru is secured from any source system.

Better would be to change the CL to require a password as long as STRPASTHR is going to be used.

Tom

By: ucoldasice

ucoldasice — Wed, 25 Aug 2010 18:12:27 +0000

call swkpasthr 200 - STRPASTHR RMTLOCNAME(SYSNAME) MODE(WMSMODE) RMTUSER(*CURRENT) PASTHRSCN(*NO) Password required. CPD8905 received by SWKPASTHR at 200. (C D I R) D Function check. CPD8905 unmonitored by SWKPASTHR at statement 200, instruction X'000C'. It only gives me the CPF9999 error message id which does not tell me anything... It is only a generic escape message... The CPD8905 error is the one that says that the remote location is not secured when using *CURRENT as rmtusrid...

By: lovemyi

lovemyi — Wed, 25 Aug 2010 17:43:26 +0000

Did you look at the CPF message that this error showed up under? It usually shows the error and a resolution for the error is there is one. Try it again andf put the cursor on the error and hit the F1 key to bring up the error number and if there is no details then hit F10 to look at your joblog and then F10 and page up to see if there was any other error messages before that one that might give you a clue. Also check your network attributes on both machine to see if they are configured the same was using DSPNETA.

Hope this helps

Lovemyi

By: ucoldasice

ucoldasice — Wed, 25 Aug 2010 14:16:55 +0000

Thanks Tom, But still need resolution on the issue. I can’t find where the system is finding that it is not a secure location. I have narrowed it down now to my source system as being the problem because I can pass through the same way to my target on one of our other as400′s. Is it in the host table, the appc ctl, the appc device, I don’t know! I am beyond stumped!!! And I know it will be something really simple once resolved….

By: tomliotta

tomliotta — Wed, 25 Aug 2010 00:35:30 +0000

Under most current circumstances, those connections should not be configured as “secure”. A “secure” connection for those types of connections means that password verification is not needed. The definition of “secure” in this context is essentially “you don’t need verification on this system for the simple reason that you successfully signed on to the system at the other end of this connection”.

However, in most ‘modern’ networks, routes exist that were not possible in earlier closed networks. Now it’s fairly common for routes to include internet connectivity.

When routes were physically isolated within a corporate network, you could reasonably sign on to one system and connect to another in the same local network and feel comfortable that the same individual was defined the same at both ends of the connection.

But today I might create a user named “QSECOFR” on my home PC and find a route to your system. If the route has the “secure” designation, I can be given access to your system as QSECOFR without needing to supply a password.

Why? Because someone designated the connection as being secure and therefore not needing a password. All that’s needed is a matching profile. And QSECOFR is guaranteed to match.

Fortunately, it generally applies only to SNA “routes” and they need to be configured ahead of time. The authority to create such routes comes from the *IOSYSCFG special authority in current or recent releases. (That was one of the reasons IBM created *IOSYSCFG a couple versions back, because networking was changing so quickly. And note that SNA-over-IP is possible.)

It’s been many years since I allowed any “secure” locations to be defined on any systems under my control. I’m probably a little behind on what kinds of holes it might open up. The holes that I know about are enough for me to keep them out of our configurations.

Tom