LDAP auth for AnyConnect på Cisco ASA

En veiledning på å sette opp LDAP autentisering begrenset til sikkerhetsgrupper i Active Directory.

Det finnes forskjellige måter å autentisere VPN-brukere på på en Cisco ASA opp mot Active Directory (AD), men noen ganger er det veldig greit å kunne organisere brukere i sikkerhetsgrupper, og uten å måtte sette opp radius.

Dette er ganske rett frem å få til på en ASA. Jeg tar utgangspunkt i ASDM her.

Dette er satt opp slik at en AD-server står på innside-nettet og er beskyttet av brannmuren der, og når en bruker forsøker å logge seg på VPN så kommuniserer ASAen med AD-serveren på det lokale interfacet på brannmuren hvor AD-serveren ligger.

Jeg antar at den som leser dette har noe kjennskap til ASA, ASDM og oppsett av AnyConnect fra tidligere.

Det første som bør gjøres er å klargjøre AD-serveren. Det er ingenting annet å gjøre enn å opprette en å opprette sikkerhetsgruppe(r) og legge godkjente brukere inn i de. I tillegg bør det opprettes en egen bruker som legges i Domain Admins gruppa, som skal brukes av ASAen til å forespørre AD-serveren om informasjon om brukeren som forsøker å logge seg inn, og til det må den ha nok rettigheter. I mitt tilfelle, kalte jeg denne brukeren for ldapadmin.

Når dette er fullført, kan man hente ut verdiene for distinguishedName for den nye admin-brukeren, samt gruppen eller gruppene som er lagd for godkjente brukere.

For å gjøre det, er greit å sette på Advanced Features i AD Users and Computers, som vist nedenfor.

Dette gjør at man får vist mer informasjon i katalogen, samt i de forskjellige objektene man åpner.

Neste blir da å finne admin-brukeren man lagde, åpne egenskaper på den og gå videre på Attribute Editor. Her finner du en lang liste med verdier, og det er distinguishedName du ser etter, som bildet under.

Når du har denne informasjonen og kopiert ut denne verdien, kan du gå inn i ASDM på ASAen, og inn på Configuration, Remote Access VPN, Network (Client) Access og AnyConnect Connection Profiles.

Jeg har her lagd en egen tilkoblingsprofil som jeg kaller for AC_ldap (forkortet for AnyConnect_ldap), hvor jeg har et IP-pool tilknyttet, og satt opp en AAA-gruppe med ldap.

Legg merke til at det står «No_access» som default Group Policy. Dette kommer jeg tilbake til om litt. Denne trenger heller ikke å ha aktivert SSL eller IPsec, som er vist som ikke avhaket i bildet.

En ting som du bør gjøre nå i forhold til det er å kopiere ut navnet på den vanlige group policyen som du normalt sett skulle brukt på AnyConnect-profilen, siden du trenger den litt lenger nede i veiledningen. Min heter GP_ldap og er helt lik standard policy, bortsett fra at jeg har definert egne DNS-servere der, og den gjelder for SSL-client og SSL-clientless.

Under DNS servers vil man gjerne ha IP-adressene til sine egne interne DNS-servere, men dette er for demo, så jeg har cloudflare sine DNS-servere angitt her.

Om man går inn på Manage under Authentication, til høyre for AAA Server Group, får man opp vinduet for de definerte server-gruppene for autentisering og autorisering på ASAen.

Her kan man legge til en LDAP-server gruppe med standardverdier, og når man legger til en server i den gruppen får man opp følgende bilde. Jeg har allerede fylt ut her, så du ser hvordan det ser ut.

Her kan du selvsagt endre slik du ønsker i forhold til ditt AD-oppsett, men på testoppsettet her, bruker jeg domenet som Base DN og så søker den i alle nivåer under der noen forsøker å autentisere via LDAP.

Under Login DN, legger du inn distinguishedName for admin-brukeren du opprettet, som du fant litt tidligere. Passordet er selvsagt AD-passordet til denne brukeren. På Naming Attribute skal det stå sAMAccountName når det autentiseres opp mot Windows AD.

