مقایسه TACACS+ و RADIUS و عیب‌یابی AAA مرکزی

انتخاب Protocol بر اساس Use Case

TACACS+ معمولاً برای Device Administration در محیط Cisco انتخاب شناخته‌شده‌ای است و RADIUS در Network Access نیز حضور گسترده دارد. سازمان ممکن است هر دو را داشته باشد: TACACS+ برای Administrator Login و RADIUS برای 802.1X یا VPN. انتخاب واقعی به Platform، Identity Infrastructure، Policy و Operational Model بستگی دارد.

برای CCNA باید بتوانی Device را به‌عنوان AAA Client برای هر دو Protocol درک کنی؛ هدف حفظ جزئیات محصول یک Vendor خاص نیست.

Device Administration -> often TACACS+
Network Access -> often RADIUS
Actual design -> policy/platform dependent

Runbook مشترک از Client تا Server

Troubleshooting را از نزدیک‌ترین نقطه به User شروع کن: آیا SSH Connection تشکیل می‌شود؟ اگر بله، Method List فعال چیست؟ آیا Device به Server Reachability دارد؟ Source IP چیست؟ آیا Server Request را می‌بیند؟ Result چیست؟ سپس Authorization و Accounting را بررسی کن.

1 SSH
2 VTY method
3 AAA server reachability
4 source/ACL
5 shared secret/client definition
6 user authentication
7 authorization
8 accounting

این Runbook برای هر دو Protocol کار می‌کند و مانع می‌شود تیم بی‌هدف بین Device و Identity Team Ticket جابه‌جا کند.

Reject، Timeout و Deny

Reject یعنی Server Request را دریافت کرده و Authentication را نپذیرفته است. Timeout یعنی Device پاسخ معتبر در زمان مقرر نگرفته؛ علت می‌تواند Path، ACL، Server Down یا Secret/Packet Handling باشد. Authorization Deny یعنی هویت ممکن است معتبر باشد اما Access موردنظر مجاز نیست.

Reject != Timeout != Authorization Deny

Local Fallback معمولاً برای Timeout/Unavailable طراحی می‌شود، نه برای Reject صریح. اگر Reject باعث Local Login شود، Central Policy می‌تواند دور زده شود؛ Design را دقیق Verify کن.

Redundancy و Failover

Server Group می‌تواند چند AAA Server داشته باشد. Device بر اساس Configuration و Server State درخواست را به Serverهای دیگر بفرستد. سپس Local Method می‌تواند آخرین Recovery باشد. Test Plan باید Failure یک Server، Failure کل Group و Recovery را جدا بررسی کند.

AAA-GRP: Server1 + Server2 -> Local break-glass

اگر دو Server پشت یک Network Path مشترک باشند، Redundancy واقعی محدود است. معماری باید Failure Domain را در نظر بگیرد.

Accounting در Failure Server ممکن است Gap داشته باشد؛ این موضوع در Audit و Security Operations باید مستند شود.

Incident Documentation

برای Incident AAA حداقل این موارد را ثبت کن: Device، Management IP، Source IP AAA، Username بدون افشای Secret، Timestamp، Protocol، Method List، Server Result، Change اخیر، Root Cause و Before/After Evidence. این اطلاعات اجازه می‌دهد Identity Team و Network Team روی یک Timeline مشترک کار کنند.

Device / Source / Server / Time / Result / Root Cause / Fix / Verification

پس از Fix علاوه بر Login، Authorization و Accounting را هم Verify کن. فقط رسیدن به Prompt کافی نیست اگر User Privilege اشتباه است یا Audit Record ساخته نمی‌شود.