Настройка Cisco ACS 5.3 в связке с Active Directory
Cisco ACS (Access Control Server) — система для централизованной аутентификации, авторизации и аккаутинга пользователей на всякого рода оборудовании, в частности на активном сетевом оборудовании различных производителей.
Имея достаточно небольшой опыт работы системным администратором в крупной компании enterprise сегмента пришёл к выводу, что каждый системный администратор в идеале должен иметь одну учётную запись для авторизации на всех необходимых ему ресурсах: сетевое оборудование, серверы, рабочие станции и т. д. Это связано как с удобством администрирования, так и с безопасностью. В случае увольнения человека можно залочить всего одну учёту в одном хранилище и пропадёт доступ абсолютно ко всему. Но идеальных случаев, как известно, не бывает. В статье мы попробуем приблизиться к идеалу и настроим авторизацию пользователей на активном сетевом оборудовании с использованием учётной записи Active Directory.
Итак, в нашей сети 3 кампуса: два пользовательских и серверная ферма.
В соответствие с кампусной структурой построения сети устройства подразделяются на группы: access layer, distribution layer, core layer. Отдельно существует группа border для управления пограничным железом: пограничные маршрутизаторы, сетевые экраны, VPN шлюзы, etc.
Полномочия администраторам предоставляются на основе иерархических политик доступа. Администраторам имеющим небольшой опыт работы разрешается работать только с оборудованием уровня access, причём пользовательского некритичного кампуса. С приобретением опыта администраторам даются полномочия на уровень access серверной фермы. При этом они так же могут работать с пользовательским оборудованием. Для разграничения доступа применяется следующая модель. Структура полномочий представлена на рисунке:
Каждая прямоугольная область — полномочия на оборудование, которые предоставлены определённой группе администраторов
Настройка сервера ACS
После скачивания с торрент-трекера покупки новой железки Cisco 1120 и первоначальной инсталляции мы попадаем на страницу ввода логина и пароля:
Вводим логин и пароль, вбитые при инсталляции и попадаем на стартовую страницу:
Network Resources
В секции Network Resources описываются местоположения, типы устройств и, собственно, сами устройства.
Для начала нам необходимо описать устройства, которые будут подключены к серверу. Заходим в секцию Network Resources → Location и создаём как минимум 3 местоположения устройств: Кампус 1, Кампус 2, Серверная ферма:
В секции Device Type создаём 3 типа устройств: AccessLayerSwitches, DistributionLayerSwitches, CoreLayerSwitches.
Далее в секции Network Devices and AAA Clients описываем ip адреса устройств и привязываем их к местоположениям и типам. Cisco ACS может использовать проколы tacacs+ и radius. Наши устройства будут работать по протоколу Tacacs+, ставим галочку напротив Tacacs+. В поле Shared Secret вбиваем ключ.
Настройки секции Network Resources закончены.
Users and Identity Stores
Переходим к настройке связки с Active Directory. Открываем секцию Users and Identity Stores → External Identity Stores → Active Directory. Заполняем поля. Для соединения с AD необходима учётка доменного администратора. Зачем — не знаю. С учёткой обычного пользователя не работает.
Во вкладке Directory Groups осуществляется привязка к группам Active Directory
Вкладка Directory Attributes нужна для настройки политик для конкретного пользователя.
Настройка связки с AD на этом закончена.
Policy Elements
Переходим к конфигурированию элементов политик. Создадим профиль полного доступа к устройству. Для этого в секции Policy Elements переходим в группу Authorization and Permissions → Device Administration → Shell Profiles. Создаём профиль FullAccess. Во вкладке Common Tasks задаём максимальные привилегии:
Нажимаем Submit. Всё, настройки профилей закончены.
Access Policies
Непосредственно сами политики доступа настраиваются в секции Access Policies.
Для начала необходимо создать политику для работы с Active Directory. Нажимаем на ссылку Access Services и создаём новую политику доступа:
Ставим 2 галочки Identity и Authorization.
Далее необходимо указать по какой политике доступа будут работать устройства. Нажимаем на ссылку Service Selection Rules. Создаём правило по которому будут матчиться устройства, работающие по протоколу tacacs+:
По этому правилу все устройства, запрашивающие данные по протоколу tacacs+ будут обрабатываться политикой, созданной выше.
Переходим непосредственно к настройке политик доступа. В пункте Identity настраивается источник учётных записей. Выбираем Active Directory. В пункте Authorization прописываются правила для авторизации пользователей. По-умолчанию нужные нам столбцы недоступны, их необходимо принудительно активировать нажав кнопочку Customize.
В секции Customize Results выбираются возможные варианты профиля командной строки и набор команд. В нашем случае используется только набор команд.
Для создания правила нажимаем кнопку Create.
Проставляем галочки и условия. Пункт AD1:mailNickname нужен если правило настраивается с привязкой к конкретному имени пользователя, а не всей группе.
Далее необходимо настроить правила в соответствие с первой картинкой.
Примеры настройки tacacs+ авторизации на устройствах Cisco и HUAWEI
Авторизация проходит через через сервер tacacs, если он недоступен, но проверяются локальные учётные записи.
Juniper SRX (хаброюзер m0ps):
Далее в Shell Profiles создаем профиль JuniperFullAccess в Custom Attributes которого создаем атрибут с именем local-user-name и значением — имя шаблона профиля пользователя (в моем примере — REMOTE_SU).
Теперь идем в Access Policies и в меню Authorization создаем соответствующее правило, согласно которого всем авторизовавшимся на девайсах Juniper применяется соответствующий Shell Profile.
Дошли руки собрать лабу.
Все «ок», за исключением того, что все пользователи из АД могут залогиниться на устройства с уровнем привилегий 1. И только пользователи из указанной группы имеют уровень привилегий 15. Нашел документ на циско.ком аналогичный этому топику — в нем все шаги совпадают.
Я что-то сделал не так, или нужно как-то ограничивать возможность логиниться на устройства пользователей, которые не состоят в «интересных» группах?
Прошу прощения, вопрос можно считать снятым. Дело в том, что есть стандартное правило, согласно которого если не одно из сконфигурированных правил не подходит Shell Profile был Permit Access, а вот Command Sets — Denny all Commands.
Соответственно в Shell Profile выбираем DenyAccess и проблема решена.
Думаю стоит уточнить это в статье, т.к. еще кто-то может наступить на эти грабли.
Access control server что это
ACS is a scalable, high-performance Remote Access Dial-In User Service (RADIUS) and Terminal Access Controller Access Control System (TACACS+) security server. As the centralized control point for managing enterprise network users, network administrators, and network infrastructure resources, ACS provides a comprehensive identity-based network-access control solution for Cisco intelligent information networks.
ACS extends network-access security by combining traditional authentication, authorization, and accounting (AAA — pronounced "triple A") with policy control. ACS enforces a uniform network-access security policy for network administrators and other network users.
ACS supports a broad variety of Cisco and other network-access devices (NADs), also known as AAA clients, including:
•Wired and wireless LAN switches and access points
•Edge and core routers
•Dialup and broadband terminators
•Content and storage devices
•Voice over IP (VoIP)
•Firewalls
•Virtual private networks (VPNs)
Figure 1-1 illustrates the role of ACS as a traditional network access control/AAA server.
Figure 1-1 A Simple AAA Scenario
Network Admission Control (NAC)
ACS is a critical component of the Cisco Network Admission Control (NAC) framework. Cisco NAC is a Cisco Systems-sponsored industry initiative that uses the network infrastructure to enforce security-policy compliance on all machines seeking to access network computing resources, thereby limiting damage from viruses and worms. With NAC, network access to compliant and trusted PCs can be permitted, while the access of noncompliant devices can be restricted. See Figure 1-2.
Figure 1-2 ACS Extended to NAC
Identity-Based Networking Services (IBNS)
ACS is also an important component of the Cisco Identity-Based Networking Services (IBNS) architecture. Cisco IBNS is based on Extensible Authentication Protocol (EAP) and on port-security standards such as IEEE 802.1x (a standard for port-based network-access control) to extend security authentication, authorization, and accounting from the perimeter of the network to every connection point inside the LAN. New policy controls such as per-user quotas, virtual LAN (VLAN) assignments, and access-control lists (ACLs) can be deployed, due to the extended capabilities of Cisco switches and wireless access points to query ACS over the RADIUS protocol.
ACS Features, Functions and Concepts
ACS as the AAA Server
ACS functions as an AAA server for one or more NADs. The NADs are AAA clients of the ACS server. You must configure each client NAD to direct end-user host access requests to the ACS by using the TACACS+ or RADIUS protocols.
TACACS+ is traditionally used to provide authorization for network administrative operations on the network infrastructure itself; RADIUS is universally used to secure the access of end-users to network resources.
Basically, the NAD serves as the network gatekeeper, and sends an access request to ACS on behalf of the user. ACS verifies the username, password and possibly other data by using its internal database or one of the configured external identity directories. ACS ultimately responds to the NAD with an access denied or an access-accept message with a set of authorization attributes. When ACS is used in the context of the NAC architecture, additional machine data, known as posture, is validated as well, before the user is granted access to the network.
AAA Protocols—TACACS+ and RADIUS
ACS can use the TACACS+ and RADIUS AAA protocols.
Table 1-1 compares the two protocols.
TACACS+
ACS conforms to the TACACS+ protocol as defined by Cisco Systems in draft 1.78. For more information, refer to the Cisco IOS software documentation at http://www.cisco.com .
RADIUS
ACS conforms to the RADIUS protocol as defined in the draft of April 1997 and in the following Requests for Comments (RFCs):
•RFC 2138, Remote Authentication Dial In User Service
•RFC 2139, RADIUS Accounting
•RFC 2284
•RFC 2865
•RFC 2866
•RFC 2867
•RFC 2868
•RFC 2869
The ports used for authentication and accounting have changed in RADIUS RFC documents. To support the older and newer RFCs, ACS accepts authentication requests on port 1645 and port 1812. For accounting, ACS accepts accounting packets on port 1646 and 1813.
In addition to support for standard Internet Engineering Task Force (IETF) RADIUS attributes, ACS includes support for RADIUS vendor-specific attributes (VSAs). We have predefined the following RADIUS VSAs in ACS:
•Cisco Building Broadband Service Manager (BBSM)
•Cisco IOS/PIX 6.0
•Cisco VPN 3000/ASA/PIX 7.x+
•Cisco VPN 5000
•Cisco Airespace
•Ascend
•Juniper
•Microsoft
•Nortel
ACS also supports up to 10 RADIUS VSAs that you define. After you define a new RADIUS VSA, you can use it as you would one of the RADIUS VSAs that come predefined in ACS. In the Network Configuration section of the ACS web interface, you can configure AAA clients to use a user-defined RADIUS VSA as the AAA protocol. In Interface Configuration, you can enable user-level and group-level attributes for user-defined RADIUS VSAs. In User Setup and Group Setup, you can configure the values for enabled attributes of a user-defined RADIUS VSA.
For more information about creating user-defined RADIUS VSAs, see Custom RADIUS Vendors and VSAs, page 8-19 .
Platforms
ACS is available on two platforms, ACS for Windows and ACS for the Solution Engine. ACS for Windows is a software platform. The Solution Engine is a hardware and software platform that requires a network appliance.
The platforms are nearly identical. However, only Windows supports Open Database Connectivity (ODBC) databases, and the CSUtil.exe database utility. Support for the Solution Engine, which is not required for Windows, includes the Remote Agent, the Simple Network Management Protocol (SNMP), File Transfer Protocol (FTP) server support, a serial console, and support for the Cisco Security Agent.
This guide identifies information exclusively belonging to one platform as "ACS for Windows only" or "ACS Solution Engine only." All other text belongs to both platforms.
Additional Features in This Release
This release of ACS provides the following features that protect networked business systems:
•Improved Compliance Support—This release contains new ACS administrator permissions to improve password management and audit reports for regulatory compliance (for example, Sarbanes-Oxley (SOX)). ACS includes the following capabilities for:
Authentication:
–Forcing periodic change of administrator's password
–Applying password structure policy
–Forcing administrator's password change for inactive account
–Preventing the reuse of password (password history)
–Disabling administrator accounts for inactivity
–Disabling administrator accounts after failed logins
–Allowing ACS administrators to change own passwords
Audit and Reporting:
–Logging all administrative actions via Syslog, in addition to existing logging targets.
–Controlling administrators' access to log file configuration in order to prevent the disablement of specific audit logging.
–Adding new reports for administrators privileges
Authorization: Providing a read-only privilege for users and groups.
•External database support for MAC Authentication Bypass—The ability to maintain MAC address lists in an external LDAP server; and map MAC addresses to user groups has been added to this release.
•Improved diagnostics and error messages—Improved the diagnostic information about certificate mismatches with HCAP and GAME servers have been added to this release. The raw dump of GAME and HCAP messages is in a readable format and the authentication failure codes are now more intuitive.
•PEAP/EAP-TLS Support — The authenticator side of PEAP/EAP-TLS as a protocol enhancement is included in this release. This permits ACS to authenticate clients with PEAP by using EAP-TLS as the phase two inner method, and enables certificate based authentication to occur within a secure tunnel, encrypting identity information. Since EAP-TLS normally relies on client-side certificates for authentication, the PEAP tunnel will protect the client's certificate content.
•Logging and Reporting Extensions—New internal mechanisms for logging have been added to this release, to create consistent log levels and improved performance. Syslog is supported and the capability to log ACS messages to remote servers that support Syslog standard is available.
•Multiple concurrent logging destinations— Log data may be sent to multiple destinations simultaneously.
•Enhanced remote agent support for logging— You can expose reports externally that were previously provided only locally, for files from previous versions, for example, sending audit reports to remote agent on appliance.
•RADIUS AES Key Wrap Functionality —This feature supports a secure, certified mode of operation, notably in a Federal Information Processing Standard (FIPS)-compliant wireless solution. RADIUS Key Wrap support with EAP-TLS authentication in ACS, is another step towards satisfying the set of security requirements in Cisco's practical, deployable, and interoperable secure solutions. AES replaces MD5 encryption.
•Cisco NAC support—ACS 4.1 acts as a policy decision point in NAC deployments. By using configurable policies, it evaluates and validates the credentials that it receives from the Cisco Trust Agent (posture), determines the state of the host, and sends a per-user authorization to the network-access device: ACLs, a policy based access control list, or a private VLAN assignment. Evaluation of the host credentials can enforce many specific policies, such as OS patch level and antivirus DAT file version. ACS records the policy evaluation result for use with monitoring systems. Before granting network access, ACS 4.1 also allows third-party Audit Vendors to audit hosts without the appropriate agent technology. ACS policies can be extended with external policy servers to which ACS forwards posture credentials. For example, credentials specific to an antivirus vendor can be forwarded to the vendor's antivirus policy server, and audit policy requests can be forwarded to third-party audit products. For more information, see Chapter 13, "Posture Validation."
–GAME Group Feedback— This feature provides the ability to authorize a host based on checking the device-type categorization returned from authentication as a user-group against an audit server.
–Expanded agentless support— This feature adds support for auditing agentless hosts connected to a Layer 2 Network Access Device (NAD). The agentless host is admitted to a quarantine network where it can receive an IP address and only then instantiate the audit. When instantiated, the audit will continue as with a regular Layer 3 host.
•Extended replication components—Improved and enhanced replication components have been added to this release. Administrators now can replicate:
–Posture validation settings
–Additional logging attributes
•Audit support for MAC Authentication Bypass —Audit processing has been enhanced to include MAC Authentication Bypass (MAB). MAB enables double checking an audit request against a MAC authentication policy and an Audit Policy, and combines the evaluation of these two policies.
•Audit Verification of MAC Exceptions — You can apply MAC exceptions to NAC audit requests. Dual verification of endpoints is then possible. You can check whether the user group (which signifies the device type) that the agentless request processing returns matches the device type that the audit server returns, and you can define a policy for handling mismatches.
•Japanese Microsoft Windows Support—New support for the Japanese version of Microsoft Windows 2003 at the service pack level is available. Only ACS for Windows supports the Japanese version of Windows 2003. The ACS Solution Engine does not support the Japanese OS.
Note We do not support distributed ACS deployments in a NAT environment.
Authentication
Authentication determines user identity and verifies the information. Traditional authentication uses a name and a fixed password. More secure methods use technologies such as Challenge Authentication Handshake Protocol (CHAP) and One-time Passwords (OTPs). ACS supports a variety of these authentication methods.
A fundamental implicit relationship exists between authentication and authorization. The more authorization privileges granted to a user, the stronger the authentication should be. ACS supports this relationship by providing various methods of authentication.
This section contains the following topics:
•Authentication Considerations
•Authentication and User Databases
•Authentication Protocol-Database Compatibility
•Passwords
•Other Authentication-Related Features
Authentication Considerations
Username and password is the most popular, simplest, and least-expensive method of authentication. The disadvantage is that this information can be told to someone else, guessed, or captured. Simple unencrypted username and password is not considered a strong authentication mechanism but can be sufficient for low authorization or privilege levels such as Internet access.
You should use encryption to reduce the risk of password capturing on the network. Client and server access-control protocols such as TACACS+ and RADIUS encrypt passwords to prevent them from being captured within a network. However, TACACS+ and RADIUS operate only between the AAA client and ACS. Before this point in the authentication process, unauthorized persons can obtain clear-text passwords, such as:
•The communication between an end-user client dialing up over a phone line
•An Integrated Services Digital Network (ISDN) line terminating at a network-access server
•Over a TELNET session between an end-user client and the hosting device
Authentication and User Databases
ACS supports a variety of user databases. It supports the ACS internal database and several external user databases, including:
•Windows User Database
•Generic Lightweight Directory Access Protocol (LDAP)
•Novell NetWare Directory Services (NDS) when used with Generic LDAP
•LEAP Proxy Remote Access Dial-In User Service (RADIUS) servers
•Token servers
•Open Database Connectivity (ODBC)-compliant relational databases (ACS for Windows)
Authentication Protocol-Database Compatibility
The various password protocols that ACS supports for authentication are supported unevenly by the various databases that ACS supports. For more information about the password protocols that ACS supports, see Passwords.
Table 1-2 specifies non-EAP authentication protocol support.
Cisco ACS Secure Access Control System
In this article, you learn about the Cisco ACS Secure Access Control System Products. In Order to implement AAA solution in a networking environment, we must need Server Infrastructure which should able to host TACACS or Radius Type Services.
Under various options, one option is feed-based software which has TACACS and Radius service
So, CISCO developed a product that has all these options combined together and It is called CISCO ACS and here ACS stands for Access control Server.
CISCO ACS Product Options
1) Appliance -Based Versions
2) Software-Based Versions
1) Appliance Based version
- It is a Linux based which has ACS 5.X pre-installed.
- You can use TACACS and Radius since both options available.
- You can use the GUI.
- It can be easily integrated with Microsoft Active Directory.
2) Software-Based Version
- It could be installed in a Virtualized environment like VM ware or it could be a physical server like a Windows-based server which is a windows-based version of this.
- This is a truly scalable solution for AAA.
- It is a centralized database for all devices likes firewall, switch, router Etc.
The benefit of CISCO ACS product
- ACS is a complete access control and confidentiality control product that that means it can easily integrate with other components like other policy or end-point components.
- ACS supports various authentication protocols available like PAP, MS_CHAP, EAP-TLS,
- There are two types of authentication protocols are there first is for Network access control and the other is for Device access control. For Network access control it uses Radius and for Devices, it could be used TACACS+
- It could be easily managed centralized and very friendly Graphical user interface it has.
- ACS is used for monitoring and reporting for logs. It’s friendly GUI can be used to export logs and use for auditing.
- ACS5.8 could be Integrate with RSA token for two-factor authentications.
How CISCO ACS product works
Step1
As per Screenshot above Endpoint user or Supplicant Hits traffic against any network devices like Wireless LAN controller.
Step 2
The network devices ask for username and password.
Step3
The user provides usernames and passwords to the network devices.
Step 4
The device sends these credentials details to CISCO ACS.
Step5
These credentials or details would check against the ACS database and return that information
step 6
If the user is already added in ACS that means which that allowed access device pass this to user due to which user could access the device.
If not allowed user will be blocked or won’t get access to the device.
It could check against Active Directory that if the user has which role like admin, read/Write.
What is Cisco ACS?
Cisco Access Control Server (ACS) is an authentication, authorization, and accounting (AAA) platform that lets you centrally manage access to network resources for a variety of access types, devices, and user groups. It is used for the following purposes:
- device administration – authenticates administrators, authorizes commands, and provides accounting functions.
- remote access – it can work with remote network access devices to enforce access policies.
- wireless – authenticates and authorizes wireless users and hosts and enforces wireless policies.
- network admission control – communicates with posture and audit servers to enforce admission control policies.
ACS is usually used to centrally manage the users and control what they are authorized to do. Users are created locally on the ACS server and the routers and switches are configured to use ACS for authentication and authorization. This way, you can avoid creating the same users locally on every router and switch in your network. ACS server can also use an external user database (such as Microsoft Active Directory) for authentication purposes.
An example ACS deployment scenario can be seen in the picture below (image source: Cisco):