Messages posted by: NTMP_38313

zone alarm bạn xem thử ...

dùng kis internet 2012 đi bạn, vừa tốt lại kiêm luôn firewall , kiểm soát port ...

mấy anh hay quá, có ngày em sẽ tự exploit đc 1 lỗi cho xem smilie

mỗi user đều có 1 profile riêng và khi bạn tạo 1 user mới thì cũng sẽ có 1 profile tương tự cho nó.
còn về vấn đề user cũ bị mất profile (có thể bạn đã del nhầm hoặc bị virus ăn) thì user này sẽ không thể restor lại profile mới mà sử dụng một cái profile temp và cái profile temp này sẽ biến mất khi user này logoff.

ko hình , cũng ko có copy lỗi đó ra, đọc hết nguyên câu chỉ toàn biết là " gì gì đó " .

hj, có vẻ như bạn đã hỉu vấn đề rồi đó smilie

đúng rồi, hay đơn giản hơn tui nghĩ bạn cứ hiểu vấn đề theo cách này nha, A là chủ nhà ( CA sv) , B là cướp. B muốn vào A thì phải có khoá.
--> Có 2 cách để B vào A
+ làm " khoá giả " ( hack)
+ xin hoặc lấy từ A

làm trong workgroup ( stand alone server) thì không cần CA Server -> CA tự phát sinh nên rất dễ " chết "
còn về cách làm thì cũng tương tự, bạn có thể tham khảo file sau
link http://www.kythuatvien.com/forum/network/Download/Part%2035%20-%20Certificate%20Authority.pdf

không phải Radius đi xin,nó có nhiệm vụ là chứng thực domain user cho hệ thống remote access policy.
clip trên user nào mình cho nó có quyền remote vào wlan thì mình phải xin cho nó (= cách logon vào user đó) smilie

lovelee wrote:

NTMP_38313 wrote:

Theo mình nghĩ về cơ bản triển khai Radius trên Workgroup hay Domain chỉ khác nhau ở tính security
và nếu VPN Server là StandAlone (workgroup) thì bạn tạo Local User và neu VPN Server là Member Server thì bạn tạo Domain user.
Nhưng tui vẫn chữa rõ ý của bạn, sử dụng VPN để join domain ???

Là thế này bạn ạ.
Mình đang làm bài LAB về WLAN + xác thực bằng RADIUS SERVER.

-Mình đã tham khảo các bài lab trên mạng và thấy là có thể làm được cả trên mô hình DOMAIN hay WORKGROUP. Nhưng họ đều chỉ thực hiện trên mô hình DOMAIN.

Và trong đó, đều có đoạn là máy sẽ dùng để tham gia mạng LAN qua WLAN đều JOIN DOMAIN từ trước

-> như thế thì còn nói làm gì nhỉ?? Nếu thế chẳng nhẽ phải cho ví dụ cái LAPTOP đó kết nối bằng dây trứoc để JOIN DOMAIN, sau đó rút ra sao??? kỳ cục quá.

Chả lẽ sau khi triển khai, ko thể mang 1 cái laptop lạ hoắc bất kỳ tới để vào WLAN thông qua 1 tài khoản của DOMAIN sao??

tất nhiên là có thể vào rồi bạn, lap đó có thể access wlan (wifi) bằng user đã tạo ở Radius mà.
còn đây là clip mình làm về Radius, user có xin và chứng thực CA.
Link http://www.mediafire.com/?7mqhw7x2t7kgmo7

lovelee wrote:

NTMP_38313 wrote:

lovelee wrote:

Các bro có thể cho em hỏi chút là khái niệm " xin chứng chỉ số" để làm gì được ko ?
Nó có phải là như kiểu xin CMNhanDan ko, để chứng tỏ mình đúng là mình phải ko ạ?

Nếu mình triển khai 1 hệ thống mạng WLAN, có 1 con RADIUS SERVER, thì con này có cần phải xin cái CA đó ko ạ?? Và nếu mình cài luôn dịch vụ CA trên chính con RADIUS này thì ko cần phải có công đoạn xin chứng chỉ nữa phải ko ạ?

Cảm ơn các bro. Mong được giúp đỡ.

Níu Radius Server có cấu hình CA thì user muốn remote vào mạng thì phải xin CA từ server , còn níu không thì thôi.

thanks. Vậy nếu mình xây dựng trên mô hình WORKGROUP, thì mình chỉ cần RADIUS SERVER, trên đó tạo danh sách người dùng được tham gia WLAN là được phải ko?? ko cần CA,DC nữa phải ko ạ.

Tại mình băn khoăn khi xem 1 số bài lab RADIUS SERVER, thì thấy toàn trên DOMAIN, cái máy muôn tham gia trước đó đã phải JOIN DOMAIN rồi, kỳ cục quá. Vậy tức là trước đó kết nói CÓ DÂY để join xong rồi lại rút dây ra JOIN vào WLAN-> thế thì còn nói làm gì.

Nếu mình đem 1 laptop lạ hoắc vào, và muốn JOIN lần đầu tiên vào WLAN bằng 1 tài khoản của DOMAIN chả nhẽ ko được? hic. Ai giải đáp giúp.

Theo mình nghĩ về cơ bản triển khai Radius trên Workgroup hay Domain chỉ khác nhau ở tính security
và nếu VPN Server là StandAlone (workgroup) thì bạn tạo Local User và neu VPN Server là Member Server thì bạn tạo Domain user.
Nhưng tui vẫn chữa rõ ý của bạn, sử dụng VPN để join domain ???

cuốn Chained Exploit này chắc hay, của bạn đây :d
link : https://rs347tl2.rapidshare.com/#!download|347cg|270858163|Chained_Exploits.rar|10170|R~0350B505C16F57FC45A8CBDC075C0E45

lovelee wrote:

Các bro có thể cho em hỏi chút là khái niệm " xin chứng chỉ số" để làm gì được ko ?
Nó có phải là như kiểu xin CMNhanDan ko, để chứng tỏ mình đúng là mình phải ko ạ?

Nếu mình triển khai 1 hệ thống mạng WLAN, có 1 con RADIUS SERVER, thì con này có cần phải xin cái CA đó ko ạ?? Và nếu mình cài luôn dịch vụ CA trên chính con RADIUS này thì ko cần phải có công đoạn xin chứng chỉ nữa phải ko ạ?

Cảm ơn các bro. Mong được giúp đỡ.

Níu Radius Server có cấu hình CA thì user muốn remote vào mạng thì phải xin CA từ server , còn níu không thì thôi.

theo tui biết thì đổi tên Domain qua khá nhìu giai đoạn, Ex lúc đầu đã lưu tên domain cũ h bạn đổi có lẽ là ko khả thi cho lắm ...

