Este documento explica como configurar um Controller de LAN Wireless (WLC) e um Access Control Server (Cisco Secure ACS) de modo que o servidor AAA possa autenticar usuários gerentes no controlador. O documento também explica como diferentes usuários gerentes podem receber diferentes privilégios usando os Atributos Específicos de Fornecedor (VSAs) retornados do servidor Cisco Secure ACS RADIUS.
Certifique-se de atender a estes requisitos antes de tentar esta configuração:
Conhecimento de como configurar parâmetros básicos em WLCs
Conhecimento de como configurar um servidor RADIUS como o Cisco Secure ACS
As informações neste documento são baseadas nestas versões de software e hardware:
Controlador de LAN sem fio Cisco 4400 que executa a versão 7.0.216.0
Um Cisco Secure ACS que executa o software versão 4.1 e é usado como um servidor RADIUS nesta configuração.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.
Nesta seção, você recebe as informações sobre como configurar a WLC e o ACS para o propósito descrito neste documento.
Este documento utiliza a seguinte configuração de rede:
Este exemplo de configuração usa estes parâmetros:
Endereço IP do Cisco Secure ACS —172.16.1.1/255.255.0.0
Endereço IP da interface de gerenciamento do controlador—172.16.1.30/255.255.0.0
Chave secreta compartilhada usada no access point (AP) e no servidor RADIUS—asdf1234
Estas são as credenciais dos dois usuários que este exemplo configura no ACS:
Nome de usuário - acsreadwrite
Senha - gravação
Nome de usuário - somente leitura
Senha - somente leitura
Você precisa configurar o WLC e o Cisco Secure Cisco Secure ACS para:
Qualquer usuário que se conecta à WLC com o nome de usuário e a senha como acsreadwrite recebe acesso administrativo total à WLC.
Qualquer usuário que se conecta à WLC com o nome de usuário e a senha como somente leitura recebe acesso somente de leitura à WLC.
Este documento utiliza as seguintes configurações:
Conclua estes passos para configurar a WLC para que ela possa se comunicar com o servidor RADIUS.
Na GUI da WLC, clique em Security. No menu à esquerda, clique em RADIUS > Authentication. A página RADIUS Authentication servers é exibida. Para adicionar um novo servidor RADIUS, clique em Novo. Na página RADIUS Authentication Servers > New, insira os parâmetros específicos do servidor RADIUS. Exemplo:
Marque o botão de opção Management para permitir que o servidor RADIUS autentique os usuários que fazem login no WLC.
Observação: certifique-se de que o segredo compartilhado configurado nesta página corresponda ao segredo compartilhado configurado no servidor RADIUS. Somente então a WLC pode se comunicar com o servidor RADIUS.
Verifique se a WLC está configurada para ser gerenciada pelo Cisco Secure ACS. Para fazer isso, clique em Segurança na GUI da WLC. A janela GUI resultante é semelhante a este exemplo.
Você pode ver que a caixa de seleção Gerenciamento está habilitada para o servidor RADIUS 172.16.1.1. Isso ilustra que o ACS tem permissão para autenticar os usuários de gerenciamento na WLC.
Conclua as etapas nestas seções para configurar o ACS:
Conclua estes passos para adicionar a WLC como um cliente AAA no Cisco Secure ACS.
Na interface gráfica do usuário do ACS, clique em Network Configuration.
Em AAA Clients, clique em Add Entry.
Na janela Add AAA Client, insira o nome do host WLC, o endereço IP da WLC e uma chave secreta compartilhada.
Neste exemplo, estas são as configurações:
O nome de host do cliente AAA é WLC-4400
172.16.1.30/16 é o endereço IP do cliente AAA, que, neste caso, é o WLC.
A chave secreta compartilhada é "asdf1234".
Essa chave secreta compartilhada deve ser a mesma que a chave secreta compartilhada configurada na WLC.
No menu suspenso Authenticate Using (Autenticar usando), escolha RADIUS (Cisco Airespace).
Clique em Enviar + Reiniciar para salvar a configuração.
Para autenticar um usuário por meio de um servidor RADIUS, para login e gerenciamento do controlador, você deve adicionar o usuário ao banco de dados RADIUS com o atributo IETF RADIUS Service-Type definido com o valor apropriado de acordo com os privilégios do usuário.
Para definir privilégios de leitura e gravação para o usuário, defina o Service-Type Attribute como Administrativo.
Para definir privilégios somente leitura para o usuário, defina o Service-Type Attribute como NAS-Prompt.
O primeiro exemplo mostra a configuração de um usuário com acesso total à WLC. Quando este usuário tenta fazer login no controlador, o servidor RADIUS autentica e fornece a este usuário acesso administrativo total.
Neste exemplo, o nome de usuário e a senha são acsreadwrite.
Conclua estas etapas no Cisco Secure ACS.
Na interface gráfica do usuário do ACS, clique em User Setup.
Digite o nome de usuário a ser adicionado ao ACS conforme mostrado nesta janela de exemplo.
Clique em Adicionar/Editar para ir para a página Editar usuário.
Na página User Edit, forneça os detalhes do nome real, da descrição e da senha desse usuário.
Role para baixo até a configuração Atributos RADIUS IETF e marque Atributo de tipo de serviço.
Como, neste exemplo, o usuário acsreadwrite precisa ter acesso total, escolha Administrative para o menu suspenso Service-Type e clique em Submit.
Isso garante que esse usuário específico tenha acesso de leitura e gravação à WLC.
Às vezes, esse atributo Service-Type não fica visível nas configurações do usuário. Nesses casos, faça o seguinte para torná-lo visível.
Na GUI do ACS, escolha Interface Configuration > RADIUS (IETF) para habilitar os atributos IETF na janela User Configuration.
Isso o leva à página Configurações do RADIUS (IETF).
Na página Configurações de RADIUS (IETF), você pode ativar o atributo IETF que precisa estar visível nas configurações de usuário ou grupo. Para esta configuração, marque Service-Type para a coluna User (Usuário) e clique em Submit (Enviar). Esta janela mostra um exemplo.
Observação: este exemplo especifica a autenticação por usuário. Você também pode executar a autenticação com base no grupo ao qual um usuário específico pertence. Nesses casos, ative a caixa de seleção Grupo para que este atributo fique visível em Configurações de grupo.
Observação: também, se a autenticação for em grupo, você precisará atribuir usuários a um grupo específico e configurar os atributos IETF da configuração do grupo para fornecer privilégios de acesso aos usuários desse grupo. Consulte Gerenciamento de Grupo para obter informações detalhadas sobre como configurar e gerenciar grupos.
Este exemplo mostra a configuração de um usuário com acesso somente leitura à WLC. Quando este usuário tenta fazer login no controlador, o servidor RADIUS autentica e fornece a este usuário acesso somente leitura.
Neste exemplo, o nome de usuário e a senha são somente leitura.
Conclua estes passos no Cisco Secure ACS:
Na interface gráfica do usuário do ACS, clique em User Setup.
Digite o nome de usuário que deseja adicionar ao ACS e clique em Add/Edit para ir para a página User Edit.
Forneça o nome real, a descrição e a senha desse usuário. Esta janela mostra um exemplo.
Role para baixo até a configuração Atributos RADIUS IETF e marque Atributo de tipo de serviço.
Como, neste exemplo, o usuário somente leitura precisa ter acesso somente leitura, escolha Prompt NAS no menu suspenso Tipo de serviço e clique em Enviar.
Isso garante que esse usuário específico tenha acesso somente leitura à WLC.
Você também pode configurar os usuários de gerenciamento localmente na WLC. Isso pode ser feito na GUI do controlador, em Gerenciamento > Usuários de gerenciamento local.
Suponha que a WLC esteja configurada com usuários de gerenciamento tanto localmente quanto no servidor RADIUS com a caixa de seleção Gerenciamento habilitada. Nesse cenário, por padrão, quando um usuário tenta fazer login na WLC, a WLC se comporta desta maneira:
A WLC primeiro examina os usuários de gerenciamento local definidos para validar o usuário. Se o usuário existir em sua lista local, ele permitirá a autenticação para esse usuário. Se esse usuário não for exibido localmente, ele procurará o servidor RADIUS.
Se o mesmo usuário existir tanto localmente quanto no servidor RADIUS, mas com privilégios de acesso diferentes, a WLC autenticará o usuário com os privilégios especificados localmente. Em outras palavras, a configuração local na WLC sempre tem precedência quando comparada ao servidor RADIUS.
A ordem da autenticação para usuários de gerenciamento pode ser alterada na WLC. Para fazer isso, na página Segurança na WLC, clique em Ordem de prioridade > Usuário de gerenciamento. Nesta página, você pode especificar a ordem da autenticação. Exemplo:
Observação: se LOCAL for selecionado como segunda prioridade, o usuário será autenticado usando esse método somente se o método definido como a primeira prioridade (RADIUS/TACACS) não puder ser alcançado.
Para verificar se sua configuração funciona corretamente, acesse a WLC através do modo CLI ou GUI (HTTP/HTTPS). Quando o prompt de login for exibido, digite o nome de usuário e a senha configurados no Cisco Secure ACS.
Se as configurações estiverem corretas, você será autenticado com êxito na WLC.
Você também pode garantir que o usuário autenticado receba restrições de acesso conforme especificado pelo ACS. Para fazer isso, acesse a GUI da WLC por HTTP/HTTPS (certifique-se de que a WLC esteja configurada para permitir HTTP/HTTPS).
Um usuário com acesso de leitura e gravação definido no ACS tem vários privilégios configuráveis na WLC. Por exemplo, um usuário de leitura/gravação tem o privilégio de criar uma nova WLAN na página WLANs da WLC. Esta janela mostra um exemplo.
Quando um usuário com privilégios somente leitura tenta alterar a configuração no controlador, o usuário vê essa mensagem.
Essas restrições de acesso também podem ser verificadas através da CLI da WLC. Esta saída mostra um exemplo.
(Cisco Controller) >? debug Manages system debug options. help Help linktest Perform a link test to a specified MAC address. logout Exit this session. Any unsaved changes are lost. show Display switch options and settings. (Cisco Controller) >config Incorrect usage. Use the '?' or <TAB> key to list commands.
Como esta saída de exemplo mostra, um ? na CLI do controlador, é exibida uma lista de comandos disponíveis para o usuário atual. Observe também que o comando config não está disponível neste exemplo de saída. Isso ilustra que um usuário somente leitura não tem o privilégio de fazer nenhuma configuração na WLC. Enquanto isso, um usuário de leitura/gravação tem os privilégios para fazer configurações no controlador (modo GUI e CLI).
Observação: mesmo depois de autenticar um usuário de WLC através do servidor RADIUS, ao navegar de página em página, o servidor HTTP[S] ainda autentica totalmente o cliente toda vez. A única razão pela qual você não é solicitado a fazer autenticação em cada página é que seu navegador armazena em cache e reproduz suas credenciais.
Há determinadas circunstâncias em que um controlador autentica usuários de gerenciamento via ACS, a autenticação é concluída com êxito (access-accept) e você não vê nenhum erro de autorização no controlador. No entanto, o usuário é solicitado novamente para autenticação.
Nesses casos, você não pode interpretar o que está errado e por que o usuário não pode fazer login na WLC usando apenas o comando debug aaa events enable. Em vez disso, o controlador exibe outro prompt para autenticação.
Uma possível razão para isso é que o ACS não está configurado para transmitir o atributo Service-Type para esse usuário ou grupo específico, mesmo que o nome de usuário e a senha estejam configurados corretamente no ACS.
A saída do comando debug aaa events enable não indica que um usuário não tem os atributos necessários (por exemplo, o atributo Service-Type) mesmo que um access-accept seja enviado de volta do servidor AAA. Este exemplo de saída do comando debug aaa events enable mostra um exemplo.
(Cisco Controller) >debug aaa events enable Mon Aug 13 20:14:33 2011: AuthenticationRequest: 0xa449a8c Mon Aug 13 20:14:33 2011: Callback.....................................0x8250c40 Mon Aug 13 20:14:33 2011: protocolType.................................0x00020001 Mon Aug 13 20:14:33 2011: proxyState......................1A:00:00:00:00:00-00:00 Mon Aug 13 20:14:33 2011: Packet contains 5 AVPs (not shown) Mon Aug 13 20:14:33 2011: 1a:00:00:00:00:00 Successful transmission of Authentication Packet (id 8) to 172.16.1.1:1812, proxy state 1a:00:00:00:00:00-00:00 Mon Aug 13 20:14:33 2011: ****Enter processIncomingMessages: response code=2 Mon Aug 13 20:14:33 2011: ****Enter processRadiusResponse: response code=2 Mon Aug 13 20:14:33 2011: 1a:00:00:00:00:00 Access-Accept received from RADIUS server 172.16.1.1 for mobile 1a:00:00:00:00:00 receiveId = 0 Mon Aug 13 20:14:33 2011: AuthorizationResponse: 0x9802520 Mon Aug 13 20:14:33 2011: structureSize................................28 Mon Aug 13 20:14:33 2011: resultCode...................................0 Mon Aug 13 20:14:33 2011: protocolUsed.................................0x00000001 Mon Aug 13 20:14:33 2011: proxyState.......................1A:00:00:00:00:00-00:00 Mon Aug 13 20:14:33 2011: Packet contains 0 AVPs:
Neste primeiro exemplo, debug aaa events enable, você vê que Access-Accept foi recebido com êxito do servidor RADIUS, mas o atributo Service-Type não é passado para a WLC. Isso ocorre porque o usuário específico não está configurado com esse atributo no ACS.
O Cisco Secure ACS precisa ser configurado para retornar o atributo Service-Type após a autenticação do usuário. O valor do atributo Service-Type deve ser definido como Administrative ou NAS-Prompt de acordo com os privilégios do usuário.
Este segundo exemplo mostra a saída do comando debug aaa events enable novamente. No entanto, desta vez, o atributo Service-Type é definido como Administrativo no ACS.
(Cisco Controller)>debug aaa events enable Mon Aug 13 20:17:02 2011: AuthenticationRequest: 0xa449f1c Mon Aug 13 20:17:02 2011: Callback.....................................0x8250c40 Mon Aug 13 20:17:02 2011: protocolType.................................0x00020001 Mon Aug 13 20:17:02 2011: proxyState.......................1D:00:00:00:00:00-00:00 Mon Aug 13 20:17:02 2011: Packet contains 5 AVPs (not shown) Mon Aug 13 20:17:02 2011: 1d:00:00:00:00:00 Successful transmission of Authentication Packet (id 11) to 172.16.1.1:1812, proxy state 1d:00:00:00:00:00-00:00 Mon Aug 13 20:17:02 2011: ****Enter processIncomingMessages: response code=2 Mon Aug 13 20:17:02 2011: ****Enter processRadiusResponse: response code=2 Mon Aug 13 20:17:02 2011: 1d:00:00:00:00:00 Access-Accept received from RADIUS server 172.16.1.1 for mobile 1d:00:00:00:00:00 receiveId = 0 Mon Aug 13 20:17:02 2011: AuthorizationResponse: 0x9802520 Mon Aug 13 20:17:02 2011: structureSize................................100 Mon Aug 13 20:17:02 2011: resultCode...................................0 Mon Aug 13 20:17:02 2011: protocolUsed.................................0x00000001 Mon Aug 13 20:17:02 2011: proxyState.......................1D:00:00:00:00:00-00:00 Mon Aug 13 20:17:02 2011: Packet contains 2 AVPs: Mon Aug 13 20:17:02 2011: AVP[01] Service-Type...........0x00000006 (6) (4 bytes) Mon Aug 13 20:17:02 2011: AVP[02] Class......... CISCOACS:000d1b9f/ac100128/acsserver (36 bytes)
Você pode ver neste exemplo de saída que o atributo Service-Type é passado para a WLC.
Revisão | Data de publicação | Comentários |
---|---|---|
1.0 |
01-Dec-2013 |
Versão inicial |