Endevor

ย View Only
  • 1.  Conversion from progam-pathing to ALTID

    Posted Dec 15, 2020 09:58 AM
    Hi all! 

    I was wondering if anyone would be willing to share their experiences and "gotchas" during a conversion of their Endevor security from program-pathing ALTID.  

    All comments/testimonials welcome! :)

    ------------------------------
    Consultant
    John D Consulting Inc.
    ------------------------------


  • 2.  RE: Conversion from progam-pathing to ALTID

    Posted Jun 09, 2022 11:36 AM
    Hi John
    Did you get any feedback on this?  After battling constantly with program pathing I am very keen to recommend this site switch to Alternate ID.  It would be good to know of the experience of others who have made this switch, especially any potential traps to watch out for.
    regards, Leanne


  • 3.  RE: Conversion from progam-pathing to ALTID

    Posted Jun 13, 2022 06:41 AM
    Hi Leanne! 

    The short answer is "no I did not receive any feedback on this topic" but we did/are doing the conversion regardless. 

    The process is relatively straightforward with a couple of things learned and "thank goodness we did that" things. 

    1) Once you specify an ALTID in the C1DEFLTS table, it takes effect immediately and Endevor stops using program-pathing even if the program-paths are still defined in thee security software. I had always thought Endevor did "AND" processing (eg ALTID and then program-path in the same instance) but it turns out its "OR" processing (eg Does ALTID exist? If Y then use only ALTID. If N then use program-path

    2) Some processors may require the user's authority for dataset access rather than the ALTID. Either you need to make the ALTID king-of-all-kings and give it universal access to all datasets or code ALTID=N on the EXEC statement for the step needing user authority.

    3) *tip* Don't revoke your program-paths right away. Leave them there for a while in case you need to backout from ALTID to program-pathing to fix a conversion issue

    4) *warning* In the instance we converted we are using Top Secret. We had an issue with the ALTID and CAP processing. Long story made very short is that the ALTID needs to have the ability explicitly declared in its definition to initiate STC as one of its TSS functions.

    That's all I have so far! Good luck!


  • 4.  RE: Conversion from progam-pathing to ALTID

    Posted Jun 13, 2022 08:23 AM
    Hi John,

    We've always used ALTID.

    I'm sure you're doing this - a change this big should be tested in an isolated LPAR, where there would be no internal customer impact, if things didn't work out as planned.

    Regards,

    Phil

    ------------------------------
    Phil Gineo
    Manager, Systems Engineering
    Aetna / CVS Health
    Hartford Connecticut USA
    ๐Ÿ™‚
    ------------------------------



  • 5.  RE: Conversion from progam-pathing to ALTID

    Posted Jun 13, 2022 08:32 PM
    Thanks John and Phil for the feedback.

    That first point about ALTID overriding any and all program pathing would seem to be the most important thing to know from the get go so I'm surprised that this wasn't mentioned in the support case I raised about this.  It sounds like this will make it easier to convert which is encouraging.

    Was is maybe temp datasets that might have used the user's personal access instead of AltID?  If I have to investigate all processors beforehand (there are bazillions here, mostly duplicates of each other - grrrrrr) that will be huge.  Was there some sort of pattern to the datasets that didn't use AltID that might help me identify them up front?

    You lost me on the 4th point.  is that just relevant to Top Secret?  We're ACF2 here.  If I ask the ACF2 person creating the AltID to "explicitly declare in its definition to initiate STC as one of its TSS functions" would that make more sense to them?

    Phil, the suggestion to test the change in a different LPAR got me wondering about whether we should go down that track.  Generally, any testing done in a "test Endevor" location (eg for a new release) would be done by an Endevor admin who has different security access to most users so it might all seem fine but when put into the real Endevor world get a different result anyway.  How did you approach this, John?  Did you try it elsewhere or just switch it on, sit back and see who screams?


  • 6.  RE: Conversion from progam-pathing to ALTID

    Posted Jun 14, 2022 07:16 AM
    Hi Leanne,

    In the isolated test LPAR, I recommend you get another TSO ID with access levels like a traditional developer.  When testing the conversion to ALTID or other changes, you should use that TSO ID as appropriate.   

    Regards,

    Phil

    ------------------------------
    Phil Gineo
    Manager, Systems Engineering
    Aetna / CVS Health
    Hartford Connecticut USA
    ๐Ÿ™‚
    ------------------------------



  • 7.  RE: Conversion from progam-pathing to ALTID

    Broadcom Employee
    Posted Jun 14, 2022 07:36 AM

    Hi all

    I'd like to try to clarify the relationship between endevor alternate ID and program pathing.

    The security identity of an MVS address space (Job, started task, TSO session ...) is represented by an ACEE control block (Accessor Control Execution Environment) pointed to by ASXBSENV field in the ASXB block (Address Space eXtension Block) that represents the address space.

    A subtask that runs within an address space may inherit the identity of the address space or have its own identity represented by an ACEE pointed to by field TCBSENV in the TCB (Task Control Block) that represents the subtask.

    The endevor alternate ID mechanism works by temporarily swapping the original ACEE associated with the subtask or the address space to an ACEE that represents the endevor alternate ID. If this is done, for example, before letting MVS process an OPEN request, it results in all effects in the OPEN being performed under the security scope of the alternate ID while in fact endevor is being executed under the security scope of the user.

    During processing of the OPEN, MVS asks the security product whether the OPEN has to be allowed. Obviously, the security product decision is based on the identity associated with the task, but it MAY also consider other factors, like for example, any program pathing rules in effect for the combination of the dataset, program and user (in this case, the endevor alternate ID).

    In a few words, the alternate ID is totally under control of endevor, who decides when to swap the security scope to that of the alternate ID. However, the use of program pathing rules is totally up to the security product and is not requested by endevor by any means.

    Regards - Eduard





  • 8.  RE: Conversion from progam-pathing to ALTID

    Posted Jun 14, 2022 09:28 AM
    No, we didn't have any problem with temporary files. We needed to use the userid instead of the ALTID in the occasional step in a badly written processor (or 2 or 3...) that made use of a user or group external dataset that was restricted to just that application or user. Some problems can only be incrementally approached and addressing the mass of security rules that have been imbedded to "control" Endevor outside of normal practice is part of the overall re-architecture that is being accomplished.

    As for STC.... that stands for Started Task. Generally speaking I would suspect your security administrators restrict which userid's have the authority to initiate a started task. Long story made very short, your ALTID needs to have that security attribute explicitly granted in its definition if you want to use CAP; assigning a profile to the ALTID that enables the ability may not be enough.

    As for testing... well..... we like to live on the edge. We do have a couple of different "test" userids that we use for confirmation that things are working the way we think they are working and flipped ALTID on with profiles assigned that reflected our sysprog access. We never really ran into a hardcore problem.