Xác thực người dùng và tên ( User authentication and Names)

Chức năng bảo mật cơ bản trong mô hình bảo mật của Domino là xác thực người dùng ( bao gồm Notes clients, các domino server khác, browser và Internet client, và các chương trình phát triển sử dụng Notes API). Trong phần này tôi sẽ nói với các bạn về phần tổng quan xác thực, đặt tên phân cấp người dùng và máy chủ.

Khi một người dùng được xác định là "xác thực", server dựa trên sự hợp lệ của user name để điều khiển truy cập với Server và Database Access Controll Lists.

Trong phần này tôi cũng giới thiệu tổng quan về phân chia tổ chức của bạn ( Organization) thành các đơn vị chức năng ( Organization Unit - OU). OU Certificate ID được tạo từ ID gốc của tổ chức, sau đó được sử dụng để đăng ký người dùng và server

-----> Phần này có một chút tới kiến thức LDAP hoặc AD

ID file được tạo trong suốt quá trình setup first Domino Server

Bạn có thể không nhận ra trong quá trình cài đặt First Server, là bạn đã cài đặt một hệ thống bảo mật cơ bản.

Sử dụng tên của Organization bạn nhập vào, quá trình cài đặt tạo ra duy nhất một Organization Certificate ( chuỗi 1024 bit bao gồm số và ký tự) cho Organization. Được xác định bởi tên, ví dụ "O=VSD"

Cùng với các thông tin khác, quá trình cài đặt thêm Organization Certificate vào Organization Certifier ID file có tên là CERT.ID

Server Setup sử dụng CERT ID để tạo ID cho server và Administrator

Các thông tin về máy chủ và người dùng được thêm vào mỗi file ID, tất cả các file này được đánh dấu hai thứ từ Organization Certifier:

• Tên của Organization, ví dụ "VSD", được nối thêm vào phần tên của server và tài khoản người dùng ( đôi khi còn được gọi là tên phân biệt - Disinguished name).
• Organization Certificate

Chú ý: trong bài hướng dẫn cài đặt lần trước, tôi đã tạo luôn Organization Unit (OU), nên tên của máy chủ và người dùng có dạng CN=Mail/OU=NN/O=COM, CN=ADMIN/OU=NN/O=COM

Nội dung của file ID

Để xem được nội dung của file ID Server hoặc ID User, bật giao diên Domino Administrator lên, di chuyển tới tab chức năng Configuration, chọn Certification\ ID Properties, chọn file ID cần xem

Tab Your Certificate bạn có thể thấy các certficate được thêm vào file ID.
Hình dưới đây thể hiện các thành phần có trong file ID

Bảng dưới đây mô tả hình ảnh trên

