ഉപയോക്തൃനാമങ്ങൾ പുതിയ ഡയറക്ടറിയിൽ പ്രത്യക്ഷപ്പെടുന്നു, കൈമാറ്റം പൂർത്തിയായതായി പ്രഖ്യാപിക്കുന്നു, എന്നിട്ടും ലോഗിനുകൾ പരാജയപ്പെടുന്നു. ഗേറ്റ്വേയ്ക്ക് ഇപ്പോഴും പിന്തുണയുള്ള പ്രാമാണീകരണ പാതയും ശരിയായ അനുമതി ഫലവും ആവശ്യമാണ്, രണ്ടും ഇപ്പോൾ അക്കൗണ്ടുകൾ ഉള്ള ഡയറക്ടറിയിൽ നിന്ന് വരുന്നില്ല. ബാക്കെൻഡ് നീക്കുന്നത് ജീവിതചക്രമുള്ള കട്ട് ഓവറാണ്, പകർപ്പ് ജോലിയല്ല. താഴെയുള്ള ലക്ഷണമാണ് സാധാരണയായി വ്യത്യാസം വെളിപ്പെടുത്തുന്നത്.

ലക്ഷണം: അക്കൗണ്ടുകൾ ഉണ്ട്, സെഷനുകൾ ഇല്ല

പുതിയ ഡയറക്ടറിയിൽ ഓരോ ഉപയോക്തൃനാമവുമുണ്ട്, ഒരു പരീക്ഷണ ബൈൻഡ് വിജയിക്കുന്നു, VPN ക്ലയന്റ് ഇപ്പോഴും പ്രാമാണീകരണ പരാജയം തിരികെ നൽകുന്നു. ഈ സംയോജനം ഐഡന്റിറ്റി ഉണ്ടെന്ന് കാണിക്കുന്നു, പക്ഷേ ഗേറ്റ്വേ ഉപയോഗിക്കുന്ന പരിശോധനാ പാത അതിലെത്തുന്നില്ല, അല്ലെങ്കിൽ അത് നിറവേറ്റാനാകാത്ത രീതിയിൽ എത്തുന്നു. രണ്ടും കോൺഫിഗറേഷനാണ്, ഇവ വ്യത്യസ്ത പ്രശ്നങ്ങളാണ്.

ആദ്യത്തേത് വയറിംഗാണ്: ഗേറ്റ്വേ മറുപടി നൽകാത്ത ബാക്കെൻഡിലേക്ക് ചൂണ്ടുന്നു, മറുവശം പ്രതീക്ഷിക്കാത്ത പങ്കിട്ട രഹസ്യം ഉപയോഗിക്കുന്നു, അല്ലെങ്കിൽ പുതിയ സേവനം തിരികെ നൽകാത്ത ഗുണം ആവശ്യപ്പെടുന്നു. രണ്ടാമത്തേത് ക്രിപ്റ്റോഗ്രാഫിക് ആണ്: രീതിക്ക് യഥാർത്ഥ രഹസ്യം വേണം, പുതിയ സംഭരണി അതിന്റെ ഹാഷ് മാത്രം സൂക്ഷിക്കുന്നു. പിശക് പാഠം രണ്ട് സന്ദർഭങ്ങളിലും സമാനമായി കാണപ്പെടുന്നു, അതിനാൽ രണ്ടും ഒരു പ്രശ്നമായി കണക്കാക്കുന്നു.

അക്കൗണ്ടുകൾ തൊടുന്നതിന് മുമ്പ് ഇവ രണ്ടും വേർതിരിക്കുന്നത് ഒരു ആഴ്ച ലാഭിക്കുന്നു. ഒന്ന് റൂട്ടിംഗും വിശ്വാസവും സംബന്ധിച്ച ചോദ്യമാണ്, മറ്റൊന്ന് ക്രെഡൻഷ്യലുകൾ റീസെറ്റ് ചെയ്യുന്നതിനെക്കുറിച്ചുള്ള തീരുമാനമാണ്, രണ്ടും കലർത്തുന്നത് ആർക്കും ആരോപിക്കാനാകാത്ത മാറ്റങ്ങൾ സൃഷ്ടിക്കുന്നു.