Raid 5 chỉ xải đc khi có ít nhất 2 đĩa -> hư 1 đĩa thì có thể phục hồi đc

Theo như tui biết WFP xảy ra khibị virus "ăn" hay bạn cố cài đặt và thay đổi file hệ thống.
Bạn có thể dùng các soft như Hide my folder ... để ẩn file của mình đi.

sau khi deny url set thì client vô web đen đc ko ...

Tai sao khi cai Backtrack5 va xong buoc 4 thi he thong chuyen luon sang buoc 7, khong hien thi buoc tao user va pass .Nen sau khi khoi dong may de hoan thanh qua trinh cai dat roi tien hanh dang nhap toi khong the dang nhap duoc vi khong co user va pass. Vui long giup toi voi .Thank you

Tai sao khi cai Backtrack5 va xong buoc 4 thi he thong chuyen luon sang buoc 7, khong hien thi buoc tao user va pass .Nen sau khi khoi dong may de hoan thanh qua trinh cai dat roi tien hanh dang nhap toi khong the dang nhap duoc vi khong co user va pass. Vui long giup toi voi .Thank you

hvthang wrote:

Bạn NTMP_38313 đang tham khảo tài liệu nào vậy? Bạn trình bày nghe lủng củng quá. Về lý thuyết, bạn hoàn toàn có thể tổng hợp từ một nguồn tài liệu tham khảo đáng tin cậy là được.

lủng củng , bạn có thể chỉ rỏ cho tui phần nào được ko , bây giờ tui bấng loạn rồi , hix

mỗi phần tui lấy từ nhiều diễn đàn khác nhau.
còn radius tui lay' từ bảng tiếng anh , chắc dịch ra hơi lủng củng ...

mình mới update phần lý thuyết , còn phần thực hành tuần sau làm xong mình sẽ up lên tiếp.
mong các bạn cho ý kiến.

Mong các bạn giúp đỡ
Về nội dung , khi làm xong phần nào mình sẽ update lên sau

4. Khái niệm IP Security

Thuật ngữ IPSec là một từ viết tắt của thuật Internet Protocol Security. Nó có quan hệ tới một số bộ giao thức (AH, ESP, FIP-140-1, và một số chuẩn khác) được phát triển bởi Internet Engineering Task Force (IETF). Mục đích chính của việc phát triển IPSec là cung cấp một cơ cấu bảo mật ở tầng 3 (Network layer) của mô hình OSI, như dưới

gpj.f7d838a88d_1576582975/4872/moc.rkcilf.citats.3mraf//:ptth

- Mọi giao tiếp trong một mạng trên cơ sở IP đều dựa trên các giao thức IP. Do đó, khi một cơ chế bảo mật cao được tích hợp với giao thức IP, toàn bộ mạng được bảo mật bởi vì các giao tiếp đều đi qua tầng 3. (Đó là lý do tai sao IPSec được phát triển ở giao thức tầng 3 thay vì tầng 2).
- Ngoài ra,với IPSec tất cả các ứng dụng đang chạy ở tầng ứng dụng của mô hình OSI đều độc lập trên tầng 3 khi định tuyến dữ liệu từ nguồn đến đích. Bởi vì IPSec được tích hợp chặt chẽ với IP, nên những ứng dụng có thể dùng các dịch vụ kế thừa tính năng bảo mật mà không cần phải có sự thay đổi lớn lao nào. Cũng giống IP, IPSec trong suốt với người dùng cuối, là người mà không cần quan tâm đến cơ chế bảo mật mở rộng liên tục đằng sau một chuổi các hoạt động.

4.1 Các thao tác bảo mật.

Các thao tác bảo mật trong hệ thống Windows Server 2003 gồm:

Block transmissions: Ngăn chặn những gói dữ liệu được truyền.Ví dụ, bạn muốn IPSec ngăn chặn dữ liệu truyền từ máy A đến máy B thì giao thức IPSec trên máy B loại bỏ mọi dữ liệu truyền đến từ máy A.

Encrypt transmissions: Mã hóa những gói dữ liệu được truyền. Ví dụ, bạn muốn dữ liệu được truyền từ máy A đến máy B.Nhưng bạn sợ rằng có người sẽ nghe trộm (sniffer) trên đường truyền kết nối giữa hai máy A và B, vì vậy bạn cần cấu hình cho IPSec sử dụng giao thức ESP (Encapsulating Security Payload) để mã hóa dữ liệu cần truyền trước khi đưa lên mạng. Lúc này, những người xem trộm sẽ thấy những dòng byte ngẫu nhiên và không đọc/hiểu dữ liệu thật. Do IPSec hoạt động ở lớp Network nên hầu như việc mã hóa được trong suốt đối với người dùng. Người dùng có thể gửi mail, truyền file hay telnet như bình thường.

Sign transmissions: Ký tên vào các gói dữ liệu truyền nhằm tránh những kẻ tấn công trên mạng giả dạng những gói dữ liệu được truyền từ những máy mà bạn đã thiết lập quan hệ tin cậy (kiểu tấn công còn gọi là main-in-the-middle). IPSec cho phép bạn chống lại điều này bằng một giao thức AH _ Authentication Header. Giao thức này là phương pháp ký tên số hóa (digitally signing) vào các gói dữ liệu trước khi truyền, nó chỉ ngăn ngừa được giả mạo và sai lệch thông tin chứ không ngăn ngừa được sự nghe trộm thông tin. Nguyên lý hoạt động của phương pháp này là hệ thống sẽ thêm một bit vào cuối mỗi gói dữ liệu truyền qua mạng, từ đó chúng ta có thể kiểm tra xem dữ liệu có bị thay đổi khi truyền hay không.

Permit transmissions: Cho phép dữ liệu được truyền qua, chúng dùng để tạo ra các quy tắc (rule) hạn chế một số điều này và không hạn chế một số điều khác. Ví dụ, một quy tắc dạng này “Hãy ngăn chặn tất cả những dữ liệu truyền tới, chỉ trừ dữ liệu truyền trên các cổng 80 và 443”.
Chú ý: Đối với hai thao tác bảo mật theo phương pháp ký tên (sign) và mã hóa (encrypt) thì hệ thống còn yêu cầu bạn chỉ ra IPSec dùng phương pháp chứng thực nào (có nghĩa là cho IPSec biết cách thức mà máy nhận (receiver) và máy gửi (transmitter) sẽ trao đổi mật khẩu; sau đó, chúng sẽ dùng mật khẩu này để ký tên hoặc mã hóa các gói dữ liệu truyền đi trên mạng).
Microsoft hỗ trợ ba phương pháp chứng thực như: Kerberos, chứng chỉ (Certificate) hoặc một khóa dựa trên sự thỏa thuận (agree-upon key).
+ Phương pháp Kerberos : chỉ áp dụng được trong các máy trong cùng một miền (domain) Active Directory hoặc trong những miền Active Directory có ủy quyền cho nhau.
+ Phương pháp dùng các chứng chỉ cho phép bạn sử dụng các chứng chỉ PKI (Public Key Infrastructure) để nhận diện một máy.Phương pháp dùng khóa dùng chung (chia sẻ) trước (preshared key) thì cho phép bạn dùng một chuỗi ký tự thông thường (plain text) làm khóa (key).