Thành phần	Chức năng
User Name	Tên ( người dùng, máy chủ) để Domino quản lý và kiểm tra bảo mật database
Password	Nhấp vào tab Security Basics, nhấp chuột vào Change Password, để thay đổi mật khẩu. Độ khó của mật khẩu được thiết lập lúc đăng ký, và người dùng có thể thay đổi mật khẩu của họ miễn là mật khẩu đủ mạnh. Nếu mật khẩu không đủ mạnh, bạn sẽ gặp một thông báo là nhập một mật khẩu khác mạnh hơn. Người quản trị có thể yêu cầu ( thông qua cài đặt trong Domino Directory) mật khẩu User ID thay đổi trong khoảng thời gian hoặc người dùng bị khóa bởi máy chủ
Expiration Date	Theo mặc định, certificate của Server ID có thời hạn là 100 năm, User ID có thời hạn là 2 năm. Khi bạn đăng ký hoặc gia hạn ID file, bạn có thể thay đổi các thời hạn khác nhau.
Recovery Password(s)	Đây là một lựa chọn phục hồi lại mật khẩu, được thêm vào bởi người quản trị khi mở User ID file nếu quên mật khẩu. Việc khôi phục này, chỉ áp dụng nới Notes User ID và không áp dụng với Server ID, trong trường hợp khác, bạn có thể cấu hình Notes User ID Vault để nhanh chóng khôi phục lại ID và mật khẩu bị mất.
Notes Certificates	Bao gồm 2 certificate, (Notes Multi-purpose, Notes international encryption) và còn lại là certificate từ Certifier : Một từ Organization Certifier.(CERT.ID) Một từ mọi OU certifier (OU.ID) Mỗi certificate gồm có: Tên của Organization hoặc Organization Unit certifier được sử dụng để cấp phát certificate Tên của người dùng hoặc máy chủ mà certificate được cấp phát Private Key và Public key Chữ ký số của certifier để chứng minh quá trình xác thực của Notes Certificate Ngày hết hạn khi certificate không còn hợp lệ
Public Key	Một khóa mã hóa duy nhất được lưu trữ trong file ID, sử dụng trong suốt quá trình xác thực, mã hóa mail gửi tới các Notes Client khác và được lưu trong mail database của người dùng. Public Key có thể được sao chép, gửi mail từ User Security >Your Certificate, hoặc sao chép từ tài liệu user’s Person trong Domino Directory
Private Key	Một khóa mã hóa duy nhất cho người dùng, và được lưu trữ chỉ trong file User ID. Khóa này không thể xem được. Khóa Private được sử dụng để valid người dùng trong quá trình xác thực, cũng có thể dùng: Giải mã mail đã được mã hóa khớp với Public Key Mã hóa mail gửi tới Notes User. Chú ý : Nếu mất User ID và không có bản backup, tất cả các mail đã được mã hóa sẽ không thể được giải mã bởi vì User ID mới có chứa Private Key mới.
Document Encryption Keys	Các khóa mã hóa sử dụng để mã hóa và giải mã document fields. Ví dụ, HR database cho phép người dùng đọc các thông tin tổng quan về người lao động, nhưng trường Salary được mã hóa và chỉ một số người trong công có chìa khóa mã hóa để mã hóa và giải mã trường này.
Internet Certificates	Một option, chứng chỉ X.509 sử dụng để mã hóa với Web server, xác thực user name, mã hóa mail gửi tới internet user. Chứng chỉ này được thêm vào sau khi người dùng được đăng ký.

.

Server ID file: Có mật khẩu hay không có mật khẩu?

Có hay không mật khẩu cho server id file là một chủ đề lớn cần tranh luận. Theo mặc định, server id file không có mật khẩu, điều này làm giảm khả năng bảo mật. Đặt mật khẩu cho server id file  tạo cho server bảo mật hơn và bảo vệ những databases đã được mã hóa. Nhưng bên cạnh đó, bạn phải luôn thường trực tại server khi bạn khởi động nó, thậm chí Domino server khởi động như windows services ( Khà khà, không chạy đi đâu được, vì phải gõ mật khẩu cho file ID Server, thì domino server mới bật lên được).
Để được tốt nhất cả về sự thuận tiện và bảo mật, bạn cần cài đặt thêm một công cụ của hãng thứ ba để bảo mật quá trình khởi động server mà không ảnh hưởng tới Server ID.
Bạn không nên đặt mật khẩu cho server id trong hai trường hợp sau:

• Sử dụng công cụ Domino Admin từ xa để khởi động lại Domino Server
• Sử dụng tính năng tự động phục hồi máy chủ

Cả hai tính năng này có bộ nhớ cache mật khẩu và sử dụng nó khi server khởi động lại.

Xác nhận và xác thực ( Validation and Authentication)

Nhắc lại mô hình bảo mật tôi giới thiệu trong bài trước, khi người dùng Notes thực hiện kết nối vào Domino Server ( hoặc Domino Server này kết nối vào Domino Server khác), việc đầu tiên xảy ra là quá trình xử lý hai pha, validation và authentication. Tại điểm cuối của quá trình, hai bên trust với nhau, và danh tính của người dùng được xác nhận. Điều này đủ để chuyển qua bước tiếp theo trong mô hình bảo mật, bước "Server access list" để so sánh sự hợp lệ của người dùng và server.
Sau đây tôi sẽ mô tả một cách đơn giản quá trình xử lý hai pha khi đồng chí Admin/VSD/COM kết nối vào máy chủ Mail, áp dụng với tất cả các kết nối (LAN, WAN, dial-up,...).
Mọi thứ cần thiết cần thiết để xác nhận và xác thực đều chứa trong file ID của người dùng hoặc server.

