IBM Support

IT28712: EXCESSIVE NUMBER OF LDAP AUTHENTICATION REQUEST FOR SINGLE USER CAUSED BY GROUP-WDIE AUTHENTICATION LOOKUP

Subscribe to this APAR

By subscribing, you receive periodic emails alerting you to the status of the APAR, along with a link to the fix after it becomes available. You can track this item individually or track all items by product.

Notify me when this APAR changes.

Notify me when an APAR for this component changes.

 

APAR status

  • Closed as program error.

Error description

  • 1.  Problem description
    The customer setup Db2 with transparent LDAP authentication. He
    noticed that he was seeing an unexpectedly high number of
    authentication requests on the LDAP server. He did some testing
    and found that an authentication request for a single user would
    return the group for that user, then make authentication
    requests for all users within that group.
    The AIX team performed an analysis and came to the following
    root cause and suggested resolution. (They came to these
    conclusions after analysing the source for the sample
    authentication program, aixAuthTest.C.)
    
    ###################################
    AIX team root cause analysis
    ###################################
    The auth test code is doing this:
    .
    1) getgrset   (gives GIDs user belongs to)
    This is the function that is giving us the GIDs of db1 through
    db7 that we see above. We send a request to the server asking
    for the GIDs the user belongs to, and it responds to that
    request - one request made, and one reply returned.
    .
    2) getgrgid_r (get group data for each of these GIDs)
    This call is being made in order to translate the GID from step
    1 into a group name. The auth test code makes this call for each
    of the GIDs we got from getgrset. It is getting all group
    information - in addition to getting the group name, it is also
    grabbing attributes like 'memberuid' - and as we see above in
    the IP trace, if we see a memberuid that is defined as full DN,
    we'll do a search on it to translate it and get a short user
    name
    .
    That is the explanation for why we are seeing those extra
    searches - as each call to getgrgid_r is made, and we are
    grabbing all of that group's attributes, we are also going to
    need to translate the full DN into its short name.
    .
    Note, that when getgrset is called, we are able to get a full
    list of GIDs that the user belongs to without needing to do any
    extra searches for these fullDN's. We send a request to the
    server saying 'give us the GIDs of all groups that this user
    belongs to', and it does so.
    This is similar to what is happening when lsuser does a
    getuserattr to get group names - except instead of asking the
    server 'give us the GIDs', it is asking 'give us the group
    names'. Since it gets the groups names rather than GIDs, there
    is no need to use getgrgid_r to find the group name - and that
    also takes away the need to translate the 'member' information
    that getgrgid_r is returning.
    .
    If DB2 just needs a list of group names that the user belongs
    to, it would be better to use getuserattr(), ie:
    .
            rc=getuserattr(argv[2],S_GROUPS,&val2,SEC_LIST);
            if(rc==0) {
                    char * str = val2;
                    int len;
                    printf("User %s in authdb %s has group list
    ",argv[2],new);
                    while(1) {
                            len=strlen(str);
                            printf("%s ",str);
                            str=str+len+1;
                            if(str[0] == 0) break;
                    }
                    printf("\n");
    .
            }
            else printf("getuserattr failed\n");
    .
    Attached is a test program called groupsids.c, as well as it's
    compiled form.
    It would be run as:
    .
    ./groupsids LDAP <username>
    .
    This shows how to make a call to:
    .
            rc = getuserattr(argv[2],S_GROUPSIDS, &val, SEC_LIST);
    (get group ID's)
    and:
            rc=getuserattr(argv[2],S_GROUPS,&val2,SEC_LIST);    (get
    group names)
    .
    The S_GROUPSIDS call is functionally equivalent to making a call
    to getgrset, so I wouldn't say it's any better or worse than
    using getgrset.
    The S_GROUPS call, however, gives you the user's group names
    without going through the extra business that getgrgid_r will do
    as far as translating the full DN's.
    
    ###################################
    groupsids.c
    ###################################
    
    #include <usersec.h>
    #include <strings.h>
    #include <sys/types.h>
    void main(int argc, char * argv[]) {
            char *new;
            char *val;
            char *val2;
            int rc;
            new = strdup(argv[1]);
            setauthdb(new,NULL);
            rc = getuserattr(argv[2],S_GROUPSIDS, &val, SEC_LIST);
            if(rc==0) {
                    char * str = val;
                    int len;
                    printf("User %s in authdb %s has group list
    ",argv[2],new);
                    while(1) {
                            len=strlen(str);
                            printf("%s ",str);
                            str=str+len+1;
                            if(str[0] == 0) break;
                    }
                    printf("\n");
            }
            else printf("getuserattr failed\n");
            rc=getuserattr(argv[2],S_GROUPS,&val2,SEC_LIST);
            if(rc==0) {
                    char * str = val2;
                    int len;
                    printf("User %s in authdb %s has group list
    ",argv[2],new);
                    while(1) {
                            len=strlen(str);
                            printf("%s ",str);
                            str=str+len+1;
                            if(str[0] == 0) break;
                    }
                    printf("\n");
            }
            else printf("getuserattr failed\n");
    }
    
    2.  Operating system and level:
    		AIX 64 bit 7.1
    
    3.  Client, server, and gateway information
        a. Client information, if applicable
        b. Gateway information, if applicable
        c. Server information, if applicable
    		AIX 64 bit 7.1
    		Db2 v11.1m4fp5
    
    4.  How to reproduce the problem
    Attempt to connect using an LDAP managed user that is part of a
    group that also includes multiple other users. Authentication
    requests will be sent for those users as well.
    

Local fix

  • N/A
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED:                                              *
    * ALL                                                          *
    ****************************************************************
    * PROBLEM DESCRIPTION:                                         *
    * See Error Description                                        *
    ****************************************************************
    * RECOMMENDATION:                                              *
    * Upgrade to Db2 11.1 Mod 4 Fixpack 5 or higher                *
    ****************************************************************
    

Problem conclusion

  • First fixed in Db2 11.1 Mod 4 Fixpack 5
    

Temporary fix

Comments

APAR Information

  • APAR number

    IT28712

  • Reported component name

    DB2 FOR LUW

  • Reported component ID

    DB2FORLUW

  • Reported release

    B10

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2019-04-08

  • Closed date

    2020-01-16

  • Last modified date

    2020-01-16

  • APAR is sysrouted FROM one or more of the following:

    IT28520

  • APAR is sysrouted TO one or more of the following:

Fix information

  • Fixed component name

    DB2 FOR LUW

  • Fixed component ID

    DB2FORLUW

Applicable component levels

  • RB10 PSN

       UP

[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSEPGG","label":"Db2 for Linux, UNIX and Windows"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"11.1","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}}]

Document Information

Modified date:
16 January 2020