Som standard vil det også stå «-none-» under LDAP Attribute Map. Dette skal endres om litt. Man må først legge til et attribute map.

Trykk bare ok når de andre feltene er fylt ut

Da skal du være tilbake i vinduet for AAA Server Groups. Om du ser nederst i det vinduet, er det en blå stripe hvor det står LDAP Attribute Map. Trykk på den for å utvide den.

Her får du da mulighet til å legge til et attribute map. Trykke på «add» for å legge til et nytt. Du vil da få opp et vindu likt det under:

Her skriver du først inn et navn øverst, så kan du fylle inn følgende på LDAP Attribute Name og Cisco Attribute Name:

LDAP Attribute Name: memberOf
Cisco Attribute Name: velg Group-Policy i listen som vist over

Velg add for legge til i listen til høyre. Når du har gjort det, går du til neste fane; Mapping of Attribute Value:

Her skal du legge inn distinguishedName fra AD for gruppen(e) man ønsker å knytte til spesifikke group policys.

I mitt tilfelle er distinguishedName for min VPN-gruppe CN=VPN,OU=Grupper,DC=test,DC=lan

Dette limer du inn under LDAP Attribute Value, og under Cisco Attribute Value, skriver du navnet på group policyen for AnyConnect som brukere som ligger i denne gruppen på AD skal tilknyttes når de kobler seg på AnyConnect. Dette må stå helt ordrett så det er greit å copy/paste denne veriden.

Trykk deretter OK for å lagre attribute mapet. Du vil da se at det har dukket opp i listen nedenfor AAA Server Groups.

Du kan da trykke «edit» på serveren du la inn i sted og velge dette attribute mapet under det korresponderende valget der, som du hoppet over når du la inn serveren.

Trykk igjen OK for å gå tilbake til AAA Server Groups. Nå kan du gjerne teste LDAP-påloggingen. Om du velger serveren du la inn og trykker på knappen «test» til høyre kan du teste en pålogging. Velg «authentication» og skriv inn et brukernavn og passord du har i en godkjent gruppe på AD-serveren. Du skal da gjerne få melding om «authentication successful».

Vi har nå sålangt fått opp autentisering av brukere mot AD gjennom LDAP, men vi stopper fortsatt ikke ikke-godkjente brukere fra pålogging.

For å gjøre det må man lage en såkalt «no_access» policy. Det er bare en group policy med 0 simultane pålogginger definert. Om du går helt ut til Remote Access VPN igjen, kan du under Network (Client) Access velge Group Policies.

Her er det bare å trykke «add» og kalle den for noe som «NoAccess,» og under «general» inne på profilen utvider du linjen med «More Options» og haker vekk «inherit» under Simultaneous Logins og skriver «0» som verdi der. Det er alt, så bare trykk OK.

Denne profilen skal da settes som default group policy på tilkoblingsprofilen din under AnyConnect Connection Profiles, som vist under.

Grunnen til det er at det er den profilen som skal treffes som standard når man logger på VPN. Det LDAP Attribute Mapet som ble opprettet tidligere og knyttet til LDAP-serveren overstyrer dette og knytter den godkjente group policyen til brukere som autentiseres gjennom LDAP, så de får tilgang som normalt.

Når man kikker på loggingen med kommandoen «debug ldap 255» aktivert, kan man se forskjellen på hva som skjer når en godkjent og en ikke godkjent bruker logger inn.

Her er et utdrag fra loggen når bruker «testbruker_vpn» logger inn, som ligger i VPN-gruppa på AD:

[124] Session Start
[124] New request Session, context 0x00002aaac3ce7d58, reqType = Authentication
[124] Fiber started
[124] Creating LDAP context with uri=ldap://192.168.250.200:389
[124] Connect to LDAP server: ldap://192.168.250.200:389, status = Successful
[124] supportedLDAPVersion: value = 3
[124] supportedLDAPVersion: value = 2
[124] Binding as ldapadmin
[124] Performing Simple authentication for ldapadmin to 192.168.250.200
[124] LDAP Search:
         Base DN = [DC=test,DC=lan]
         Filter  = [sAMAccountName=testbruker_vpn]
         Scope   = [SUBTREE]