Trong pha xác nhận, MAIL server xác định Public Key của đồng chí ADMIN:

1. Notes client gửi tất cả Notes Certfificates trong file admin.id tới MAIL server, bao gồm cả Admin's personal certificate và tất cả certificate của Organization/Organization Unit.
2. MAIL server tìm kiếm certificate /VSD mà Admin gửi, và tìm một certificate có tên giống như vậy trong file ID mà nó quản lý.
3. Sử dụng Public Key của /VSD cert, MAIL server xác định Admin's persional certificate là hợp lệ bởi vì nó giống với /VSD cert
4. MAIL server kết luận Public Key trong Admin's personal cert là hợp lệ.

Pha xác nhận được lặp lại, nhưng đổi chiều

Trong pha xác thực, MAIL server xác định tính hợp lệ định danh của ADMIN:

1. MAIL server sinh ra một số ngẫu nhiên và mã hóa nó sử dụng Admin Public key và gửi nó cho Notes clients.
2. Sử dụng Private ksy chỉ có trong Admin User ID file, Notes giải mã số và gửi lại cho Mail server.
3. Mail server so sánh số ban đầu với số mà mà Notes gửi. Nếu bằng nhau, thì Notes User ID có Private key giống với Public key sử dụng để giải mã thành công.

Pha xác thực được lặp lại, nhưng đổi chiều.
Trong suốt quá trình cài đặt First Domino server, OU cert được sử dụng để đăng ký Administrator user. Miễn là bạn đăng ký người dùng và máy chủ sử dụng OU cert này, thì quá trình xác nhận và xác thực đều được đảm bảo.
Nếu bạn mất  Organization ID, thì bạn gặp vấn đề lớn rồi đấy. Thậm chí nếu bạn tạo một ID giống hệt với Organization  name, bạn sẽ có một tập các khóa mới. Mọi người dùng và máy chủ mới tạo ra bởi ID mới sẽ không thể xác thực được với server hiện tại. Có hai cách giải quyết vấn đề này:

• Tạo mới Organization cert, đăng ký mới người dùng và máy chủ sử dụng ID này. Sau đó cross certify người dùng và máy chủ hiện đang tồn tại.
• Tạo mới Organization ID với tên giống trước hoặc khác, sau đó recertify Notes và Domino ID file.

Tăng cường bảo mật xác thực

Nếu quá trình xác thực hiện tại chưa làm bạn hài lòng, bạn có thể tăng cường khả năng bảo mật của quá trình xác thực bằng cách bắt server so sánh Public key từ Domino Directory trong suốt quá trình xác thực Public key được gửi từ Notes client hoặc server. Vì thế, trong trường hợp gần như không thể, hách cơ hack user id file để có được Public key, với việc kích hoạt tính năng này, khóa phải khớp với khóa được lưu trong Domino Directory.
Để kích hoạt tính năng so sánh key, bạn xem hình dưới

Chú ý: thiết lập này nhằm ngăn chặn người dùng bên ngoài tổ chức có thể cross-certified để có thể truy cập vào máy chủ. Nó còn ngăn chặn người dùng đã xóa khỏi Domino Directory có thể truy cập.
Thiết lập này ko áp dụng với browser client.

Hệ thống phân cấp OU Cert

Trong quá trình cài đặt First Server đã tạo ra Organization Cert ID, và từ ID này tạo ra Server ID và Admin ID tại gốc trong mô hình phân cấp ( cụ thể ở đây là /VSD)
Không hạn chế nếu bạn đăng ký tất cả user và server sử dụng Organization Certifier ID. Nhưng đôi khi, bạn có hàng trăm người dùng Notes, cách tốt nhất là bạn tạo ra một hệ thống phân cấp, để tiện cho việc quản lý, ví dụ:

Các OU cert được tạo ra từ O cert.

Thuận lợi của việc sử dụng Organizational Unit

Những thuận lợi khi bạn chia nhỏ Organization thành các OU là:
Người dùng trùng tên có thể phân biệt qua OU
Người quản tri tại mức OU có thể sử dụng OU ID để đăng ký người dùng và server bên trong tổ chức của mình
Phân quyền truy cập tới máy chủ và database có thể sử dụng ký tự đại diện (*/UB/QN/VSD)