4.2 Các bộ lọc IP Sec.

Để IPSec hoạt động linh hoạt hơn, Microsoft đưa thêm khái niệm bộ lọc IPSec (IPSec filter).Bộ lọc có tác dụng thống kê các điều kiện để quy tắc hoạt động.Đồng thời chúng cũng giới hạn tầm tác dụng của các thao tác bảo mật trên một phạm vi máy tính nào đó hay một số dịch vụ nào đó.Bộ lọc IPSec chủ yếu dựa trên các yếu tố sau:
Địa chỉ IP, subnet hoặc tên DNS của máy nguồn.
Địa chỉ IP, subnet hoặc tên DNS của máy đích.
Theo giao thức (TCP, UDP, ICMP) và số hiệu cổng (port).

5. Khái niệm về Radius Server

RADIUS : là một giao thức dùng để chứng thực người dùng trong những trường hợp truy cập từ xa (remote access).

Thông tin dùng để chứng thực được lưu tập trung ở RADIUS server. Khi cần chứng thực người dùng và nếu được cấu hình sử dụng RADIUS, NAS (lúc này là RADIUS client) sẽ chuyển thông tin của người dùng đến RADIUS server để nhờ kiểm tra. Kết quả sẽ được RADIUS server trả lại cho NAS. Thông tin được trao đổi giữa RADIUS server và RADIUS client đều được mã hóa.
Có thể hiểu RADIUS server cung cấp cho RADIUS client khả năng truy xuất vào hệ
thống tài khoản người dùng trên Active directory service.
Trên môi trường domain của Windows 2003 Server, máy tính cài dịch vụ RADIUS
server sẽ là máy tính nằm trong domain.

- Internet Authentication Service : là máy chủ Radius hỗ trợ thiết lập nhiều tên miền. Nó hoạt động liên kết với Routing và Remote Access (RRAS) được sử dụng cho các doanh nghiệp nhỏ. Nó cung cấp tập trung
+ Chứng thực ủy quyền Kế toán (Authentication Authorization Accounting) (AAA) và lưu trữ thông tin trong Active Directory. Active Directory cho phép các quản trị viên để tạo và thiết lập các chính sách,chứng thực cho hàng ngàn máy tính và người sử dụng. Nó có thể chuyển tiếp thẩm định và thông báo đến RADIUS server khác.
+ Hỗ trợ nhiều giao thức như PPP, PAP, CHAP, MS-CHAP, MS-CHAP v2.
+ IAS khi được triển khai trên một máy nằm trong Active Directory domain, có thể chứng thực người dùng của AD domain đó. Tính năng này chỉ có trên AD domain hoạt động ở chế độ Windows 2003 domain functional level.

5.1 Cơ chế hoạt động (operation)

Khi một client được định cầu hình để sử dụng Radius, thì bất cứ user nào của client đều giới thiệu những thông tin xác nhân quyền (Authentication information) với client. Đó có thể là dấu nhắc lệnh đăng ký vào mạng (logon prompt) yêu cầu user nhập tên và mật khẩu vào. User có thể lựa chọn việc sử dụng protocol thích hợp để thực hiện giới thiệu những thông tin này bằng các gói dữ liệu (packets), chẳng hạn như PPP (Point to Point Protocol)

Mỗi lần client nhận được thông tin như vậy, nó có thể chọn dùng Radius để xác nhận quyền. Client sẽ tạo ra một “ yêu cầu truy nhập” (Accest-Request) chứa các thuộc tính như tên, mật khẩu của user, số hiệu (ID) mà user sẽ truy cập vào. Mật khẩu khi nhập vào sẽ được ẩn (phương pháp dựa trên giải thuật RSA Message Digest Algorithm MD5).

“Yêu cầu truy nhập” (Accest-Request) sẽ được gửi cho Radius thông qua mạng. Nếu không có trả lời trong một khoảng thời gian quy ước thì yêu cầu sẽ được gửi lại. Client cũng có thể chuyển (forward) yêu cầu cho các server dự phóng trong trường hợp server chính bị tắt hoặc hư hỏng hoặc hoạt động theo kiểu round-robin.

Mỗi khi Radius server nhận được yêu cầu, nó sẽ xác nhận client gởi. Những yêu cầu từ các cliemt nào không chia sẽ thọng tin bảo mật (share secret) với Radius sẽ không được xác nhận và trả lời (sliently discarded). Nếu client là hợp lệ, Radius server sẽ tiềm kiếm trong cơ sở dữ liệu (CSDL) user có cùng tên trong yêu cầu. Chỉ mục của user (user entry) trong CSDL sẽ chứa danh sách các đòi hỏi cần thiét cho phép user truy cập vào mạng. Radius luôn luôn xác nhận mật khẩu của user và có thể cả số hiệu của client và port mà user được phép truy cập .

Radius server có thể yêu cầu các server khác xác nhận. Lúc đó Radius đóng vai trò của một client

Nếu bất cử điều kiện nào không được thỏa, Radis server sẽ gởi một trả lời “từ chối truy cập” (Access-Reject) biểu thị rằng yêu cầu của user là không hợp lệ. Server có thể kèm theo một thông báo dạng văn bản ( text message) trong Access-Reject để client có thể hiện thì cho user.

Nếu tất cả các điều kiện đều được thỏa và Radius server muốn đưa ra một yêu cầu đòi hỏi user phải trả lời, thì Radius sẽ gởi một trả lời “đòi hỏi truy cập” (Access-Challenge), nó có thể dưới dạng một thông báo dạng văn bản đươc hiển thì cho user. Client sẽ nhận Access-Challenge, và nếu nó được trang bị challenge/response, nó sẽ hiện thị thông báo nhắc user trả lời yêu cầu. Sau đó client sẽ gửi lại (re-submit) “yêu cầu truy cập” gốc (original Access-request) với một số hiệu yêu cầu ( request ID) mới, nhưng thuộc tình tên - mật khẩu được lấy từ thông yin vừa mới nhập vào, và kèm luôn cả thuộc tính trạng thái từ Access-Challenge. Radius server có thể trả lời “yêu cầu truy cập mới bằng “chấp nhận truy cập” ( Access-Request) hay “từ chối truy cập“ (Accest-Reject) hoặc một “đòi hỏi truy cập” (Access-Challenge) khác.