ആരെയും നീക്കുന്നതിന് മുമ്പ് ശൃംഖല മാപ്പ് ചെയ്യുക

ഓരോ ക്ലയന്റ് പ്രൊഫൈലിനും ആറ് കാര്യങ്ങൾ എഴുതുക: പുറം പ്രാമാണീകരണ രീതി, എന്തെങ്കിലും ആന്തരിക രീതി, ക്ലയന്റ് പ്രതീക്ഷിക്കുന്ന സെർവർ ഐഡന്റിറ്റി, ഗേറ്റ്വേയും ബാക്കെൻഡും തമ്മിലുള്ള ഇന്റർഫേസ്, ഗേറ്റ്വേ ഗ്രൂപ്പ് അംഗത്വത്തിലേക്ക് മാപ്പ് ചെയ്യുന്ന ഗുണം, അതിൽ നിന്ന് ഉരുത്തിരിയുന്ന വിഭവ നയം. അവ ക്രമത്തിൽ വായിക്കുന്നത് ഏത് കണ്ണിക്ക് ഉടമയില്ലെന്ന് കാണിക്കുന്നു. ഓരോ ഇനത്തിനും ഒരു ഉത്തരവാദിയുണ്ട്, ആരും പരിശോധിക്കാത്ത ഇടത്ത് കട്ട് ഓവർ പരാജയപ്പെടുന്നു.

LinkQuestion it answers
Client profileWhich method and server name does the client use?
Inner methodIs there a second authentication step?
Server identityWhich certificate or name must the client accept?
Gateway to backendWhich protocol, port and shared secret?
Attribute mappingWhich returned value becomes group membership?
Resource policyWhat the resulting session may reach

സാധാരണ ഡയറക്ടറി ലോഗിൻ ആ ശൃംഖലയിൽ നിന്ന് കാര്യമായി ഒന്നും കടക്കുന്നില്ല. അക്കൗണ്ട് ഉണ്ടെന്നും പാസ്വേഡ് പ്രവർത്തിക്കുന്നു എന്നും തെളിയിക്കുന്നു, അതായത് ഒരിക്കലും സംശയത്തിലാകാത്ത ഭാഗം.

ഹാഷുകൾ രീതികൾക്കിടയിൽ യാത്ര ചെയ്യുന്നില്ല

ക്രെഡൻഷ്യലുകളുടെ അനുയോജ്യത ഒരിക്കൽ പരിശോധിക്കണം, ഏതെങ്കിലും ഗ്രൂപ്പ് നീങ്ങുന്നതിന് മുമ്പ്. FreeRADIUS വിഭജനം വ്യക്തമായി രേഖപ്പെടുത്തുന്നു: സെർവർ സ്വയം ചെയ്യുന്ന CHAP പരിശോധനയ്ക്ക് യഥാർത്ഥ പാസ്വേഡ് വേണം, MS-CHAP ആ പാസ്വേഡോ അനുയോജ്യമായ NT വസ്തുവോ സ്വീകരിക്കുന്നു. മറ്റൊരു ഉദ്ദേശ്യത്തിനായി നിർമ്മിച്ച ഹാഷ് ഏത് സാഹചര്യത്തിലും യോജിക്കുന്നില്ല, അത് എത്ര ശക്തമായാലും.

വ്യത്യാസം തെളിവ് ആരു കണക്കാക്കുന്നു എന്നതിലാണ്. ഡയറക്ടറിയുമായി ബന്ധിപ്പിച്ച് പരിശോധിക്കുന്ന രീതി ഡയറക്ടറിക്ക് പരിശോധിക്കാനാകുന്നത് പരിശോധിക്കാൻ അനുവദിക്കുന്നു. വെല്ലുവിളി പ്രതികരണം വീണ്ടും കണക്കാക്കി പരിശോധിക്കുന്ന രീതിക്ക് രഹസ്യം തന്നെ വേണം, കാരണം സെർവറും അതേ കണക്കുകൂട്ടൽ ചെയ്യണം.

