OpenVPN માં LDAP પ્રમાણીકરણ કામ કરે છે પણ જૂથ તપાસ નિષ્ફળ જાય છે: ક્યાં જોવું

પ્રમાણીકરણ પસાર થઈ શકે છે જ્યારે જૂથ તપાસ બધાને નકારી કાઢે છે. Authorization બ્લોક, સભ્યપદ લક્ષણ અને ડિરેક્ટરી એન્ડપોઇન્ટ એક પછી એક તપાસો.

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

નકારને અધિકૃતિના જવાબ તરીકે ગણો

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

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

નક્કી કરો કે સભ્યપદ ફિલ્ટરમાં રહે છે કે જૂથ બ્લોકમાં

બે સમર્થિત સ્વરૂપો છે, અને તેમને મિશ્ર કરવા એ જ રીતે કાર્યરત રૂપરેખા કામ કરવાનું બંધ કરે છે. પ્રથમ વપરાશકર્તા ઑબ્જેક્ટ પર લક્ષણ માંગીને સભ્યપદને વપરાશકર્તા શોધમાં ધકેલે છે; બીજું વપરાશકર્તા શોધને અસ્પૃશ્ય રાખે છે અને પછી પ્લગઇનને જૂથ ઑબ્જેક્ટ શોધવા દે છે. દરેક ડિપ્લોયમેન્ટ માટે એક પસંદ કરો અને તમે કયું પસંદ કર્યું તે લખો.

<Authorization>
    BaseDN       "OU=People,DC=example,DC=org"
    SearchFilter "(&(sAMAccountName=%u)(memberOf=CN=VPN Access,OU=Groups,DC=example,DC=org))"
    RequireGroup false
</Authorization>

એ સ્વરૂપમાં ફિલ્ટર બધું નક્કી કરે છે, તેથી RequireGroup એ false હોવું જોઈએ, નહીં તો પ્લગઇન એવા જૂથ ઑબ્જેક્ટની શોધમાં જાય છે જેનો ફિલ્ટરે ક્યારેય ઉલ્લેખ કર્યો નથી. ફિલ્ટરમાંનું લક્ષણ વપરાશકર્તા ઑબ્જેક્ટ પર હોવું જોઈએ અને ભરેલું હોવું જોઈએ, જે જૂથો નેસ્ટેડ થાય એટલે ખાતરીપૂર્વક નથી.

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

<Authorization>
    BaseDN       "OU=People,DC=example,DC=org"
    SearchFilter "(sAMAccountName=%u)"
    RequireGroup true
    Group        "CN=VPN Access,OU=Groups,DC=example,DC=org"
</Authorization>

અંધ સ્થળ સામાન્ય છે: સાદી સભ્યપદ સરખામણી નેસ્ટેડ જૂથોને વિસ્તૃત કરતી નથી, તેથી જે ખાતાની પહોંચ મૂળ જૂથ દ્વારા આવે છે તે નિષ્ફળ જાય છે જ્યારે કન્સોલ હજી સભ્યપદ બતાવે છે. Active Directory જૂથ પર member આપે છે, બીજી સ્કીમા uniqueMember વાપરે છે, અને ખોટા લક્ષણ તરફ ઇશારો કરવાથી ભૂલને બદલે ખાલી પરિણામ આવે છે.

એવો એન્ડપોઇન્ટ પસંદ કરો જે જૂથ ઑબ્જેક્ટ ધરાવે

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

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

ખાતાની સ્થિતિ અને શોધ વ્યાપ તેમના પોતાના ક્ષેત્રોમાં રાખો

નિષ્ક્રિય ધ્વજ ફિલ્ટરમાં આવે છે, જૂથ તપાસમાં નહીં. Active Directory માં તે userAccountControl નું બીજું બિટ છે, અને એ શરત વિના માન્ય પાસવર્ડવાળું નિષ્ક્રિય ખાતું પ્રમાણીકરણ કરે છે અને પછી જૂથ પગલા પર નિષ્ફળ જાય છે, જે અધિકૃતિ ભૂલ જેવું લાગે છે. શોધ વ્યાપ પાયાના DN માં આવે છે, કારણ કે ડોમેન રૂટથી શરૂ કરવું ધીમું છે અને તમે આવરી લેવા માંગતા હતા તે સંસ્થાકીય એકમની બહારના ઑબ્જેક્ટ સાથે મેળ ખાઈ શકે છે.

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

ત્રણ ખાતાં સાથે પરિણામ સાબિત કરો

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

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

ldapsearch -H ldap://dc01.example.org:3268 -x -D "[email protected]" -W -b "DC=example,DC=org" "(sAMAccountName=alice)" memberOf
ldapsearch -H ldap://dc01.example.org:3268 -x -D "[email protected]" -W -b "DC=example,DC=org" "(sAMAccountName=bob)" userAccountControl

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

સંબંધિત લેખો