VPN પ્રમાણપત્ર LDAP ભાગનું રક્ષણ કરતું નથી

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

એ જ અસમાનતા એવા લોગિન પાછળની ક્રિયાવિધિ છે જે એન્ક્રિપ્ટેડ દેખાય છે અને તોપણ bind પાસવર્ડ ખુલ્લો મોકલે છે.

બે જોડાણો, બે ભરોસાના નિર્ણયો

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

એટલે જ નિષ્ફળતા જોરદાર નહીં, શાંત છે. જે ગેટવે ક્યારેય ડિરેક્ટરીનું પ્રમાણપત્ર ચકાસતું નથી તે તો વપરાશકર્તાઓને યોગ્ય રીતે પ્રમાણિત કરે જ છે; તે ફક્ત એવી ચેનલ પર કરે છે જે તેણે ચકાસી નથી.

StartTLS અને LDAPS, સભાનપણે પસંદ કરેલા

StartTLS સાદા LDAP તરીકે ખૂલે છે અને ત્યાં જ અપગ્રેડ થાય છે, સામાન્ય રીતે પોર્ટ 389 પર. LDAPS જોડાણ સાથે TLS શરૂ કરે છે, સામાન્ય રીતે 636 પર. બંને કાયદેસર છે અને એડેપ્ટરે ડિરેક્ટરી જે આપે છે તેની સાથે મેળ ખાવો જોઈએ. StartTLS જરૂરી ઠેરવવું એ તેને અજમાવીને અપગ્રેડ નિષ્ફળ જાય ત્યારે ચાલુ રાખવાથી અલગ છે, અને એ જ ફરક એવી જગ્યા છે જ્યાંથી bind પાસવર્ડ બહાર નીકળી શકે. કડક મોડ ગોઠવો, અને પાસવર્ડ bind માટે અસુરક્ષિત વૈકલ્પિક માર્ગને મંજૂરી આપશો નહીં.

ldapsearch -H ldap://dc1.corp.example -ZZ -x -D "CN=VPN Bind,OU=Service Accounts,DC=corp,DC=example" -W -b "DC=corp,DC=example" "(sAMAccountName=example-user)" dn

-ZZ વિકલ્પ એ જ આખો મુદ્દો છે: ક્વેરી અપગ્રેડ વિના ચૂપચાપ આગળ વધવાને બદલે નિષ્ફળ જાય છે. તે લીટીના નામો અને ખાતાં ઉદાહરણો છે. OpenLDAP TLS દસ્તાવેજીકરણ તેની પાછળની ટ્રસ્ટ ગોઠવણો આવરી લે છે.

LDAP ક્લાયન્ટ કયું ટ્રસ્ટ સ્ટોર વાંચે છે?

OpenLDAP ક્લાયન્ટ લાઇબ્રેરી પોતાની ટ્રસ્ટ ગોઠવણી વાંચે છે, ભલે સિસ્ટમ ફાઇલમાંથી કે પ્લગઇન-વિશિષ્ટ સેટિંગમાંથી. VPNની CA સૂચના VPN સાથીઓને લાગુ પડે છે અને LDAP લાઇબ્રેરી એ જ ફાઇલ વાંચે છે તેનો પુરાવો નથી. પ્રમાણપત્ર ખરેખર આવરી લેતું ડિરેક્ટરી હોસ્ટનામ વાપરો, સાથે લાઇબ્રેરી જે ઇશ્યૂઇંગ ચેઇન પર ભરોસો કરે છે તે. Active Directoryમાં ડિસ્પ્લે નામ પરથી અનુમાન કરવાને બદલે યોગ્ય સર્વર-પ્રમાણીકરણ વપરાશ સાથે ડિરેક્ટરી-સેવા પ્રમાણપત્ર તૈનાત કરો.

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

bind ખાતું અલગ સમસ્યા રહે છે

પરિવહનનું રક્ષણ bind ખાતું શું કરી શકે તે ઘટાડતું નથી. ડિરેક્ટરી શોધ વ્યાપ્તિ, જૂથ અધિકૃતિ અને સેવા ખાતાના વિશેષાધિકારો અલગ નિર્ણયો છે, અને TLS સક્ષમ થયા પછી પણ પહોળું bind ખાતું પહોળું જ રહે છે. સંકલનને જે જોઈએ તે સાંકડું સેવા ખાતું અને શોધ આધાર વાપરો, અને એન્ડપોઇન્ટ, TLS મોડ, ટ્રસ્ટનો માલિક અને નવીકરણ પ્રક્રિયા VPN ગોઠવણી સાથે નોંધો.

જ્યારે પ્રમાણપત્રની અસંગતિ દેખાય, ત્યારે યોગ્ય પ્રમાણપત્ર કે ચેઇન તૈનાત કરો. ચકાસણી બંધ કરવાથી દૃશ્ય અસંગતિ અદૃશ્ય થઈ જાય છે અને બીજો ભરોસાનો સંબંધ પરીક્ષણ વગર રહે છે.

બે જોડાણો, બે માલિકો, બે નવીકરણ તારીખો. દસ્તાવેજીકરણમાં તેમને અલગ રાખવા એ જ લોગિનને પ્રામાણિક રાખે છે.