Nếu cuối cùng tát cả các điều kiện được thỏa, thì danh sách các giá trị cầu hình cho user được đặt vào trả lời “chấp nhận truy cập” (Accest-Accept). Các giá tri này bao gồm kiểu của dịch vụ (ví dụ:SLIP, PPP, Login user) và các giá trị cần thiết để cấp phát dịch vụ này. Ví dụ như đối với SLIP hay PPP, các giá trị này có thể là địa chỉ IP, địa chỉ mạng con (subnet mask), MTU, phương pháp nén và số hiệu lọc gói (filtering packet ID). Ở chế độ ký tự (character mde), các giá trị này có thể là giao thức (protocol) và tên máy chủ (host).

5.2 Dạng của gói (packet format)

Một gói Radius được bao bọc trong trường dữ liệu của gói UDP (UDP data field), và trường địa chỉ đích (UDP Destination Port field) có số hiệu cổng là 1645. Khi gói trả lời được tạo ra, số hiệu cổng của địa chỉ nguồn và đích được bảo lưu.

code : 1 byte

Xác định kiểu gói của Radius, gói có mã không hợp lệ sẽ không được xác nhận và trả lời (sliently discarded)

Code 1: Accest-Request
Code 2: Accest-Accept
Code 3: Accest-Reject
Code 4: Accouting-Request
Code 5: Accouting -Response

Code 11: Accest-Challenge
Code 12: Status-Server (experimental - thực nghiệm) được sử dụng cho tương lai
Code 13: Status-Client (experimental - thực nghiệm) được sử dụng cho tương lai

5.3 Kiểu của gói (packet types)

Kiểu của gói được xác định bởi trường mã (code field) chiếm byte đầu tiên của Radius.

5.3.1 Gói “yêu cầu truy cập” (Accest-Requset)
Gói Accest-Request được gởi tới Radius server. Nó chuyên chở thông tin dùng để xác định xem user có được phép truy câp vào NAS và các dịch vụ được chỉ định hay không. Trường mã của gói phải có giá trị 1.
Gói Access-Request phải chứa thuộc tính User-Name, User-Password hoac CHAP-Password, và có thể chứa các thuộc tính NAS-IP-Address, NASIdentifier,
NAS-Port, NAS-Port-Type.

5.3.2 Gói “chấp nhận truy cập” (Accest-Accept)

Gói Access-Accept được gửi trả bởi Radius server khi tất cả các giá trị của gói Accest-Request. Nó cung cấp thông tin cấu hình cần thiết để cấp phát các dịch vụ cho user. Trường mã của gói phải có giá trì 2. Gói Access-Accept nhận được ở NAS phải có trường danh hiệu trùng khớp với gói Accest-Request tương ứng đã gởi trước đó và phải có trường xác nhận (Response Authenticator) phù hợp với thông tin bí mật dùng chung (share secret).

5.3.3 Gói “từ chối truy cập” (Accest-Reject)

Gói Accest-Reject được gửi trả từ Radius server khi có giá trị thuộc tính không được thỏa. Trường mã của gói phải có trị 3. Gói có thể chứa hoặc nhiều thuộc tính Reply-Message với một thông báo dạng văn bản mà NAS sẽ hiển thị nó với user. Trường danh hiệu của gói Access-Reject chính là bản sao của gói Access-Request tương ứng.

5.3.4 Gói “ đòi hỏi truy cập” (Access-Challenge)

Access-Challenge được Radius server gửi đền user đòi hỏi thêm thông tin cần thiết mà user phải trả lời. Trường mã của gói phải có giá trị 11. Gói có thể chứa 1 hoặc nhiều thuộc tính Reply-Message và có thể có 1 thuộc tính State. Các thuộc tính khác không được xuất hiện trong gói Access-Challenge. Trường danh hiệu của gói Access-Challenge phải trùng khớp với gói Access-Request tương ứng đã gởi trước đó và phải có trường xác nhận (Response uthenticator) phủ hợp với thông tin bí mật dùng chung (share secret). Nếu NAS không được trang bị challenge/response thì gói Access-Challenge nhận được sẽ coi như là gói Access-Reject. Nếu NAS được trang bị chức năng challenge / response và gói Access-Challenge nhận được là hợp lệ thì NAS sẽ hiển thị thông báo và yêu cầu user trả lời thông tin mà Radius server yêu cầu. Sau đó NAS sẽ gởi gói Access-Request gốc nhưng với danh hiệu yêu cầu (request ID) và xác nhận yêu cầu (request authenticator) mới, đồng thời thuộc tính User-Password cũng được thay thế bởi thông tin trả lời của user.

5.4 Giao thức chứng thực ( Authentication protocol)

Radius có nhiều giao thức chứng thực khác nhau. Số ít được liệt kê dưới đây được sử dụng với mạng Point to point. Một vài giao thức chứng thực mở rộng (Extensible Authentication Protocol) cũng được sử dụng trong mạng 802.1x điển hình là mạng WLAN.

5.4.1 Giao thức chứng thực mật khẩu ( Password Authentication Protocol - PAP)

Được sử dụng khi máy chủ (host) và thiết bị định tuyến (router) kết nối với giao thức Point to Point Protocol (PPP) thông qua dịch vu quay số (dial up) hoặc đường truyền chuyên dụng khác.
Liên kết được thành lập lặp đi lặp lại việc gửi ID và mật khẩu để xác thực cho đền khi nó được công nhận hoặc cho đến khi kết nối kết thúc

5.4.2 Chap (Challenge-Handshake Authentication Protocol) :

Là một kiểu kết nối khác hỗ trợ giao thức PPP , nó trái ngược vói giao thức PAP mà mật khẩu được gửi đi là chính bản thân nó trong suốt quá trình chứng thực. Quá trình chứng thực gồm ba bước :
+ Sau khi liên kết được thiết lập, máy chủ xác nhận (authenticator) gửi gói tin challenge tới máy khách, máy khách phản hồi lại bằng việc sử dụng thuật toán băm MD5 để tính toán các giá trị mà kết quả dựa trên mật khẩu và gói tin challenge ở trên.
+ Máy chủ xác nhận (authenticator) sử dụng một dạng mật khẩu tương tự của hàm băm để so sánh kết quả máy khách gửi tới.
+ Nếu 2 chuỗi là giống nhau thì quá trình chứng thực CHAP đã thành công. Điều này có nghĩa là kết nối đã được chứng thực hợp lệ.

Thuật toán được nêu ở trên là một cách mã hóa dữ liệu rất phức tạp do đó CHAP được sử dụng phổ biến hơn PAP,

5.4.3 MS Chap(v1/v2)

MSCHAP (Microsoft Challenge Handshake Authentication Protocol) là phiên bản Chap của Microsoft.
Cả hai phiên bản 1 và phiên bản 2 đều có thể mua được, nhưng phiên bản 1 không được ưa chuộng. Nó sử dụng thuật toán băm MD4, mã hóa DES và được sử dụng trong mạng của Microsft

