Từ chối RADIUS so với không phản hồi: khi nào đăng nhập cục bộ chạy

Việc giữ một tài khoản cục bộ khẩn cấp không biến nó thành cơ hội thứ hai cho mọi lần đăng nhập bị từ chối. Trong mô hình AAA của Cisco IOS và IOS XE, cơ sở dữ liệu đó chỉ được hỏi khi phương thức trước đó thất bại theo một cách cụ thể, và một máy chủ RADIUS trả lời bằng từ chối không thất bại theo cách đó. Tài khoản cục bộ bao phủ một phương thức không thể truy cập, không phải phương thức bị từ chối. Tin vào điều ngược lại biến một quyết định chính sách thành việc săn tìm một lỗi máy chủ không tồn tại.

Vì sao danh sách phương thức trông như một cái thang

Một dòng như aaa authentication login default group radius local được đọc từ trái sang phải, và hầu hết mọi người đọc nó như thử RADIUS, rồi thử cơ sở dữ liệu cục bộ. Cú pháp mời gọi cách đọc đó vì danh sách là một chuỗi. Ý nghĩa hẹp hơn: danh sách nêu tên các phương thức xác thực, và quy tắc chuyển từ phương thức này sang phương thức kế tiếp phụ thuộc vào kết quả của phương thức trước, chứ không phải việc cho người dùng thêm một lần thử.

Một phương thức trả về lỗi và một phương thức trả về thất bại dẫn đến những kết quả khác nhau ở đây. Từ chối là một câu trả lời, vì máy chủ đã xử lý thông tin đăng nhập và nói không, và danh sách dừng ở đó. Một máy chủ không thể truy cập, một yêu cầu hết hạn hoặc một phản hồi không thể xác thực là trường hợp cho phép phương thức tiếp theo chạy, và chỉ ở nơi việc xử lý lỗi của nền tảng được cấu hình như vậy. Đó là lý do lời khuyên cổ điển thêm local hoạt động khi có sự cố và không làm gì với mật khẩu sai. Thay vào đó, hãy đọc danh sách như hai câu hỏi: phương thức nào trả lời, và nền tảng coi đâu là câu trả lời.

Tách danh sách phương thức khỏi nhóm máy chủ

Danh sách phương thức là một lớp và nhóm máy chủ là một lớp khác. Từ khóa group radius nêu tên một nhóm mà thứ tự bên trong, các lần thử lại, thời gian chờ và việc phát hiện máy chủ chết thuộc về nhóm, trong khi phương thức cục bộ là một lớp phía trên nó. Vì vậy việc chỉnh bất cứ thứ gì bên trong nhóm không thể biến một sự từ chối thành đường dự phòng. Hãy xác nhận dịch vụ thực sự tham chiếu danh sách nào trước khi thay đổi một trong hai lớp.

In cấu hình AAA và đọc danh sách mà dịch vụ trỏ tới, không phải giá trị mặc định mà bạn nhớ là đã viết. Hãy làm việc đó từ thiết bị nơi dịch vụ thực sự kết thúc.

show running-config | section aaa
show radius server-group RAD-GRP
show aaa servers

Bảng máy chủ báo cáo trạng thái và bộ đếm của từng mục, cho biết cổng có tới được máy chủ trong lần thử hay không. Một máy chủ được đánh dấu là hoạt động với bộ đếm yêu cầu tăng lên đã trả lời, nên lần đăng nhập thất bại là một quyết định chứ không phải sự cố kết nối.

Đọc phản hồi trước khi đọc nhật ký

Mã phản hồi nêu tên kết quả và ngụ ý bước tiếp theo của chính nó. Access-Reject nghĩa là phần phía sau đã đưa ra quyết định, nên bằng chứng hữu ích là chính sách đã khớp và trạng thái tài khoản phía sau nó. Access-Challenge nghĩa là cuộc trao đổi muốn một bước được hỗ trợ khác như yếu tố thứ hai, và đường dự phòng cục bộ sẽ âm thầm bỏ qua điều mà chính sách yêu cầu.