[124] User DN = [CN=testbruker_vpn,OU=Brukere,DC=test,DC=lan]
[124] Talking to Active Directory server 192.168.250.200
[124] Reading password policy for testbruker_vpn, dn:CN=testbruker_vpn,OU=Brukere,DC=test,DC=lan

[...]

[124] Processing LDAP response for user testbruker_vpn
[124] Message (testbruker_vpn):
[124] Authentication successful for testbruker_vpn to 192.168.250.200
[124] Retrieved User Attributes:

[...]

[124]   givenName: value = testbruker_vpn
[124]   distinguishedName: value = CN=testbruker_vpn,OU=Brukere,DC=test,DC=lan 
[124]   memberOf: value = CN=VPN,OU=Grupper,DC=test,DC=lan
[124]           mapped to Group-Policy: value = GP_ldap
[124]           mapped to LDAP-Class: value = GP_ldap

Som man ser så kobler den seg opp til AD med ldapadmin-brukeren, finner den brukeren som skal autentiseres, testbruker_vpn, som da autentiserer fint. Det ville alle brukere gjort, selv om de ikke ligger i VPN-gruppa. De nederste linjene er det som faktisk gjør at denne brukeren slippes gjennom på VPN. Den går ut i fra LDAP attribute map som vi definerte og derfor mapper brukeren til group policy GP_ldap, som da tas i bruk for denne brukeren på AnyConnect i stedet for no_access, som ble satt som default på tilkoblingsprofilen.

Når man ser på en annen bruker som ikke ligger i VPN-gruppa, ser det ganske likt ut i stor grad:

[127] Session Start
[127] New request Session, context 0x00002aaac3ce7d58, reqType = Authentication
[127] Fiber started
[127] Creating LDAP context with uri=ldap://192.168.250.200:389
[127] Connect to LDAP server: ldap://192.168.250.200:389, status = Successful
[127] supportedLDAPVersion: value = 3
[127] supportedLDAPVersion: value = 2
[127] Binding as ldapadmin
[127] Performing Simple authentication for ldapadmin to 192.168.250.200
[127] LDAP Search:
         Base DN = [DC=test,DC=lan]
         Filter  = [sAMAccountName=testbruker_uvpn]
         Scope   = [SUBTREE]
[127] User DN = [CN=testbruker_uvpn,OU=Brukere,DC=test,DC=lan]
[127] Talking to Active Directory server 192.168.250.200
[127] Reading password policy for testbruker_uvpn, dn:CN=testbruker_uvpn,OU=Brukere,DC=test,DC=lan

[...]

[127] Processing LDAP response for user testbruker_uvpn
[127] Message (testbruker_uvpn):
[127] Authentication successful for testbruker_uvpn to 192.168.250.200
[127] Retrieved User Attributes:

[...]

[127]   givenName: value = testbruker_uvpn
[127]   distinguishedName: value = CN=testbruker_uvpn,OU=Brukere,DC=test,DC=lan

Denne brukeren har ikke noe gruppemedlemskap i AD, så det kommer heller ikke noen informasjon om det i loggen for denne brukeren. Om den hadde hatt flere gruppemedlemskap, ville den ikke trigget noen mapping til group policy uten at ett eller flere av de gruppemedlemskapene i AD stemmer overens med LDAP attribute maps på ASAen.

Jeg har kuttet mye av loggen som ikke er relevant til akkurat dette, så det vil være mange flere linjer der om du sjekker selv.

Dette skal dekke det meste i denne prosessen. Jeg tok en gjennomgang av det selv fra scratch mens jeg skrev dette, så det burde fungere greit. Håper dette kan være nyttig for noen iallefall. 🙂

Forfatter: Lars

Jeg kommer fra Sunnmøre og jobber som IT-konsulent i Trondheim og bruker en del av tiden min til relaterte ting på fritiden. Ellers blir det noen turer i marka med telt og fiskestang når anledningen byr seg og jeg har tid. Driver også med litt simulatorspill, primært innen fly.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *