A Microsoft Entra alkalmazásproxyval kapcsolatos gyakori kérdések

Nem, az alkalmazásproxy a következő konfigurációelemeket használja, és nem szabad módosítani vagy törölni:

• Engedélyezze/tiltsa le a "Nyilvános ügyfélfolyamatok engedélyezése" lehetőséget.
• CWAP_AuthSecret (titkos ügyfélkódok).
• API-engedélyek. A fenti konfigurációelemek módosítása az alkalmazásregisztrációs oldalon megszakítja a Microsoft Entra alkalmazásproxy előzetes hitelesítését.

Nem, törölnie kell egy alkalmazásproxy-alkalmazást a Microsoft Entra felügyeleti központ Nagyvállalati alkalmazások területéről. Ha törli az alkalmazásproxy-alkalmazást a Microsoft Entra felügyeleti központ Alkalmazásregisztrációk területéről, problémákat tapasztalhat.

A Microsoft Entra alkalmazásproxy használatához P1 vagy P2 Microsoft Entra-azonosítójú licenccel kell rendelkeznie. A licenceléssel kapcsolatos további információkért tekintse meg a Microsoft Entra díjszabását

Ha a licenc lejár, az alkalmazásproxy automatikusan le lesz tiltva. Az alkalmazás adatai legfeljebb egy évig lesznek mentve.

Győződjön meg arról, hogy legalább egy P1 vagy P2 Azonosítójú Microsoft Entra-licenccel és egy Microsoft Entra magánhálózati összekötővel rendelkezik. Az első összekötő sikeres telepítése után a Microsoft Entra alkalmazásproxy szolgáltatás automatikusan engedélyezve lesz.

Igen, a Microsoft Entra privát hálózati összekötőt az alkalmazásproxy és a Microsoft Entra privát hozzáférés is használja. Az összekötőről további információt a Microsoft Entra magánhálózati összekötő című témakörben talál. Az összekötők konfigurálásának hibaelhárításához tekintse meg az összekötők hibaelhárítását.

Bár ezek az utótagok megjelennek az utótaglistában, nem érdemes használni őket. Ezek a tartomány-utótagok nem a Microsoft Entra alkalmazásproxyval való használatra szolgálnak. Ha ezeket a tartományi utótagokat használja, a létrehozott Microsoft Entra alkalmazásproxy-alkalmazás nem fog működni. Használhatja a standard tartomány utótagját msappproxy.net vagy egy egyéni tartományt.

A Microsoft Entra ID egy alkalmazásproxy szolgáltatással rendelkezik, amely lehetővé teszi a felhasználók számára a helyszíni alkalmazások elérését a Microsoft Entra-fiókjukkal való bejelentkezéssel. Ha különböző régiókban telepített összekötőket, úgy optimalizálhatja a forgalmat, ha kiválasztja a legközelebbi alkalmazásproxy felhőszolgáltatás-régiót, amelyet az egyes összekötőcsoportokhoz használni szeretne. Lásd: Forgalom optimalizálása a Microsoft Entra alkalmazásproxyval.

Miután feltöltötte az SSL-tanúsítványt, a portálon megjelenik az "Érvénytelen tanúsítvány, lehetséges helytelen jelszó" üzenet.

Néhány tipp a hiba elhárításához:

• Ellenőrizze, hogy nincs-e probléma a tanúsítvánnyal. Telepítse a helyi számítógépre. Ha nem tapasztal problémát, a tanúsítvány rendben van.
• Győződjön meg arról, hogy a jelszó nem tartalmaz speciális karaktereket. A jelszónak csak a 0-9, az A-Z és az a-z karaktereket kell tartalmaznia.
• Ha a tanúsítványt a Microsoft szoftverkulcstároló-szolgáltatójával hozta létre, az RSA-algoritmust kell használnia.

Az alapértelmezett hossz 85 másodperc. A "hosszú" beállítás 180 másodperc. Az időtúllépési korlát nem hosszabbítható meg.

Nem, ez jelenleg nem támogatott.

