ASA LDAP-hópavörpun gegn DAP fyrir VPN-hópstefnu
LDAP-eiginleikakort og DAP-stefna velja bæði hópstefnu, en þau keyra á mismunandi punktum. Finndu út hvort þitt ASA-lota notaði í raun.
Tvær aðskildar færslur ákveða hvaða hópstefnu AnyConnect-lota fær, og þær eru á mismunandi stöðum í stillingunum með mismunandi bilanatilfellum. LDAP-eiginleikakort þýðir gildi úr skránni í ASA-heimildareiginleika við auðkenningu; DAP-færsla metur skilyrði eftir á og getur bætt við eða hnekkt eiginleikum. Báðar geta endað á sama stefnunafni, svo innskráning sem virkar segir þér ekkert um hvaða kerfi myndaði hana. Tilgangurinn með að bera þær saman er að velja aðra af ásettu ráði í stað þess að láta hina seinni hnekkja þeirri fyrri í hljóði.
Tvö kerfi, tveir ákvörðunarpunktar
Valið kemur niður á þrjár spurningar. Er ákvörðunin háð einu gildi eiginleika úr skránni, þarf hún meira en það gildi, og hvaða kerfi má vinna þegar bæði passa?
Ef eina inntakið er hópmeðlimur er eiginleikakortið minna tólið og það sem auðveldara er að endurskoða: eitt kort, tengt einum AAA-þjóni, með einni línu á hóp. Ef valið verður að taka tillit til ástands tækisins, auðkennis endapunkts, annars eiginleika eða tímaramma klárast inntak kortsins og DAP er kerfið sem getur tjáð regluna. Ef bæði eru í gangi skaltu læra forganginn í þinni útgáfu áður en þú skrifar hvort sem er, því lota sem passar við DAP-færslu geymir kannski ekki stefnuna sem kortið skilaði. Allt annað er bókhald.
Leið eiginleikakortsins, í stillingaröð
Leið kortsins byrjar á skilgreiningu AAA-þjónsins. Eiginleikakortið verður að vera tengt LDAP-þjónsfærslunni sem tengiprofíllinn notar í raun; kort sem er til í keyrandi stillingum en þjónninn vísar ekki í breytir engu. Einmitt sú tengilína gerir afganginn af stillingunni lifandi. LDAP-kortagerðarleiðbeining ASA er viðmið fyrir setningafræði kortsins í útgáfum 9.x.
Inni í kortinu nefnir eitt yrðing eiginleika skrárinnar og ASA-eiginleikann sem hann fæðir, og frekari yrðingar þýða tiltekin gildi. map-name memberOf Group-Policy og síðan map-value memberOf CN=VPN-Support,OU=Groups,DC=corp,DC=example Support-ReadOnly er formið: vinstri hliðin er það sem skráin skilaði, hægri hliðin er nafn hópstefnu sem verður þegar að vera til. Aðgreint nafn og skjáheiti stefnu eru ekki skiptanleg, og næstum-samsvörun í hvorugum strengnum veldur engri villu við innskráningu.
Tveir smáatriðir bíta hér: memberOf skilar hverjum hóp sem reikningurinn tilheyrir, svo notandi í tveimur kortlögðum hópum gefur kortinu tvö kandídatsgildi, og stafrófsreglan í leiðbeiningunni er eina jafnteflisúrlausnin sem þú getur treyst á í stað þinnar eigin forgangsröðunar. Ókortlagt gildi gefur ekkert, sem fellur í hljóði til baka á sjálfgefna stefnu prófílsins.
DAP-leiðin, og hvað hún bætir við
DAP metur skilyrði og beitir eiginleikum ofan á AAA-niðurstöðuna. Færsla ber forgang, aðgerð og mengi skilyrða; færslur eru metnar í forgangsröð og aðgerðin ákveður hvort matið heldur áfram eða stöðvast. Það er önnur framkvæmdarlíkan en gildisleit, og einmitt þess vegna getur það tjáð reglur sem kortið getur ekki.
Það sem DAP bætir við eru inntök. Skilyrði geta vísað í eiginleika skrárinnar, eiginleika endapunkts og ástand tækisins, og samsvarandi færsla getur borið ACL, URL-lista eða síur fyrir þá lotu. Þannig er regla eins og að stuðningsfólk á stýrðri fartölvu fái stefnuna um aðeins lestur á meðan sama fólk á óstýrðu tæki fái takmarkaða tjáanleg í DAP en ekki í eiginleikakorti. Kortið hefur nákvæmlega eitt inntak: gildið sem skráin skilaði fyrir eiginleikann sem þú nefndir.
DAP bætir líka við öðrum stað til að skoða þegar lota lendir í rangri stefnu. Færsla sem passar með aðgerðinni halda áfram endar ekki matið, og síðari færsla getur enn breytt niðurstöðunni, svo það sem þú tekur eftir er afrakstur rásar en ekki einnar leitar. Lestu forgangsnúmerin í röð, og mundu að varafærslan gæti verið sú sem vinnur verkið. Kortið hefur hins vegar enga rás: einn eiginleiki, eitt gildi, eitt svar.
Þar sem þær tvær greinir á
Forgangurinn er sá hluti sem brýtur hönnun. Þegar lota passar bæði við kortfærslu og DAP-færslu fer niðurstaðan eftir útgáfunni og aðgerð færslunnar, svo staðfestu það á þínum eigin ASA í stað þess að gera ráð fyrir að annað kerfanna eigi niðurstöðuna.
Þrjú bilanatilfelli útskýra mestan hluta ruglsins. Kort sem er skilgreint en var aldrei tengt þjónsmerkinu sem prófíllinn notar gefur sjálfgefnu stefnuna án nokkurrar villu hvergi. DAP-skilyrðisstrengur sem er frábrugðinn gildi skrárinnar í há- og lágstöfum eða bilum passar aldrei, og varafærslan gildir í hljóði. Og hópstefna sem er ekki enn til er samþykkt af kortinu, því kortið skilar aðeins nafni, svo lotan fær engin af fyrirhuguðum heimildum og ekkert er í annálnum sem bendir á hið vantaða hlut. Athugaðu öll þrjú áður en þú snertir hópmeðlim.
Að lesa sönnunargögnin af lifandi lotu
Lestu svarið af nýrri lotu en ekki af stillingunum. show vpn-sessiondb detail anyconnect filter name jdoe prentar hópstefnuna sem lotan fékk í raun, og show running-config ldap attribute-map staðfestir hvaða gildum kortið gat hafa skilað. Á skrárhliðinni sýnir test aaa-server authentication LDAP-AD username jdoe password <password> eiginleikana sem ASA fékk til baka, og debug ldap 255 sýnir skiptin þegar prófið stangast á við það sem þú bjóst við.
Samræmdu síðan fjórar færslur skriflega: gildi skrárinnar, stillta kortið eða DAP-skilyrðið, staðbundna hópstefnuna og auðlindina sem notandinn gat í raun náð. Ef fyrstu þrjár stemma og sú fjórða ekki, er vandamálið í stefnulíkamanum en ekki í valinu. Ef lotan sýnir rétta stefnunafnið en ranga ACL skaltu hætta alveg að horfa á LDAP. Breyttu einni færslu í einu og athugaðu nýja lotu, því endurtengd lota er eina sönnunin sem endurspeglar stillingarnar sem þú varst að skrifa.