Integração da interface web do Apstra com o FreeIPA
Primeira tentativa (a correta?)
Querendo dar a vários usuários um acesso decente ao Apstra 4.0.0, descobri que ele suporta diretórios baseados em LDAP na forma de “Providers” na seção “External Systems”:
Adaptei feliz a configuração padrão para casar com o esquema do FreeIPA (testado com FreeIPA 4.6.8), consegui autenticar usuários com sucesso, mas a autorização falhou, não importa qual parâmetro eu mudasse para alterar a função de busca de grupos.
| Parâmetro | Valor |
|---|---|
| Groups Search DN | cn=groups,cn=accounts,dc=ipa,dc=mydomain,dc=com |
| Users Search DN | cn=users,cn=accounts,dc=ipa,dc=mydomain,dc=com |
| Bind DN | uid=sys.apstra,cn=users,cn=accounts,dc=ipa,dc=mydomain,dc=com |
| Password | you.wish |
| Encryption | STARTTLS |
Tabela 1 - “Provider-specific Parameters” testados – Não funciona
| Parâmetro | Valor | Padrão do Apstra? |
|---|---|---|
| Username Attribute Name | uid | Sim |
| User Search Attribute Name | uid | Sim |
| User First Name Attribute Name | givenName | Sim |
| User Last Name Attribute Name | sn | Sim |
| User Email Attribute Name | Sim | |
| User Object Class Attribute Name | inetOrgPerson* | Sim |
| User Member Attribute Name | memberOf | Sim |
| Group Name Attribute Name | cn | Sim |
| Group DN Attribute Name | entryDN | Sim |
| Group Search Attribute Name | cn | Sim |
| Group Member Attribute Name | entryDN | Sim |
| Group Member Mapping Attribute Name | member | Não |
| Group Object Class Attribute Name | groupofnames* | Não |
Tabela 2 - “Advanced configuration” testada – Não funciona
Leve em conta que “Group Object Class Attribute Name” pode receber “groupofnames” ou “ipausergroup” para este caso de uso.
Olhando os logs, o atributo para a busca de associação de usuários parece estar fixo em UID, então a busca é:
SRCH base="cn=groups,cn=accounts,dc=ipa,dc=mydomain,dc=com" scope=2 filter="(member=john.doe)" attrs="cn"Quando deveria ser algo como:
SRCH base="cn=groups,cn=accounts,dc=ipa,dc=mydomain,dc=com" scope=2 filter="(member=uid=john.doe,cn=users,cn=accounts,dc=ipa,dc=mydomain,dc=com)" attrs="cn"O workaround
A forma correta de resolver isso seria aceitar um parâmetro com o atributo de usuário que devemos usar para a busca de associação a grupos (DN em vez de UID neste caso).
Como workaround, descobri que a visão “compat” do FreeIPA pode ser usada para fornecer outra visão mais parecida com o que o openLDAP apresentaria, por exemplo.
O problema para mim é que a visão compat:
- é gerada na hora, não é indexada: provavelmente não escala se você lida com milhares de usuários.
- exige que o grupo seja da classe “posixGroup”: como se espera que os grupos do Apstra sejam grupos exclusivos da aplicação, isso vai poluir a visão dos sysadmins Unix/Linux com grupos irrelevantes.
Na esperança de uma correção adequada da Juniper (agora dona do Apstra), e dado que este é um ambiente limitado (em termos de escalabilidade), o workaround parece bom o suficiente.
Como só a busca de grupos falha, usaremos a visão compat apenas para os grupos.
| Parâmetro | Valor |
|---|---|
| Groups Search DN | cn=groups,cn=compat,dc=ipa,dc=mydomain,dc=com |
| Users Search DN | cn=users,cn=accounts,dc=ipa,dc=mydomain,dc=com |
| Bind DN | uid=sys.apstra,cn=users,cn=accounts,dc=ipa,dc=mydomain,dc=com |
| Password | you.wish |
| Encryption | STARTTLS |
Tabela 3 - “Provider-specific Parameters” testados – Workaround funcionando
| Parâmetro | Valor | Padrão do Apstra? |
|---|---|---|
| Username Attribute Name | uid | Sim |
| User Search Attribute Name | uid | Sim |
| User First Name Attribute Name | givenName | Sim |
| User Last Name Attribute Name | sn | Sim |
| User Email Attribute Name | Sim | |
| User Object Class Attribute Name | inetOrgPerson | Sim |
| User Member Attribute Name | memberOf | Sim |
| Group Name Attribute Name | cn | Sim |
| Group DN Attribute Name | entryDN | Sim |
| Group Search Attribute Name | cn | Sim |
| Group Member Attribute Name | entryDN | Sim |
| Group Member Mapping Attribute Name | memberUid | Sim |
| Group Object Class Attribute Name | posixGroup | Sim |
Tabela 4 - “Advanced configuration” testada – Workaround funcionando
Não esqueça de configurar a seção “Provider Role Mapping” para a autorização funcionar.
| AOS Role | Grupo do provedor |
|---|---|
| administrator | gapstra-administrator |
| device_ztp | gapstra-device_ztp |
| user | gapstra-user |
| viewer | gapstra-viewer |
Tabela 5 - Configuração do mapeamento de papéis
Observação adicional
Mesmo conseguindo autenticação e autorização corretas, o atributo de usuário “role” no perfil mostra só uma caixa cinza para o usuário baseado em LDAP. Pode ser um bug de apresentação, fora isso a autorização funciona como esperado
Editar este post no GitHub · achou um erro? Pull requests são bem-vindos.