A Microsoft Entra alkalmazásproxy-alkalmazás létrehozásakor a rendszer automatikusan hozzáadja az CWAP_AuthSecret nevű ügyfélkulcsot az alkalmazásobjektumhoz (alkalmazásregisztrációhoz).

Az ügyfélkód egy évig érvényes. A rendszer automatikusan létrehoz egy új egyéves ügyfélkulcsot, mielőtt az aktuális érvényes ügyfélkód lejár. Három CWAP_AuthSecret ügyfélkulcs mindig az alkalmazásobjektumban marad.

Nem, az eredeti tartalék tartományt kell használnia.

A szóban forgó cikk: Onmicrosoft.com tartalék tartomány hozzáadása és cseréje a Microsoft 365-ben

Az Alkalmazásregisztrációk lapon módosíthatja a kezdőlap URL-címét a kezdőlap kívánt külső URL-címére. A megadott lap betöltődik, amikor az alkalmazás Saját alkalmazások vagy az Office 365 Portálról indul. A konfigurációs lépésekért lásd: Egyéni kezdőlap beállítása közzétett alkalmazásokhoz a Microsoft Entra alkalmazásproxyval

Ha a Microsoft Entra előzetes hitelesítése konfigurálva van, és az alkalmazás URL-címe egy "#" karaktert tartalmaz, amikor először próbál hozzáférni az alkalmazáshoz, a rendszer átirányítja a hitelesítéshez a Microsoft Entra-azonosítóra (login.microsoftonline.com). A hitelesítés befejezése után a rendszer átirányítja az URL-részre a "#" karakter előtt, és úgy tűnik, hogy a "#" után megjelenő összes elem figyelmen kívül lesz hagyva/ eltávolítva. Ha például az URL-cím az https://www.contoso.com/#/home/index.html, a Microsoft Entra-hitelesítés befejezése után a rendszer átirányítja a felhasználót https://www.contoso.com/. Ezt a viselkedést a böngésző a "#" karakter kezelésének köszönhetően tervezheti.

Lehetséges megoldások/ alternatívák:

• Átirányítás beállítása a célról https://www.contoso.com a következőre https://contoso.com/#/home/index.html: . A felhasználónak először hozzá kell férnie https://www.contoso.com.
• Az első hozzáférési kísérlethez használt URL-címnek tartalmaznia kell a "#" karaktert kódolt formában (%23). Előfordulhat, hogy a közzétett kiszolgáló nem fogadja el ezt.
• A passthrough preauthentication típus konfigurálása (nem ajánlott).

Nem, a közzétett alkalmazásokhoz nincs IIS-követelmény. A Windows Serveren kívüli kiszolgálókon futó webalkalmazásokat közzéteheti. Előfordulhat azonban, hogy nem windowsos kiszolgálóval nem tud előhitelesítést használni attól függően, hogy a webkiszolgáló támogatja-e az egyeztetést (Kerberos-hitelesítés). Nincs szükség IIS-ra azon a kiszolgálón, amelyen az összekötő telepítve van.

Az alkalmazásproxy nem adja hozzá automatikusan a HTTP Strict-Transport-Security fejlécet a HTTPS-válaszokhoz, de fenntartja a fejlécet, ha a közzétett alkalmazás által küldött eredeti válaszban van. A funkció engedélyezésére vonatkozó beállítás igazolása az ütemtervben található.

Nem, ha a protokoll http a külső URL-címben van konfigurálva, akkor a Microsoft Entra alkalmazásproxy-végpontja fogadja a bejövő kéréseket a TCP 80 porton, ha a protokoll https , majd a TCP 443 porton.

Igen, néhány példa a belső URL-címekre, beleértve a portokat: http://app.contoso.local:8888/, https://app.contoso.local:8080/, https://app.contoso.local:8081/test/.

A közzétett webalkalmazások által küldött válaszok némelyike tartalmazhat szigorúan kódolt URL-címeket. Ebben az esetben egy hivatkozásfordítási megoldással kell biztosítani, hogy az ügyfél mindig a megfelelő URL-címet használja. A hivatkozásfordítási megoldások összetettek lehetnek, és előfordulhat, hogy nem minden forgatókönyvben működnek. A hivatkozásfordítás dokumentált megoldásait itt találja.