Bài tiếp theo: Đăng ký người dùng và nhóm

Tổng quan về bảo mật trong Domino ( Domino Security overview)

Bảo mật trong Domino rất mạnh mẽ, liên quan tới cơ chế bảo mật nhiều lớp để bảo vệ máy chủ và database tránh khỏi các truy cập không hợp pháp.
Trong phần này, tôi sẽ giới thiệu tổng quan về bảo mật trong Domino, thể hiện cho các bạn theo trình tự truy cập được phần quyền từ mức thấp tới mức cao.

Mô hình bảo mật ( Security Model)

Biểu đồ dưới đây thể hiện một loạt các bước bảo mật thông qua các lớp.

Người dùng phải thỏa mãn các cơ chế bảo mật của Domino - theo chuỗi từ trái qua phải để có thể truy cập vào dữ liệu:

• Authentication: trong suốt quá trình xác thực, người dùng chứng mình - tên của họ được xác thực
• Server access: điều khiển truy cập tới Domino Server dựa trên tên có tồn tại trong Server Access Control List.
• Database access: điều khiển toàn bộ quyền thiết lập tới database trong ACL

Tổng quan về mô hình bảo mật

• Mô hình bảo mật cho Notes Client truy cập tới Domino server giống với cách Domino Server này truy cập tới Domino server khác ( ví dụ như đồng bộ hóa, định tuyến mail, chia sẻ các thông tin về lập lịch, ect), nhưng truy cập Domino theo trình duyệt và các trình Internet client khác (POP, LDAP, ...) theo một cách khác.
• Cho phép Anonymous truy cập bằng Notes hoặc qua trình duyệt là cách "nhanh nhất" để mở một session trên server, nhưng bạn mất kiểm soát người dùng truy cập qua Database ACL và Document ACL bởi vì bạn không thể phân biệt chúng bằng tên.
• Cuối cùng, bạn nên áp dụng tất cả các phương thức bảo mật máy chủ, điều này sẽ làm tăng chi phí, nếu bạn thực hiện không đúng thì cả người dùng hợp lệ sẽ bị khóa.

Chú ý 1: các cơ chế bảo mật khác của Notes bao gồm mã hóa CSDL trên đĩa, bắt buộc đổi mật khẩu, khóa công khai phải khớp lúc đăng nhập, ..
Chú ý 2: Cơ chế bảo mật trong phần này chủ yếu áp dụng cho giao thức Notes. Bảo mật Internet Mail và HTTP Protocol tôi sẽ nói với các bạn trong phần Cấu hình Mail

Các mức bảo mật

Mức	Chức năng
Mức1: General Access	Đây là mức thấp nhất bảo mật dữ liệu Notes, bao gồm các cơ chế bảo mật sau: Bảo mật mức vật lý của máy chủ để ngăn chặn cá nhân mở local file Bảo mật mức mạng ngăn chặn người dùng phá vỡ bảo mật Domino thông qua truy cập trực tiếp file hệ thống Xác thực ( cho phép Anonymous truy cập nếu có thể) Báo cáo truy cập máy chủ Database ACL Các cơ chế bảo mật này là thiết yếu và không bao giờ được bỏ qua
Mức 2: I/O Access	Khi bạn cho tổ chức khác truy cập tới máy chủ của mình, bạn nên thêm vào mức bảo mật lớp 2, bao gồm các cơ chế bảo mật sau: Cổng điều khiển truy cập với danh sách người dùng và nhóm trong file NOTES.INI Mã hóa dữ liệu truyền trên mạng Liên kết tới thư mục với danh sách người dùng và nhóm được phép trong .DIR file
Mức 3: Firewall Dominos	Đây là mức cao được khuyến cáo khi truyền thông và đồng bộ hóa với các tổ chức khác, trực tiếp hoặc qua Internet mà bạn đã tạo firewall giữa vùng mạng bên trong và bên ngoài. Chồng chéo chức năng network firewall: bạn có thể tạo Domino Firewall Domain bằng cách sử dụng Domino Directory và Organization Certifirer

