Mật khẩu AAA / TACACS + trên thiết bị chuyển mạch của Cisco luôn bị lỗi tại dấu nhắc mật khẩu thứ hai

Bất cứ khi nào đăng nhập vào thiết bị mạng bằng AAA / TACACS +, nếu tôi nhấn mạnh vào dấu nhắc mật khẩu sau dấu nhắc tên người dùng, lời nhắc mật khẩu thứ hai luôn thất bại ngay cả khi mật khẩu đúng. Tôi phải đợi lời nhắc tên người dùng một lần nữa và phải lấy đúng mật khẩu trên dấu nhắc mật khẩu đầu tiên ngay sau đó. Nói cách khác, bất cứ khi nào tôi thấy dấu nhắc mật khẩu thứ hai, nó sẽ không hoạt động.

Xem các tương tác vệ sinh và cấu hình dưới đây.

Xác minh quyền truy cập của người dùng
Tên đăng nhập: tên người dùng
Mật khẩu:

Mật khẩu: (luôn bị lỗi ở đây)
% Truy cập bị từ chối

Xác minh quyền truy cập của người dùng
Tên đăng nhập: tên người dùng
Mật khẩu:

Đã kết nối với s-site-rack-agg2.example.net trên dòng 1 (tên trang web).
s-site-rack-agg2 #

Điều gì có thể khác với lời nhắc mật khẩu thứ hai để giải thích cho hành vi này?

AAA điển hình và cấu hình liên quan tôi có là:

aaa mô hình mới
aaa xác thực đăng nhập nhóm mặc định tacacs + dòng cục bộ
aaa xác thực đăng nhập TIÊU THỤ
xác thực aaa cho phép tacacs nhóm mặc định + enable
aaa ủy quyền thực hiện mặc định nhóm tacacs + cục bộ nếu được xác thực
lệnh ủy quyền aaa 1 tacacs nhóm mặc định + cục bộ nếu được xác thực
lệnh ủy quyền aaa 7 tacacs nhóm mặc định + cục bộ nếu được xác thực
aaa ủy quyền lệnh 15 tacacs nhóm mặc định + cục bộ nếu được xác thực
aaa kế toán thực hiện mặc định nhóm bắt đầu dừng tacacs +
aaa lệnh kế toán 0 tacacs nhóm dừng bắt đầu mặc định +
lệnh aaa kế toán 1 nhóm bắt đầu dừng mặc định tacacs +
aaa lệnh kế toán 7 tacacs nhóm bắt đầu dừng mặc định +
lệnh aaa kế toán 15 tacacs nhóm bắt đầu dừng mặc định +
aaa hệ thống kế toán mặc định bắt đầu dừng nhóm tacacs +
!
giao diện nguồn ip tacacs Loopback0
máy chủ tacacs-server -prmiaryipremond- kết nối đơn
máy chủ tacacs-server -secondaryipremond- kết nối đơn
thời gian chờ máy chủ tacacs 10
tacacs-server direct-request
khóa máy chủ tacacs 7 -remond-
!
dòng con 0
 đăng nhập xác thực TIÊU THỤ
dòng vty 0 4
 vị trí -remond-
 thời gian chờ 60 0
 mật khẩu 7 -được yêu thích-
 vận chuyển đầu vào telnet ssh

Tôi sẽ gỡ lỗi trên máy chủ TACACS + của bạn trong khi bạn đang thử điều này.

Tôi sẽ cho rằng bạn chỉ muốn sử dụng xác thực TACACS và chỉ quay lại đăng nhập cục bộ nếu không thể truy cập máy chủ?

Hãy thử sử dụng cái này:
aaa authentication login default group tacacs+ line
aaa authentication enable default group tacacs+ enable

Cũng xem trang web này: Nó có một số ví dụ và giải thích tốt

http://my.safaribooksonline.com/book/networking/cisco-ios/0596527225/tacacsplus/i13896_ heada _4_2 # X2ludGVybmFsX0h0bWxWaWV3P3htbGlkPTA1OTY1MjcyMjUlMkZpNTAzNjNfX2hlYWRhX180XzEmcXVlcnk9

Tôi đoán là vì bạn có từ khóa "cục bộ" trong:
aaa authentication login default group tacacs+ local line

Xác thực TACACS + trả về lỗi, vì vậy bộ định tuyến thử thực hiện xác thực cục bộ. Tôi đoán bạn nên cung cấp cho chúng tôi line vtycấu hình vệ sinh. Nếu bạn có
line vty 0 15
login local

