Azure AD(Active Directory) 애플리케이션 프록시 질문과 대답

아니요, 다음 구성 항목은 앱 프록시에서 사용되며 변경하거나 삭제해서는 안 됩니다.

• "공용 클라이언트 흐름 허용"을 사용/사용하지 않도록 설정합니다.
• CWAP_AuthSecret(클라이언트 암호).
• API 권한. 앱 등록 페이지에서 위의 구성 항목을 수정하면 Azure AD 애플리케이션 프록시에 대한 사전 인증이 중단됩니다.

아니요. 앱 프록시 앱은 Azure Portal의 엔터프라이즈 애플리케이션 영역에서 삭제해야 합니다. Azure Portal의 앱 등록 영역에서 앱 프록시 앱을 삭제하면 문제가 발생할 수 있습니다.

Azure AD 애플리케이션 프록시를 사용하려면 Azure AD Premium P1 또는 P2 라이선스가 있어야 합니다. 라이선스에 대한 자세한 내용은 Azure Active Directory 가격 책정을 참조하세요.

라이선스가 만료되면 애플리케이션 프록시가 자동으로 사용하지 않도록 설정됩니다. 애플리케이션 정보는 최대 1년 동안 저장됩니다.

적어도 Azure AD Premium P1 또는 P2 라이선스가 있으며 Azure AD 애플리케이션 프록시 커넥터가 설치되어 있는지 확인하세요. 첫 번째 커넥터를 성공적으로 설치하면 Azure AD 애플리케이션 프록시 서비스가 자동으로 사용하도록 설정됩니다.

이 문제는 업데이트 프로그램 서비스가 올바르게 작동하지 않거나 서비스에서 설치할 수 있는 새 업데이트가 없는 경우에 발생할 수 있습니다.

업데이트 프로그램 서비스가 실행 중이고 이벤트 로그에 기록된 오류가 없는 경우(애플리케이션 및 서비스 로그 -> Microsoft -> AadApplicationProxy -> 업데이트 프로그램 -> 관리자) 업데이트 프로그램 서비스가 정상인 것입니다.

커넥터를 수동으로 업그레이드하려면

