Layer7 Access Management

Expand all | Collapse all

Siteminder Reg

Jump to Best Answer
  • 1.  Siteminder Reg

    Posted 07-26-2017 04:22 PM

    Hi There,

    We have an Apache where agent is pointing to sm12.0 version and we upgraded to sm 2.7.Now the question is re-registering the host(apache) with new sm12.7,is the below command is sufficient to re-register do we need any additional steps? Please advice.

    smreghost -i policy_server_IP_address:[port] -u administrator_username -p Administrator_password
    -hn hostname_for_registration -hc host_configuration_ object

     

    Thanks In advance.



  • 2.  Re: Siteminder Reg

    Posted 07-26-2017 06:01 PM

    Hi Popleys,

     

    smreghost command will remain same. There shouldn't be any issue with host registration.



  • 3.  Re: Siteminder Reg

    Posted 07-27-2017 02:59 PM

    Hello Popleys,

    There was no change in command in the 12.7 documentation. https://docops.ca.com/ca-single-sign-on/12-7/en/administrating/register-a-trusted-host-using-the-smreghost-registration-tool

    Please find below another way using smreghost,

    smreghost -i Policyserver IP Address -u user -p password -hn hostname -hc hostconfigname -f path_to_existing_host_config_file      -o overwrite_existing_trusted_host.

    Note:

    If -o not used, existing trusted host must be deleted and then use smreghost command. 



  • 4.  Re: Siteminder Reg

    Posted 07-27-2017 04:03 PM

    Thanks Krishna.How about if I have multiple policy servers because we have 3 policy servers.



  • 5.  Re: Siteminder Reg

    Posted 07-27-2017 05:05 PM

    You can manually add the remaining two Policysercer IP later in SmHost.conf or also use them while running smreghostb command



  • 6.  Re: Siteminder Reg

    Posted 07-28-2017 04:57 PM

    Hi Ujwol,

    Could you please provide the sample for it which mean modify below to reflect multiple policy servers through command line rather editing in smhost.conf.

     

    smreghost -i policy_server_IP_address:[port] -u administrator_username -p Administrator_password
    -hn hostname_for_registration -hc host_configuration_ object



  • 7.  Re: Siteminder Reg
    Best Answer

    Posted 07-28-2017 05:07 PM

    Hi Sharath,


    My bad. 


    smreghost currently doesnt support multiple PS IP.


    You can vote for this idea:


    https://communities.ca.com/ideas/235730325

    • -i policy_server_IP_ address:port
      Indicates the IP address of the Policy Server where you are registering this host. Specify the port of the authentication server only if you are not using the default port.
      If you specify a port number, which can be a non-default port, that port is used for all three Policy Server processes (authentication, authorization, accounting). The Policy Server responds to any Agent request on any port. 
      Use a colon between the IP address and non-default port number, as shown in the following examples.
      Default: (ports) 44441,44442,44443
      Example: (IPv4 non-default port of 55555) -i 127.0.0.1:55555
      Example: (IPv4 default ports) -i 127.0.0.1
      Example: (IPv6 non-default port of 55555) -i [2001:DB8::/32][:55555]
      Example: (IPv6 default ports) -i [2001:DB8::/32]


  • 8.  Re: Siteminder Reg

    Posted 07-28-2017 05:16 PM

    If multiple ps were used is it some thing below

    smreghost -b 192.18.96.177 192.18.96.178  192.18.96.179  -u siteminder -p test@123 -hn <trustedhostname>  -hc <HCO>



  • 9.  Re: Siteminder Reg

    Posted 07-28-2017 08:53 PM

    As long as all the policy servers are pointing to the same policy store or stores that replicate, you only need to reregister it once and either all the policy servers will use the new trusted host or if using multiple stores with replication, they will be copied over. You only need to run the smreghost on one Policy Server and make sure the new SmHost.conf file is written to the same location, as specified in your WebAgent.conf file, you should be fine. Also if your using multiple Policy Stores that replicate, it's best practice to write to one master Policy Store otherwise it could get confusing and multiple admins writing to different stores could overwrite each other's changes.