വസ്തു ഇല്ലാത്തിടത്ത്, സത്യസന്ധമായ ഓപ്ഷനുകൾ പിന്തുണയുള്ള റീസെറ്റ്, പുനർരജിസ്ട്രേഷൻ, ബാഹ്യ പരിശോധനാ സേവനം അല്ലെങ്കിൽ രീതി മാറ്റം. വീണ്ടെടുക്കാവുന്ന പാസ്വേഡുകളുടെ താൽക്കാലിക കയറ്റുമതി ആ പട്ടികയിലില്ല. പ്രോജക്ടിന്റെ ഏറ്റവും കലക്കമുള്ള ആഴ്ചയിൽ ഇത് സാധാരണ പാഠ ക്രെഡൻഷ്യൽ സംഭരണി സൃഷ്ടിക്കുന്നു, സാധാരണയായി കൈമാറ്റത്തിന് ശേഷവും നിലനിൽക്കുന്നു.

പൈലറ്റ് ഗ്രൂപ്പ്, പിന്നീട് ജീവിതചക്ര മാറ്റങ്ങൾ

അംഗീകരിച്ച ഐഡന്റിറ്റികളുടെ ഒരു ചെറിയ ഗ്രൂപ്പ് യഥാർത്ഥ ക്ലയന്റുമായി നീക്കി, നാല് കാര്യങ്ങൾ പരീക്ഷിക്കുക: പുതിയ ലോഗിൻ, മനഃപൂർവം തെറ്റായ ക്രെഡൻഷ്യൽ, സെഷന് എത്താനാകുന്ന വിഭവങ്ങൾ, എത്താൻ പാടില്ലാത്ത വിഭവങ്ങൾ. ക്ലയന്റ് സ്വീകരിച്ച സെർവർ ഐഡന്റിറ്റിയും പരിശോധിക്കുക, കാരണം സർട്ടിഫിക്കറ്റ് പേരിന്റെ പൊരുത്തക്കേട് ആരെങ്കിലും ക്ലയന്റ് ലോഗ് വായിക്കുന്നതുവരെ കാണപ്പെടുന്നില്ല.

പിന്നീട് വിന്യാസം യഥാർത്ഥത്തിൽ ആശ്രയിക്കുന്ന മാറ്റങ്ങൾ അഭ്യസിക്കുക. പാസ്വേഡ് മാറ്റുക, സർട്ടിഫിക്കറ്റ് പുതുക്കുക അല്ലെങ്കിൽ വീണ്ടും രജിസ്റ്റർ ചെയ്യുക, ഒരു പൈലറ്റ് അക്കൗണ്ടിൽ നിന്ന് പ്രവേശനം നീക്കുക. ഓരോന്നിനും ശേഷം ഏത് പരിശോധകനാണ് ശ്രമം കൈകാര്യം ചെയ്തതെന്ന് സ്ഥിരീകരിക്കുക, കാരണം കട്ട് ഓവറിന് മുമ്പ് സൃഷ്ടിച്ച സെഷൻ പ്രവർത്തിച്ചുകൊണ്ടിരിക്കാം, അടുത്ത ലോഗിനെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല.

പ്രൊഫൈൽ വിതരണം ഐഡന്റിറ്റി മാറ്റത്തിൽ നിന്ന് വേർതിരിക്കുക. ഓരോ ഗ്രൂപ്പിനും അതിന്റെ ഉദ്ദേശിത പ്രൊഫൈൽ, ക്രെഡൻഷ്യൽ അല്ലെങ്കിൽ രജിസ്ട്രേഷൻ അവസ്ഥ, ഉപയോഗിക്കേണ്ട പ്രാമാണീകരണ സേവനം, ഒരു പിന്തുണാ ബന്ധം ആവശ്യമാണ്, ഈ രേഖകളിൽ ഒന്നും രഹസ്യം ഉൾക്കൊള്ളരുത്.

