An toàn DB2 UDB, Phần 1: Hiểu cách các tài khoản người dùng và nhóm tương tác với DB2 UDB

Chia sẻ: Nhung Nhung | Ngày: | Loại File: PDF | Số trang:21

Thêm vào BST

Báo xấu

109
lượt xem 7
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Giới thiệu Những người mới dùng DB2 UDB thường hay hỏi về các tài khoản người dùng và nhóm cần thiết cho một bản cài đặt và môi trường hoạt động của DB2 UDB. Trong bài này, bạn sẽ tìm hiểu về các tương tác chính của DB2 UDB với những người dùng và các nhóm. Bài này mô tả tài khoản người dùng mà bạn sẽ cần đến khi cài đặt DB2 UDB trên các hệ điều hành Linux, UNIX và Windows, cũng như các tài khoản bổ sung mà bạn sẽ cần để chạy các quy trình và...

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: An toàn DB2 UDB, Phần 1: Hiểu cách các tài khoản người dùng và nhóm tương tác với DB2 UDB

An toàn DB2 UDB, Phần 1: Hiểu cách các tài khoản người dùng và nhóm tương tác với DB2 UDB Giới thiệu Những người mới dùng DB2 UDB thường hay hỏi về các tài khoản người dùng và nhóm cần thiết cho một bản cài đặt và môi trường hoạt động của DB2 UDB. Trong bài này, bạn sẽ tìm hiểu về các tương tác chính của DB2 UDB với những người dùng và các nhóm. Bài này mô tả tài khoản người dùng mà bạn sẽ cần đến khi cài đặt DB2 UDB trên các hệ điều hành Linux, UNIX và Windows, cũng như các tài khoản bổ sung mà bạn sẽ cần để chạy các quy trình và các dịch vụ DB2 UDB khác nhau. Bài này cũng đánh giá mô hình an toàn DB2 UDB, bao gồm việc xác thực người dùng, ủy quyền của người dùng và nhóm, và các siêu người dùng. Bài này áp dụng cho Phiên bản 8.2 của DB2 UDB cho Linux, UNIX, và Windows; tuy nhiên, nhiều phần trong bài này cũng có thể áp dụng cho các phiên bản DB2 UDB cũ hơn. Về đầu trang Mô hình an toàn DB2 UDB Mô hình an toàn DB2 UDB gồm hai thành phần chính: xác thực và ủy quyền. Hình 1 đưa ra một tổng quan về mô hình an toàn DB2 UDB. Hình 1. Mô hình an toàn DB2 UDB
Xác thực Việc xác thực là quá trình xác nhận hợp lệ một mã định danh (ID) và mật khẩu đã cấp cho người dùng khi sử dụng một cơ chế an toàn. Việc xác thực người dùng và nhóm được quản lý trong một phương tiện ngoài thay cho DB2 UDB, như hệ điều hành, một trình điều khiển miền, hoặc một hệ thống an toàn Kerberos. Điều này khác với các hệ thống quản lý cơ sở dữ liệu khác (các DBMS), như Oracle và SQL Server, là ở đây các tài khoản người dùng có thể được định nghĩa và xác thực trong chính cơ sở dữ liệu đó, cũng như trong một phương tiện bên ngoài như hệ điều hành. Bất kỳ lúc nào cung cấp trực tiếp cho DB2 UDB một ID và mật khẩu người dùng như là một phần của một cá thể đính kèm hoặc yêu cầu kết nối cơ sở dữ liệu, DB2 UDB cố gắng xác nhận ID và mật khẩu người dùng đó bằng cách sử dụng phương tiện an toàn bên ngoài này. Nếu ID hoặc mật khẩu người dùng không được cung cấp kèm với yêu cầu, DB2 UDB ngầm sử dụng ID và mật khẩu người dùng đã được sử dụng để đăng nhập vào máy trạm, nơi tạo ra yêu cầu này. Giá trị của tham số AUTHENTICATION của cá thể DB2 UDB xác định vị trí xác thực thực tế. Các lược đồ xác thực khác nhau gồm những người dùng đã xác thực trên chính máy chủ DB2 UDB đó (bằng cách sử dụng phương tiện chức năng an toàn của máy chủ), trên máy khách (cho phép truy cập "đăng nhập một lần"), một phương tiện an toàn Kerberos, hoặc một trình cắm thêm GSS (Generic Security Service – Dịch vụ an toàn chung) do người dùng định nghĩa. Các tùy chọn xác thực bổ sung gồm khả năng mã hóa các tên và các mật khẩu người dùng, cũng như dữ liệu, khi chúng truyền trên mạng giữa máy khách và máy chủ. Giá trị mà bạn chọn cho tham số AUTHENTICATION tùy thuộc vào môi trường cụ thể của bạn cũng như các chính sách an toàn cục bộ. Để có một mô tả đầy đủ về các lược đồ xác thực khác nhau, hãy tham khảo Tài liệu DB2 UDB. (Xem phần Tài nguyên.) Ví dụ, Hình 1 cho thấy câu lệnh kết nối được một người dùng có tên là bob sử dụng để nối tới cơ sở dữ liệu finance (tài chính) bằng mật khẩu bobpsw. Có sáu bước xảy ra trong quá trình xác thực này: 1. Câu lệnh CONNECT được truyền đến máy chủ DB2 UDB. 2. Nếu vẫn chưa cấu hình trình cắm thêm an toàn, thì sẽ sử dụng trình cắm thêm mặc định. Khi tham số AUTHENTICATION của cá thể có chứa cơ sở dữ liệu finance được thiết lập là SERVER (thiết lập mặc định), phương tiện chức năng an toàn trên máy chủ DB2 UDB sẽ xác thực ID và mật khẩu người dùng được cấp trong yêu cầu kết nối. Trình cắm thêm mặc định sẽ gửi ID và mật khẩu người dùng tới hệ điều hành để xác nhận hợp lệ. 3. Hệ điều hành xác nhận xem liệu tổ hợp bob/bobpsw có hợp lệ hay không, và trả về thông tin này cho trình cắm thêm an toàn. 4. Trình cắm thêm an toàn gọi cơ chế an toàn DB2 UDB để truy vấn các bảng danh mục DB2 UDB cho người dùng bob để xem liệu người dùng có tên đó đã được cấp đặc quyền CONNECT với cơ sở dữ liệu đó chưa. Theo mặc định, đặc quyền CONNECT được cấp PUBLIC (CÔNG KHAI), có nghĩa là bất kỳ người dùng nào được xác thực thành công đều có thể kết nối tới cơ sở dữ liệu này. 5. Cơ chế an toàn DB2 UDB xác nhận hợp lệ người dùng bob, hoặc trả về một lỗi.
6. Trình cắm thêm an toàn trả về cho người dùng một thông báo thành công hay thất bại. Nếu người dùng không thể xác thực thành công, DB2 UDB từ chối yêu cầu kết nối và trả về một thông báo lỗi cho ứng dụng khách, tương tự như sau: Liệt kê 1. DB2 UDB trả về một thông báo cho ứng dụng này khi xác thực người dùng không thành công SQL30082N Attempt to establish connection failed with security reason "24" ("USERNAME AND/OR PASSWORD INVALID"). SQLSTATE=08001 Một mục nhập tương tự như sau cũng xuất hiện trong bản ghi nhật ký chẩn đoán DB2 UDB (db2diag.log) trên máy chủ DB2 UDB: Liệt kê 2. Thông báo trong bản ghi nhật ký chẩn đoán của DB2 khi xác thực người dùng không thành công 2005-07-09-16.18.33.546000-240 I729347H256 LEVEL: Severe PID : 3888 TID : 604 FUNCTION: DB2 Common, Security, Users and Groups, secLogMessage, probe:20 DATA #1 : String, 44 bytes check password failed with rc = -2146500502 Trên Windows, có thể tìm thấy bản ghi nhật ký chẩn đoán trong thư mục gốc Instance, theo mặc định là C:\Program Files\IBM\SQLLIB\DB2 . Trên UNIX, theo mặc định, bản ghi này đặt ở /DB2/db2dump, ở đây là đường dẫn của chủ sở hữu cá thể. Nếu bạn luôn gặp phải các thông báo này, hãy bảo đảm rằng người dùng hay ứng dụng nối đến cơ sở dữ liệu đã cung cấp một ID và mật khẩu người dùng hợp lệ. ID và mật khẩu người dùng này phải tồn tại trong phương tiện mà việc xác thực người dùng được thiết lập để diễn ra ở đó (được xác định bởi tham số AUTHENTICATION của cá thể DB2 UDB đích). Uỷ quyền Uỷ quyền là quá trình xác định thông tin truy cập và đặc quyền về các đối tượng và các hành động của cơ sở dữ liệu cụ thể đối với một ID người dùng đã cấp. DB2 UDB lưu trữ và duy trì thông tin ủy quyền người dùng và nhóm ở bên trong. Mỗi lần bạn gửi đi một lệnh, DB2 UDB thực hiện kiểm tra ủy quyền để đảm bảo rằng bạn có tập đặc quyền đúng để thực hiện hành động đó. Các đặc quyền có thể được cấp cho những người dùng cụ thể hoặc cho các nhóm người dùng. Thêm nữa, cả hai định nghĩa người dùng và định nghĩa nhóm tự chúng được định nghĩa bên ngoài DB2 UDB. Những người dùng là một thành viên của một nhóm tự động thừa hưởng các
đặc quyền của nhóm. Các đặc quyền cụ thể được cấp cho một người dùng có tiền lệ hơn các đặc quyền liên quan với bất kỳ (các) nhóm mà người dùng là một thành viên, và vẫn cứ tồn tại ngay cả khi sau đó người dùng bị loại khỏi (các) nhóm đó. Có nghĩa là, các đặc quyền trực tiếp đã cấp cho một người dùng phải trực tiếp bị hủy bỏ. Hầu hết các đối tượng cơ sở dữ liệu có một tập các đặc quyền liên quan có thể được gán cho những người dùng và các nhóm, bằng cách sử dụng các câu lệnh SQL GRANT (cấp) và REVOKE (hủy bỏ). Ví dụ, câu lệnh SQL dưới đây cấp đặc quyền SELECT (chọn) trên bảng có tên là ADM.ACCTABC cho một người dùng tên là bob: GRANT SELECT ON TABLE ADM.ACCTABC TO USER BOB Một khi ban hành câu lệnh này, người dùng bob có thể gửi đi các câu lệnh SELECT để tham khảo bảng này. Cũng vậy, câu lệnh SQL sau hủy bỏ đặc quyền INSERT (chèn) trên một khung nhìn (view) tên là ADM.LEGERS từ một nhóm có tên là clerks (các thư ký): REVOKE INSERT ON VIEW ADM.LEGERS FROM GROUP CLERKS Bạn chỉ có thể hủy bỏ một đặc quyền đã cấp trước đây. Để biết thông tin chi tiết về tất cả các đặc quyền của đối tượng cơ sở dữ liệu khác nhau, có thể được cấp cho những người dùng và các nhóm, hãy tham khảo tài liệu DB2 UDB (xem phần Tài nguyên). Điều quan trọng cần lưu ý, đặc biệt với những người mới dùng DB2 UDB, câu lệnh GRANT không kiểm tra sự tồn tại của một tài khoản người dùng hoặc tài khoản của nhóm trong phương tiện bên ngoài. Điều này có nghĩa là có thể cấp các đặc quyền cho các tài khoản người dùng và nhóm không tồn tại theo thông tin được lưu trữ trong cơ sở dữ liệu. Điều này gây ra cảm giác sai lầm rằng các tài khoản người dùng và nhóm có thể được định nghĩa trong DB2 UDB. Ví dụ, nếu bạn đưa ra câu lệnh sau trong khi kết nối tới cơ sở dữ liệu finance: GRANT SELECT ON TABLE ADM.TAXCODE TO USER XYZ ở đây xyz là bất kỳ chuỗi ký tự nào không ánh xạ tới một người dùng hiện có trong phương tiện an toàn bên ngoài, sau đó DB2 UDB sẽ hiển thị xyz trong các công cụ giao diện người dùng đồ họa (GUI) của nó hoặc trong một số các bảng danh mục, như được minh họa trong Hình 2. Điều này không có nghĩa là một người dùng tên là xyz tồn tại hoặc đã được tạo ra. Hình 2. Các đặc quyền bảng sau khi cấp các đặc quyền cho một người dùng không xác
định Phần dưới cùng của Hình 1 cho thấy một ví dụ về một kịch bản uỷ quyền. Người dùng có tên là bob, người trước đó đã kết nối thành công, bây giờ cố gắng thực hiện một câu lệnh SELECT trên bảng ADM.TAXCODES. DB2 UDB sẽ tìm trong các bảng danh mục của nó để xem liệu người dùng này đã được cấp phép với câu lệnh SELECT từ bảng này chưa. Do đặc quyền này trước đây được cấp cho bob, nên DB2 UDB cho phép tiếp tục thực hiện câu lệnh SELECT. Nếu người dùng không được uỷ quyền thực hiện một hoạt động đối với một đối tượng cụ thể, DB2 UDB từ chối hoạt động này và trả về một thông báo lỗi đến ứng dụng khách. Ví dụ, nếu người dùng bob đã cố INSERT (chèn) một hàng vào bảng ADM.TAXCODES, nhưng lại không có đủ các đặc quyền để làm như vậy, thông báo lỗi sau sẽ được trả về: Liệt kê 3. DB2 UDB trả về thông báo khi ủy quyền người dùng không thành công DB21034E The command was processed as an SQL statement because it was not a valid Command Line Processor command. During SQL processing it returned: SQL0551N "BOB" does not have the privilege to perform operation "INSERT" on object "ADM.TAXCODES". SQLSTATE=42501 Nếu bạn luôn gặp phải các thông báo tương tự, hãy bảo đảm rằng ID người dùng được đưa ra để nối tới cơ sở dữ liệu có các đặc quyền thích hợp để thực hiện hoạt động đích. Người dùng phải được cấp trực tiếp đặc quyền đó, là một phần của một nhóm đã được cấp đặc quyền đó, hoặc là một siêu người dùng.
Các siêu người dùng Có thể chọn các nhóm người dùng nào đó khi có các ủy quyền cá thể và cơ sở dữ liệu đặc biệt. DB2 UDB định nghĩa một hệ thống phân cấp về các ủy quyền siêu người dùng (SYSADM, SYSCTRL, SYSMAINT, SYSMON), mỗi ủy quyền có khả năng thực hiện một tập con các hoạt động quản trị ví dụ như tạo một cơ sở dữ liệu, bắt buộc những người dùng thoát khỏi hệ thống, và lấy một bản sao lưu cơ sở dữ liệu. Để biết một cuộc thảo luận đầy đủ về các mức ủy quyền, hãy tham khảo tài liệu DB2 UDB (xem phần Tài nguyên). Bạn có thể cấu hình các ủy quyền cá thể bằng cách sử dụng các tham số mức-cá thể có liên quan (SYSADM_GROUP, SYSCTRL_GROUP, SYSMAIN_GROUP, SYSMON_GROUP). Có thể thiết lập từng tham số theo tên của nhóm những người dùng (được định nghĩa bên ngoài của DB2 UDB) có thể có ủy quyền đó. Ví dụ, nếu bạn định nghĩa một nhóm có tên là snrdba chứa tất cả các tài khoản người dùng DBA cao cấp, bạn có thể tạo tất cả các siêu người dùng SYSADM của những người dùng này bằng cách thiết lập giá trị của tham số cá thể SYSADM_GROUP là snrdba, khi sử dụng các lệnh sau đây: Liệt kê 4. Cập nhật tham số cá thể SYSADM_GROUP UPDATE DBM CFG USING SYSADM_GROUP snrdba db2stop db2start Sau đó tất cả những người dùng trong nhóm snrdba sẽ có tất cả các đặc quyền liên quan đến mức ủy quyền SYSADM và do đó có thể thực hiện tất cả các nhiệm vụ quản trị đòi hỏi mức ủy quyền đó. Việc định nghĩa các ủy quyền theo cách này cho phép bạn phân biệt giữa các quản trị viên DB2 UDB và các quản trị viên hệ thống/mạng. Ví dụ, có thể một quản trị viên (DBA) được yêu cầu có đầy đủ ủy quyền quản trị trên cá thể DB2 UDB, nhưng không phải trên máy tính hoặc mạng cục bộ. Trong trường hợp này, có thể thêm tài khoản người dùng của DBA vào một nhóm không có các quyền truy cập đầy đủ vào hệ thống/mạng, nhưng có thể có các quyền truy cập đầy đủ vào cá thể DB2 UDB, bằng cách xác định tên nhóm đó trong tham số cá thể SYSADM_GROUP. Trong lúc cài đặt DB2 UDB mặc định trên Windows, các giá trị của các tham số ủy quyền siêu người dùng mức-cá thể này (SYSADM_GROUP, SYSCTRL_GROUP, SYSMAIN_GROUP, SYSMON_GROUP) mặc định tới NULL (bằng không). Điều này có nghĩa là ủy quyền siêu người dùng được cấp cho bất kỳ tài khoản hợp lệ nào thuộc về nhóm Administrators (các quản trị viên) cục bộ. Chúng tôi đánh giá cao đề nghị thay đổi trực tiếp giá trị của các tham số này theo các tên nhóm hợp lệ để ngăn chặn truy cập trái phép. Trên các bản cài đặt Linux và UNIX, việc này không phải là một mối quan tâm lớn, vì một giá trị NULL mặc định cho nhóm chính của chủ sở hữu cá thể, mà theo mặc định sau khi cài đặt chủ sở hữu cá thể chỉ gồm có ID người dùng của mình.
Cũng có thể gán cho những người dùng một tập các ủy quyền mức-cơ sở dữ liệu. Các ủy quyền cơ sở dữ liệu được cấp bằng cách sử dụng các câu lệnh SQL GRANT và REVOKE tiêu chuẩn. Có thể tìm thấy nhiều thông tin hơn về các mức ủy quyền cơ sở dữ liệu trong tài liệu DB2 UDB (xem phần Tài nguyên.) Các lệnh hệ thống DB2 UDB như db2, db2ilist, db2start, db2stop, db2iupdt và v.v.., là các lệnh có thể thực thi được của hệ điều hành. Vì vậy, cơ chế an toàn để chạy các lệnh này được dựa vào các quyền hạn của các tệp của hệ điều hành. Các quyền hạn của các tệp được thiết lập lúc cài đặt DB2 UDB. Về đầu trang Các quy tắc đặt tên tài khoản người dùng và nhóm của DB2 UDB Trong DB2 UDB, các tài khoản người dùng và nhóm phải tuân thủ các quy tắc đặt tên được mô tả trong Bảng 1 và 2. Các hạn chế này nằm ngoài bất kỳ các hạn chế nào có hiệu lực trong phương tiện ở đó định nghĩa các tài khoản. Bảng 1. Các giới hạn và các hạn chế bởi nền tảng Giới hạn Windows Linux/UNIX Độ dài tên Lên đến 30 ký Lên đến 30 ký tự nhóm tự Độ dài tên Lên đến 30 ký tự Lên đến 8 ký người dùng (1) (2) tự Không phân biệt Chỉ chữ Trường hợp dạng chữ thường (1) Windows NT®, Windows 2000®, Windows XP® và Windows Server® 2003 hiện đang có giới hạn thực tế là 20 ký tự. (2) Khi không sử dụng xác thực máy khách, các máy khách 32-bit không phải Windows đang nối với Windows NT, Windows 2000, Windows XP và Windows Server 2003 có hỗ trợ các tên người dùng dài hơn 8 ký tự khi tên và mật khẩu người dùng được quy định rõ ràng. Bảng 2 cho thấy các hạn chế đặt tên với tất cả các nền tảng. Bảng 2. Các hạn chế đặt tên cho tất cả các nền tảng Quy tắc Giá trị Các từ dành USERS, ADMINS, GUESTS, PUBLIC (3), riêng không LOCAL, hoặc bất kỳ từ SQL dành riêng nào được phép Các tên không IBM, SQL, SYS, một số hoặc một dấu gạch thể bắt đầu dưới bằng Các ký tự Các ký tự có trọng âm không được
phép Từ A đến Z (Khi sử dụng trong hầu hết các tên, các ký tự từ A đến Z được chuyển đổi từ chữ thường thành chữ hoa). Các ký tự được phép (4) 0 đến 9 ! % ( ) { } . - ^ ~ _ (dấu gạch dưới) 7 @, #, $, \ (dấu gạch chéo ngược) và khoảng trống (3) DB2 UDB sử dụng bên trong một nhóm-giả có tên là PUBLIC (công khai), có thể cấp và hủy bỏ các đặc quyền. Trên thực tế PUBLIC không phải là một nhóm được định nghĩa trong phương tiện an toàn ngoài. Đó là một cách để gán các đặc quyền cho bất kỳ người dùng nào đã xác thực thành công. (4) Cũng có thể sử dụng các ký tự đặc biệt khác, tùy thuộc vào hệ điều hành của bạn và ở đó bạn đang làm việc với DB2 UDB. Tuy nhiên, để tránh sự không nhất quán và các vấn đề tiềm năng, không sử dụng các ký tự đặc biệt khác này khi đặt tên các đối tượng trong cơ sở dữ liệu của bạn. Việc cài đặt DB2 UDB với các ID người dùng mặc định (ví dụ, db2admin) và cung cấp một mật khẩu yếu (hoặc không có gì cả) có thể đặt hệ thống của bạn vào nguy hiểm. Nhiều virus, sâu và những con ngựa thành trojan (trojan horses) của máy tính được thiết kế để khai thác mật khẩu yếu. Ví dụ, rất nhiều chương trình cố dùng các mật khẩu phổ biến như "password", "123456", "111111", "db2admin" và v.v.. để đạt được quyền truy cập vào hệ thống. Do đó, điều quan trọng không nên coi thường mật khẩu của bạn. Các mật khẩu cũng rất quan trọng khi xác thực những người dùng. Ví dụ, trên các hệ điều hành Linux và UNIX, các mật khẩu không xác định được xử lý là NULL (bằng không). Bất kỳ người dùng nào không có một mật khẩu xác định được coi là có mật khẩu NULL. Từ quan điểm của hệ điều hành, đây là một cuộc đấu và người dùng được xác nhận hợp lệ và có thể kết nối với cơ sở dữ liệu. Về đầu trang Một bản cài đặt DB2 UDB tạo ra và yêu cầu các tài khoản người dùng và nhóm Các môi trường cơ sở dữ liệu phân vùng Trong một môi trường cơ sở dữ liệu phân vùng có sử dụng tính năng phân vùng dữ liệu (DPF) của DB2 UDB, mỗi phân vùng cơ sở dữ liệu phải có cùng tập những người dùng và các nhóm được định nghĩa. Nếu các định nghĩa không giống nhau, người dùng có thể không được ủy quyền thực hiện các hành động cần thiết trên một số phân vùng. Tính nhất quán trên tất cả các phân vùng rất quan trọng. Một bản cài đặt DB2 UDB đòi hỏi một tài khoản người dùng có các quyền quản trị để thực hiện việc cài đặt. Người dùng này yêu cầu các đặc quyền cụ thể tùy thuộc vào nền tảng mà DB2 UDB đang được cài đặt trên đó. Theo mặc định, DB2 UDB tạo ra một số tài khoản người dùng và
nhóm trong lúc cài đặt. Các tài khoản này được sử dụng để "sở hữu" và khởi động các dịch vụ và quá trình DB2 UDB khác nhau đang chạy trên máy chủ. Trong phần này, chúng tôi mô tả các đặc quyền người dùng cần thiết để thực hiện một bản cài đặt DB2 UDB trong môi trường Windows, Linux, và UNIX. Chúng tôi cũng nêu bật các tài khoản người dùng và nhóm khác nhau được tạo trong một bản cài đặt DB2 UDB mặc định. Các tài khoản người dùng và nhóm cần thiết trên các hệ điều hành Microsoft Windows Nếu bạn đang cài đặt DB2 UDB trên các hệ điều hành Windows, bạn sẽ yêu cầu các tài khoản người dùng sau đây:  Tài khoản người dùng cài đặt.  Tài khoản người dùng DAS (DB2 Administration Server – Máy chủ quản trị DB2).  Tài khoản người dùng của chủ sở hữu cá thể DB2 UDB. Tài khoản người dùng cài đặt Trước khi chạy Trình hướng dẫn cài đặt DB2 (DB2 Setup wizard), bạn cần phải định nghĩa một tài khoản người dùng cài đặt. Tài khoản này có thể là một tài khoản người dùng hay miền cục bộ. Tài khoản phải thuộc nhóm Administrators trên máy tính thực hiện cài đặt này. Khi sử dụng các tài khoản miền, tài khoản cài đặt phải thuộc nhóm Domain Administrators (Các quản trị viên miền) trên miền ở đó các tài khoản người dùng thiết lập khác sẽ được tạo ra. Bạn cũng có thể sử dụng tài khoản LocalSystem dựng sẵn để chạy cài đặt này cho tất cả các sản phẩm ngoại trừ DB2 UDB Enterprise Server Edition (Ấn bản doanh nghiệp của máy chủ DB2 UDB). Bạn có thể định nghĩa các tài khoản người dùng khác trước lần cài đặt này, hoặc bạn có thể để cho Trình hướng dẫn cài đặt DB2 tạo chúng cho bạn. Tất cả các tên tài khoản người dùng phải tuân theo các quy tắc đặt tên hệ thống của bạn cũng như các quy tắc đặt tên của DB2 UDB. Tài khoản người dùng DAS Cần có một tài khoản cục bộ và miền để quản lý DAS (Máy chủ quản trị DB2). DAS là một dịch vụ đặc biệt hỗ trợ các công cụ GUI và trợ giúp các nhiệm vụ quản trị. DAS có một tài khoản người dùng đã gán dùng để để khởi động dịch vụ khi DB2 UDB được tải. Trong Trình hướng dẫn cài đặt DB2, một trong các màn hình (được hiển thị trong Hình 3) sẽ nhắc bạn chọn một tài khoản người dùng có thể được dùng để khởi động dịch vụ DAS.
Hình 3. Chỉ định tài khoản người dùng DAS trong Trình hướng dẫn cài đặt DB2 Bạn có thể tạo tài khoản người dùng này trước khi cài đặt DB2 UDB và chỉ rõ nó trong màn hình này, hoặc bạn có thể dùng Trình hướng dẫn cài đặt DB2 tạo nó cho bạn. Theo mặc định, trình hướng dẫn này tạo ra một tài khoản mới tên là db2admin (tuy vậy, bạn có thể đặt cho nó bất cứ tên nào bạn thích). Tài khoản người dùng DAS cũng phải thuộc nhóm Administrators trên máy tính ở đó bạn sẽ thực hiện cài đặt này. Nếu bạn muốn dùng Trình hướng dẫn cài đặt DB2 tạo một tài khoản người dùng miền mới, tài khoản người dùng mà bạn sử dụng để thực hiện cài đặt này phải có quyền tạo các tài khoản người dùng miền. Các quyền người dùng sau đây sẽ được cấp tự động cho tài khoản này khi nó được các trình hướng dẫn cài đặt tạo ra:  Làm thay một phần của hệ điều hành  Gỡ lỗi các chương trình  Tạo đối tượng mã thông báo  Tăng các hạn ngạch  Khóa các trang trong bộ nhớ  Đăng nhập là một dịch vụ  Thay thế một mã thông báo mức quy trình
Nếu bạn đã tạo hoặc quy định một tài khoản khác, hãy chắc chắn tài khoản đó cũng có các quyền người dùng nói trên. Để đảm bảo các quyền này được thiết lập đúng, mở Control Panel của Windows (Start > Settings > Control Panel) và nhấn đúp chuột vào biểu tượng Administrative Tools (Các công cụ quản trị). Nhấn đúp chuột vào biểu tượng Local Security Policy (Chính sách an toàn cục bộ). Đối với từng chính sách được liệt kê ở trên, đảm bảo rằng người dùng được bao gồm trong danh sách của những người dùng và các nhóm có ủy quyền. Việc cung cấp một mật khẩu không đúng sẽ làm cho một dịch vụ không tải được trong lúc khởi động DB2 UDB và có khả năng ngăn không cho bạn thực hiện một số hoạt động. Trong lúc cài đặt, bạn cũng có thể chỉ dẫn Trình hướng dẫn cài đặt DB2 sử dụng cùng một tài khoản này (tài khoản mà bạn đã chỉ định cho DAS) cho mình và khởi động tất cả các dịch vụ khác của DB2 UDB cũng được. Để làm điều này, hãy chắc chắn đánh dấu chọn hộp kiểm "Use the same user name and password for the remaining DB2 UDB services" (Sử dụng cùng một tên người dùng và mật khẩu cho các dịch vụ còn lại của DB2 UDB) (xem Hình 3). Nếu bạn bỏ dấu chọn của hộp này, trình hướng dẫn sẽ nhắc bạn chọn một tài khoản người dùng cho mình và khởi động cá thể mặc định đã tạo. Tất cả các dịch vụ DB2 UDB khác sẽ sử dụng tài khoản LocalSystem dựng sẵn của Windows để khởi động. Bạn cũng nên đảm bảo rằng tài khoản người dùng DAS có ủy quyền SYSADM trên từng hệ thống DB2 UDB trong môi trường của bạn, sao cho nó có thể khởi động hoặc dừng các cá thể khác khi cần thiết. Theo mặc định, sau khi cài đặt DB2 UDB trong môi trường Windows, bất kỳ người dùng nào, là một phần của Administrators, cũng có ủy quyền SYSADM. Tên dịch vụ DAS được gọi là DB2DAS - DB2DAS00. Tài khoản người dùng chủ sở hữu cá thể của DB2 UDB Cần phải có một tài khoản cục bộ và miền cho riêng mình và khởi động một cá thể DB2 UDB. Bạn có thể tạo tài khoản người dùng của chủ sở hữu cá thể DB2 UDB trước khi cài đặt DB2 UDB, hoặc bạn có thể dùng Trình hướng dẫn cài đặt DB2 tạo nó cho bạn. Nếu bạn muốn dùng Trình hướng dẫn cài đặt DB2 tạo một tài khoản người dùng miền mới cho bạn, khi bạn thực hiện lần cài đặt này bạn phải sử dụng một tài khoản người dùng có ủy quyền để tạo các tài khoản người dùng miền. Tài khoản người dùng cũng phải thuộc nhóm Administrators trên máy tính mà bạn sẽ thực hiện lần cài đặt này. Các quyền người dùng sau sẽ được cấp tự động cho tài khoản này khi được Trình hướng dẫn cài đặt DB2 tạo:  Làm thay một phần của hệ điều hành  Gỡ lỗi các chương trình  Tạo đối tượng mã thông báo  Tăng các hạn ngạch  Khóa các trang trong bộ nhớ  Đăng nhập là một dịch vụ  Thay thế một mã thông báo mức quy trình Nếu bạn đã tạo hoặc quy định một tài khoản khác, hãy chắc chắn tài khoản đó cũng có các quyền người dùng nói trên. Để đảm bảo các quyền này được thiết lập đúng, mở Control Panel của Windows (Start > Settings > Control Panel) và nhấn đúp chuột vào biểu tượng Administrative
Tools. Nhấn đúp chuột vào biểu tượng Local Security Policy. Đối với từng chính sách được liệt kê ở trên, đảm bảo rằng người dùng được bao gồm trong danh sách của những người dùng và các nhóm có ủy quyền. Việc cung cấp một mật khẩu không đúng sẽ làm cho một dịch vụ không tải được trong lúc khởi động DB2 UDB và có khả năng ngăn không cho bạn thực hiện một số hoạt động. Trong một bản cài đặt mặc định của Windows, một cá thể có tên là DB2 được tạo ra tự động. Bạn có thể tạo ra các cá thể khác hoặc loại bỏ các cá thể hiện có bằng cách sử dụng các tiện ích tương ứng là db2icrt và db2idrop. Có thể tìm thấy các tiện ích này trong thư mục DB2PATH\sqllib\bin, ở đây DB2PATH DB2PATH là nơi bạn đã cài đặt DB2 UDB. Để chạy các tiện ích này, bạn phải sử dụng một tài khoản người dùng có ủy quyền Administrator cục bộ. Nếu bạn đưa ra một tài khoản và mật khẩu người dùng làm các tham số khi bạn tạo ra cá thể này, nó sẽ sử dụng tài khoản người dùng đó cho riêng mình và khởi động dịch vụ. Nếu bạn không cung cấp một tài khoản và mật khẩu người dùng, tài khoản LocalSystem sẽ được sử dụng để thay thế. Ví dụ, lệnh sau đây tạo ra một cá thể mới gọi là devinst, và gán tài khoản LocalSystem cho riêng nó và khởi động quy trình cá thể: Liệt kê 5. Tạo một cá thể DB2 UDB mới trong Windows db2icrt devinst Thay đổi thông tin tài khoản Ngoài ra, khi bắt đầu với Phiên bản 8.2 của DB2 UDB, bạn có thể sử dụng tài khoản LocalSystem (LSA) dựng sẵn để khởi động một dịch vụ DB2 UDB. Việc sử dụng LSA có thể thuận lợi trên các hệ thống ở đó bắt tuân thủ các chính sách mật khẩu nghiêm ngặt, vì LSA không liên kết với một mật khẩu. Ví dụ, trong một số môi trường, những người dùng buộc phải thay đổi các mật khẩu của họ hai tháng một lần, hoặc tài khoản của họ tạm thời bị khóa. Do đó, một chính sách như vậy sẽ đòi hỏi phải thay đổi mật khẩu cho tài khoản người dùng được chỉ định để khởi động các dịch vụ DB2 UDB. Nếu tài khoản người dùng được cấu hình để khởi động các dịch vụ trở nên bị khóa, hoặc tài khoản người dùng đã thay đổi mật khẩu, nhưng chưa được cập nhật trong các thuộc tính khởi động dịch vụ, thì các dịch vụ đó sẽ không thể khởi động được. Trước khi chuyển đổi bất kỳ các dịch vụ DB2 UDB nào từ một tài khoản người dùng dành riêng sang tài khoản LocalSystem, bạn nên cân nhắc là tài khoản LocalSystem không thể truy cập vào các phần chia sẻ trên LAN được, vì không thể xác thực nó trên máy tính khác. Do đó, bạn phải đảm bảo rằng hệ thống DB2 UDB của bạn không có bất kỳ tài nguyên tệp nào của nó trên máy tính khác. Các ứng dụng chạy trong ngữ cảnh của tài khoản LocalSystem (LSA) sử dụng các kết nối DB2 UDB ngầm cục bộ. Nếu bạn đang phát triển một ứng dụng sẽ chạy trong tài khoản này, nên hiểu rõ rằng DB2 UDB có các hạn chế trên các đối tượng có các tên lược đồ bắt đầu bằng "SYS". Nếu các ứng dụng của bạn có chứa các câu lệnh tạo các đối tượng DB2 UDB, cần phải viết chúng như sau:
 Đối với SQL tĩnh, cần kết buộc chúng với một giá trị cho các tùy chọn QUALIFIER khác với giá trị mặc định.  Đối với SQL động, các đối tượng được tạo ra cần có đủ điều kiện rõ ràng với một tên lược đồ được DB2 UDB hỗ trợ, hoặc phải thiết lập thanh ghi CURRENT SCHEMA (lược đồ hiện tại) cho một lược đồ. Hình 4 cho thấy một danh sách của một số các quá trình DB2 UDB đang chạy trên một hệ thống DB2 UDB đang hoạt động. Như bạn có thể thấy, mỗi quy trình có liên quan với một chủ sở hữu (tên người dùng). Để có một mô tả về tất cả các quy trình liên kết với DB2 UDB, hãy tham khảo "Tất cả mọi thứ bạn muốn biết về các quy trình cơ sở dữ liệu phổ biến của DB2" (developerWorks, 04. 2003). Hình 4. Xem các quy trình DB2 UDB đang chạy Để thay đổi tài khoản người dùng đang được dùng để khởi động một dịch vụ DB2 UDB, hãy mở ô Services (Start > Settings > Control Panel > Administrative Tools > Services). Nhấn chuột phải vào một dịch vụ DB2 UDB để xem các đặc tính của nó. Nhấn vào thẻ Log On ở trên cùng của cửa sổ Service properties (Các thuộc tính dịch vụ) (Hình 5). Trong thẻ này, bạn có thể chỉ rõ tài khoản người dùng mà bạn muốn dịch vụ sử dụng khi khởi động nó, hoặc bạn có thể chỉ định LSA. Nhấn vào OK để lưu lại các lựa chọn của bạn và đóng cửa sổ các thuộc tính cho dịch vụ đó.