5.4 Giao thức chứng thực mở rộng (Extensible Authentication Protocol )
Là giao thức cung cấp cơ cấu làm việc (framework) cho máy khách truy cập vào mạng và máy chủ chứng thực. được miêu tả trong RFC 3748. Nó hỗ trở việc sử dụng chứng thực đa phuong tiện. Ngoài ra nó còn chỉ rỏ các gói tin trao đổi giữa máy khách, việc chứng thực và máy chủ xác nhận (authenticator) được diễn ra như thế nào.
Thông thường nó được phát triển cho việc sử dụng giao thức PPP, nhưng bây giờ nó được sử dụng cho mạng Lan không dây IEEE 802.1x.Trong hệ thống mạng này,máy khách (client) có thể đăng nhập vào hệ thống mạng không dây

Nó hỗ trợ một số giao thức dưới đây.

EAP-MD5 ( Message-Digest 5) : tên người dùng và mật khẩu để được sử dụng để xác nhận thông tin theo miêu tả trong RFC 1194. Đó là một giao thức đơn giản. Máy chủ RADIUS xác nhận yêu cầu kết nối mật khẩu người bằng thuật toán băm MD5. Nó gửi một gói tin (challenge) ngẫu nhiên mà máy khách phản hồi lại mật khẩu bằng việc sử dụng MD5

EAP-TLS (Transport Layer Security) : nó cung cấp bảo mật mạnh mẽ bằng cách yêu cầu cả máy chủ lẫn máy khách xác nhận chứng thực bằng PKI.Các gói tin EAP tương tác với máy khách lẫn máy chủ được mã hóa và bảo vệ kết nối mạng bằng TLS. Nhược điểm với giao thức này là sử dụng và cài đặt chứng thực luôn ở cả hai bên.

EAP-TTLS
PEAP (Protected EAP)
Cisco LEAP ( Lightweight EAP Protocol)

III. Mô hình triển khai

Thực hành

1 ) HTTPS :
+ Cài đặt Enterprise CA
+ Default Website
+ Network Monitor
+ HTTPS

2 ) Secure Mail :
+ Cài đặt Mail Server Mdeamon
+ Cấu hình Windows Mail cho users
+ Admin sửa mail của users
+ User xin và cài đặt Certificates
+ User gửi mail có sign
+ Users gửi mail có encrypt

3 ) IP Security :
+ Cài đặt Network Monitor
+ Cấu hình IPSEC trên DC
+ Cấu hình IPSEC trên máy Client

4 ) Radius :
+ Cấu hình VPN – Client to gateway
+Cài IAS – Internet Authencation Services
+Cấu hình Radius Server

IV . Kết luận

tks các bạn đã cho lời khuyên ...

Theo dàn ý mình soạn ở trên, từ lý thuyết với mô hình triển khai hình như chưa có logic, liên quan giữa các phần với nhau.
Bạn nào biết thì giúp mình với ...

Về cách làm 2k3 và 2k8 cũng giống nhau , chỉ khác phần giao diện đồ hoạ.
Với lại lúcc đầu mình cũng định chọn rồi nhưng do máy laptop của mình cùi quá chạy máy ảo 2k8 ko nổi nên đành chọn 2k3 thôi smilie

Mong các bạn giúp đỡ
Về nội dung , khi làm xong phần nào mình sẽ update lên sau

1. Tên đề tài : Tìm hiểu về các phương pháp mã hóa và chứng thực trên Window Server 2003

I. PHẦN MỞ ĐẦU
1. Lý do và mục đích chọn đề tài

2. Nội dung đề tài

3. Phương pháp nghiên cứu

4. Cấu trúc đề tài

II. Cơ sở lý thuyết

1. Bảo mật - Mã hóa dữ liệu
1.1 Symmetric Key Cryptography – SKC
( Phương pháp Mã hóa Đối xứng )

Phương pháp Mã hóa Đối xứng đã được biết đến và sử dụng từ rất lâu .
Sử dụng cùng một Mã khóa (Key code) cho việc mã hóa (Encryption) và Giải mã (Decryption). Việc mã hóa được thực hiện rất nhanh chóng dẫn đến khó bảo quản khi sử dụng nhiều Key Code.
Các thuật toán thường sử dụng :
DES (Data Encryption Standard), AES (Advanced Encryption Standard), 3DES (Triple DES )

Ví dụ :
SKC với nguyên tắc dời vị trí

Nội dung gốc : “Hello everybody”
Mã hóa : dời nội dung sang phải – Keycode =1
à “Lfmmp fxfsacpea”
Giải mã : dời nội dung sang trái – Keycode =1
à “Hello everybody

1.2 Public Key Infrastructure – PKI
( Phương pháp Mã hóa Công Khai )
1.2.1 Tổng quan về PKI

Public Key Infrastructure (PKI) là một cơ chế để cho một bên thứ ba (thường là nhà cung cấp chứng thực số ) cung cấp và xác thực định danh các bên tham gia vào quá trình trao đổi thông tin. Cơ chế này cũng cho phép gán cho mỗi người sử dụng trong hệ thống một cặp public/private. Các quá trình này thường được thực hiện bởi một phần mềm đặt tại trung tâm và các phần mềm khác tại các địa điểm của người dùng. Khoá công khai thường được phân phối trong chứng thực khóa công khai – hay Public Key Infrastructure.
Khái niệm hạ tầng công khai (PKI) thường được dùng để chỉ toàn bộ hệ thống bao gồm cả nhà cung cấp chứng thực (CA) cùng các cơ chế liên quan đồng thời với toàn bộ việc sử dụng các thuật toàn mã hóa công khai trong trao đổi thông tin .

1.2.2 Các thành phần của PKI

Một hệ thống PKI gồm 4 thành phần sau :
+ Certification Authorities (CA) : Cấp và thu hồi chứng chỉ
+ Registration Authorities (RA) : Gằn kết giữa kháo công khai và định danh của người giữ chứng chỉ
+ Clients : Người sử dụng chứng chỉ PKI hay theo cách khác được xác định như những thực thể cuối
Người sử dụng cuối hoặc hệ thống là chủ thể của chứng chỉ PKI
+ Repository : Hệ thống ( có thể phân tán ) lưu trữ chứng chỉ và danh sách các chứng chỉ bị thu hồi .
Cung cấp cơ chế phân phối chứng chỉ và CRLs đến các thực thể cuối . Các thành phần PKI và các mối quan hệ giữa chứng chỉ được chỉ ra như trong hình 2.1 . Đây là mô hình kiến trúc do PKIX đua ra

Hình 2.1

