This document will help you learn more about the DB2 security model and what's involved when communicating with DB2 database system on Windows platforms.
Resolving the problem
Getting background information on DB2 security model for Windows platforms
On a Windows platfrom, If the DB2 Windows services are starting using a local id, that is an id
defined on the local Windows server with administrative rights, the following happens:
1. DB2 will authenticate "locally" defined user ids with administrative rights on the Windows server.
2. DB2 will not authenticate ids that are defined in the Domain only, even if they are in the Administrative group(s). The reason is, since the DB2 Windows services are starting up under a locally defined id, DB2 does not know anything about the Domain and does not go to the Domain to authenticate ids.
If the DB2 Windows services are starting up under a Domain id that is also defined in the Windows administrator group (either directly as an id, or indirectly as a member of a Domain group defined to the local administrator group), DB2 is able to authenticate ids that are defined in the Domain only.
If Domain ids will be used to administrate DB2, the DB2 Windows services must start up under an id that is also defined in the Domain. The individual domain ids can either be defined directly to the local Windows administrator group, or they can be defined to a Domain group that is then defined to the local Windows administrator group.
For a detailed explanation on the DB2 Security model for Windows platforms, refer to the DB2 and Windows Security pages in the Information Center.
|Information Management||DB2 Connect||Windows||9.7, 9.5, 9.1|