Ajánlott eljárásként ajánlott azonos külső és belső URL-címeket használni. A külső és belső URL-címek azonosnak minősülnek, ha mindkét protocol://hostname:port/path/ URL-cím azonos.

Ez az Egyéni tartományok funkcióval érhető el.

Példák:

Azonos:

External URL: https://app1.contoso.com/test/
Internal URL: https://app1.contoso.com/test/

Nem azonos:

External URL: https://app1.contoso.com/test/
Internal URL: http://app1.contoso.com/test/

External URL: https://app1.contoso.com/test/
Internal URL: https://app1.contoso.com:8080/test/

External URL: https://app1.msappproxy.net/test/
Internal URL: https://app1.contoso.com:/test/

A külső és belső URL-címek azonossá tétele egyáltalán nem lehetséges, ha a belső URL-cím nem szabványos portot tartalmaz (a TCP 80/443-at kivéve).

Bizonyos esetekben módosításokat kell végrehajtani a webalkalmazás konfigurációjában.

A PrincipalsAllowedToDelegateToAccount metódust akkor használja a rendszer, ha az összekötő-kiszolgálók más tartományban vannak, mint a webalkalmazás-szolgáltatásfiók. Erőforrás-alapú korlátozott delegálást igényel. Ha az összekötő-kiszolgálók és a webalkalmazás-szolgáltatásfiók ugyanabban a tartományban vannak, a Active Directory - felhasználók és számítógépek használatával konfigurálhatja a delegálási beállításokat az egyes összekötőgép-fiókokon, lehetővé téve számukra, hogy delegálják őket a cél egyszerű szolgáltatásnévre.

Ha az összekötő-kiszolgálók és a webalkalmazás-szolgáltatásfiók különböző tartományokban vannak, a rendszer erőforrás-alapú delegálást használ. A delegálási engedélyek a cél webkiszolgálón és a webalkalmazás-szolgáltatásfiókon vannak konfigurálva. Ez a korlátozott delegálási módszer viszonylag új. A metódus a Windows Server 2012-ben lett bevezetve, amely támogatja a tartományok közötti delegálást azáltal, hogy lehetővé teszi az erőforrás (webszolgáltatás) tulajdonosának, hogy szabályozza, mely gép- és szolgáltatásfiókok delegálhatók hozzá. Ehhez a konfigurációhoz nincs felhasználói felület, ezért a PowerShellt kell használnia. További információ: A Kerberos korlátozott delegálásának ismertetése alkalmazásproxyval.

Az NTLM-hitelesítés nem használható előhitelesítésként vagy egyszeri bejelentkezési módszerként. Az NTLM-hitelesítés csak akkor használható, ha közvetlenül az ügyfél és a közzétett webalkalmazás között lehet tárgyalni. Az NTLM-hitelesítés használata általában azt eredményezi, hogy megjelenik egy bejelentkezési kérés a böngészőben.

Nem, ez nem fog működni, mert a Microsoft Entra-azonosítóban lévő vendégfelhasználók nem rendelkeznek a fent említett bejelentkezési identitások egyikéhez szükséges attribútummal sem.

Ebben az esetben a "Felhasználónév neve" visszaesik. A B2B-forgatókönyvkel kapcsolatos további részletekért olvassa el a B2B-felhasználók hozzáférésének biztosítását a Microsoft Entra ID-ban a helyszíni alkalmazásokhoz.

A feltételes hozzáférési szabályzatok csak a Microsoft Entra-azonosítóban sikeresen előhitelesített felhasználók számára lesznek kikényszerítve. Az átmenő hitelesítés nem aktiválja a Microsoft Entra-hitelesítést, így a feltételes hozzáférési szabályzatok nem kényszeríthetők ki. Az átmenő hitelesítéssel az MFA-szabályzatokat a helyszíni kiszolgálón kell megvalósítani, ha lehetséges, vagy a Microsoft Entra alkalmazásproxyval történő előhitelesítés engedélyezésével.

Nem, ez a forgatókönyv nem támogatott, mert az alkalmazásproxy leállítja a TLS-forgalmat.

