|
Benvenuto,
Ospite
|
ARGOMENTO:
OpenLDAP authentication server per accesso amministrativo 10 Anni 1 Mese fa #1
|
Ciao a tutti e scusate per la lunga latitanza... ogni tanto riciccio. Vado dritto al punto: sto configurando un firewall Cisco ASA 5510 (ASA v. 8.4, ASDM 7.1) per eseguire l'autenticazione degli utenti usando come backend un server ActiveDirectory/OpenLDAP e sto incontrando qualche difficoltà. Il mio obiettivo è quello di regolare tramite LDAP sia l'accesso amministrativo al dispositivo (ssh/asdm) che i login al servizio di Remote Access VPN. Il server ActiveDirectory/OpenLDAP che sto usando non è Microsoft (manco morto) ma GNU/Linux, in particolare Zentyal 3.7. Il mio problema riguarda in particolare l'accesso amministrativo al firewall; ho tentato due configurazioni, una via ActiveDirectory (che funziona) e l'altra via OpenLDAP, che invece non funziona ma che preferirei rispetto alla prima.
Configurazione funzionante (ActiveDirectory) Sul server Zentyal è configurato un utente "normale", senza privilegi particolari se non quello di essere un utente del dominio. Questo utente si chiama "ciscoasa". Sul firewall ho quindi configurato un server group chiamato NetworkSecurity e al suo interno ho definito un server di tipo Microsoft: aaa-server NetworkSecurity (office-lan) host 192.168.168.100
server-port 389
ldap-base-dn dc=domain,dc=lan
ldap-scope subtree
ldap-naming-attribute sAMAccountName
ldap-login-password *****
ldap-login-dn ciscoasa@domain.lan
server-type microsoft
ldap-attribute-map ADGroupMemberIl cuore di questa configurazione sta nel mapping degli attributi ldap, mostrato di seguito: ldap attribute-map ADGroupMember
map-name memberOf IETF-Radius-Service-Type
map-value memberOf CN=NetAdmins,OU=Groups,DC=domain,DC=lan 6Questa configurazione in pratica fa in modo che, quando un utente si logga, si verifica la sua appartenenza al gruppo NetAdmins tramite una query sull'attributo sAMAccountName sul server ActiveDirectory e, in caso affermativo, il corrispondente attributo IETF-Radius-Service-Type viene impostato al valore 6, il ché permette l'accesso alla console (via ssh e asdm) e alla modalità privilegiata, secondo la configurazione seguente: aaa authentication enable console NetworkSecurity LOCAL
aaa authentication http console NetworkSecurity LOCAL
aaa authentication ssh console NetworkSecurity LOCAL
aaa authorization exec authentication-serverCome anticipato, questa cosa funziona perfettamente, ma a me non piace dover usare un account di dominio (in questo caso ciscoasa) per fare da autenticatore verso il server ActiveDirectory. Il server Zentyal offre anche il servizio OpenLDAP e un account di tipo read-only, e mi piacerebbe utilizzare questo per fare da autenticatore. Quella che segue è la configurazione (non funzionante). Configurazione NON funzionante (OpenLDAP) In questo caso non è possibile eseguire la query sull'attributo sAMAccountName, ma si possono ottenere le stesse informazioni usando l'attributo uid: aaa-server OpenLDAP protocol ldap
aaa-server OpenLDAP (office-lan) host 192.168.168.100
server-port 390
ldap-base-dn dc=n3tcom,dc=lan
ldap-group-base-dn ou=Groups,dc=domain,dc=lan
ldap-scope subtree
ldap-naming-attribute uid
ldap-login-password *****
ldap-login-dn cn=zentyalro,dc=domain,dc=lan
server-type openldap
ldap-attribute-map openldapSi noti che su Zentyal il servizio ldap è in ascolto sulla porta 390 anziché sulla canonica 389. Anche in questo caso definisco un mapping sugli attributi (praticamente identico al precedente): ldap attribute-map openldap
map-name memberOf IETF-Radius-Service-Type
map-value memberOf cn=NetAdmins,ou=Groups,dc=domain,dc=lan 6Ovviamente la configurazione AAA cambierà per usare questo nuovo server group: aaa authentication enable console OpenLDAP LOCAL
aaa authentication http console OpenLDAP LOCAL
aaa authentication ssh console OpenLDAP LOCAL
aaa authorization exec authentication-serverQuesta configurazione funziona fino all'autenticazione, nel senso che, per il firewall, l'utente viene autenticato con successo, persò sembra che non abbia effetto il mapping dell'attributo memberOf su IETF-Radius-Service-Type e quindi l'accesso alla console viene rifiutato col messaggio "Attempted console login failed user 'username' did NOT have appropriate Admin Rights." Se eseguo manualmente una query verso il server OpenLDAP posso vedere con certezza che l'utente appartiene al gruppo NetAdmins:
Questo invece è quello che viene mostrato sul firewall (debug ldap 255) durante una transazione per l'autenticazione di un utente:
Qualcuno di voi ha mai avuto modo di configurare qualcosa del genere (accesso amministrativo con autenticazione tramite OpenLDAP) su un ASA o su un altro apparato di rete e saprebbe darmi qualche consiglio o suggerimento? Ad esempio, una cosa che mi viene in mente è quella di usare un altro tipo di mapping, ma non saprei quale altro attributo dell'ASA mappare su memberOf. Grazie e scusate per la lunghezza del post...  Gianluca |
|
Si prega Accedi a partecipare alla conversazione. |
OpenLDAP authentication server per accesso amministrativo 10 Anni 1 Mese fa #2
|
Che dire, veramente interessante, se riuscissimo a risolverlo vorrei chiederti di riorganizzare il post per pubblicare questo come blog vista la sua validità
Premetto che secondo me l'AAA è uno degli aspetti più complessi in una configurazione di rete specialmente se si cerca di uscire dalle soluzioni proprietarie come stai tentando di fare. Detto questo personalmente ho sempre prediletto per l'accesso alla command line TACACS vista la sua fantastica granularità e scalabilità di configurazione, ma per questo avresti bisogno di un ACS o di un ISE se usassi RADIUS (per il futuro facci un pensierino perchè soprattutto ISE è veramente potente  )Intanto le due situazioni che confronti non sono esattamente allineate, infatti Active Durectory da quanto riporti sembrerebbe funzionare in quanto fai authentication e authorizazion in locale, mentre con LDAP la fai verso il server che è la tua vera intenzione. Ciò che manca è la configurazine dell'autorizzazione lato server, se fosse un radius dovresti inviare al firewall l'attributo proprietario Cisco cisco-avpair = "shell:priv-lvl=15" Trattandosi di LDAP non so esattamente come funzioni l'authorizzazione ma immagino ci sia bisogno di un attributo per autorizzare l'utente a livello 15 Con tacacs la cosa è totalmente differente, puoi autorizzare ogni singolo comando verificandolo sul server dandoti una grandissima scalabilità nella configurazione dei privilegi. |
|
Si prega Accedi a partecipare alla conversazione. |
OpenLDAP authentication server per accesso amministrativo 10 Anni 1 Mese fa #3
|
Nel mio piccolo utilizzo tac_plus su macchine Linux oppure questa implementazione di tacacs su Windows. Quest'ultimo, se installato su un domain controller Active Directory, può sfruttare gli attributi degli utenti per conferire le autorizzazioni sui dispositivi di rete.
Non mi pare (a meno di errori di trascrizione); le due configurazioni sono identiche, cambia solo il nome del server group (nel primo caso si chiama NetworkSecurity, nel secondo OpenLDAP). Ho fatto in questo modo per evitare di apportare continuamente modifiche allo stesso server group. L'autenticazione LOCAL è solo di fallback nel caso l'authentication server non sia raggiungibile.
Dalla documentazione dell'ASA , l'attributo da configurare per l'accesso amministrativo è IETF-Radius-Service-Type, a cui bisogna assegnare il valore 6:
Questa fonte utilizza l'attributo LDAP accessType, mentre io sto cercando di usare sempre memberOf come faccio nel caso di Active Directory. A quanto pare è questa cosa che non funziona. Ora cerco di individuare quell'attributo sul mio server OpenLDAP e di configurare l'ASA di conseguenza. Vi aggiornerò col risultato. Grazie |
|
Si prega Accedi a partecipare alla conversazione. |