ഓരോ അക്കൗണ്ടിനും സാധാരണ രീതിയിൽ ലോഗിൻ ചെയ്യാൻ അനുവദിക്കുക, എന്നാൽ VPN ഉപയോഗിക്കാൻ ഒരു ഗ്രൂപ്പിന് മാത്രം അനുമതി നൽകുക. രണ്ടാമത് ഒരു പാസ്വേഡ് സംഭരണിയില്ലാതെ PAMക്ക് ആ വ്യത്യാസം പ്രകടിപ്പിക്കാം, കൂടാതെ OpenVPN പ്ലഗിൻ നിങ്ങൾ ഉദ്ദേശിക്കുന്ന പരിശോധനകൾ മാത്രം അടങ്ങുന്ന ഒരു സേവനത്തിലേക്ക് ചൂണ്ടിക്കാണിക്കാം. സിസ്റ്റം പരിധിയിലുള്ള സ്റ്റാക്ക് അബദ്ധത്തിൽ പാരമ്പര്യമായി സ്വീകരിക്കാതെ ആ സേവനം നിർമ്മിക്കുകയാണ് തന്ത്രം.

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

എന്തിന് പ്രത്യേക PAM സേവനം

auth-pam പ്ലഗിൻ അതിന്റെ ആർഗ്യുമെന്റായി ഒരു സേവനനാമം എടുക്കുന്നു. ആ നാമം /etc/pam.d ക്ക് കീഴിലുള്ള ഒരു ഫയൽ തിരഞ്ഞെടുക്കുന്നു, ആ ഫയലിലെ സ്റ്റാക്കാണ് VPN ലോഗിൻ സമയത്ത് പ്രവർത്തിക്കുന്നത്. സിസ്റ്റം പരിധിയിലുള്ള ലോഗിൻ ഉപയോഗിക്കുന്ന അതേ പേര് നൽകിയാൽ, ആ സ്റ്റാക്കിലെ എല്ലാ തീരുമാനങ്ങളും നിങ്ങൾ പാരമ്പര്യമായി സ്വീകരിക്കും, പിന്നീട് അപ്രസക്തമായ കാരണങ്ങളാൽ ചേർത്തവയും ഉൾപ്പെടെ.

പകരം പ്രത്യേക സേവനം സൃഷ്ടിക്കുക. ഉദ്ദേശിച്ച backendനോട് ഇതിനകം പ്രാമാണീകരിക്കുന്ന പ്രവർത്തിക്കുന്ന സ്റ്റാക്കിൽ നിന്ന് ആരംഭിക്കുക, ഉദാഹരണത്തിന് ഒരു പ്രാദേശിക പാസ്വേഡ് ഫയൽ, SSSD അല്ലെങ്കിൽ ഒരു ഡയറക്ടറി സേവനം, തുടർന്ന് യോഗ്യതാ നിയമം ചേർക്കുക. ശൂന്യമായ ഫയലിലേക്ക് രണ്ട് വരികൾ പകർത്തുന്നതാണ് സാധാരണ തെറ്റ്: പാസ്വേഡ് കാലഹരണം, അക്കൗണ്ട് ലോക്ക്, മറ്റ് പരിശോധനകൾ എന്നിവ നിങ്ങൾ പകർത്താത്ത സ്റ്റാക്കിൽ ആകാം.

സേവനം വേർതിരിക്കുന്നത് നാശത്തിന്റെ പരിധിയും പരിമിതപ്പെടുത്തുന്നു. പങ്കിട്ട സ്റ്റാക്കിലെ VPN-മാത്രം നിയമം എല്ലാവർക്കും SSH അല്ലെങ്കിൽ കൺസോൾ പ്രവേശനം നിഷേധിക്കാം, ഇത് പ്രവേശന മാറ്റത്തെ തടസ്സമാക്കി മാറ്റുന്നു.

ഗ്രൂപ്പ് നിയമം എഴുതുന്നു

യോഗ്യതാ പരിശോധന ക്രെഡൻഷ്യൽ സ്ഥിരീകരിച്ചതിന് ശേഷമുള്ള അക്കൗണ്ട് ഘട്ടത്തിൽ പെടുന്നു. account required pam_succeed_if.so user ingroup vpnusers പോലുള്ള ഒരു നിയമം, പ്രാമാണീകരിച്ച ഉപയോക്താവ് ആ ഗ്രൂപ്പിലെ അംഗമാകുമ്പോൾ മാത്രം പ്രോസസ്സിംഗ് തുടരാൻ അനുവദിക്കുന്നു.

ആ വരി ഒരു ശകലമാണ്, പൂർണ്ണ സേവനമല്ല. സ്വീകരിക്കപ്പെടുന്ന എല്ലാ പാതയും അതിൽ എത്തുന്നിടത്ത് അത് സംയോജിപ്പിക്കുക, അതിന് ചുറ്റുമുള്ള നിയന്ത്രണ ഫ്ലാഗുകൾ പരിശോധിക്കുക. സ്റ്റാക്കിൽ മുൻപുള്ള sufficient അല്ലെങ്കിൽ ജംപ് നിയന്ത്രണം നിങ്ങളുടെ നിയമം പ്രവർത്തിക്കുന്നതിന് മുൻപ് പ്രോസസ്സിംഗ് അവസാനിപ്പിക്കാം, ഇത് നിയന്ത്രണത്തെ ഒരു നിർദ്ദേശമാക്കി മാറ്റുന്നു.

ശീലത്തിന്റെ പേരിൽ use_uid ചേർക്കരുത്. അതില്ലാതെ മൊഡ്യൂൾ പ്രാമാണീകരിക്കപ്പെടുന്ന ഉപയോക്താവിനെ വിലയിരുത്തുന്നു; അതോടെ മൊഡ്യൂൾ OpenVPN പ്രോസസ്സ് പ്രവർത്തിക്കുന്ന അക്കൗണ്ടിനെ വിലയിരുത്തുന്നു, അത് സാധാരണയായി root അല്ലെങ്കിൽ ഒരു സേവന അക്കൗണ്ടാണ്, അതിനാൽ ലോഗിൻ ചെയ്യുന്ന വ്യക്തിയല്ല.

ഗ്രൂപ്പ് അംഗത്വം സിസ്റ്റത്തിന്റെ ഐഡന്റിറ്റി പരിഹാരത്തിൽ നിന്നാണ് വരുന്നത്, നിങ്ങൾ തിരിച്ചറിയുന്ന ഒരു പേരിൽ നിന്നല്ല. ഡയറക്ടറി ഉപയോക്താക്കൾക്ക്, അതേ backend ആ ഉപയോക്താവിന്റെ ഗ്രൂപ്പ് അന്വേഷണങ്ങൾക്ക് ഉത്തരം നൽകുന്നുവെന്ന് ഉറപ്പാക്കുക, കാരണം പരിചിതമായ പേരുള്ള ഒരു പ്രാദേശിക ഗ്രൂപ്പ് അതേ പേരുള്ള ഡയറക്ടറി ഗ്രൂപ്പിൽ നിന്ന് വ്യത്യസ്ത വസ്തുവാണ്.

ക്രമവും ഐഡന്റിറ്റിയും കെണികൾ

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

ഇരട്ട സ്റ്റാക്കുകളെ സൂക്ഷിക്കുക. സാധാരണ മാതൃക ഇതാണ്: ഇതിനകം ഒരു അക്കൗണ്ട് നിയമം അടങ്ങുന്ന include, തുടർന്ന് നിങ്ങളുടെ സ്വന്തം ഗ്രൂപ്പ് നിയമം, ഇത് ഒന്ന് പ്രതീക്ഷിച്ചിടത്ത് രണ്ട് തീരുമാനങ്ങൾ ഉണ്ടാക്കുന്നു. നിങ്ങൾ തിരുത്തിയ ഫയൽ മാത്രമല്ല, ഉൾപ്പെടുത്തിയ ഫയലും വായിക്കുക. ഫലപ്രദമായ ക്രമം കാണാനുള്ള വേഗമാർഗം ഫയൽ മുകളിൽ നിന്ന് താഴേക്ക് വായിച്ച് ഓരോ നിയന്ത്രണ മൂല്യവും എഴുതിവയ്ക്കുകയാണ്.

മറ്റ് പ്രവേശന ആവശ്യകതകൾ അതേപടി നിലനിർത്തുക. വിജയകരമായ പാസ്വേഡ് സർട്ടിഫിക്കറ്റ് പരിശോധനകൾ, രണ്ടാം ഘടകം, അല്ലെങ്കിൽ കണക്ഷന് ശേഷമുള്ള അധികാരം എന്നിവയ്ക്ക് പകരമാകുന്നില്ല, ഈ നയവും അവയിൽ ഒന്നിനും പകരമല്ല. അക്കൗണ്ട് VPN പ്രവേശനത്തിന് പരിഗണിക്കാൻ യോഗ്യമാണോ എന്ന് മാത്രം ഇത് തീരുമാനിക്കുന്നു.

അംഗങ്ങളെയും പുറത്തുള്ളവരെയും തെറ്റായ പാസ്വേഡുകളെയും പരീക്ഷിക്കുന്നു

നയം പൂർണ്ണമെന്ന് കരുതുന്നതിന് മുൻപ് മൂന്ന് കേസുകൾ പരീക്ഷിക്കുക. ഒരു അംഗം വിജയകരമായി കണക്റ്റ് ചെയ്യുന്നു. ഗ്രൂപ്പിന് പുറത്തുള്ള സാധുവായ ഒരു അക്കൗണ്ട് അതിന്റെ പാസ്വേഡ് പ്രാമാണീകരിക്കുന്നു, പക്ഷേ VPN പ്രവേശനം നിഷേധിക്കപ്പെടുന്നു. ഏതെങ്കിലും അക്കൗണ്ടിനുള്ള തെറ്റായ പാസ്വേഡ് പ്രാമാണീകരണ ഘട്ടത്തിൽ തള്ളപ്പെടുന്നു, ഗ്രൂപ്പ് നിയമത്താൽ അല്ല.

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

PAM തിരുത്തുമ്പോൾ രണ്ടാമത്തെ സെഷൻ തുറന്ന് വയ്ക്കുക, മാറ്റത്തിന് ശേഷം സാധാരണ SSH ലോഗിനും പരിശോധിക്കുക. സമർപ്പിത സേവനത്തിന്റെ ഉദ്ദേശ്യം സിസ്റ്റം ലോഗിൻ ബാധിക്കപ്പെടരുത് എന്നതാണ്, അത് അറിയാനുള്ള ഏക വഴി അത് പരീക്ഷിക്കുകയാണ്.

എന്തെങ്കിലും തകർന്നാൽ പകർപ്പിൽ നിന്ന് മുൻ സേവന ഫയൽ പുനഃസ്ഥാപിക്കുക. ആവശ്യമായ നിയമം പറയാൻ എളുപ്പമാണ്: അംഗത്വം ഒരു അക്കൗണ്ടിനെ VPN പ്രവേശനത്തിന് യോഗ്യമാക്കുന്നു, മറ്റ് എല്ലാ നിർബന്ധിത പരിശോധനകളും ഇപ്പോഴും ബാധകമാണ്.

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