AWS Client VPN SAML і Google Workspace: разрыў у зваротным выкліку
Google паказвае app_not_configured_for_user раней, чым існуе хоць які тунэль. Кліент патрабуе звычайны HTTP-зваротны выклік на loopback, якога Workspace не прымае.
Старонка app_not_configured_for_user прыходзіць з Google Workspace і з’яўляецца раней, чым узгоджаны хоць адзін пакет тунэля. Гэты парадак і ёсць увесь дыягназ. Пераўсталяванне кліента, праўка профілю або праверка маршрутаў не могуць прыбраць старонку, якую канцавы пункт VPN яшчэ не бачыў. Збойны крок — гэта перадача ў браўзеры паміж пастаўшчыком ідэнтычнасці і слухачом на ўласнай машыне карыстальніка, і ў гэтай перадачы варта праверыць роўна тры рэчы.
Чытайце старонку як заяву пастаўшчыка ідэнтычнасці
Google вяртае гэта, калі праграма SAML не ўключана для ўліковага запісу, які ўвайшоў. Праграма можа быць выключана, карыстальнік можа знаходзіцца па-за прызначанай арганізацыйнай адзінкай або групай, або налады пастаўшчыка паслуг могуць не адпавядаць таму, што патрабаваў запыт.
Нішто з гэтага не з’яўляецца праблемай сертыфіката, маршруту або тунэля, хаця карыстальнік заўважыў гэта менавіта ў кліенце VPN.
Дзве велічыні, якія кліент прыме
AWS Client VPN праводзіць абмен SAML, ініцыяваны пастаўшчыком паслуг, таму кліент адкрывае браўзер, карыстальнік аўтэнтыфікуецца, а пастаўшчык адпраўляе падпісанае сцвярджэнне на адрас Assertion Consumer Service. Для прапанаванага AWS настольнага кліента гэты адрас — слухач на loopback, звычайна порт 35001, а чаканая аўдыторыя — ідэнтыфікатар сутнасці праграмы Client VPN SAML, а не сутнасць уваходу ў кансоль AWS.
Абедзве велічыні павінны адпавядаць таму, што чакае кліент: куды адпраўляецца сцвярджэнне і каму яно адрасавана. Канфігурацыя, скапіяваная з праграмы SSO у кансолі, можа выглядаць цалкам праўдападобна і ўсё ж нацэльвацца на няправільную пару.
Берыце абедзве велічыні з патрабаванняў Client VPN SAML, а не з агульнага кіраўніцтва па адзіным уваходзе AWS. Сутнасць SSO у кансолі выглядае досыць падобна, каб спакусіць. Гэта іншая праграма з іншай аўдыторыяй, і кліент адхіляе сцвярджэнне, не тлумачачы сябе. Скапіюйце пару адзін раз і захавайце яе побач з профілем.
Google не прыме звычайны HTTP-зваротны выклік
Кансоль адміністратара патрабуе адрас ACS праз HTTPS, а зваротны выклік кліента — звычайны HTTP на loopback. Гэтую велічыню ўвогуле нельга ўпісаць у канфігурацыю праграмы Workspace, таму некаторыя каманды спрабуюць зваротны проксі, які завяршае TLS і перадае далей на лакальны слухач. Гэта не выпраўляе неадпаведнасць: браўзер бачыць адзін origin, кліент абвяшчае іншы, і вернуты адказ можа прыйсці з няправільным прызначэннем.
Працоўная схема — гэта пасярэдні пастаўшчык ідэнтычнасці. Праграма SAML у пасярэдніку атрымлівае loopback-зварот і аўдыторыю AWS, а пасярэднік федэруе ўліковы запіс Workspace вышэй. Правіла HTTPS у Google застаецца выкананым, і сцвярджэнне, якое дасягае кліента, па-ранейшаму называе чаканыя адрас і аўдыторыю.
Гэты пасярэднік — адміністрацыйная залежнасць, якой нехта павінен валодаць, якую трэба маніторыць і ўключаць у вывядзенне са службы. Гэта таксама другое месца, дзе збой ператвараецца ў няўдачу ўваходу. Ацаніце яго, перш чым абяцаць дызайн. Калі ніхто не будзе ім валодаць, сумленны адказ: кліент AWS не можа выкарыстоўваць Workspace як адзінага пастаўшчыка ідэнтычнасці.
Прызначэнне і двухэтапная праверка
Перш чым нешта перарабляць, пераканайцеся, што праграма ўключана для патрэбнай арганізацыйнай адзінкі або групы, і што ў старонніх праграм SAML ёсць уласныя кантролі прызначэння, асобныя ад спісу праграм на баку Google.
Праверце таксама, ці ўключана для ўліковага запісу двухэтапная праверка. Google можа патрабаваць яе, перш чым праграма SAML стане даступнай карыстальніку, і адзін адказ у зыходнай размове быў вырашаны менавіта так. Гэта самае таннае, што можна выключыць, і самае непрыемнае, калі выявіць апошнім.
Праверце на чыстай сесіі
Пасля любой змены тэстуйце з новым профілем браўзера і чыстай канфігурацыяй кліента. Кэшаваныя сцвярджэнні і паўторна выкарыстаныя сесіі хаваюць, ці спрацавала выпраўленне.
Затым параўнайце два запісы побач: падзею аўдыту пастаўшчыка ідэнтычнасці і журнал кліента. Паспяховы ўваход без тунэля ўказвае на зваротны выклік або аўдыторыю. Падключаны тунэль з недасяжным рэсурсам — гэта праблема маршрутызацыі або аўтарызацыі, і яна належыць зусім у іншае месца.
Што не трэба змяняць
Не выдаляйце auth-federate з профілю і не адключайце праверкі сертыфікатаў, каб абысці старонку. Абодва змяняюць дызайн аўтэнтыфікацыі, а не збойны зваротны выклік, і абодва звычайна ламаюцца пры наступным абнаўленні кліента.
Выпраўце замест гэтага перадачу і пакіньце нататку, якая называе пасярэдніка, аўдыторыю і порт loopback. Наступнаму чалавеку, які ўбачыць старонку, спатрэбяцца ўсе тры.