DB2 security via ACF2 Secondary auth ID

[Anon Anon]

I'm the new ACF2 admin & configuration admin  at an old site with little  doc of the existing config available, so I have a steep learning curve becoming familiar with the local setup.   I'm seeking some direction toward appropriate doc or info about this kind of security  for DB2; perhaps DB2 manuals or ACF2 manuals??   I'm somewhat knowledgeable about database, but cluless about DB2 security administration alternatives.  It looks to me like we probably don't have the CA ACF2 Option for DB2.   The doc on that "product" seems to talk about how it is better than what we use....but I haven't found doc on  the kind of more  primitive  setup we use; they make it sound like the old-hat standard.  What I see is X(SGP) XREF  groups with LOGONIDS grouped as if they were terminal ID sources, and the group names are then used in DB2  kind of like group IDs for additional access permissions.  Is the term "secondary auth ID" a DB2 concept controlled via ACF2 or  an ACF2 concept?      Are there also some resource or dataset  rules (which I am unaware of) or other  LOGONIDs with these secondary auth ID X(RGP) group names  as SOURCE?   If so, how can I find them?   If not, why does this use X(SGP) instead of X(RGP)?   Is this  really DB2 entry validation or resource access permission checking?   Are RACF validation point exits involved, or ACF2 pre-vald / post-vald exits involved in this kind of setup (I see we do have ACF2 rsrc pre and post validation exits in effect, but have not been able to find the source code yet)?    I know IBM can provide a RACF access control module which can be put in the DB2 DSNX@XAC  to make  calls (presumably SAF, which ACF2 coudl handle)  for a variety of DB2 resource accesses, but I have no idea whether that or something like it is in use here, nor do I have any idea whether the alternative standard DB2 exit routine makes calls to the external security system.  And  my big question,  I need to know more about these  calls to determine whether I can  SAFTRACE these calls somewhat specifically, because right now some users are having a problem and I can't be sure whether it's an  ACF2 or DB2 issue.

#TopSecret

[ca.portal.admin]

Hi,secondary auth ids is a DB2 concept - and you are using CA ACF2 to exploit it.CA ACF2 provides 2 exit modules that are called to setup secondary auth IDs for a user.The two DB2 exits are DSN3@ATH and DSN3@SGN   - CA ACF2 provides samples in the CAIMAC library called ACF3@ATH and ACF3@SGN  .These exits do indeed use source records. In your case they use X(SGP) records.What they do is, for each user, they provide a cross reference to secondary ids that will be used by DB2 when deciding if a user is allowed to access resources - in addition to their own authority.Without ACF2 for DB2 option in place, DB2 uses its own internal tables for resource validation.If ACF2 for DB2 option is  installed, ACF2 resource rules will be used for the  validation process instead of internal security tables.  If you have ACF2 for DB2 option active you will see  messages similar to the following  at DB2 startup  CAS9800I - ENF-DB2 Interface Initialization in Progress                      
CADB2002 - DB2 subsystem DSNQ now protected by CA-ACF2/DB2 1.2 SP02
CAS9801I - ENF-DB2 Interface Initialization Complete   System DSNX    If you are having problems at signon time then a sectrace  will show the VERIFY REQUESTS being issued, if it is aresource access validation, then it  may be related to internal DB2 accesswhich will not involve SAF calls.  If you are having problems that cannot be solved here, I would suggest that you open a support call for CA ACF2 and it can be investigated.    regardsRossD  

#TopSecret

[Anon Anon]

Thanks.    CA support promptly  gave me a  thorough concise explanation via email by the time I returned to work in the morning.   I'll be looking at the exits later today.   The relevant points that mattered to me:- This is not the full product ACF2 for DB2.  - There are usually no associated resource or dataset rules using the x(SGP) source group names.- The main doc is in comments within the two exits   ACF3@ATH and ACF3@SGN   in the   ACF2.CX1xxMLD .CAIMAC library.   These are DB2 exits supplied with z/OS ACF2.  - The exits have a facility to send WTOs for diagnostic use.   Change or zap $WTOFLAG to 'Y' in the exits.  - The ACF2 TRACE bitflag in the LOGONIDs for the primary and/or secondary gives good diagnostics to SMF for the  ACFRPTRV report.  - SECTRACE of SAF won't work...I don't think this uses SAF, these exits probably  work only with ACF2.   

#TopSecret