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 પોર્ટનું નામ દર્શાવતી નોંધ છોડો. પૃષ્ઠ જોનારી આગલી વ્યક્તિને ત્રણેયની જરૂર પડશે.