AWS Client VPN SAML, Google Workspace: കോൾബാക്കിലെ വിടവ്

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

പേജിനെ ഐഡന്റിറ്റി പ്രൊവൈഡറിന്റെ പ്രസ്താവനയായി വായിക്കുക

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

ഇവയൊന്നും സർട്ടിഫിക്കറ്റ്, റൂട്ട് അല്ലെങ്കിൽ ടണൽ പ്രശ്നമല്ല, ഉപയോക്താവ് അത് VPN ക്ലൈന്റിൽ ശ്രദ്ധിച്ചെങ്കിലും.

ക്ലൈന്റ് സ്വീകരിക്കുന്ന രണ്ട് മൂല്യങ്ങൾ

AWS Client VPN സേവന ദാതാവ് ആരംഭിക്കുന്ന SAML കൈമാറ്റം നടത്തുന്നു, അതിനാൽ ക്ലൈന്റ് ഒരു ബ്രൗസർ തുറക്കുന്നു, ഉപയോക്താവ് സ്വയം പ്രാമാണീകരിക്കുന്നു, ദാതാവ് ഒപ്പിട്ട പ്രസ്താവന Assertion Consumer Service URL-ലേക്ക് തിരികെ അയയ്ക്കുന്നു. AWS നൽകുന്ന ഡെസ്ക്ടോപ്പ് ക്ലൈന്റിന് ആ URL loopback-ലെ ശ്രോതാവാണ്, സാധാരണയായി പോർട്ട് 35001, പ്രതീക്ഷിക്കുന്ന പ്രേക്ഷകർ Client VPN SAML ആപ്ലിക്കേഷന്റെ എന്റിറ്റി ഐഡന്റിഫയർ ആണ്, AWS കൺസോൾ സൈൻ-ഇൻ എന്റിറ്റിയല്ല.

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

രണ്ട് മൂല്യങ്ങളും Client VPN SAML ആവശ്യകതകളിൽ നിന്ന് എടുക്കുക, പൊതുവായ AWS സിംഗിൾ സൈൻ-ഓൺ ഗൈഡിൽ നിന്നല്ല. കൺസോളിലെ SSO എന്റിറ്റി പ്രലോഭിപ്പിക്കുന്നത്ര സമാനമായി കാണപ്പെടുന്നു. അത് വേറെ പ്രേക്ഷകരുള്ള വേറെ ആപ്ലിക്കേഷനാണ്, ക്ലൈന്റ് സ്വയം വിശദീകരിക്കാതെ പ്രസ്താവന നിരസിക്കുന്നു. ജോഡി ഒരിക്കൽ പകർത്തി പ്രൊഫൈലിനരികിൽ സൂക്ഷിക്കുക.

Google സാധാരണ HTTP കോൾബാക്ക് സ്വീകരിക്കില്ല

അഡ്മിൻ കൺസോൾ HTTPS ACS URL ആവശ്യപ്പെടുന്നു, ക്ലൈന്റിന്റെ കോൾബാക്ക് loopback-ലെ സാധാരണ HTTP ആണ്. ആ മൂല്യം Workspace ആപ്പ് കോൺഫിഗറേഷനിൽ ടൈപ്പ് ചെയ്യാൻ കഴിയില്ല, അതുകൊണ്ടാണ് ചില ടീമുകൾ TLS അവസാനിപ്പിച്ച് പ്രാദേശിക ശ്രോതാവിലേക്ക് കൈമാറുന്ന റിവേഴ്സ് പ്രോക്സി പരീക്ഷിക്കുന്നത്. അത് പൊരുത്തക്കേട് പരിഹരിക്കുന്നില്ല: ബ്രൗസർ ഒരു ഒറിജിൻ കാണുന്നു, ക്ലൈന്റ് മറ്റൊന്ന് പ്രഖ്യാപിക്കുന്നു, തിരികെ വരുന്ന പ്രതികരണം തെറ്റായ ലക്ഷ്യസ്ഥാനത്ത് എത്താം.

