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 nhóm Lên đến 30 ký tự Lên đến 30 ký tự Độ dài tên người dùng Lên đến 30 ký tự (1) (2) Lên đến 8 ký tự Trường hợp Không phân biệt dạng chữ Chỉ 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 riêng không được phép USERS, ADMINS, GUESTS, PUBLIC (3), LOCAL, hoặc bất kỳ từ SQL dành riêng nào Các tên không thể bắt đầu bằng IBM, SQL, SYS, một số hoặc một dấu gạch dưới Các ký tự không được Các ký tự có trọng âm phép Các ký tự được phép (4) 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). 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 t