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 కాన్ఫిగరేషన్‌తో పాటు నమోదు చేయండి.

ధృవపత్రంలో అసమతుల్యత కనిపించినప్పుడు సరైన ధృవపత్రం లేదా గొలుసును అమలు చేయండి. ధృవీకరణను నిలిపివేయడం కనిపించే అసమతుల్యతను అదృశ్యంగా మారుస్తుంది మరియు రెండవ నమ్మక సంబంధాన్ని పరీక్షించకుండా వదిలేస్తుంది.

రెండు కనెక్షన్‌లు, ఇద్దరు యజమానులు, రెండు పునరుద్ధరణ తేదీలు. పత్రాలలో వాటిని వేరుగా ఉంచడమే లాగిన్‌ను నిజాయితీగా ఉంచుతుంది.