Cơ bản bảo mật mạng

Hạn chế truy cập tới Domino Server qua mạng là một phần nhiệm vụ của người quản trị và có thể thực hiện theo cách sau:

• Yêu cầu mật khẩu người dùng khi đăng nhập vào mạng, thiết lập thời hạn của mật khẩu và không cho phép sử dụng mật khẩu giống nhau, hạn chế khả năng đăng nhập thông qua nhiểu nguồn.Thiết lập thời gian để log out người dùng khi không sử dụng. Notes hỗ trợ đặt User IDs trên SmartCard, khuyến khích người dùng bảo mật tài khoản của họ.
• Nếu Domino server chạy HTTP stack, hãy chạy trên cổng 80 ( 443 nếu dùng SSL)
• Nếu định tuyến mail sử dụng SMTP, dùng cổng 35 ( 465 nếu dùng SSL)
• Nếu hỗ trợ Lotus iNotes, cổng 80 và 443 nên sử dụng ( và cổng 1352 nếu dùng DOLS)
• Phụ thuộc vào các dịch vụ internet khác ( ví dụ LDAP), bạn nên mở các cổng này. Nếu sử dụng Quickr, bạn nên sử dụng cổng 80/443 cho HTTP/HTTPS, 1352 for DOLS, cổng 1533 và 8080 cho online awareness và chat.

Port access list

Bạn có teher hạn chế truy cập tới mạng LAN hoặc cổng COM trên máy chủ bao gồm cả những dòng trong file NOTES.INI hoặc sử dụng câu lệnh >set config :

Allow_Access_<PortName>= <Groupname>, <groupname>
Deny_Acess_<PortName>= <Groupname>, <groupname>

Hãy nhớ những điều sau khi bạn sử dụng Port access

Tên nhóm hoặc tên tổ chức có thể sử ký tự đại diện ví dụ:

Allow_Acess_TCPIP=Admins,LocalDomainServer,*/NN

Dấu * đại diện cho mọi người có tên trong Domino Directory ví dụ

Allow_Access_TCPIP=*

Thiết lập các Port nếu bạn muốn bảo vệ sử dụng tên trong hộp thoại Ports
Thành viên trong nhóm bị cấm truy cập sẽ ghi đè thành viên trong nhóm được phép truy cập
Bạn phải khởi động lại server để Port Access có thể effect
Chú ý: Port access không áp dụng cho Notes Anonymous user hoặc tới browser. Nó chỉ điều khiển những Port nào được xác thực Notes Clients

Mã hóa dữ liệu mạng

Một khía cạnh khác của bảo mật mạng là khả năng giữa Notes Client và Domino Server có thể mã hóa dữ liệu gửi tới Domino Servers

Firewall Network

Bạn nên tạo ra các vùng mạng riêng biệt để tăng cường bảo mật cho hệ thống. Giữa các vùng nên có firewall hoặc router lọc gói tin.

Domino firewall domain

Domino firewall domain được sử dụng để điều khiển truy cập tới internal server. Việc định tuyến mail, đồng bộ hóa với các máy chủ bên ngoài chỉ được thực hiện bởi server trong Domino firewall domain.
Domain này đòi hỏi quản trị phải public một Domino Directory thứ hai có các đặc điểm sau:

• Default ACL mặc định được set là No Access để bên ngoài không thể tìm ra các kết nối khác của bạn
• Chứa tất cả các tài liệu Connections tới tất cả các domain bên ngoài để đồng bộ hóa và định tuyến mail.
• Định nghĩa nhóm server cung cấp truy cập tới server trong Domino Firewall Domain
• Cần thiết thêm vào tài liệu Cross Certificate để xác thực Internal Domino Domain Server với các server bên ngoài.

internal Domino Domain Domino Directory của bạn cần có:

• Tài liệu Connection tới server trong Domino Firewall domain để định tuyến mail và đồng bộ hóa
• Tài liệu Non-Adjacent Domain  để dễ dàng định giải quyết thư tin và cho phép định tuyến mail chỉ từ các Domino Domain xác định.
• Tài liệu Server cho phép truy cập bởi server trong Domino firewall domain
• Tài liệu Cross Certificate, nếu cần thiết để xác thực với server trong Domino firewall organization.