1.2.2.1 Tổ chức chứng thực ( Certification Authority)
+ Trong hạ tằng cơ sở công khai , chứng chỉ có vai trò gắn kết giữa định danh với khóa công. Sự gắn kết này thể hiện trong dạng cấu trúc dữ liệu được ký số , được đề cập đến như chứng chỉ đã được thảo luận ở phần trước . Một Certificate Authority (CA) là một thục thể PKI có trách nhiệm cấp chứng chỉ cho các thực thể trong hệ thống .
+ Tổ chức chứng thực – CA cũng được gọi là bên thứ ba được tin tưởng vì người sử dụng cuối tin tưởng vào chữ ký số CA trên chứng chỉ trong khi thực hiện những hoạt động mã hóa công khai cần thiết . Tổ chức cung cấp dịch vụ chứng thực – Certification Service Provider (CSP) là một thuật ngữ khác nhắc đền CA được sử dụng trong bài báo cáo.
+Thông thường CA thực hiện chức năng xác thực bằng cách cấp chứng chỉ cho các CA khác và cho thực thể cuối ( người giữ chứng chỉ ) trong hệ thống. Nếu CA nằm ở đỉnh của mô hình phân cấp PKI và chi cấp chứng chỉ cho những CA ở mức thấp hơn thì chứng chỉ này được gọi là chứng chỉ gốc “root certificate”.

1.2.2.2 Trung tâm đăng ký ( Registration Authorities)
+Mặc dù CA có thể thực hiện những chức năng đăng ký cần thiết, nhưng đôi khi cần có thực thể độc lập thực hiện chức năng này. Thực thể này được gọi là “registration authority” – trung tam đăng ký. Ví dụ khi số lượng thực thể cuồi trong miền PKI tăng lên và số thực thể cuối này được phân tán khắp nơi về mặt địa lý thì việc đăng ký tại một CA trung tâm trở thành vấn đề khó giải quyết. Để giải quyết vấn đề này cần thiết phải có một hoặc nhiều RAs ( trung tâm đăng ký địa phương )
+Mục đích chính của RA là để giảm tải công việc của CA. Chức năng thực hiện của một RA cụ thể sẽ khác nhau tùy theo nhu cầu truển khai PKI nhưng chu yếu bao gồm những chức năng sau :
+ Xác thực cá nhân chủ thể đăng ký chứng chỉ.
+ Kiểm tra tính hợp lệ của thông in do chủ thể cung cấp.
+ Xác nhận quyền của chủ thể đối với những thuộc tính chứng chỉ được yêu càu.
+ Kiểm tra xem chủ thể có thực sự sở hữu khóa riêng đang được đăng ký hay không – điều này thường được đề cập đến như sự chứng minh sở hữu (proof of possession – POP).
+ Tạo cặp kháo bí mật / công khai.
+ Phân phối bí mật được chỉa sẻ đền thực thể cuối khởi tạo quá trình đăng ký với CA.
+ Lưu trữ khóa riêng.
+ Khởi sinh quá trình khôi phục khóa.
+ Phân phối thẻ bài vật lý (ví dụ như thẻ thông minh) chứa khóa riêng.

1.2.2.3 Thực thể cuối (Người giữ chứng chỉ và Clients)
+ Thực thể cuối trong PKI có thể là con người, thiết bị, và thậm chí là một chương trình phần mềm nhưng thường là người sử dụng hệ thống. Thực thể cuối sẽ thực hiện những chức năng mật mã (mã hóa , giải mã và ký số)

1.2.2.4 Hệ thống lưu trữ (Repositories)
- Chứng chỉ (khóa công) và thông tin thu hồi chứng chỉ phải được phân phối sao cho những người cần đến chứng chỉ đều có thể truy cập và lấy được.
- Có 2 phương pháp phân phối chứng chỉ :
+ Phân phối cá nhân :
Là cách phân phối cở bản nhất. Trong phương pháp này sẽ trực tiếp đưa chứng chi của họ cho người dng2 khác nhau. Chuyển giao bằng tay chứng chỉ được lưu trong đĩa cứng hoặc trong một số các môi trường lưu trữ khác. Cũng có thể phân phối bằng cách gằn chứng chỉ trong email để gửi cho người khác.
Cách này thực hiện tốt trong môi nột nhóm ít người dùng nhưng khi số lượng tăng người tăng lên thì có thể xảy ra vấn đề quan lí.
+ Phân phối công khai
Một phương pháp khác phổ biến hơn để phân phối chứng chỉ ( và thông tin thu hồi chứng chỉ) là công bố các chứng chỉ rộng rãi, các chứng chỉ này có thể sử dụng một cách công khai và được đặt ở vị trí có thể truy cập dễ dàng. Những vị trí này được gọi là cơ sở dữ liệu.
Dưới đây là ví dụ về một số hệ thống lưu trữ:
- X.500 Directory Access Protocol (DSAs)
- Lightweight Directory Access Protocol (LDAP) Server
- Domain name System (DNS) và Web Servers
- File Transfer Protocol (FTP) Servers và Corporate Databases

1.2.3 Chức năng cơ bản của PKI
Những hệ thống cho phép PKI có những chức năng khác nhau. Nhưng nhìn chung có hai chức năng chình là: chứng thực và kiểm tra.
+ Chứng thực ( Certification) : là chức năng quan trong nhất của hệ thống PKI. Đây là quá trình ràng buộc khóa công khai với định danh của thực thể. CA là thực thể PKI thực hiện chứng năng, chứng thực. Có hai phương pháp chứng thực:
- Tồ chức chứng thực (CA) tạo ra cặp khóa công khai / khóa bí mật và tạo ra chứng chỉ cho phần công khóa công của cặp khóa.
- Người sử dụng tư tạo cặp khóa và đưa khóa công cho CA để CA tạo chứng chỉ khóa công đó. Chứng chi đảm bảo tính toan vẹn của khóa công khai và các thông tin gắn cùng.

+ Thẩm tra ( validation) : quá trình các định liệu chứng chỉ đã đưa ra có thể được sử dụng đúng mục đích thích hợp hay không được xem như là quá trình kiểm tra tính hiệu lực của chứng chỉ. Úa trình này bao gồm một sau bước sau:
- Kiểm tra xem liệu có đúng là CA được tin tưởng đã ký số lện chứng chỉ hay không (xử lý theo đường dẫn chứng chỉ).
- Kiểm tra chữ ký số của CA trên chứng chỉ để kiểm tra tính toàn vẹn.
- Xác định xem chứng chỉ còn ở trong thời gian có hiệu lực hay không.
- Xác định xem chứng chỉ đã bị thu hồi hay chưa.
-Xác định xem chứng chỉ đang được sử dụng đúng mục đích, chính sách giới hạn hay không (bằng cách kiểm tra những trường mở rộng cụ thể như mở rộng chính sách chứng chỉ hay mở rộng việc sử dụng khóa công khai).

