Using SMH with secured and non-secured Broker

[Mona_Kaminsky]

Hi all :lol:
I’m bringing a qustion for one of my customers.
How (if it’s even possible) can they monitor from the same SMH 2 remote brokers, when one is secured(with EntireX Security), and the second isn’t ?
Does anyone use this configuration ?
Thanks
Mona

[Wayne_Campos]

I have done this. However, I did not do anything special.

My SMH is running on Windows XP. My remote brokers are running on z/OS 1.4. I have EntireX Security installed on both platforms.

When you define the remote broker (secured or unsecured) you should Set User Credentials before you try to access the remote broker. For the secured remote broker it is important that you provide a valid user id and password. I thought that you might have to add the following to the broker attribute file on the unsecured remote broker “IGNORE-SECURITY-CONSISTENCY=YES” but now I don’t think that it is necessary. I am accessing 3 unsecured remote brokers and 2 secured remote brokers. One of my unsecured remote brokers does NOT have the setting above and I can still access it via SMH.

Wayne Campos

[Mona_Kaminsky]

Hello Wayne,
I’m well aware of the IGNORE-SECURITY-CONSISTENCY parameter- I wouldn’t like to use it .
On the Pc machine you’re using for the SMH did you install EntireX with security ?
In my case connecting the secure Broker (after setting of course user credentials) gives the message “PASSWORD NOT AUTHORIZED” :oops: and I’m passing the correct password for sure …

[Wayne_Campos]

Mona,
IGNORE-SECURITY-CONSISTENCY allows a secured application to talk to an unsecured Broker. It does not compromise your security. Could you please explain why you wouldn’t like to use it?

Yes, I have EXX721 with security installed on WinXP Pro SP2 talking to EXX711 with EXS711 on z/OS.

I think that if security is not installed on your PC, or if it is installed incorrectly, PASSWORD NOT AUTHORIZED is the message you would receive.

The password is encrypted before it is sent to the Broker and then it is decrypted by the Broker. If security is not installed (or installed incorrectly) on the client then the decryption process gets the wrong value since the password was not encrypted properly on the client.

Wayne

[Mona_Kaminsky]

Thanks Wayne.
I’ll try this way

[system]

Hi Mona,

It seems the client has to be on EXX721 to make this work without the IGNORE-SECURITY-CONSISTENCY parameter set to YES.

In EXX721 there is a new ACI field named KERNELSECURITY.

Description about KERNELSECURITY from the 721pl15 documentation:

This field is used by the application to programmatically indicate its intention to communicate with a secure/non-secure Broker. The field also indicates to the application how security has been configured for a particular Broker kernel. See Broker attribute SECURITY.
Input Field Field used by programmer to indicate the desired security behavior of the application. If no option is specified, defaults to administrator’s configuration setup.
Y EntireX Security
U User-Written Security
N No security
Note:
• Output: In version 7 or above, this field returns the output value when executing the KERNELVERSION command.
• Input: In version 8 or above, the application can programmatically specify the desired security behavior for all commands other than KERNELVERSION.

It has two purposes:

• First – this field tells you (function KERNELVERSION) whether you communicate with a secure or non-secure Broker.
  
  Second – you can specify (functions other than KERNELVERSION) the behavior you request regarding security (security or no security) for your call.