• 최신 버전의 커넥터를 다운로드합니다. (Azure Portal의 애플리케이션 프록시 아래에서 찾을 수 있습니다. Azure AD 애플리케이션 프록시: 버전 릴리스 기록에서 링크를 찾을 수도 있습니다.
• 설치 관리자가 Azure AD 애플리케이션 프록시 커넥터 서비스를 다시 시작합니다. 일부 경우에는 설치 관리자가 모든 파일을 바꿀 수 없는 경우 서버를 다시 부팅해야 할 수 있습니다. 따라서 업그레이드를 시작하기 전에 모든 애플리케이션을 닫는 것이 좋습니다(예: 이벤트 뷰어).
• 설치 관리자를 실행합니다. 업그레이드 프로세스가 신속하게 진행되며 자격 증명을 제공할 필요가 없으며 커넥터는 다시 등록되지 않습니다.

아니요. 이 시나리오는 지원되지 않습니다. 기본 설정은 다음과 같습니다.

• Microsoft Azure Active Directory 애플리케이션 프록시 커넥터 - WAPCSvc - 네트워크 서비스
• Microsoft Azure Active Directory 애플리케이션 프록시 커넥터 업데이트 프로그램 - WAPCUpdaterSvc - NT Authority\System

아니요. 현재는 가능하지 않습니다. 등록 시도는 항상 사용자의 홈 테넌트에서 수행됩니다.

권장 사항은 애플리케이션 프록시 커넥터 및 애플리케이션의 고가용성 및 부하 분산을 참조하세요.

애플리케이션 프록시 커넥터는 Azure에 대한 인증서 기반 인증을 수행합니다. TlS 종료(TLS/HTTPS 검사 또는 가속)는 이 인증 방법을 중단하며 지원되지 않습니다. 커넥터에서 Azure로의 트래픽은 TLS 종료를 수행하는 모든 디바이스를 무시해야 합니다.

예. 고객에게 동급 최고의 암호화를 제공하기 위해 애플리케이션 프록시 서비스는 TLS 1.2 프로토콜에 대한 액세스만 제한합니다. 이러한 변경 내용은 2019년 8월 31일 이후에 점진적으로 롤아웃되고 유효합니다. TLS 1.2를 사용하여 애플리케이션 프록시 서비스에 대한 연결을 유지하도록 모든 클라이언트-서버 및 브라우저-서버 조합을 업데이트해야 합니다. 여기에는 사용자가 애플리케이션 프록시를 통해 게시된 애플리케이션에 액세스할 때 사용하는 클라이언트도 포함됩니다. Office 365의 TLS 1.2에서 유용한 참고 자료 및 리소스를 확인하세요.

예, 이 시나리오는 커넥터 버전 1.5.1526.0부터 지원됩니다. 기존 온-프레미스 프록시 서버 작업을 참조하세요.

이렇게 해야 할 이유는 없습니다. 모든 전역 관리자 또는 애플리케이션 관리자 계정이 작동합니다. 설치 중에 입력한 자격 증명은 등록 프로세스 후에 사용되지 않습니다. 대신, 해당 지점에서의 인증에 사용되는 인증서가 커넥터에 발급됩니다.

커넥터와 함께 설치되는 성능 모니터 카운터가 있습니다. 이 내용을 확인하려면 다음을 수행하십시오.

1. 시작을 선택하고 "Perfmon"을 입력한 다음, Enter 키를 누릅니다.
2. 성능 모니터를 선택하고 녹색 + 아이콘을 클릭합니다.
3. 모니터링하려는 Microsoft Azure Active Directory 애플리케이션 프록시 커넥터 카운터를 추가합니다.

커넥터가 동일한 서브넷에 있을 필요는 없습니다. 그러나 리소스에 대한 이름 확인(DNS, hosts 파일) 및 필요한 네트워크 연결(리소스에 대한 라우팅, 리소스에서 열린 포트 등)이 필요합니다. 권장 사항에 대해서는 Azure Active Directory 애플리케이션 프록시를 사용할 때 네트워크 토폴로지 고려 사항을 참조하세요.

애플리케이션 프록시에는 Windows Server 2012 R2 이상이 필요합니다. 현재 Windows Server 2019용 HTTP2에는 제한이 적용됩니다. Windows Server 2019에서 커넥터를 성공적으로 사용하려면 다음 레지스트리 키를 추가하고 서버를 다시 시작해야 합니다.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp\EnableDefaultHttp2 (DWORD) Value: 0 

커넥터가 실행 중인 경우 서비스에 연결됨에 따라 활성 상태가 유지됩니다. 제거된/미사용 커넥터는 비활성으로 태그가 지정되고 비활성 상태가 된 지 10일 후에 포털에서 제거됩니다. Azure Portal에서 비활성 커넥터를 수동으로 제거할 수 있는 방법은 없습니다.

이러한 접미사는 접미사 목록에 표시되지만 사용해서는 안 됩니다. 이러한 도메인 접미사는 Azure AD 애플리케이션 프록시와 함께 사용하기 위한 것이 아닙니다. 이러한 도메인 접미사를 사용하는 경우 생성된 Azure AD 애플리케이션 프록시 애플리케이션이 작동하지 않습니다. 표준 도메인 접미사 msappproxy.net 또는 사용자 지정 도메인을 사용할 수 있습니다.

SSL 인증서를 업로드한 후에는 Portal에서 "잘못된 인증서, 잘못된 암호" 라는 메시지가 표시됩니다.

이 오류를 해결하기 위한 몇 가지 팁은 다음과 같습니다.

• 인증서의 문제를 확인합니다. 로컬 컴퓨터에 설치합니다. 문제가 발생하지 않으면 인증서에 문제가 없는 것입니다.
• 암호에 특수 문자가 포함되어 있지 않은지 확인합니다. 테스트를 위해 암호는 문자 0-9, A-Z 및 a-z만 포함해야 합니다.
• Microsoft 소프트웨어 키 스토리지 공급자를 사용하여 인증서를 만든 경우 RSA 알고리즘을 사용해야 합니다.

기본 길이는 85초입니다. "장기" 설정은 180초입니다. 시간 제한은 연장할 수 없습니다.

아니요. 현재는 지원되지 않습니다.

CWAP_AuthSecret라고도 하는 클라이언트 암호는 Azure AD 애플리케이션 프록시 앱을 만들 때 애플리케이션 개체에 자동으로 추가됩니다(앱 등록).

클라이언트 암호는 1년 동안 유효합니다. 현재 유효한 클라이언트 암호가 만료되기 전에 1년 기간의 새 클라이언트 암호가 자동으로 생성됩니다. 3개의 CWAP_AuthSecret 클라이언트 암호가 항상 애플리케이션 개체에 유지됩니다.

애플리케이션 등록 페이지에서 홈페이지 URL을 방문 페이지의 원하는 외부 URL로 변경할 수 있습니다. 애플리케이션이 내 앱 또는 Office 365 포털에서 시작되면 지정된 페이지가 로드됩니다. 구성 단계에 대해서는 Azure AD 애플리케이션 프록시를 사용하여 게시된 앱에 대해 사용자 지정 홈페이지 설정을 참조하세요.

Azure AD 사전 인증이 구성되어 있고 애플리케이션 URL에서 처음으로 애플리케이션에 액세스하려고 할 때 "#" 문자가 포함된 경우 인증을 위해 Azure AD(login.microsoftonline.com)로 리디렉션됩니다. 인증을 완료하면 "#" 문자 앞에 URL 부분으로 리디렉션되고 "#" 뒤에 오는 모든 항목이 무시/제거된 것으로 보입니다. 예를 들어 URL이 https://www.contoso.com/#/home/index.html인 경우 Azure AD 인증이 완료되면 사용자가 https://www.contoso.com/으로 리디렉션됩니다. 이 동작은 브라우저에서 "#" 문자를 처리하는 방식으로 인해 의도적으로 설계된 것입니다.

가능한 솔루션/대안:

• https://www.contoso.com에서 https://contoso.com/#/home/index.html로의 리디렉션을 설정합니다. 사용자는 먼저 https://www.contoso.com에 액세스해야 합니다.
• 첫 번째 액세스 시도에 사용되는 URL에는 인코딩된 형식(%23)의 "#" 문자가 포함되어야 합니다. 게시된 서버에서 이를 허용하지 않을 수 있습니다.
• 통과 사전 인증 유형을 구성합니다(권장하지 않음).

아니요, 게시된 애플리케이션에 대한 IIS 요구 사항은 없습니다. Windows Server가 아닌 서버에서 실행되는 웹 애플리케이션을 게시할 수 있습니다. 그러나 웹 서버에서 협상(Kerberos 인증)를 지원하는지 여부에 따라 비 Windows 서버에서 사전 인증을 사용하지 못할 수도 있습니다. 커넥터가 설치된 서버에는 IIS가 필요하지 않습니다.

애플리케이션 프록시는 HTTPS 응답에 HTTP Strict-Transport-Security 헤더를 자동으로 추가하지 않지만 게시된 애플리케이션에서 보낸 원래 응답에 이 헤더가 있으면 유지됩니다. 이 기능을 사용하도록 설정하는 방식은 로드맵에 나와 있습니다.

아니요, 프로토콜 http가 외부 URL에 구성된 경우 Azure AD 애플리케이션 프록시 엔드포인트는 포트 TCP 80에서 들어오는 요청을 수락하고 프로토콜 https인 경우 포트 TCP 443에서 들어오는 요청을 수락합니다.

예, http://app.contoso.local:8888/, https://app.contoso.local:8080/, https://app.contoso.local:8081/test/ 포트를 포함한 내부 URL에 대한 몇 가지 예제가 있습니다.

게시된 웹 애플리케이션에서 보낸 일부 응답에는 하드 코딩된 URL이 포함될 수 있습니다. 이 경우 클라이언트가 항상 올바른 URL을 사용하도록 링크 변환 솔루션을 사용하여 확인해야 합니다. 링크 변환 솔루션은 복잡할 수 있으며 모든 시나리오에서 작동하지 않을 수 있습니다. 링크 번역에 대한 문서화된 솔루션은 여기에서 찾을 수 있습니다.

모범 사례로 동일한 외부 및 내부 URL을 사용하는 것이 좋습니다. 두 URL의 protocol://hostname:port/path/가 동일한 경우 외부 및 내부 URL은 동일한 것으로 간주됩니다.

사용자 지정 도메인 기능을 사용하여 이 작업을 수행할 수 있습니다.

예:

동일함:

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

동일하지 않음:

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/

내부 URL에 비표준 포트(TCP 80/443 제외)가 포함된 경우 외부 URL과 내부 URL을 동일하게 만드는 것은 전혀 불가능합니다.

일부 시나리오에서는 웹앱 구성에서 변경해야 합니다.

PrincipalsAllowedToDelegateToAccount 메서드는 커넥터 서버가 웹 애플리케이션 서비스 계정과는 다른 도메인에 있을 때 사용됩니다. 리소스 기반 제한 위임을 사용해야 합니다. 커넥터 서버와 웹 애플리케이션 서비스 계정이 동일한 도메인에 있는 경우 Active Directory 사용자 및 컴퓨터를 사용하여 각 커넥터 머신 계정에 대한 위임 설정을 구성하여 대상 SPN에 위임할 수 있습니다.

커넥터 서버와 웹 애플리케이션 서비스 계정이 서로 다른 도메인에 있는 경우 리소스 기반 위임이 사용됩니다. 위임 권한은 대상 웹 서버 및 웹 애플리케이션 서비스 계정에서 구성됩니다. 이 제한된 위임 방법은 비교적 새로운 방법입니다. 이 메서드는 Windows Server 2012에 도입되었으며 리소스(웹 서비스) 소유자가 위임할 수 있는 머신 및 서비스 계정을 제어하도록 허용하여 도메인 간 위임을 지원합니다. 이 구성에 도움이 되는 UI가 없으므로 PowerShell을 사용해야 합니다. 자세한 내용은 애플리케이션 프록시를 사용하여 Kerberos 제한된 위임 이해 백서를 참조하세요.

NTLM 인증은 사전 인증 또는 Single Sign-On 방법으로 사용할 수 없습니다. NTLM 인증은 클라이언트와 게시된 웹 애플리케이션 간에 직접 협상할 수 있는 경우에만 사용할 수 있습니다. NTLM 인증을 사용하면 일반적으로 브라우저에 로그인 프롬프트가 표시됩니다.

아니요, Azure AD의 게스트 사용자가 위에서 언급한 로그온 ID에 필요한 특성을 포함하지 않기 때문에 이 작업은 가능하지 않습니다.

이 경우 "사용자 계정 이름"으로 대체됩니다. B2B 시나리오에 대한 자세한 내용은 Azure AD의 B2B 사용자에게 온-프레미스 애플리케이션에 대한 액세스 권한 부여를 참조하세요.

Azure AD에서 성공적으로 미리 인증된 사용자에 대해서만 조건부 액세스 정책이 적용됩니다. 통과 인증은 Azure AD 인증을 트리거하지 않으므로 조건부 액세스 정책을 적용할 수 없습니다. 통과 인증을 사용하는 경우 온-프레미스 서버에서 MFA 정책을 구현하거나(가능한 경우) Azure AD 애플리케이션 프록시에서 사전 인증을 사용하도록 설정해야 합니다.

아니요, 이 시나리오는 애플리케이션 프록시가 TLS 트래픽을 종료하기 때문에 지원되지 않습니다.

Azure AD 애플리케이션 프록시를 사용하여 원격 데스크톱 게시를 참조하세요.

아니요. 이 시나리오는 지원되지 않습니다.

예, 예상된 것입니다. 사전 인증 시나리오에는 타사 브라우저에서 지원되지 않는 ActiveX 컨트롤이 필요합니다.

예, 이 시나리오는 현재 퍼블릭 미리 보기로 제공됩니다. Azure AD 애플리케이션 프록시를 사용하여 원격 데스크톱 게시를 참조하세요.

예, 예상된 것입니다. 사용자의 컴퓨터가 Azure AD에 조인되어 있으면 자동으로 Azure AD에 로그인됩니다. 사용자는 RDWeb 로그인 양식에만 자격 증명을 제공하면 됩니다.

이 옵션을 사용하면 사용자가 rdp 파일을 다운로드하여 다른 RDP 클라이언트(원격 데스크톱 웹 클라이언트 외부)에서 사용할 수 있습니다. 일반적으로 Microsoft 원격 데스크톱 클라이언트와 같은 다른 RDP 클라이언트는 사전 인증을 기본적으로 처리할 수 없습니다. 이것이 작동하지 않는 이유입니다.

Azure AD 애플리케이션 프록시를 사용하여 SharePoint에 원격 액세스 사용하도록 설정을 참조하세요.

SharePoint 모바일 앱은 현재 Azure Active Directory 사전 인증을 지원하지 않습니다.

아니요. Azure AD 애플리케이션 프록시는 Azure AD에서 작동하도록 설계되었으며 AD FS 프록시 역할을 하기 위한 요구 사항을 충족하지 않습니다.

아니요, 지원되지 않습니다.

WebSocket 프로토콜(예: QlikSense 및 HTML5(원격 데스크톱 웹 클라이언트))을 사용하는 애플리케이션이 이제 지원됩니다. 알려진 제한 사항은 다음과 같습니다.

• 애플리케이션 프록시는 WebSocket 연결을 여는 동안 서버 응답에 설정된 쿠키를 삭제합니다.
• WebSocket 요청에 SSO가 적용되지 않습니다.
• WAC(Windows 관리 센터)의 기능(Eventlogs, PowerShell 및 원격 데스크톱 서비스)은 Azure AD 애플리케이션 프록시를 통해 작동하지 않습니다.

WebSocket 애플리케이션에는 고유한 게시 요구 사항이 없으며, 다른 모든 애플리케이션 프록시 애플리케이션과 동일한 방식으로 게시할 수 있습니다.

예. 링크 변환은 성능에 영향을 줍니다. 애플리케이션 프록시 서비스는 애플리케이션에서 하드 코드된 링크를 검색한 후 해당 링크를 사용자에게 제공하기 전에 게시된 해당 외부 URL로 바꿉니다.

최상의 성능을 위해 사용자 지정 도메인을 구성하여 동일한 내부 및 외부 URL을 사용하는 것이 좋습니다. 사용자 지정 도메인을 사용하는 것이 불가능한 경우에는 모바일에서 내 앱 보안 로그인 확장 또는 Microsoft Edge 브라우저를 사용하여 링크 변환 성능을 향상시킬 수 있습니다. Azure AD 애플리케이션 프록시를 사용하여 게시된 앱에 대해 하드 코드된 링크 리디렉션을 참조하세요.

이 시나리오는 직접 지원되지 않습니다. 이 시나리오에 대한 옵션은 다음과 같습니다.

1. 와일드카드를 사용하여 HTTP 및 HTTPS URL 둘 다를 별도의 애플리케이션으로 게시하되 각 애플리케이션에 서로 다른 사용자 지정 도메인을 제공합니다. 이 구성은 외부 URL이 다르기 때문에 작동합니다.

2. 와일드카드 애플리케이션을 통해 HTTPS URL을 게시합니다. 이러한 애플리케이션 프록시 PowerShell cmdlet을 사용하여 HTTP 애플리케이션을 별도로 게시합니다.

   • 애플리케이션 프록시 애플리케이션 관리
   • 애플리케이션 프록시 커넥터 관리