Workload Automation1

Expand all | Collapse all

Seeking customer experiences for moving to WAAE External Security

  • 1.  Seeking customer experiences for moving to WAAE External Security

    Posted 23 days ago
    Hi,

    I am seeking customer experiences and feedback for moving to WAAE External Security from Native Security.

    Were there unexpected issues with job and machine access after you enabled External Security? If so, what kinds of issues?

    Do you have any tips on rapidly getting to the root cause of access issues, especially for scheduled job runs?

    Thanks


  • 2.  RE: Seeking customer experiences for moving to WAAE External Security

    Posted 22 days ago

    ?? you mean using eEM? I suggest setting up the policies as soon as possible. eEM for AutoSys has been tuned so well, it behooves anyone to not use it.

     

     

     

    Steve C.

     



    Nothing in this message is intended to constitute an electronic signature unless a specific statement to the contrary is included in this message.

    Confidentiality Note: This message is intended only for the person or entity to which it is addressed. It may contain confidential and/or privileged material. Any review, transmission, dissemination or other use, or taking of any action in reliance upon this message by persons or entities other than the intended recipient is prohibited and may be unlawful. If you received this message in error, please contact the sender and delete it from your computer.





  • 3.  RE: Seeking customer experiences for moving to WAAE External Security

    Posted 22 days ago
    We've been on EEM for years, it's really the way to go.   The permission check in EEM helps you get to the root of any issue quickly.
    Set it up in your dev system and play with it until you understand how it works.   You won't regret the switch.


  • 4.  RE: Seeking customer experiences for moving to WAAE External Security

    Posted 2 days ago
    EEM is great, but it should be 95% planning and 5% implementation.  The problem I see at most companies is that the policies aren't scalable.  If you need to define one or more new policies in the various as-* classes to onboard new applications, you're baking a future headache.  Have a solid naming convention that spans all objects (as applicable).  You can then trigger off that convention (hopefully a prefix).  That, in conjunction with an assigned role, provides everything you need to assign segregated access across the estate as desired. I'm sure there are other avenues people have used ... I just find this one the easiest to deploy and manage.


  • 5.  RE: Seeking customer experiences for moving to WAAE External Security

    Posted 2 days ago

    GROUP-AutosysRole and use string subtraction.. one and done. Goes hand in hand with solid naming conventions.

    "This is the way".

     

     

     

    Steve C.

     



    Nothing in this message is intended to constitute an electronic signature unless a specific statement to the contrary is included in this message.

    Confidentiality Note: This message is intended only for the person or entity to which it is addressed. It may contain confidential and/or privileged material. Any review, transmission, dissemination or other use, or taking of any action in reliance upon this message by persons or entities other than the intended recipient is prohibited and may be unlawful. If you received this message in error, please contact the sender and delete it from your computer.





  • 6.  RE: Seeking customer experiences for moving to WAAE External Security

    Posted 2 days ago
    WAAE External Security (aka EEM) does not impact scheduled job runs -- it is used to control changes (definitions, overrides, sendevents, etc) and reporting (autorep, forecast, etc)

    as Steve mentioned below, role based groups is the way to go.   Offload user/group membership to your LDAP team

    By using a strong naming convention, you can minimize the policies needed.