Sau đó, nó sẽ thực hiện xác thực tên người dùng / mật khẩu nếu không mật khẩu của nó

Tôi nghĩ rằng cấu hình của bạn khá nguy hiểm và bạn có vẻ thiếu quyết đoán nếu bạn đang sử dụng 'enable / line' hoặc 'local' làm dự phòng, câu trả lời đúng là cục bộ, không bao giờ sử dụng 'enable' và đặc biệt là không bao giờ 'line' cho bất cứ điều gì (dòng là hai- cách 'được mã hóa' không được băm một chiều).

Tôi muốn giới thiệu cấu hình này thay thế:

aaa new-model
! uses tacacs, fallsback to local user if tacacs not working
aaa authentication login default group tacacs+ local
! user gets enabled by tacacs or by enable password
aaa authentication enable default group tacacs+ enable
! console user is authorized as well (gets enabled, if such permission)
aaa authorization console
! configuration commands are authorized as well as exec commands (Good to prevent dangerous commands)
aaa authorization config-commands
! user privilege level is recovered from tacacs or from local account
aaa authorization exec default group tacacs+ local
! level 15 commands are authorized (you really only need this) 
aaa authorization commands 15 default group tacacs+ if-authenticated 
! level 1, 15 commands are logged (you really only need these two)
aaa accounting commands 1 default start-stop group tacacs+
aaa accounting commands 15 default start-stop group tacacs+
!
! fallback user consulted only when tacacs is broken
username sikrit privilege 15 secret <password>

Người dùng 'sikrit' sẽ được sử dụng khi tacacs không hoạt động (không thể sử dụng nếu câu trả lời của TACACS) không cần mật khẩu 'line' theo VTY, vì nó không bao giờ được tham khảo. Không cần mật khẩu 'enable', vì nó không bao giờ được hỏi ý kiến. Nếu bạn muốn người dùng sao lưu không kích hoạt, chỉ cần tạo một người khác với 'đặc quyền 1'.
Tuy nhiên tôi đã thêm hỗ trợ cho 'enable' nếu bạn muốn sử dụng nó vì một số lý do.

Nếu bạn đang sử dụng OOB và quyền truy cập OOB đã được bảo mật / xác thực, bạn có thể muốn cho phép người dùng OOB luôn sử dụng xác thực cục bộ, chỉ trong trường hợp TACACS bị hỏng nhưng IOS nhầm tưởng là không, sau đó bạn sẽ thêm một cái gì đó như thế này :

aaa authentication login CONSOLE local
!
line con 0
 login authentication CONSOLE

Tôi không chắc cấu hình thiết bị cục bộ của bạn sẽ bị đổ lỗi cho điều này, mà là chính máy chủ TACACS của bạn. TACACS ủy nhiệm nhắc nhở tên người dùng / mật khẩu từ máy chủ TACACS (và có thể là cửa hàng nhận dạng bên ngoài) cho thiết bị, vì vậy, nếu bạn đang sử dụng ACS (ví dụ) và thiết lập để nói chuyện với AD để xác thực người dùng, bạn cần nghĩ về lời nhắc tên người dùng / mật khẩu đến từ bộ điều khiển miền thay vì chính thiết bị.

Gần đây tôi đã gặp phải một vấn đề chính xác như thế này đã được sửa bởi một bản vá cho ACS - một lần nữa, tôi cho rằng bạn đang sử dụng ACS và lấy nó từ AD để xác minh người dùng / xác thực nhóm, v.v. ID lỗi của Cisco là CSCtz03211 và về cơ bản, ACS 5.3 đã gửi nhiều lần thử tự động tới AD cho mỗi lần thử "xác thực / mật khẩu" cho thiết bị. Điều này sẽ dẫn đến hành vi nếu người dùng sử dụng mật khẩu trong lần thử đầu tiên, nhiều trường hợp kết hợp tên người dùng / mật khẩu sai được gửi đến AD và tài khoản người dùng thực sự bị khóa, do đó dẫn đến lần thử đăng nhập thất bại sau đó thiết bị ngay cả khi người dùng nhập đúng tên người dùng / mật khẩu của họ vào lần thử thứ hai (hành vi này tất nhiên thay đổi theo ngưỡng khóa bạn đã đặt trên tài khoản người dùng trong AD).

Chỉ cần một cái gì đó để xem xét (không có kiến ​​thức về việc triển khai máy chủ TACACS của bạn).