14 Replies Latest reply on Feb 14, 2019 4:47 PM by Russell Hentz

    Cyberark integration after upgrade to 11.3.0.4

    Viktor Marinov

      Hello dear experts,

       

      I have probably a support case, but will try to resolve it here, it is probably important for other customers too.

      After doing an OS patch and ADDM upgrade:

       

      ADDM_OS_Upgrade_CentOS_64_7.19.01.22_758402_ga.sh.gz

      ADDM_Upgrade_11.3.0.4_753624_CentOS7_ga.tgz

       

      got the version:

       

      Software Version     11.3.0.4

      Software Revision     753624

      Commission Date     Sat Jun 30 01:44:13 BST 2018

      Kickstart Version     7.0.738629

       

      Cyberark integration is still working, but only for Windows credentials and UNIX keys. Cyberark provider:

       

      Credential Provider Status     Installed: 9.80.0.85

       

      Deeper into "not working", I have seen that for UNIX systems it tries to connect getting the right user, but putting the hostname with \ in front of it, as it tries to login locally on windows machine:

       

      Trying ssh access as user hostname_unix_host\unix_user_from_cyberark

      <image001.png>Permission Denied

      <image001.png>ssh access failed as user hostname_unix_host\unix_user_from_cyberark (show session log)

      1.    OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017

      2.    debug1: Reading configuration data /etc/ssh/ssh_config

      3.    debug1: /etc/ssh/ssh_config line 58: Applying options for *

      4.    debug1: Connecting to 10.10.10.10 [10.10.10.10] port 22.

      5.    debug1: Connection established.

      6.    debug1: key_load_public: No such file or directory

      7.    debug1: identity file /usr/tideway/.ssh/id_rsa type -1

      8.    debug1: key_load_public: No such file or directory

      9.    debug1: identity file /usr/tideway/.ssh/id_rsa-cert type -1

      10.    debug1: key_load_public: No such file or directory

      11.    debug1: identity file /usr/tideway/.ssh/id_dsa type -1

      12.    debug1: key_load_public: No such file or directory

      13.    debug1: identity file /usr/tideway/.ssh/id_dsa-cert type -1

      14.    debug1: key_load_public: No such file or directory

      15.    debug1: identity file /usr/tideway/.ssh/id_ecdsa type -1

      16.    debug1: key_load_public: No such file or directory

      17.    debug1: identity file /usr/tideway/.ssh/id_ecdsa-cert type -1

      18.    debug1: key_load_public: No such file or directory

      19.    debug1: identity file /usr/tideway/.ssh/id_ed25519 type -1

      20.    debug1: key_load_public: No such file or directory

      21.    debug1: identity file /usr/tideway/.ssh/id_ed25519-cert type -1

      22.    debug1: Enabling compatibility mode for protocol 2.0

      23.    debug1: Local version string SSH-2.0-OpenSSH_7.4

      24.    debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1

      25.    debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000

      26.    debug1: Authenticating to 10.10.10.10:22 as 'hostname_unix_host\\unix_user_from_cyberark'

      27.    debug1: SSH2_MSG_KEXINIT sent

      28.    debug1: SSH2_MSG_KEXINIT received

      29.    debug1: kex: algorithm: diffie-hellman-group-exchange-sha256

      30.    debug1: kex: host key algorithm: ecdsa-sha2-nistp256

      31.    debug1: kex: server->client cipher: aes128-ctr MAC: umac-128-etm@openssh.com compression: none

      32.    debug1: kex: client->server cipher: aes128-ctr MAC: umac-128-etm@openssh.com compression: none

      33.    debug1: kex: diffie-hellman-group-exchange-sha256 need=16 dh_need=16

      34.    debug1: kex: diffie-hellman-group-exchange-sha256 need=16 dh_need=16

      35.    debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<3072<8192) sent

      36.    debug1: got SSH2_MSG_KEX_DH_GEX_GROUP

      37.    debug1: SSH2_MSG_KEX_DH_GEX_INIT sent

      38.    debug1: got SSH2_MSG_KEX_DH_GEX_REPLY

      39.    debug1: Server host key: ecdsa-sha2-nistp256 SHA256:58R7Mv5xL7dZYN0+b7LOKmew3j7/g0gw99zJbs3JCiI

      40.    The authenticity of host '10.10.10.10 (10.10.10.10)' can't be established.

      41.    ECDSA key fingerprint is SHA256:58R7Mv5xL7dZYN0+b7LOKmew3j7/g0gw99zJbs3JCiI.

      42.    ECDSA key fingerprint is MD5:21:00:18:76:d5:e4:16:b8:f5:3e:2c:b3:6a:b9:3f:ab.

      43.    Are you sure you want to continue connecting (yes/no)? yes

      44.    Warning: Permanently added '10.10.10.10' (ECDSA) to the list of known hosts.

      45.    debug1: rekey after 4294967296 blocks

      46.    debug1: SSH2_MSG_NEWKEYS sent

      47.    debug1: expecting SSH2_MSG_NEWKEYS

      48.    debug1: SSH2_MSG_NEWKEYS received

      49.    debug1: rekey after 4294967296 blocks

      50.    debug1: SSH2_MSG_SERVICE_ACCEPT received

      51.    **************************************************************************

      52.    WARNING: Unauthorized access to this system...

      57.    **************************************************************************

      58.    debug1: Authentications that can continue: publickey,password,keyboard-interactive

      59.    debug1: Next authentication method: keyboard-interactive

      60.    Password:

      61.    debug1: Authentications that can continue: publickey,password,keyboard-interactive

      62.    Password:

       

      If you get user and password from cyberark and put them on appliance (of course you get the right username without the hostname in front of it and also testing the credentials provider with the search string returns the right user without "hostname\"), the scan is successful.

      Vaults or any other configuration on cyberark hasnt changed at all, before the upgrade everything was working fine. It is also not a single case with some hosts, but with all hosts world-wide, because the customer hast seen it coming in DEV and also upgraded PROD...

       

      Do you have any idea?

       

      Thanks in advance!