Results 1 to 8 of 8

Thread: db2admin

  1. #1
    Join Date
    Aug 2008
    Location
    Toronto, Canada
    Posts
    2,367

    Unanswered: db2admin

    v9.7 ESE on Windows 2003.

    Is it ok to remove db2admin (got created during installation) if db2 is started using Local System account and SYSADM_GROUP is set to DB2ADMNS (DBA user is part of DB2ADMNS) and SECADM / DBADM is granted to DBA user? The db was created using application id.

  2. #2
    Join Date
    Jun 2003
    Location
    Toronto, Canada
    Posts
    5,516
    Provided Answers: 1
    I'd check the instance and database file ownership first.
    ---
    "It does not work" is not a valid problem statement.

  3. #3
    Join Date
    Apr 2012
    Posts
    1,035
    Provided Answers: 18
    I would not delete the account, instead I would disable the account in active-directory (just to avoid potential hassles during upgrades etc). It's easier to recover from unexpected situations than if you have to recreate the account (different sid).

    Apart from the instance(s) login credentials, verify also that no other services use db2admin credentials (e.g. DAS if still used , etc) and change if needed (services.msc).

    Also check whether any replication settings reference db2admin.

    Also check which objects are owned by db2admin and consider if ownership needs to be transferred, and/or security settings changed.

  4. #4
    Join Date
    Aug 2008
    Location
    Toronto, Canada
    Posts
    2,367
    The instance and database directories/files are owned by Administrators (group).

    I wonder why? I just created a file when logged in as db2admin and then checked the owner of this file - it says Administrators. Why not db2admin?


    Another question related to administering DB2 on Windows.

    AIX/Linux: We sudo to the instance owner. Our personal IDs don't have any DB2 privileges.

    Windows: Is it better for DBA's to use their personal IDs or use a shared id (ie. db2admin) ? For shared IDs, our security policy states that "Userids are not to be shared unless individual accountability can be maintained"

  5. #5
    Join Date
    Jun 2003
    Location
    Toronto, Canada
    Posts
    5,516
    Provided Answers: 1
    Quote Originally Posted by db2girl View Post
    our security policy states that "Userids are not to be shared unless individual accountability can be maintained"
    And how do you maintain individual accountability when sudo-ing to the instance owner? After the sudo there is no way to track the individual ID that ran "db2 drop db dwh".
    ---
    "It does not work" is not a valid problem statement.

  6. #6
    Join Date
    Aug 2008
    Location
    Toronto, Canada
    Posts
    2,367
    Our OS team said they can tell who had done what and when. I guess all they can see if what id sudo to the instance owner and at what time.

  7. #7
    Join Date
    Apr 2012
    Posts
    1,035
    Provided Answers: 18
    If you accepted the installation-time default for DB2 on Windows (extended security enabled) then the file/directory ownership will be per db2extsec. Check Icacls or cacls (depending on your windows version) for more details of file-system object permissions.

    If you disable db2admin in active-directory then logins and authentications for that account will fail - so it is no longer shareable.
    If it is a local account, it can also be disabled locally - though of course can be re-enabled, although domain policies can prevent this.

    With sudo on AIX/Linux, the "who am i" command shows the account-name of the login that performed the sudo.

    On current versions of Windows the 'whoami.exe /logonid' command gives the SID of the logged-in user (as distinct from the account that is running the command, e.g. in a runas scenario), and other useful information.

    In addition, for v9.7 and higher, for Big-Brother types, a suitably written CONNECT_PROC can check the authid (is is DB2ADMIN ?), and can check the workstation-login-id (who is trying to connect as db2admin?) and react appropriately...the docs state that if the connect_proc fails then the connection attempt will fail...or just insert into a table a row recording the fact of the db2admin connection and its timestamp, originating workstation detail/logon account etc - and ensure that select/delete access on that table is rigidly enforced.

  8. #8
    Join Date
    Aug 2008
    Location
    Toronto, Canada
    Posts
    2,367
    Thanks a lot for the info.

Posting Permissions

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