Integrazione dell'interfaccia web di Apstra con FreeIPA
Primo tentativo (quello corretto?)
Cercando di dare a più utenti un accesso sensato ad Apstra 4.0.0, ho scoperto che supporta le directory basate su LDAP sotto forma di “Providers” nella sezione “External Systems”:
Ho adattato con entusiasmo la configurazione di default per farla corrispondere allo schema di FreeIPA (testato con FreeIPA 4.6.8): sono riuscito ad autenticare gli utenti, ma l’autorizzazione è fallita, qualunque parametro cambiassi per modificare la funzione di ricerca dei gruppi.
| Parametro | Valore |
|---|---|
| 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 |
Tabella 1 - “Provider-specific Parameters” testati – Non funziona
| Parametro | Valore | Default di Apstra? |
|---|---|---|
| Username Attribute Name | uid | Sì |
| User Search Attribute Name | uid | Sì |
| User First Name Attribute Name | givenName | Sì |
| User Last Name Attribute Name | sn | Sì |
| User Email Attribute Name | Sì | |
| User Object Class Attribute Name | inetOrgPerson* | Sì |
| User Member Attribute Name | memberOf | Sì |
| Group Name Attribute Name | cn | Sì |
| Group DN Attribute Name | entryDN | Sì |
| Group Search Attribute Name | cn | Sì |
| Group Member Attribute Name | entryDN | Sì |
| Group Member Mapping Attribute Name | member | No |
| Group Object Class Attribute Name | groupofnames* | No |
Tabella 2 - “Advanced configuration” testata – Non funziona
Tieni presente che “Group Object Class Attribute Name” può assumere “groupofnames” oppure “ipausergroup” per questo caso d’uso.
Guardando i log, l’attributo per la ricerca dell’appartenenza degli utenti sembra essere fisso su UID, quindi la ricerca è:
SRCH base="cn=groups,cn=accounts,dc=ipa,dc=mydomain,dc=com" scope=2 filter="(member=john.doe)" attrs="cn"Mentre dovrebbe essere come:
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"Il workaround
Il modo corretto di risolvere sarebbe accettare un parametro con l’attributo utente da usare per la ricerca dell’appartenenza ai gruppi (DN invece di UID in questo caso).
Come workaround, ho scoperto che la vista “compat” di FreeIPA può essere usata per fornire un’altra vista più in linea con quello che presenterebbe, per esempio, openLDAP.
Il problema, per me, è che la vista compat:
- viene generata al volo, non è indicizzata: probabilmente non scala se hai a che fare con migliaia di utenti.
- richiede che il gruppo sia della classe “posixGroup”: dato che i gruppi di Apstra devono essere gruppi solo per l’applicazione, riempirà di gruppi irrilevanti la vista dei sysadmin Unix/Linux.
Nella speranza di una soluzione adeguata da parte di Juniper (ora proprietari di Apstra), e dato che questo è un ambiente limitato (in termini di scalabilità), il workaround sembra abbastanza buono.
Dato che fallisce solo la ricerca dei gruppi, useremo la vista compat solo per i gruppi.
| Parametro | Valore |
|---|---|
| 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 |
Tabella 3 - “Provider-specific Parameters” testati – Workaround funzionante
| Parametro | Valore | Default di Apstra? |
|---|---|---|
| Username Attribute Name | uid | Sì |
| User Search Attribute Name | uid | Sì |
| User First Name Attribute Name | givenName | Sì |
| User Last Name Attribute Name | sn | Sì |
| User Email Attribute Name | Sì | |
| User Object Class Attribute Name | inetOrgPerson | Sì |
| User Member Attribute Name | memberOf | Sì |
| Group Name Attribute Name | cn | Sì |
| Group DN Attribute Name | entryDN | Sì |
| Group Search Attribute Name | cn | Sì |
| Group Member Attribute Name | entryDN | Sì |
| Group Member Mapping Attribute Name | memberUid | Sì |
| Group Object Class Attribute Name | posixGroup | Sì |
Tabella 4 - “Advanced configuration” testata – Workaround funzionante
Non dimenticare di configurare la sezione “Provider Role Mapping” per far funzionare l’autorizzazione.
| AOS Role | Gruppo del provider |
|---|---|
| administrator | gapstra-administrator |
| device_ztp | gapstra-device_ztp |
| user | gapstra-user |
| viewer | gapstra-viewer |
Tabella 5 - Configurazione del mapping dei ruoli
Nota a margine
Anche se ottengo autenticazione e autorizzazione corrette, l’attributo utente “role” nel profilo mostra solo un riquadro grigio per l’utente gestito da LDAP. Potrebbe essere un bug di presentazione, per il resto l’autorizzazione funziona come previsto
Modifica questo articolo su GitHub · hai trovato un errore? Le pull request sono benvenute.