Hình 5. Cửa sổ Các đặc tính đăng nhập dịch vụ DAS Nói chung, bạn nên sử dụng một tài khoản người dùng riêng biệt và dễ định danh để khởi động các dịch vụ DB2 UDB. Tuy nhiên, nếu các tài khoản người dùng được kiểm soát chặt chẽ hơn trong môi trường của bạn, bạn có tùy chọn sử dụng các tài khoản người dùng hiện có hoặc sử dụng tài khoản LocalSystem để khởi động các dịch vụ này. Sau khi thiết lập một tài khoản để chạy một dịch vụ, không thể xóa được tài khoản đó hoặc trái lại các dịch vụ khác có liên quan đến tài khoản đó sẽ không khởi động được. Điều này đúng ngay cả khi bạn tạo lại tài khoản bằng cách sử dụng cùng một tên. Trong các trường hợp như vậy, bạn phải chuyển vào ô các dịch vụ bằng thủ công như đã mô tả trước đây và cấu hình lại tài khoản người dùng được sử dụng để khởi động dịch vụ. Các nhóm DB2USERS và DB2ADMNS Khi bắt đầu với phiên bản 8.2 của DB2 UDB, tính năng an toàn bổ sung được thêm vào DB2 UDB trong môi trường Windows. Một tùy chọn mới tồn tại như là một phần của bản cài đặt DB2 UDB để tạo hai nhóm bổ sung trong hệ điều hành, đó là, DB2USERS và DB2ADMNS. Một khi đã tạo các nhóm này, chỉ các tài khoản người dùng là các thành viên của các nhóm này mới có quyền truy cập các tệp DB2 UDB trên hệ thống (bao gồm các lệnh cũng như các tệp dữ liệu người dùng được DB2 UDB tạo ra).
Có thể tùy chỉnh các tên nhóm này, nhưng bạn nên chấp nhận các tên mặc định nếu có thể. Nếu có một xung đột với các tên nhóm hiện có, bạn sẽ được nhắc thay đổi các tên nhóm. Nếu bạn không chọn tùy chọn này trong lúc cài đặt DB2 UDB ban đầu, bạn luôn có thể chạy nó sau này bằng cách chạy chương trình db2secv82.exe. Có thể tìm thấy chương trình này trong thư mục DB2PATH\SQLLIB\BIN\ , ở đây DB2PATH là nơi đã cài đặt DB2 UDB. Bạn nên chạy tùy chọn này để bảo vệ máy chủ của bạn ở mức cao nhất. Hình 6 cho thấy kết quả của việc đã chạy tính năng an toàn bổ sung này. Bây giờ tất cả các thư mục DB2 UDB trên hệ thống tệp của máy chủ đòi hỏi những người dùng là thành viên của một trong hai nhóm này có quyền truy cập các thư mục và các tệp DB2 UDB. Hình 6. Các quyền hạn của thư mục khi chạy tính năng an toàn mới của Windows
Một khi bạn chạy tính năng an toàn bổ sung bằng cách sử dụng lệnh db2secv82.exe, bạn có hai lựa chọn thoát khỏi nó:  Chạy lại lệnh db2secv82.exe ngay lập tức MÀ KHÔNG thực hiện bất kỳ các thay đổi bổ sung nào vào hệ thống. Nếu đã thực hiện bất kỳ các thay đổi nào với hệ thống, bạn phải sử dụng tùy chọn tiếp theo.  Thêm nhóm EVERYONE vào các nhóm DB2ADMNS và DB2USERS. Khi chạy tính năng an toàn mở rộng, biến đăng ký DB2_EXTSECURITY của DB2 UDB được thiết lập là YES. Việc này ra lệnh cho DB2 UDB kiểm tra tính năng an toàn bổ sung cần thiết từ phần của nó. Nếu bạn thay đổi giá trị DB2_EXTSECURITY là NO sau khi tạo các nhóm DB2ADMNS và DB2USERS các quyền hạn với các tệp và các thư mục sẽ vẫn được các nhóm này sở hữu; tuy nhiên, DB2 UDB sẽ không thực hiện kiểm tra tính năng an toàn bổ sung. Về đầu trang Các tài khoản người dùng và nhóm cần thiết trên các hệ điều hành Linux và UNIX Xem xét NIS/NIS+ Nếu sử dụng phần mềm NIS/NIS+ hoặc phần mềm an toàn tương tự trong môi trường của bạn, bạn phải tạo các tài khoản người dùng và nhóm cần thiết của DB2 UDB bằng cách thủ công trước khi bạn cài đặt DB2 UDB. Hãy tham khảo chủ đề NIS trong tài liệu DB2 UDB (xem phần Tài nguyên) trước khi bạn bắt đầu. Trong các hệ điều hành Linux và UNIX, một số tài khoản người dùng và nhóm thường cần dùng để cài đặt và hoạt động DB2 UDB:  Tài khoản người dùng cài đặt  Tài khoản người dùng DAS (Máy chủ quản trị của DB2)  Tài khoản người dùng chủ sở hữu cá thể DB2 UDB  Tài khoản người dùng thường trình có rào chắn DB2 UDB Theo mặc định, Trình hướng dẫn cài đặt DB2 tạo ra các tài khoản người dùng và nhóm này tự động trong lúc cài đặt máy chủ DB2 UDB. Ngoài ra, bạn có thể chỉ định một tài khoản người dùng hiện có trong lúc cài đặt. Tài khoản người dùng cài đặt Bạn phải cài đặt DB2 UDB bằng cách sử dụng tài khoản "root" (chủ). Đây là tài khoản người dùng duy nhất có đủ các đặc quyền để thực hiện cài đặt. Tài khoản người dùng của chủ sở hữu cá thể Một cá thể DB2 UDB được tạo ra trong thư mục chủ của chủ sở hữu cá thể. Tài khoản người dùng này kiểm soát tất cả các quy trình DB2 UDB và sở hữu tất cả các hệ thống tệp và các thiết
bị do các cơ sở dữ liệu chứa trong cá thể đó sử dụng. ID người dùng mặc định được sử dụng cho chủ sở hữu cá thể DB2 UDB trong một bản cài đặt DB2 UDB là db2inst1, và nhóm mặc định là db2iadm1. Nếu tên người dùng đã tồn tại, Trình hướng dẫn cài đặt DB2 gắn thêm một số từ 1 đến 99 vào tên người dùng mặc định, cho đến khi có thể tạo ra một ID người dùng chưa có. Ví dụ, nếu những người dùng db2inst1 và db2inst2 đã có trong cài đặt DB2 UDB mới, trình hướng dẫn tạo người dùng db2inst3. Nếu người dùng này đã tồn tại, trình hướng dẫn tiếp tục việc tìm kiếm của mình (db2inst4, db2inst5 và v.v..) cho đến khi nó tìm được một người dùng có thể dùng được. Thuật toán đặt tên này cũng được áp dụng cho việc tạo ra tài khoản người dùng có rào chắn và tài khoản người dùng của trình ứng dụng quản trị DB2. Một cách thực hành tốt là hạn chế tài khoản người dùng của chủ sở hữu cá thể là thành viên của nhóm chủ sở hữu cá thể duy nhất, và không sử dụng nó trong bất kỳ nhóm khác nào. Điều này giúp kiểm soát số lượng tài khoản người dùng và các nhóm, có thể thay đổi cá thể, hoặc bất kỳ đối tượng nào trong cá thể đó. Trong một bản cài đặt Linux hoặc UNIX mặc định, bạn có tùy chọn tạo một cá thể như là một phần của quy trình cài đặt. Bạn cũng có thể tạo các cá thể khác hoặc loại bỏ các cá thể hiện có sau này, bằng cách sử dụng các tiện ích tương ứng là db2icrt và db2idrop. Có thể tìm thấy các tiện ích này trong thư mục DB2PATH/instance, ở đây DB2PATH biểu thị /usr/opt/db2_08_01 trên AIX, và /opt/IBM/db2/V8.1 trên tất cả các hệ thống dựa trên UNIX và Linux khác. Để chạy các tiện ích này, bạn phải sử dụng tài khoản người dùng gốc. Khi tạo một cá thể mới trong Linux và UNIX bằng tiện ích db2icrt, bạn phải chỉ định tài khoản người dùng có rào chắn liên quan đến cá thể đó. Tên cá thể bạn chọn phải ánh xạ tới tên tài khoản người dùng là chủ sở hữu cá thể. Ví dụ, nếu một tài khoản người dùng hiện có là prodinst là chủ sở hữu của cá thể mới, bạn sẽ chỉ định prodinst làm tên cá thể trong lệnh db2icrt. Cá thể sẽ được tạo ra trong thư mục chủ của người dùng sở hữu cá thể. Ví dụ, lệnh sau đây tạo ra một cá thể mới tên là devinst, do tài khoản người dùng devinst sở hữu, và sử dụng tài khoản người dùng hiện có tên là devfenc cho tài khoản người dùng có rào chắn: Liệt kê 6. Tạo một cá thể DB2 UDB mới trong Linux và UNIX db2icrt -u devfenc devinst DB2 UDB không hỗ trợ tài khoản root hoạt động trực tiếp là một quản trị viên cơ sở dữ liệu. Bạn nên sử dụng lệnh su - để chuyển sang tài khoản (chủ sở hữu cá thể) của quản trị viên cơ sở dữ liệu. Tài khoản người dùng DAS Sử dụng tài khoản người dùng cho DAS (Trình ứng dụng chủ quản trị DB2) để chạy quy trình DAS trên hệ thống. ID người dùng mặc định được tạo trong quá trình cài đặt mặc định là dasusr1 và ID nhóm mặc định là dasadm1. Tài khoản DAS cũng được các công cụ GUI của DB2 UDB sử dụng để thực hiện các nhiệm vụ quản trị đối với các cá thể và các cơ sở dữ liệu của máy chủ cục bộ. Chỉ cần một DAS cho mỗi máy. Nó có thể quản lý tất cả các cá thể được định nghĩa
trên máy chủ. Tài khoản người dùng DAS phải khác với tài khoản người dùng của chủ sở hữu cá thể. Một khi khởi động quá trình DAS bằng tài khoản này, cũng phải dừng nó bằng tài khoản này. Vì vậy, trong Linux và UNIX, bạn phải sử dụng lệnh su - để chuyển sang tài khoản người dùng DAS để khởi động và dừng quá trình DAS. Tài khoản người dùng có rào chắn Tài khoản người dùng có rào chắn được sử dụng để chạy các hàm do người dùng định nghĩa (UDF) và các thủ tục đã lưu bên ngoài vùng địa chỉ (bộ nhớ) do máy DB2 UDB sử dụng. Đôi khi, nếu một thủ tục hoặc hàm không ổn định hoặc đang được thử nghiệm, nó sẽ được định nghĩa là FENCED (có rào chắn) sao cho có thể chạy nó trong vùng địa chỉ của quá trình của nó. Theo cách này, nếu chức năng hoặc thủ tục bị sự cố hoặc chấm dứt bất thường, nó sẽ không ảnh hưởng đến bất kỳ các quá trình cá thể nào khác. Tài khoản người dùng mặc định được tạo cho người dùng có rào chắn là db2fenc1 và nhóm mặc định là db2fadm1. Vì các lý do an toàn, chúng tôi khuyên bạn không sử dụng tài khoản chủ sở hữu cá thể cho tài khoản người dùng có rào chắn. Nếu bạn không cần mức an toàn này -- ví dụ, nếu bạn đang chạy trong một môi trường thử nghiệm, hoặc bạn không có kế hoạch sử dụng các UDF có rào chắn hoặc các thủ tục đã lưu -- bạn có thể sử dụng tài khoản chủ sở hữu cá thể thay vì tạo ra một tài khoản người dùng . Khi tạo ra các cá thể mới, các tài khoản người dùng có rào chắn phải được xác định như là một phần của lệnh tạo cá thể (db2icrt ... -u ). Thiết lập môi trường DB2 UDB cho những người dùng Linux và UNIX Kiểm tra vị trí đường dẫn DB2 UDB Sử dụng lệnh which db2 để đảm bảo rằng đường dẫn tìm kiếm của bạn đã được thiết lập đúng. Điều này đặc biệt quan trọng khi bạn có nhiều cá thể đang chạy trên cùng một máy chủ. Lệnh này sẽ trả về đường dẫn tuyệt đối có thể thực hiện được của bộ xử lý dòng lệnh (CLP). Kiểm tra xem nó có được đặt trong thư mục sqllib của cá thể đúng không. Các môi trường Linux và UNIX bắt tuân thủ an toàn chắc chắn ở mức người dùng; các tệp và các quá trình liên kết với một tài khoản người dùng không thể truy cập trực tiếp bởi người dùng khác. Theo mặc định, khi tạo một cá thể DB2 UDB mới, một kịch bản lệnh của môi trường DB2 UDB đặc biệt được gọi là db2profile cũng được thêm vào hồ sơ hệ thống của chủ sở hữu cá thể, để cho kịch bản lệnh này được chỉ rõ nguồn gốc mỗi khi chủ sở hữu cá thể đăng nhập vào hệ thống. Các kịch bản lệnh này thiết lập quyền truy cập vào môi trường cơ sở dữ liệu và cho phép chủ sở hữu cá thể thực hiện các lệnh DB2 UDB. Để những người dùng khác trên hệ thống có quyền truy cập đến cá thể đó và môi trường DB2 UDB, chúng cũng phải chạy các kịch bản lệnh tương tự. Một cách để làm điều này là "chỉ rõ nguồn gốc" cho tệp .profile của chủ sở hữu cá thể DB2 UDB (hoặc tệp .profile đó tham khảo tệp db2profile). Nếu bạn đang sử dụng trình bao (shell) Bourne hoặc Korn, bạn có thể chỉnh sửa tệp .profile của một tài khoản người dùng đích sao cho kịch bản lệnh db2profile chạy tự động khi người dùng đăng nhập vào hệ thống. Đối với người dùng trình bao C, bạn có thể chỉnh sửa tệp .login sao cho nó chạy tệp kịch bản db2shrc. Để chọn cá thể bạn muốn sử dụng, thêm một trong các câu sau đây vào tệp kịch bản lệnh .profile
hoặc .login, hoặc ban hành các câu lệnh từ một cửa sổ đầu cuối ở đó người dùng cần truy cập DB2 UDB từ (lưu ý cần có period (.) và khoảng trống):  với trình bao Bourne hoặc Korn: . INSTHOME/sqllib/db2profile  với trình bao C: source INSTHOME/sqllib/db2cshrc ở đây INSTHOME là thư mục chủ của cá thể bạn muốn sử dụng. Đối với những người dùng có một phiên bản kịch bản lệnh tùy chỉnh trong thư mục chủ của họ:  với trình bao Bourne hoặc Korn: . USERHOME/db2profile  với trình bao C: source USERHOME/db2cshrc ở đây USERHOME là thư mục chủ của người dùng. Nếu bạn muốn làm việc với nhiều hơn một cá thể cùng lúc, hãy chạy kịch bản lệnh cho từng cá thể mà bạn muốn sử dụng trong các cửa sổ thiết bị đầu cuối riêng biệt. Về đầu trang Tài khoản người dùng của trình lịch biểu Tài khoản người dùng của trình lịch biểu là cần thiết khi chạy các phương tiện tạo lịch của DB2 UDB. Tài khoản này được trình lịch biểu DB2 UDB sử dụng để kết nối với cơ sở dữ liệu danh mục của các công cụ khi nó lưu trú trên một máy chủ ở xa. Cơ sở dữ liệu danh mục của các công cụ chứa tất cả các siêu dữ liệu về các nhiệm vụ được tạo lịch để chạy trên máy chủ DB2 UDB (ví dụ, một nhiệm vụ sao lưu được tạo lịch để chạy mỗi Chủ nhật một lần lúc 1:00 am). Các phương tiện tạo lịch biểu được thiết kế để cho cơ sở dữ liệu danh mục của các công cụ không cần phải lưu trú trên cùng một cùng máy chủ DB2 UDB mà ở đó các nhiệm vụ được tạo lịch để chạy. Trong trường hợp này, trình lịch biểu trên máy chủ DB2 UDB cần kết nối với cơ sở dữ liệu danh mục của các công cụ để lấy ra bất kỳ thông tin cần thiết nào về các nhiệm vụ được chạy. Tài khoản trình lịch biểu được các tham số cấu hình SCHED_USERID điều khiển. Tham số này chỉ thích hợp nếu cơ sở dữ liệu danh mục các công cụ không nằm trên cùng một máy tính như máy chủ quản trị DB2. Bạn có thể xem giá trị của tham số này bằng cách ban hành lệnh db2 get admin cfg. Để thay đổi giá trị của tham số này, bạn có thể dùng lệnh db2admin setschedid ở đây và là ID và mật khẩu người dùng mà bạn cần trình lịch biểu sử dụng để kết nối với cơ sở dữ liệu danh mục của các công cụ từ xa. Liệt kê 7 cho thấy các kết quả sau khi thiết lập ID của trình lịch biểu với một giá trị là xtradba.
Liệt kê 7. Một danh sách của các tham số DAS và giá trị của chúng có thể cấu hình được C:\>db2 get admin cfg Admin Server Configuration Authentication Type DAS (AUTHENTICATION) = SERVER_ENCRYPT DAS Administration Authority Group Name (DASADM_GROUP) = DAS Discovery Mode (DISCOVER) = DISABLE Name of the DB2 Server System (DB2SYSTEM) = TEDWAS Java Development Kit Installation Path DAS (JDK_PATH) = C:\Program Files\IBM\SQLLIB\java\jdk\ Java Development Kit Installation Path DAS (JDK_64_PATH) = DAS Code Page (DAS_CODEPAGE) = 0 DAS Territory (DAS_TERRITORY) = 0 Location of Contact List (CONTACT_HOST) = Execute Expired Tasks (EXEC_EXP_TASK) = NO Scheduler Mode (SCHED_ENABLE) = ON SMTP Server (SMTP_SERVER) = Tools Catalog Database (TOOLSCAT_DB) = TOOLSDB Tools Catalog Database Instance (TOOLSCAT_INST) = DB2 Tools Catalog Database Schema (TOOLSCAT_SCHEMA) = TOOLSDB Scheduler User ID = xtradba Kết luận Bài này đã xem xét các tương tác chính của DB2 UDB với các tài khoản người dùng và nhóm. Nó đã tóm tắt cách DB2 UDB thực hiện xác thực người dùng và ủy quyền người dùng/nhóm, cũng như cách định nghĩa siêu người dùng cho một cá thể DB2 UDB. Bạn đã tìm hiểu về các tài khoản người dùng và nhóm mặc định được yêu cầu và/hoặc tạo một bản cài đặt DB2 UDB và cách cấu hình chúng. Với hiểu biết tốt hơn về cách các tài khoản người dùng và nhóm tương tác