Chú ý:
Domino Directory không được định nghĩa các server trong Domino Domain khác
Trong phần sau tôi sẽ nói về tài liệu Connection, Cross Certificate và No-Adjacent Domain.

Trách nhiệm của người quản trị:

Để đảm bảo thành công trong việc bảo vệ ứng dụng, database developer phải làm việc với Domino Administrator, người mà:

• Đăng ký các tài khoản cần thiết
• Cung cấp cho Notes Client Notes User ID file
• Cung cấp cho người dùng cách tự đăng ký qua web ( tạo tài liệu Person trong Domino Directory có Internet password)
• Nếu chứng thực sử dụng X.509 Internet Certificate, kich hoạt SSL và tạo ra Certificate Authority Key Ring và Certificate, Server Key Ring và Certificate, và phê duyệt người dùng yêu cầu Certificate.

Trách nhiệm của người phát triển:

Như một phần tổng thể của việc thiết kế database, người phát triển phải quyết định:
Ai có thể truy cập tới các mức của mô hình bảo mật, bao gồm những truy cập gán cho người dùng nội bộ và người dùng bên ngoài, quyền được đưa cho Notes clients hoặc browsers.
Dễ dàng điều khiển bảo mật sử dụng groups và roles.
Những mục nào có thể Create và View trên menu cho người dùng xác định
Đọc mức trường ( field-level) và edit access cho Notes Clients.

Bài tiếp theo: Xác thực người dùng và tên ( User authentication and Names).

Hot Mail SMTP error code

SMTP Error code	Explain
421 RP-001	The mail server IP connecting to Hotmail server has exceeded the rate limit allowed. Reason for rate limitation is related to IP/domain reputation. If you are not an email/network admin please contact your Email/Internet Service Provider for help.
421 RP-002	The mail server IP connecting to Hotmail server has exceeded the rate limit allowed on this connection. Reason for rate limitation is related to IP/domain reputation. If you are not an email/network admin please contact your Email/Internet Service Provider for help.
421 RP-003	The mail server IP connecting to Hotmail server has exceeded the connection limit allowed. Reason for limitation is related to IP/domain reputation. If you are not an email/network admin please contact your Email/Internet Service Provider for help.
550 SC-001	Mail rejected by Hotmail for policy reasons. Reasons for rejection may be related to content with spam-like characteristics or IP/domain reputation. If you are not an email/network admin please contact your Email/Internet Service Provider for help.
550 SC-002	Mail rejected by Hotmail for policy reasons. The mail server IP connecting to Hotmail has exhibited namespace mining behavior. If you are not an email/network admin please contact your Email/Internet Service Provider for help.
550 SC-003	Mail rejected by Hotmail for policy reasons. Your IP address appears to be an open proxy/relay. If you are not an email/network admin please contact your Email/Internet Service Provider for help.
550 SC-004	Mail rejected by Hotmail for policy reasons. A block has been placed against your IP address because we have received complaints concerning mail coming from that IP address. We recommend enrolling in our Junk Email Reporting Program (JMRP), a free program intended to help senders remove unwanted recipients from their email list. If you are not an email/network admin please contact your Email/Internet Service Provider for help.
550 DY-001	Mail rejected by Hotmail for policy reasons. We generally do not accept email from dynamic IP's as they are not typically used to deliver unauthenticated SMTP email to an Internet mail server. If you are not an email/network admin please contact your Email/Internet Service Provider for help. http://www.spamhaus.org maintains lists of dynamic and residential IP addresses.
550 DY-002	Mail rejected by Hotmail for policy reasons. The likely cause is a compromised or virus infected server/personal computer. If you are not an email/network admin please contact your Email/Internet Service Provider for help.
550 OU-001	Mail rejected by Hotmail for policy reasons. If you are not an email/network admin please contact your Email/Internet Service Provider for help. For more information about this block and to request removal please go to: http://www.spamhaus.org.
550 OU-002	Mail rejected by Hotmail for policy reasons. Reasons for rejection may be related to content with spam-like characteristics or IP/domain reputation. If you are not an email/network admin please contact your Email/Internet Service Provider for help.