പ്രവർത്തിക്കുന്ന ക്രമീകരണം ബ്രോക്കർ ഐഡന്റിറ്റി പ്രൊവൈഡർ ആണ്. ബ്രോക്കറിലെ SAML ആപ്ലിക്കേഷന് loopback കോൾബാക്കും AWS പ്രേക്ഷകരും ലഭിക്കുന്നു, ബ്രോക്കർ Workspace അക്കൗണ്ട് മുകളിലേക്ക് ഫെഡറേറ്റ് ചെയ്യുന്നു. Google-ന്റെ HTTPS നിയമം തൃപ്തികരമായി തുടരുന്നു, ക്ലൈന്റിലെത്തുന്ന പ്രസ്താവന ഇപ്പോഴും അത് പ്രതീക്ഷിക്കുന്ന വിലാസവും പ്രേക്ഷകരും പേരെടുത്ത് പറയുന്നു.

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

അനുവദനവും രണ്ട് ഘട്ട പരിശോധനയും

എന്തെങ്കിലും പുനർരൂപകൽപ്പന ചെയ്യുന്നതിന് മുൻപ് ആപ്പ് ശരിയായ ഓർഗനൈസേഷണൽ യൂണിറ്റിനോ ഗ്രൂപ്പിനോ ഓണാണെന്നും മൂന്നാം കക്ഷി SAML ആപ്പുകൾക്ക് Google വശത്തെ ആപ്പ് പട്ടികയിൽ നിന്ന് വേറിട്ട സ്വന്തം അനുവദന നിയന്ത്രണങ്ങളുണ്ടെന്നും ഉറപ്പാക്കുക.

അക്കൗണ്ടിൽ രണ്ട് ഘട്ട പരിശോധന പ്രവർത്തനക്ഷമമാണോ എന്നും പരിശോധിക്കുക. ഒരു SAML ആപ്പ് ഉപയോക്താവിന് ഉപയോഗയോഗ്യമാകുന്നതിന് മുൻപ് Google അത് ആവശ്യപ്പെടാം, യഥാർത്ഥ ത്രെഡിലെ ഒരു ഉത്തരം കൃത്യമായി അങ്ങനെയാണ് പരിഹരിച്ചത്. ഒഴിവാക്കാൻ ഏറ്റവും വിലകുറഞ്ഞതും അവസാനം കണ്ടെത്താൻ ഏറ്റവും ശല്യപ്പെടുത്തുന്നതുമായ കാര്യമാണിത്.

ശുദ്ധമായ സെഷൻ ഉപയോഗിച്ച് പരിശോധിക്കുക

ഏതെങ്കിലും മാറ്റത്തിന് ശേഷം പുതിയ ബ്രൗസർ പ്രൊഫൈലും ശുദ്ധമായ ക്ലൈന്റ് കോൺഫിഗറേഷനും ഉപയോഗിച്ച് പരിശോധിക്കുക. കാഷ് ചെയ്ത പ്രസ്താവനകളും വീണ്ടും ഉപയോഗിച്ച സെഷനുകളും പരിഹാരം ഫലിച്ചോ എന്ന് മറയ്ക്കുന്നു.

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

എന്ത് മാറ്റരുത്

പേജ് കടക്കാൻ പ്രൊഫൈലിൽ നിന്ന് auth-federate നീക്കം ചെയ്യരുത്, സർട്ടിഫിക്കറ്റ് പരിശോധനകൾ പ്രവർത്തനരഹിതമാക്കരുത്. രണ്ടും പരാജയപ്പെടുന്ന കോൾബാക്കിന് പകരം പ്രാമാണീകരണ ഡിസൈൻ മാറ്റുന്നു, രണ്ടും സാധാരണയായി അടുത്ത ക്ലൈന്റ് അപ്ഡേറ്റിൽ തകരുന്നു.

പകരം കൈമാറ്റം ശരിയാക്കുക, ബ്രോക്കർ, പ്രേക്ഷകർ, loopback പോർട്ട് എന്നിവ പേരെടുത്ത് പറയുന്ന ഒരു കുറിപ്പ് വിടുക. പേജ് കാണുന്ന അടുത്ത വ്യക്തിക്ക് മൂന്നും ആവശ്യമാകും.