2. Tìm hiểu giao thức SSL/TLS –Hoạt động, tấn công và phòng chống.
2.1 Tổng quan về giao thức SSL/TLS

2.1.1 SSL/TLS là gì ?
- Secure Sockets Layer (SSL), Transport Layer Security (TLS) là hai giao thức nổi bật để cung cấp dịch vụ bảo mật cho lưu lượng dữ liệutrên kênh truyền.
- Lợi ích khi dùng SSL/TLS :
+ Strong authentication, message privacy, and integrity.
+ Interoperability
+ Algorithm flexibility
+ Ease of deployment
+ Ease of use

2.2.2 Lịch sử ra đời SSL/TLS

- SSL được phát triển bởi Netscape Communications Corporationvào năm 1994để đảm bảo các giao dịch trên World Wide Web.
- Đến nay đã có 3 phiên bản SSL:
+ SSL 1.0: Được sử dụng nội bộ chỉ bởi Netscape Communications. Nó chứa một số khiếm khuyết nghiêm trọng và không bao giờ được tung ra bên ngoài
+ SSL 2.0: Ra đời cùng lúc Microsoft giới thiệu giao thức PCT (Private Communication Technology) , nhằm cạnh tranh trong lần tung ra Internet Explorer đầu tiênvào năm 1996.
+ SLL 3.0: Netscape Communications đã phản ứng lại sự thách thức PCT của Microsoft bằng cách giới thiệu SSL 3.0 vốn giải quyết các vấn đề trong SSL 2.0 và thêm một số tính năng mới. Vào thời điểm này, Microsoft nhượng bộ và đồng ý hỗ trợ SSL trong tất cả các phiên bản phần mềm dựa vào TCP/IP của nó (mặc dù phiên bản riêng của nó vẫn hỗ trợ PCT cho sự tương thích ngược).
Ngay sau đó, IETF (Internet Engineering Task Force)đã bắt đầu làm việc để phát triển một giao thức chuẩn để cung cấp các chức năng tương tự -> TLS ra đời.
TLS 1.0 được IETF phát triển dựa trên SSL 3.0. TLS được thông tin chi tiết trong RFC2246.

2.2.3 Giải thuật SSL và TLS
- SSL sử dụng giải thuật MAC(Message Authentication Code)
- TLS sử dụng giải thuật HMAC(Hashing for Message Authentication Code)
MAC và HMAC là hai phương thức bảo đảm tính toàn vẹn của dữ liệu khi truyền trong môi trường không tin cậy như Internet. HMAC có thêm các giải thuật băm.
- TLS được chuẩn hóa trong RFC 2246
- TLS được đính thêm mới một số thông điệp cảnh báo (alert message)
- TLS bao gồm thêm giải thuật Fortezza(giải thuật này không được công bố bởi các chính sách của IETF)

Các dịch vụ dùng SSL/TLS sử dụng các số cổng chuyên dụng được dành riêng bởi IANA -Internet Asigned Numbers Authority

2.2 Cấu trúc của giao thức SSL

- Cấu trúc và giao thức SSL được minh họa trong hình 1.1

hình 1.1: Cấu trúc của SSL và giao thức SSL

Theo hình 1.1 , SSL ám chỉ một lớp (bảo mật) trung gian giữa lớp vận chuyển (Transport Layer) và lớp ứng dụng (Application Layer). SSL được xếp lớp lên trên một dịch vụ vận chuyển định hướng nối kết và đáng tin cậy, chẳng hạn như được cung cấp bởi TCP.
- Về khả năng, nó có thể cung cấp các dịch vụ bảo mật cho các giao thức ứng dụng tùy ý dựa vào TCP chứ không chỉ HTTP. Thực tế, một ưu điểm chính của các giao thức bảo mật lớp vận chuyển (Transport layer) nói chung và giao thức SSL nói riêng là chúng độc lập với ứng dụng theo nghĩa là chúng có thể được sử dụng để bảo vệ bất kỳ giao thức ứng dụng được xếp lớp lên trên TCP một cách trong suốt.
- Tất cả chúng có thể được bảo vệ bằng cách xếp lớn chúng lên trên SSL (mẫu tự S được thêm vào trong các từ ghép giao thức tương ứng chỉ định việc sử dụng SSL). Tuy nhiên, chú ý rằng SSL có một định hướng client-server mạnh mẽ và thật sự không đáp ứng các yêu cầu của các giao thức ứng dụng ngang hàng.
- Tóm lại, giao thức SSL cung cấp sự bảo mật truyền thông vốn có ba đặc tính cơ bản:

1. Các bên giao tiếp (nghĩa là client và server) có thể xác thực nhau bằng cách sử dụng mật mã khóa chung.
2. Sự bí mật của lưu lượng dữ liệu được bảo vệ vì nối kết được mã hóa trong suốt sau khi một sự thiết lập quan hệ ban đầu và sự thương lượng khóa session đã xảy ra.
3. Tính xác thực và tính toàn vẹn của lưu lượng dữ liệu cũng được bảo vệ vì các thông báo được xác thực và được kiểm tra tính toàn vẹn một cách trong suốt bằng cách sử dụng MAC.
Tuy nhiên, điều quan trọng cần lưu ý là SSL không ngăn các cuộc tấn công phân tích lưu lượng. Ví dụ, bằng cách xem xét các địa chỉ IP nguồn và đích không được mã hóa và các sô cổng TCP, hoặc xem xét lượng dữ liệu được truyền, một người phân tích lưu lượng vẫn có thể xác định các bên nào đang tương tác, các loại dịch vụ đang được sử dụng, và đôi khi ngay cả dành được thông tin về các mối quan hệ doanh nghiệp hoặc cá nhân. Hơn nữa, SSL không ngăn các cuộc tấn công có định hướng dựa vào phần thực thi TCP, chẳng hạn như các cuộc tấn công làm tràn ngập TCP SYN hoặc cưỡng đoạt session.
Để sử dụng sự bảo vệ SSL, cả client lẫn server phải biết rằng phía bên kia đang sử dụng SSL. Nói chung, có ba khả năng để giải quyết vấn đề này:

1. Sử dụng các số cổng chuyên dụng được dành riêng bởi Internet Asigned Numbers Authority (IANA). Trong trường hợp này, một số cổng riêng biệt phải được gán cho mọi giao thức ứng dụng vốn sử dụng SSL.
2. Sử dụng số cổng chuẩn cho mọi giao thức ứng dụng và để thương lượng các tùy chọn bảo mật như là một phần của giao thức ứng dụng (bây giờ được chỉnh sửa đôi chút).
3. Sử dụng một tùy chọn TCP để thương lượng việc sử dụng một giao thức bảo mật, chẳng hạn như SSL trong suốt giai đoạn thiết lập nối kết TCP thông thường.

