Results 1 to 4 of 4
  1. #1
    Join Date
    Jan 2009
    Location
    Zoetermeer, Holland
    Posts
    746

    Unanswered: Did I shoot myself in the foot?

    On a windows2008/64 server I need db2client software. It has become a habit of me to install express-C because all the client packages are included and you can also run 'db2mon' on that same server to monitor your databaseservers in your network. Once finished I run a nice little script I've created loaded with
    Code:
    update cli cfg's
    catalog tcpip node's
    catalog database's
    catalog system odbc data source's
    When that script has finished my whole db-infrastructure is configured..... until yesterday.

    Yesterday:
    - my client software which is going to use db2-cli is 32 bit (db2mon as well) so I installed the 32-bit version of db2-express-c-v974
    - I started with a cmd-shell which I "ran as administrator" and did the install from there worked like a charm and the sample database was created.
    - next I started a db2cmd-shell to run my script it failed! SQL1092N. I am not authorized to either catalog "tcpip nodes" or catalog "databases"

    I've worked with db2 on windows before so I took the aces out of my sleeve. I tried:
    - start the db2cmd-shell with "run as adminstrator" -- NO RESULT
    - created a local group db2admns, make my ad-account a member and updated the dbm cfg, db2stop/-start -- NO RESULT
    - went to services. changed from Local System Account to my ad-account with my password. db2stop/-start -- NO RESULT

    Everything I know relates to instances or databases (and the SAMPLE database is there ready for use), but now I want to catalog nodes and it does not let me... and my sleeve is empty now. Before I give up and try the regular db2-client packages I hopesome has another suggestion for me to try.
    Somewhere between " too small" and " too large" lies the size that is just right.
    - Scott Hayes

  2. #2
    Join Date
    Feb 2012
    Posts
    22

    Check NTFS security (especially "owner") at instance folder level

    Shooting left foot, hurts less Dick (evil grins).

    Seems that you bumped into nasty (filesystem) security.
    My guess is, you first installed DB2 with another user that you are using with your new attempt ?
    Your first install has "special" rights on NTFS filesystem, somewhere...
    Default NTFS security will allow FULL access to the "owner" of file system objects (folders, files), and READ-ONLY access to (local) Users

    I would say: Check the NTFS security of the (toplevel) folder where the Instance is stored on the filesystem, and simply correct the NTFS security
    (be sure to se recursive)

    From memory, I think the "catalog config file(s)" are kept where the instance config is kept.
    The (crappy IBM DB2 install wizard), puts the default instance "DB2" in C:\ProgramData\IBM\DB2\DB2COPY1

  3. #3
    Join Date
    Jan 2009
    Location
    Zoetermeer, Holland
    Posts
    746
    Quote Originally Posted by ErwinHaTsoF View Post
    Shooting left foot, hurts less Dick (evil grins).
    I know this guy. He actually sent me a picture of a foot with a bullithole... Not good for the stomache.

    Solved the problem Erwin. My guess that you could be right but that should generate scary messages in the db2dialog instead of the SQL1092 error.
    The solution:
    Code:
    db2set -g DB2_GRP_LOOKUP=LOCAL,TOKENLOCAL
    as explained here: WriteStreams of Consciousness » Default This
    Somewhere between " too small" and " too large" lies the size that is just right.
    - Scott Hayes

  4. #4
    Join Date
    Feb 2012
    Posts
    22

    Db2_grp_lookup

    Both true and untrue,

    Security on instance level (sysadm etc) , database level (dbadmin , secadm, etc) and file system level (NTFS with local/domain users and groups), they all match up, one or the other, and yes, grrrr, puzzeling at times.

    DB2_GRP_LOOKUP indeed is ONE of the components (for DB2 on Windows, running standalone, or in a domain; local users /groups, domain users / groups)

    With DB2 9.7 things have changed by the way :
    "Due to the changes to the security model in Version 9.7, if this registry variable is not set, ensure that domain users are granted the database authorities and privileges that they required after the upgrade."

    I agree, It sure looks like this "should" have been a better "default" for DB2 9.7 : db2set DB2_GRP_LOOKUP=LOCAL,TOKENLOCAL

    Maybe best fit for most, BUT, it is not the default, and why should it be ?
    All depends what one wants to achieve, and how .... what is defined on ActiveDirectory (AD) domain level, user / server policies that are "pushed " to the server.

    ==> At our site, DB2 ver 9.7.5 , we don't set DB2_GRP_LOOKUP at all , whatever the "default" is (or was ... previously < 9.7.5 ... ), have not used it in 9.5.5. either....
    And: actually works as a charm, using the "normal" ("standard") approach Windows domain-member servers uses, in respect to domain groups mapping to local groups usage, etc.


    Taken from DB2 9.7 doc :
    <snip>
    •The first parameter is for conventional group lookup and can take the values: " ", "LOCAL", or "DOMAIN".
    •The second parameter is for token style group lookup and can take the values: "TOKEN", "TOKENDOMAIN", or "TOKENLOCAL".

    If the second parameter (TOKEN, TOKENDOMAIN, or TOKENLOCAL) is specified, it takes precedence over conventional group enumeration. If token group enumeration fails, conventional group lookup occurs, if the first parameter of DB2_GRP_LOOKUP was specified.

    The meaning of the values TOKEN, TOKENDOMAIN, and TOKENLOCAL are as follows:
    •TOKENLOCAL
    The token is used to enumerate groups at the local machine (this is equivalent to conventional "LOCAL" group lookup).

    •TOKENDOMAIN
    The token is used to enumerate groups at the location where the user is defined (at local machine for a local user and at the domain for a domain user). This is equivalent to conventional " ", or "DOMAIN" group lookup.

    •TOKEN
    The token is used to enumerate groups at both the domain and on the local machine. For a local user, the groups returned will contain local groups. For a domain user, the groups returned will contain both domain and local groups. There is no equivalent in conventional group lookup.


    For example, the following setting of DB2_GRP_LOOKUP enables access token support for enumerating local groups:
    db2set DB2_GRP_LOOKUP=LOCAL,TOKENLOCAL

    The next example enables access token support for enumerating groups at both the local machine as well as the location where the user ID is defined (if the account is defined at the domain):
    db2set DB2_GRP_LOOKUP=,TOKEN

    This final example enables access token support for enumerating domain groups at the location where the user ID is defined:
    db2set DB2_GRP_LOOKUP=DOMAIN,TOKENDOMAIN

    <snip>

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •