VPN જૂથ નીતિ માટે ASA LDAP જૂથ મેપિંગ વિરુદ્ધ DAP

બે અલગ રેકોર્ડ નક્કી કરે છે કે AnyConnect સત્રને કઈ જૂથ નીતિ મળે છે, અને તે કન્ફિગરેશનના અલગ અલગ ભાગમાં અલગ નિષ્ફળતાની રીતો સાથે રહે છે. LDAP એટ્રિબ્યુટ મેપ પ્રમાણીકરણ દરમિયાન ડિરેક્ટરીના મૂલ્યને ASA અધિકૃતતા એટ્રિબ્યુટમાં અનુવાદિત કરે છે; DAP રેકોર્ડ પછી શરતોનું મૂલ્યાંકન કરે છે અને એટ્રિબ્યુટ ઉમેરી શકે છે અથવા બદલી શકે છે. બંને સમાન નીતિ નામ પર પૂરા થઈ શકે છે, તેથી કામ કરતું લોગિન તમને કંઈ કહેતું નથી કે કઈ પદ્ધતિએ તે બનાવ્યું. તેમની તુલના કરવાનો હેતુ એ છે કે બીજાને પહેલાને ચૂપચાપ દબાવી દેવા દેવાને બદલે જાણી જોઈને એક પસંદ કરવો.

બે પદ્ધતિઓ, બે નિર્ણય બિંદુઓ

પસંદગી ત્રણ પ્રશ્નો સુધી આવે છે. શું નિર્ણય ડિરેક્ટરીના એક જ એટ્રિબ્યુટ મૂલ્ય પર આધાર રાખે છે, શું તેને તે મૂલ્ય કરતાં વધુની જરૂર છે, અને જ્યારે બંને મેળ ખાય ત્યારે કઈ પદ્ધતિને જીતવાની પરવાનગી છે?

જો એકમાત્ર ઇનપુટ જૂથ સભ્યપદ હોય, તો એટ્રિબ્યુટ મેપ નાનું સાધન છે અને ઓડિટ કરવા માટે સરળ છે: એક મેપ, એક AAA સર્વર સાથે જોડાયેલ, દરેક જૂથ માટે એક લીટી. જો પસંદગીએ ઉપકરણની સ્થિતિ, એન્ડપોઇન્ટ ઓળખ, બીજું એટ્રિબ્યુટ અથવા સમય વિન્ડો ધ્યાનમાં લેવી હોય, તો મેપના ઇનપુટ ખતમ થઈ જાય છે અને DAP એ પદ્ધતિ છે જે નિયમ વ્યક્ત કરી શકે છે. જો બંને રમતમાં હોય, તો બંનેમાંથી કોઈ પણ લખતા પહેલાં તમારા રીલીઝ પર પ્રાધાન્યતા જાણો, કારણ કે DAP રેકોર્ડ સાથે મેળ ખાતું સત્ર કદાચ મેપે પરત કરેલી નીતિ જાળવી ન રાખે. બાકીનું બધું હિસાબ છે.

એટ્રિબ્યુટ મેપનો માર્ગ, કન્ફિગરેશન ક્રમમાં

મેપનો માર્ગ AAA સર્વરની વ્યાખ્યાથી શરૂ થાય છે. એટ્રિબ્યુટ મેપ તે LDAP સર્વર એન્ટ્રી સાથે જોડાયેલ હોવો જોઈએ જે કનેક્શન પ્રોફાઇલ ખરેખર વાપરે છે; જે મેપ ચાલુ કન્ફિગરેશનમાં અસ્તિત્વમાં છે પણ તે સર્વર દ્વારા સંદર્ભિત નથી તે કંઈ બદલતું નથી. તે જોડાણની લીટી જ બાકીના કન્ફિગરેશનને જીવંત બનાવે છે. ASA LDAP મેપિંગ માર્ગદર્શિકા 9.x રીલીઝમાં મેપ સિન્ટેક્સ માટેનો સંદર્ભ છે.

મેપની અંદર, એક વિધાન ડિરેક્ટરી એટ્રિબ્યુટ અને તે જે ASA એટ્રિબ્યુટને પોષે છે તેનું નામ આપે છે, અને આગળનાં વિધાનો ચોક્કસ મૂલ્યોનું અનુવાદ કરે છે. map-name memberOf Group-Policy અને તેના પછી map-value memberOf CN=VPN-Support,OU=Groups,DC=corp,DC=example Support-ReadOnly સ્વરૂપ છે: ડાબી બાજુ ડિરેક્ટરીએ પરત કરેલું છે, જમણી બાજુ જૂથ નીતિનું નામ છે જે પહેલેથી અસ્તિત્વમાં હોવી જોઈએ. વિશિષ્ટ નામ અને નીતિનું પ્રદર્શન નામ એકબીજાના બદલે વાપરી શકાય નહીં, અને બંને શબ્દમાળામાં લગભગ મેળ પણ લોગિન વખતે કોઈ ભૂલ ઉત્પન્ન કરતું નથી.

અહીં બે વિગતો કરડે છે: memberOf એ દરેક જૂથ પરત કરે છે જેમાં ખાતું છે, તેથી બે મેપ કરેલા જૂથોમાંનો વપરાશકર્તા મેપને બે ઉમેદવાર મૂલ્યો આપે છે, અને માર્ગદર્શિકાનો મૂળાક્ષર ક્રમનો નિયમ એ જ એકમાત્ર ટાઈ-બ્રેક છે જેના પર તમે તમારા પોતાના પ્રાધાન્ય ક્રમને બદલે ભરોસો કરી શકો. મેપ ન કરેલું મૂલ્ય કંઈ આપતું નથી, જે ચૂપચાપ પ્રોફાઇલની મૂળભૂત નીતિ પર પાછું આવે છે.

DAP નો માર્ગ, અને તે શું ઉમેરે છે

DAP શરતોનું મૂલ્યાંકન કરે છે અને AAA પરિણામ પર એટ્રિબ્યુટ લાગુ કરે છે. રેકોર્ડમાં પ્રાધાન્યતા, ક્રિયા અને શરતોનો સમૂહ હોય છે; રેકોર્ડ પ્રાધાન્ય ક્રમમાં મૂલ્યાંકિત થાય છે અને ક્રિયા નક્કી કરે છે કે મૂલ્યાંકન ચાલુ રહે છે કે અટકે છે. તે મૂલ્ય શોધ કરતાં અલગ અમલ મોડેલ છે, અને તેથી જ તે એવા નિયમો વ્યક્ત કરી શકે છે જે મેપ કરી શકતું નથી.

DAP જે ઉમેરે છે તે ઇનપુટ છે. શરતો ડિરેક્ટરી એટ્રિબ્યુટ, એન્ડપોઇન્ટ એટ્રિબ્યુટ અને ઉપકરણની સ્થિતિનો સંદર્ભ લઈ શકે છે, અને મેળ ખાતો રેકોર્ડ તે સત્ર માટે ACL, URL યાદીઓ અથવા ફિલ્ટર લઈ શકે છે. તેથી મેનેજ કરેલા લેપટોપ પરના સપોર્ટ કર્મચારીઓને ફક્ત-વાંચન નીતિ મળે અને તે જ કર્મચારીઓને બિન-મેનેજ કરેલા ઉપકરણ પર મર્યાદિત નીતિ મળે એવો નિયમ DAP માં વ્યક્ત કરી શકાય છે, એટ્રિબ્યુટ મેપમાં નહીં. મેપમાં બરાબર એક જ ઇનપુટ છે: તમે નામ આપેલા એટ્રિબ્યુટ માટે ડિરેક્ટરીએ પરત કરેલું મૂલ્ય.

જ્યારે સત્ર ખોટી નીતિમાં પડે ત્યારે જોવા માટે DAP બીજું સ્થાન પણ ઉમેરે છે. ચાલુ રાખવાની ક્રિયા સાથે મેળ ખાતો રેકોર્ડ મૂલ્યાંકન સમાપ્ત કરતો નથી, અને પછીનો રેકોર્ડ હજી પરિણામ બદલી શકે છે, તેથી તમે જે જુઓ છો તે એક ક્રમનું પરિણામ છે, એક જ શોધનું નહીં. પ્રાધાન્યતાના ક્રમાંકો ક્રમમાં વાંચો, અને યાદ રાખો કે બેકઅપ રેકોર્ડ જ કામ કરી રહ્યો હોઈ શકે. મેપમાં, તેનાથી વિપરીત, કોઈ ક્રમ નથી: એક એટ્રિબ્યુટ, એક મૂલ્ય, એક જવાબ.