Tekintse meg a Távoli asztal közzététele a Microsoft Entra alkalmazásproxyval című témakört.

Nem, ez a forgatókönyv nem támogatott.

Igen, ez várható. Az előhitelesítési forgatókönyvhez ActiveX-vezérlő szükséges, amely külső böngészőkben nem támogatott.

Igen, ez a forgatókönyv jelenleg nyilvános előzetes verzióban érhető el. Tekintse meg a Távoli asztal közzététele a Microsoft Entra alkalmazásproxyval című témakört.

Igen, ez várható. Ha a felhasználó számítógépe csatlakozik a Microsoft Entra-hoz, a felhasználó automatikusan bejelentkezik a Microsoft Entra-azonosítóba. A felhasználónak csak az RDWeb bejelentkezési űrlapon kell megadnia a hitelesítő adatait.

Ez a beállítás lehetővé teszi, hogy a felhasználó letöltse az rdp-fájlt, és egy másik RDP-ügyfél használja (a távoli asztali webügyfélen kívül). Egy másik RDP-ügyfél (például a Microsoft Távoli asztal Ügyfél) általában nem tudja natív módon kezelni az előhitelesítést. Ezért nem működik a forgatókönyv.

Tekintse meg a SharePoint távoli elérésének engedélyezése a Microsoft Entra alkalmazásproxyval című témakört.

A SharePoint mobilalkalmazás jelenleg nem támogatja a Microsoft Entra előhitelesítését.

Nem, a Microsoft Entra alkalmazásproxy úgy van kialakítva, hogy a Microsoft Entra-azonosítóval működjön, és nem felel meg az AD FS-proxyként való működésre vonatkozó követelményeknek.

Nem, ez nem támogatott.

A WebSocket protokollt használó alkalmazások, például a QlikSense és a Távoli asztali webügyfél (HTML5) mostantól támogatottak. Az alábbiak ismert korlátozások:

• Az alkalmazásproxy elveti a kiszolgáló válaszán a WebSocket-kapcsolat megnyitásakor beállított cookie-t.
• A WebSocket-kérelemre nincs SSO alkalmazva.
• A Windows Rendszergazda Center (WAC) funkciói (Eventlogs, PowerShell és Távoli asztali szolgáltatások) nem működnek a Microsoft Entra alkalmazásproxyn keresztül.

A WebSocket-alkalmazás nem rendelkezik egyedi közzétételi követelményekkel, és ugyanúgy közzétehető, mint a többi alkalmazásproxy-alkalmazás.

Igen. A hivatkozásfordítás hatással van a teljesítményre. Az alkalmazásproxy szolgáltatás megvizsgálja az alkalmazást, és lecseréli azokat a megfelelő, közzétett külső URL-címekre, mielőtt a felhasználó elé tárja őket.

A legjobb teljesítmény érdekében javasoljuk, hogy egyéni tartományok konfigurálásával azonos belső és külső URL-címeket használjunk. Ha egyéni tartományok használata nem lehetséges, a Saját alkalmazások Biztonságos bejelentkezés bővítmény vagy a Microsoft Edge Böngésző mobileszközökön történő használatával javíthatja a hivatkozásfordítás teljesítményét. Lásd: A Microsoft Entra alkalmazásproxyval közzétett alkalmazásokra vonatkozó, szigorúan kódolt átirányítási hivatkozások.

Ez a forgatókönyv nem támogatott közvetlenül. Ebben a forgatókönyvben a következő lehetőségek közül választhat:

1. A HTTP- és HTTPS-URL-címeket külön alkalmazásként is közzéteheti helyettesítő karakterrel, de mindegyiknek adjon egy másik egyéni tartományt. Ez a konfiguráció működik, mivel eltérő külső URL-címekkel rendelkeznek.

2. A HTTPS URL-cím közzététele helyettesítő alkalmazáson keresztül. Tegye közzé a HTTP-alkalmazásokat külön az alkalmazásproxy PowerShell-parancsmagjaival:

   • Alkalmazásproxy-alkalmazáskezelés
   • privát hálózati összekötő kezelése