Tái tạo một lần thử với một tài khoản kiểm thử được chỉ định để phản hồi và bản ghi phía sau có thể được so sánh ở cùng một dấu thời gian. Hãy dùng thông tin đăng nhập mà bạn được phép làm cho thất bại.

test aaa group RAD-GRP svc-ops 'LabPass!24' legacy
debug radius authentication

Một mục máy khách RADIUS bị thiếu hoặc không được nhận diện là nguyên nhân phổ biến của thời gian chờ im lặng, vì máy chủ nhận yêu cầu, không tìm thấy định nghĩa máy khách phù hợp và bỏ nó đi mà không trả lời. Sự không khớp của bí mật chia sẻ cũng thường trông giống thời gian chờ, vì phản hồi không qua được xác thực và bị loại bỏ. Không điều nào trong số đó trông giống Access-Reject, và không điều nào được sửa bằng cách thêm một tài khoản cục bộ. Hãy kiểm tra định nghĩa máy khách và bí mật ở cả hai bên trước khi chạm vào danh sách phương thức.

Vì sao tài khoản cục bộ chưa bao giờ chứng minh được gì

Một tài khoản đứng sau một nhóm trong danh sách chỉ chứng minh rằng ai đó đã lên kế hoạch cho một sự cố. Nó không nói gì về việc kế hoạch có hiệu quả hay không, vì trường hợp kiểm tra nó là trường hợp không ai luyện tập: máy chủ ngừng trả lời. Một lần đăng nhập cục bộ không bao giờ được chạm tới trong vận hành bình thường có thể mang một mật khẩu hết hạn hoặc trạng thái bị khóa trong nhiều tháng mà không ai nhận ra.

Truy cập khẩn cấp là một quyết định thiết kế, không phải tác dụng phụ của cấu hình. Hãy cho nó một tài khoản hạn chế riêng, một người phụ trách riêng và một quy trình khôi phục bằng văn bản, và đưa việc luân chuyển bí mật chia sẻ vào quy trình đó. Giữ một mật khẩu cục bộ cùng tên cho mọi người dùng trung tâm là mẫu âm thầm đưa trở lại quyền truy cập mà bạn tưởng đã gỡ bỏ.

Bài kiểm tra quan trọng là có chủ đích, và nó sẽ làm gián đoạn đăng nhập trong khi chạy. Chính vì thế nó thuộc về một cửa sổ đã lên lịch với bước hoàn tác được viết trước.

Kiểm tra đường dự phòng trong một cửa sổ bảo trì

Hãy sắp xếp bài kiểm tra sao cho bạn không bao giờ gỡ bỏ lối vào cuối cùng. Xác nhận trước một đường quản trị độc lập, sau đó truy cập thông thường được phép, sau đó một sự từ chối có chủ đích, sau đó hành vi sự cố đã được phê duyệt. Bốn trường hợp đó có kết quả mong đợi khác nhau, và gộp chúng vào một bài kiểm tra là cách người ta tự khóa mình ra khỏi một thiết bị mà họ vẫn cần.

Chạy mọi kiểm tra từ một phiên console hoặc từ một đường ngoài băng, để một sai sót không thể đóng phiên bạn đang làm việc. Console là con đường duy nhất không phụ thuộc vào thành phần đang được kiểm tra.

show aaa servers
show running-config | include aaa authentication
test aaa group RAD-GRP svc-ops 'LabPass!24' legacy

Sau đó, khôi phục cấu hình trước đó và xác nhận các bộ đếm lại nhúc nhích ở lần đăng nhập thật tiếp theo. Nếu sự từ chối có chủ đích tạo ra một lần đăng nhập cục bộ thay vì từ chối, thì danh sách hoặc việc xử lý lỗi không phải như bạn tin, và phát hiện đó quan trọng hơn sự cố bạn đã bắt đầu. Ghi kết quả vào bản ghi thay đổi bên cạnh tên tài khoản và ngày kiểm tra.