જ્યાં બંને અસંમત છે

પ્રાધાન્યતા એ જ ભાગ છે જે ડિઝાઇન તોડે છે. જ્યારે સત્ર એકસાથે મેપ એન્ટ્રી અને DAP રેકોર્ડ સાથે મેળ ખાય છે, ત્યારે પરિણામ રીલીઝ અને રેકોર્ડની ક્રિયા પર આધાર રાખે છે, તેથી કોઈ એક પદ્ધતિ પરિણામની માલિક છે એમ માનવાને બદલે તમારા પોતાના ASA પર તેને ચકાસો.

ત્રણ નિષ્ફળતાની રીતો મોટાભાગની ગૂંચવણ સમજાવે છે. જે મેપ વ્યાખ્યાયિત છે પણ પ્રોફાઇલ વાપરતા સર્વર ટેગ સાથે ક્યારેય જોડાયું નથી તે ક્યાંય કોઈ ભૂલ વિના મૂળભૂત નીતિ આપે છે. DAP શરતની શબ્દમાળા જો કેસ અથવા જગ્યાઓમાં ડિરેક્ટરીના મૂલ્યથી અલગ હોય તો ક્યારેય મેળ ખાતી નથી, અને બેકઅપ રેકોર્ડ ચૂપચાપ લાગુ થાય છે. અને જે જૂથ નીતિ હજી અસ્તિત્વમાં નથી તે મેપ દ્વારા સ્વીકારવામાં આવે છે, કારણ કે મેપ ફક્ત નામ પરત કરે છે, તેથી સત્રને ઈચ્છિત પરવાનગીઓમાંથી કંઈ મળતું નથી અને લોગમાં ગુમ થયેલી વસ્તુ તરફ ઇશારો કરતું કંઈ હોતું નથી. જૂથ સભ્યપદને સ્પર્શ કરતા પહેલાં ત્રણેય ચકાસો.

જીવંત સત્રમાંથી પુરાવા વાંચવા

જવાબ કન્ફિગરેશનમાંથી નહીં, નવા સત્રમાંથી વાંચો. show vpn-sessiondb detail anyconnect filter name jdoe સત્રને ખરેખર મળેલી જૂથ નીતિ છાપે છે, અને show running-config ldap attribute-map મેપ કયા મૂલ્યો પરત કરી શક્યું હોત તેની પુષ્ટિ કરે છે. ડિરેક્ટરીની બાજુએ, test aaa-server authentication LDAP-AD username jdoe password <password> ASA ને પાછા મળેલા એટ્રિબ્યુટ દર્શાવે છે, અને debug ldap 255 જ્યારે પરીક્ષણ તમારી અપેક્ષા સાથે મેળ ખાતું નથી ત્યારે વિનિમય દર્શાવે છે.

પછી ચાર રેકોર્ડ લેખિતમાં મેળવો: ડિરેક્ટરીનું મૂલ્ય, ગોઠવેલો મેપ અથવા DAP શરત, સ્થાનિક જૂથ નીતિ અને જે સંસાધન સુધી વપરાશકર્તા ખરેખર પહોંચી શક્યો. જો પહેલા ત્રણ મેળ ખાય અને ચોથું નહીં, સમસ્યા પસંદગીમાં નહીં, નીતિના મુખ્ય ભાગમાં છે. જો સત્ર સાચું નીતિ નામ દર્શાવે પણ ખોટું ACL, તો LDAP તરફ જોવાનું સંપૂર્ણપણે બંધ કરો. એક વખતે એક રેકોર્ડ બદલો અને નવું સત્ર ફરી ચકાસો, કારણ કે ફરીથી જોડાયેલું સત્ર એ જ એકમાત્ર પુરાવો છે જે તમે હમણાં લખેલા કન્ફિગરેશનને પ્રતિબિંબિત કરે છે.