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 കോൺഫിഗറേഷനോടൊപ്പം രേഖപ്പെടുത്തുക.

സർട്ടിഫിക്കറ്റ് പൊരുത്തക്കേട് പ്രത്യക്ഷപ്പെടുമ്പോൾ ശരിയായ സർട്ടിഫിക്കറ്റോ ചെയിനോ വിന്യസിക്കുക. സ്ഥിരീകരണം അപ്രാപ്തമാക്കുന്നത് ദൃശ്യമായ പൊരുത്തക്കേടിനെ അദൃശ്യമാക്കുകയും രണ്ടാമത്തെ വിശ്വാസ ബന്ധം പരിശോധിക്കാതെ വിടുകയും ചെയ്യുന്നു.

രണ്ട് കണക്ഷനുകൾ, രണ്ട് ഉടമകൾ, രണ്ട് പുതുക്കൽ തീയതികൾ. രേഖകളിൽ അവ വേറിട്ട് നിർത്തുന്നതാണ് ലോഗിനെ സത്യസന്ധമായി നിർത്തുന്നത്.