Layer7 Access Management

Expand all | Collapse all

Lifecycle of the userPassword in CA Identity Manager & Use of Jmeter for scalability testing

  • 1.  Lifecycle of the userPassword in CA Identity Manager & Use of Jmeter for scalability testing

    Posted 12-11-2015 02:30 PM

    Team,

     

    You may find this of value.

     

    While having several discussions over the years, regarding IM's AD reverse password sync process; and how/when passwords are changed; I would outline the processes on whiteboards and/or via email.

     

    I put together the two (2) decks to clarify the password data flow; and how to "force the solution" to "fail", where "fail" is to help identify when the solution's architecture should be adjusted to horizontally scale to millions of users.

     

     

    Please forward comments if you have questions or find this of value.

     

     

     

    Cheers,

     

    A.

     

     

    Edit: 2018/07/27  Update PDF for Lifecycle of userPassword of CA Identity Manager solution.



  • 2.  Re: Lifecycle of the userPassword in CA Identity Manager & Use of Jmeter for scalability testing

    Posted 12-11-2015 04:48 PM

    Extraordinarily helpful, Alan. Thank you very much!



  • 3.  Re: Lifecycle of the userPassword in CA Identity Manager & Use of Jmeter for scalability testing

    Posted 11-20-2018 11:23 AM

    Team,

     

    If you see delays with ADS password reset, you may wish to eliminate challenges from read-only DC, Firewall ports blocked between internal network segments, or DNS issues.

     

    The IM ADS endpoint will identify all failover DC hostnames.   If any of these hostnames have a challenge, you may be able to observe your JCS/CCS logs attempt to communicate to the other DC host names.

     

    Add in full control of which DCs you wish to communicate with.   Update the CCS\data\ADS\<endpoint-name>.dns file for each AD managed endpoint.

     

    Below is a screen shot to help assist with this performance; and reduce delays.

     

     

     

    Steps to get better metrics.

     

    1. Focus efforts at the provisioning tier (not the IME)
    2. Use the IMPS GUI to view the ADS endpoint.
      1. Is the managed ADS endpoint using a FQDN or a domain name (ca.com)
    1. If using a domain name, is there a CCS_HOME\data\ADS\<endpointname>.dns file, that restricts DC list of names to “network latency close” and “writable” DCs (avoid the read-only DCs in this list)
      1. If using the FQDN for a domain controller (DC), does this DC have the PDC emulator role (aka NT4 PDC emulation)
    1. The PDC emulator role ensure that any password update, will reside here as well as any local DC, and will ignore the Active Directory latency challenges.
          1. A workstation, upon authentication event, if it fails to authenticate to the “closest DC” , before an error message is sent, the DC with the PDC emulator role will be check for the correct password.
          2. netdom query fsmo     [execute from one of the DC or any server that is part of the AD domain]
    1. Check that the remote IAMCS/CCS server has the proper OS ENV configurations set.
      1. These can be set via MS Windows Advance Properties UI (or use the command line tool of setx  ADS_***   value  /m  )

     

     

     

     

     

    1. If you wish to build a performance metric, use dxsoak command to force a single password reset to the same account
      1. Use this as your base, then start to change the above different configurations to see which have value to resolve the issue.
      2. https://communities.ca.com/thread/241817252-dxsoak-stress-testing-scaling-the-ca-identity-suite-provisioning-tier
      3. Example:
    1. Below for a password update, to the same ADS account, I am getting about 777 updates /60 seconds =  12 password changes per second
          1. Note:  This is for a single IAMCS/CCS data stream; with multiple IAMCS/CCS servers I would see this almost linearly growth per # of additional connector servers, when the JCS load-balancing kicks in.
          2. Note2:  Ensure that the remote ADS server used for the IMPS managed ADS endpoint has minimal of 4 vCPU and 8 GB RAM
            1. Otherwise the MS lsass service may be bottlenecked by CPU utilization.  (this is the service that manages the TCP 389/636 service).

     

     

    Monitor IMPS/logs/etatrans*.log to view the ADS updates.

    • May also view the CCS_HOME\logs\ADS\<ads_endpoint_name>.log

     

     

    Monitor your CCS\logs\ADS\<ads-endpoint-name>.log for any DNS issues or Port Conflicts.

     

    What are the default port allocations for CA Ident - CA Knowledge 

     

    ADS EndPoints:

    389 - Active Directory non SSL                                 [ Used base communication]

    636 - Active Directory SSL                                        [ Required for password resets]

    3268/3269 - Active Directory Global Catalog            [ For creation/modification  if feature is used. ]

    139/445 - Active Directory NetBios / microsoft-ds     [ For creation/modification  if feature is used.  Home Folder creation. ]

    4104/4105 (UDP/TCP) - Active Directory default Exchange Agent CAM/CAFT          [ OLDER MS EXCHANGE process:  For creation/modification  if feature is used.  Retire and use MS Powershell API processes]