VPN சான்றிதழ் LDAP பகுதியைப் பாதுகாக்காது
மறையாக்கப்பட்ட வாடிக்கையாளர் அமர்வு நுழைவாயிலின் LDAP இணைப்பு பற்றி எதுவும் கூறாது. StartTLS அல்லது LDAPS தேர்ந்தெடுத்து அடைவை அதன் சொந்த நம்பிக்கைக் கிடங்கால் சரிபார்க்கவும்.
அடைவுக்கு எதிராக சான்றுகளைச் சரிபார்க்கும் 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 உள்ளமைப்புடன் பதிவு செய்யவும்.
சான்றிதழ் பொருந்தாமை தோன்றும்போது சரியான சான்றிதழ் அல்லது சங்கிலியைப் பயன்படுத்தவும். சரிபார்ப்பை முடக்குவது தெரியும் பொருந்தாமையை மறைவாக மாற்றி இரண்டாவது நம்பிக்கை உறவைச் சோதிக்காமல் விடுகிறது.
இரண்டு இணைப்புகள், இரண்டு உரிமையாளர்கள், இரண்டு புதுப்பித்தல் தேதிகள். ஆவணங்களில் அவற்றைத் தனித்தனியாக வைத்திருப்பதே உள்நுழைவை நேர்மையாக வைத்திருக்கிறது.