- Ngoài ra, việc xác định một tùy chọn TCP (nghĩa là khả năng thứ ba) là một giải pháp tốt, nhưng đó không được thảo luận nghiêm túc cho đến bây giờ. Thực tế, các số cổng riêng biệt đã được dành riêng và được gán bởi IANA cho mọi giao thức ứng dụng vốn có thể chạy trên SSL hoặc TLS (nghĩa là khả năng thứ nhất). Tuy nhiên, hãy chú ý việc sử dụng các số cổng riêng biệt cũng có khuyết điểm là đòi hỏi hai nối kết TCP nếu client không biết những gì mà server hỗ trợ. Trước tiên, client phải nối kết với cổng an toàn và sau đó với cổng không an toàn hay ngược lại. Rất có thể các giao thức sau này sẽ hủy bỏ phương pháp này và tìm khả năng thứ hai. Ví dụ, SALS (Simple Authentication và Security Layer) xác định một phù hợp để thêm sự hỗ trợ xác thực vào các giao thức ứng dụng dựa vào kết nối. Theo thông số kỹ thuật SALS, việc sử dụng các cơ chế xác thực có thể thương lượng giữa client và server của một giao thức ứng dụng đã cho.

3. Khái niệm về Encrypting File System (EFS) ?

- EFS là viết tắt của Encrypting File System. EFS có từ thời Windows 2000/2003/2008 trên dòng server và WIndows 2000/XP/Vista trên dòng máy trạm. EFS được sử dụng như một lớp bảo vệ dữ liệu bên ngoài lớp bảo vệ NTFS cho truy xuất nội bộ và NTFS + File Sharing Permission cho truy cập qua phần chia sẻ hay NTFS + IIS Web Permission cho truy cập qua web.

3.1 EFS mã hóa tài liệu ra sao ?

- EFS về bản chất sử dụng chứng chỉ điện tử (digital certificate) do nền tảng khóa công khai PKI cung cấp để kiểm soát việc ai được truy cập vào tập tin/ thư mục được EFS bảo vệ.
- EFS sử dụng các thuật toán DESX/3DES/AES với số lượng bit lên đến 256 bit để bảo vệ mã cá nhân (Private Key). Hiện có một số công cụ tự nhận là bẻ khóa được EFS nhưng bản chất ko pải là giải mã được mã khóa cá nhân mà chỉ dùng cách tấn công Brutal Force đề quét ra chuỗi khóa Private Key. Tuy nhiên bạn cần một máy tính siêu mạnh để thực hiện việc bẻ khóa một tài liệu được bảo vệ ở chế độ 256 bit.

3.2 EFS được sử dụng trong những tình huống an ninh nào ?

- EFS Component Driver sẽ kiểm tra tính tương tác với NTFS.
- EFS Driver tìm kiếm chữ kí Private Key của người mã hóa tài liệu trong Local Cert - Store.
- Nếu ko tìm thấy EFS Driver sẽ đăng kí để lấy chữ kí private key cho người dùng từ CA.
- Nếu EFS Driver tiếp tục ko kết nối được với CA nó sẽ tự tạo ra một chứng chỉ (self-signing)
- EFS tạo ra khóa FEK và mã hóa nội dung tài liệu với thuật toán DESX/3DES/AES.
- EFS tiếp tục dùng khóa công khai của người dùng đễ mã hóa tiếp khóa FEK với thuật toán RSA
- EFS sẽ lưu khóa FEK đã mã hóa trong Header DDF của tập tin mã hóa. Nếu quản trị đã cấu hình DRA thì khóa của agent này cũng sẽ được lưu trong DDF.
- Khi người dùng truy cập tập tin mã hóa thì pải có sẵn chứng chỉ private key thì mới xem được tập tin.
- DRA phải import Private key mới có thể mở mã hóa của tài liệu được bảo vệ bởi EFS

3.3 EFS làm việc với môi trường ko có PKI hay ko ?

- Ko có PKI: trong môi trường này còn được gọi là Standalone tức chính bản thân máy tính đó sẽ issue chứng nhận cho người dùng khởi tạo mã hóa.
- Có PKI: EFS sẽ xin chứng chỉ private key từ PKI được store trên Root CA (Standalone/Enterprise)/ Issue CA hoặc lấy từ AD.

4. Khái niệm IP Security
4.1 Các thao tác bảo mật.
4.2 Các bộ lọc IP Sec.
4.3 Triển khai IP Sec trên Windows Server 2003.

5. Tổng quan về Radius Server
5.1 Backend Cơ sở dữ liệu và máy chủ xác thực
5.2 RADIUS gói, thuộc tính, và giao thức xác thực
5.2.1 GÓI
5.2.2 ĐIỆP
5.2.3 THUỘC TÍNH
5.2.4 THỰC GIAO
5..2.5 PAP
5.2.6 Chap
5.2.7 MSCHAP (v1/v2)
5.3 Extensible Authentication Protocol (EAP)

III. Mô hình triển khai

Thực hành

1 ) HTTPS :
+ Cài đặt Enterprise CA
+ Default Website
+ Network Monitor
+ HTTPS

2 ) Secure Mail :
+ Cài đặt Mail Server Mdeamon
+ Cấu hình Windows Mail cho users
+ Admin sửa mail của users
+ User xin và cài đặt Certificates
+ User gửi mail có sign
+ Users gửi mail có encrypt

3 ) IP Security :
+ Cài đặt Network Monitor
+ Cấu hình IPSEC trên DC
+ Cấu hình IPSEC trên máy Client

4 ) Radius :
+ Cấu hình VPN – Client to gateway
+Cài IAS – Internet Authencation Services
+Cấu hình Radius Server

IV . Kết luận

Ðã quá 48 giờ kể từ lúc thảo luận của bạn được tạo ra. Bạn không thể điều chỉnh thảo luận này được nữa.
Xin cho biết cách khắc phục .

Topic tên là : Cần giúp đỡ về đề tài tốt nghiệp mã hoá và chứng thực
Mà ko edit được thì làm sao tôi có thể update được topic của tôi .
Mong admin trả lời giùm smilie

Cám ơn .

sao mình edit lại bài của mình thì nó lại báo "Ðã quá 48 giờ kể từ lúc thảo luận của bạn được tạo ra. Bạn không thể điều chỉnh thảo luận này được nữa " .
Cách khắc phục , giúp giùm mình với t-t

mình nghĩ làm VPN client to gateway là đủ rồi vì nó cũng liên quan đền Radius smilie

Cám ơn bạn đã cho góp ý mình sẽ xem và bổ sung SSL/TLS
Còn về Win 2k3 đúng là nó đã ngưng bán phiên bản nhưng đây là hdh nhẹ và dễ sứ dụng , mà bạn biết đó máy tính của sinh viên thì ... smilie