പഴയതും പുതിയതുമായ പാതകൾ ഒരുമിച്ചുണ്ടെങ്കിൽ, അവ അവസാന തീയതിയാൽ പരിമിതപ്പെടുത്തുക. സ്വയമേവയുള്ള പിൻവാങ്ങൽ പുതിയ ഉടമ പ്രവേശനം നീക്കിയതിന് ശേഷം അക്കൗണ്ടിനെ പഴയ ക്രെഡൻഷ്യലിലൂടെ അകത്തേക്ക് അനുവദിച്ചേക്കാം, ഇത് ലഭ്യതയുടെ മുഖംമൂടിയിൽ സുരക്ഷാ പിൻവാങ്ങലാണ്.

പിൻവാങ്ങൽ ക്രെഡൻഷ്യൽ പുനഃസ്ഥാപിക്കാനാവില്ല

കട്ട് ഓവർ തിരിച്ചുമാറ്റുന്നത് ഡയറക്ടറിയെ ഇപ്പോൾ ഉള്ള അതേ അവസ്ഥയിൽ വിടുന്നു. റീസെറ്റ് ചെയ്ത പാസ്വേഡ് റീസെറ്റ് ചെയ്തതായി തുടരും, റദ്ദാക്കിയ സർട്ടിഫിക്കറ്റ് റദ്ദാക്കിയതായി തുടരും, മാറ്റിയ ക്രെഡൻഷ്യൽ ഫോർമാറ്റ് മാറ്റിയതായി തുടരും. ഇവ ഡയറക്ടറിയിലെ സംഭവങ്ങളാണ്, ഗേറ്റ്വേ ഒരിക്കലും അവയുടെ ഉറവിടമായിരുന്നില്ല. വീണ്ടെടുപ്പ് ഓരോ സംഭവത്തിനും നിർവചിക്കണം, ഇതിൽ ഒന്നും പൊരുത്തമില്ലാത്ത ഹാഷിൽ നിന്ന് രഹസ്യം പുനർനിർമ്മിക്കുന്നതിനെ ആശ്രയിക്കരുത്.

കൈമാറ്റം ചെയ്യപ്പെടുന്ന കണക്ഷൻ ഉപയോഗിക്കാത്ത ഒരു ഭരണ പാത സൂക്ഷിക്കുക. പുതിയ പ്രാമാണീകരണം പരാജയപ്പെടുമ്പോൾ ഗ്രൂപ്പ് നിർത്തി, സമയപരിധി പാലിക്കാൻ എല്ലാവർക്കും പ്രാമാണീകരണം ദുർബലമാക്കുന്നതിന് പകരം അതിന്റെ രേഖപ്പെടുത്തിയ വീണ്ടെടുപ്പ് പാത ഉപയോഗിക്കുക.

ഗ്രൂപ്പുകൾ മൂടിയതിന് ശേഷം പഴയ ബാക്കെൻഡ് ക്രെഡൻഷ്യലുകൾ, പ്രൊഫൈലുകൾ, വിശ്വാസ ബന്ധങ്ങൾ അവയുടെ ഉടമകളിലൂടെ പിൻവലിക്കുക. പഴയ പാത ഇനി ഉപയോക്താക്കളെ അകത്തേക്ക് അനുവദിക്കുന്നില്ലെന്ന് സ്ഥിരീകരിക്കുക, പിന്തുണയ്ക്ക് ഇനിയും വേണ്ട രഹസ്യരഹിത ഐഡന്റിറ്റി-മുതൽ-നയം മാപ്പിംഗ് സൂക്ഷിക്കുക. കൈമാറ്റം പുതിയ ജീവിതചക്രം പ്രവർത്തിച്ച് ആരും പഴയ പാതയിലൂടെ അകത്തേക്ക് വരാനാകാത്തപ്പോൾ പൂർത്തിയാകുന്നു, അക്കൗണ്ട് പട്ടിക പൂർണ്ണമായി തോന്നുമ്പോൾ അല്ല.

അനുബന്ധ ലേഖനങ്ങൾ