Exchange 2007 전송 권한 모델
적용 대상: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
마지막으로 수정된 항목: 2007-08-27
이 항목에서는 Microsoft Exchange Server 2007 전송 권한 모델에 대한 자세한 정보를 제공합니다. Microsoft Exchange Server 2007에서 전송이란 서버 간에 메시지를 전송하는 프로세스를 뜻합니다. 사서함 서버와 허브 전송 서버 간에 메시지를 전송할 때는 MAPI 프로토콜이 사용됩니다. 허브 전송 서버 간에 메시지를 주고받을 때는 SMTP(Simple Mail Transfer Protocol)가 사용됩니다. 서버 간의 각 통신 세션에 옵션 인증 단계를 지정할 수 있습니다. 연결 요청에는 권한 부여 검사가 필요할 수 있습니다.
인증은 메시지를 보낸 사람을 확인하는 프로세스입니다. 인증이 수행되지 않거나 인증 시도가 실패하면 보낸 사람의 ID는 익명으로 지정됩니다. 권한 부여는 특정 데이터, 기능 또는 서비스에 액세스하기 위해 연결 중인 사용자, 프로그램 또는 장치를 허용할 것인지 여부를 결정하는 프로세스입니다. 이 경우 요청하는 작업에 따라 엑세스 여부가 결정됩니다. 인증 프로세스에서는 ID를 확인하며 권한 부여 프로세스에서는 허용되는 액세스 수준을 결정합니다.
Exchange 2007에서는 Microsoft Exchange 전송 서비스에서 SMTP 및 MAPI 프로토콜이 제공됩니다. SMTP 또는 MAPI 프로토콜 중 하나를 사용하는 세션의 경우 Microsoft Exchange 전송 서비스에서는 Microsoft Windows 권한 부여 모델을 사용하여 세션의 사용 권한을 관리합니다. Exchange 2007의 전송 문맥에서 권한 부여는 다양한 프로토콜 동사 또는 이벤트의 수락 여부와 관련됩니다. 예를 들어, 권한 부여 과정에서는 보낸 사람이 특정 전자 메일 주소에서 메시지를 전송하도록 허용하거나 특정 메시지 크기를 허용하는 권한을 확인할 수 있습니다. MAPI 및 SMTP 프로토콜 대화 중에 Exchange 2007에서는 세션 인증을 수행할 수 있습니다. 세션이 인증되고 나면 해당 세션에서 사용할 수 있는 사용 권한 그룹이 인증으로 인해 변경될 수 있습니다. 이처럼 인증을 통해 서로 다른 사용 권한 그룹이 부여되므로, 인터넷에서 받은 익명 메시지와 Exchange 조직의 인증된 사용자가 전송한 메시지를 다른 방식으로 처리할 수 있습니다.
Edge 전송 서버 역할의 기본 전송 작업은 허브 전송 서버 역할의 기본 작업과는 다릅니다. 이와 같이 작업이 서로 다른 이유는 코드가 다르기 때문이 아니라 각 역할에 대해 기본 사용 권한 집합이 다르기 때문입니다. 동일한 Active Directory 포리스트에 속한 Exchange Server 간에는 트러스트 관계가 지정되어 있습니다. 이 트러스트 관계는 설치 중에 구성되는 기본 사용 권한을 통해 포리스트 내의 메일 흐름에 보안이 적용됨을 의미합니다.
각각의 인증된 세션은 인증 보안 주체가 속해 있는 각 그룹의 보안 식별자를 나열하는 액세스 토큰이 있습니다. 그림 1에서는 액세스 토큰에 나열되어 있는 그룹 구성원과 액세스하는 개체에 대해 해당 그룹에 할당되어 있는 사용 권한 간의 관계를 보여줍니다.
그림 1 Exchange 2007의 전송 권한 부여 구성 요소
.gif "Exchange Transport 인증 구성 요소")
인증 세션과 인증 메시지 간의 차이점
Exchange 2007 전송 모델의 주요 개념은 인증 전송 세션과 인증 메시지 간의 차이점이라고 할 수 있습니다. 메시지가 인증되었거나 익명임을 나타내는 메타데이터로 메시지에 스탬프 처리를 할 수 있습니다. 다른 서버에 대해 인증된 서버는 메시지를 보낼 수 있으며 해당 메시지가 인증되었거나 익명임을 나타내는 메타데이터로 메시지에 스탬프 처리를 할 수 있습니다. 이 메시지를 받는 서버에서는 인증 스탬프를 신뢰할 수 있는지 여부를 결정합니다. 메시지를 받는 서버에서 보낸 사람을 신뢰하는 경우에는 인증 스탬프가 변경되지 않은 상태로 유지됩니다. 그러나 메시지를 받는 서버에서 보낸 사람을 신뢰하지 않으면 메시지를 보낸 서버의 인증 스탬프를 다시 지정하여 해당 메시지가 익명임을 나타내는 메타데이터로 메시지에 대해 스탬프 처리를 다시 수행합니다. Exchange 조직에서는 인증 메시지 스탬프를 서로 신뢰하는 서버 간에 종단 간 내부 메일 흐름이 수행됩니다. 인터넷에서 메시지를 받는 Edge 전송 서버는 인터넷의 익명 서버에서 처리한 인증 스탬프를 신뢰하지 않습니다. 그러므로 Edge 전송 서버에서는 메시지가 익명임을 나타내는 메타데이터로 각 메시지를 스탬프 처리한 후에 인증된 연결을 통해 메시지를 허브 전송 서버로 보냅니다.
메시지 전송 인증 및 권한 부여 프로세스 작동 방법
Exchange 2007에서는 SMTP 세션을 인증하는 데 다음과 같은 기본 메커니즘을 사용할 수 있습니다.
MAPI 세션에서 Windows 계정 및 암호를 사용할 수 있습니다. SMTP의 AUTH 확장을 사용할 수도 있습니다. 여기에는 일반 텍스트 암호 인증, NTLM 인증 및 Kerberos 인증이 포함됩니다.
SMTP의 STARTTLS 확장을 통해 X.509 인증서를 사용할 수 있습니다. 이 시나리오에서는 서버가 TLS(전송 계층 보안) 협상의 일부로 인증서를 제공합니다. 또한 클라이언트에서도 인증서를 제공합니다(옵션).
외부 인증 메커니즘을 사용할 수 있습니다. 외부 인증에서는 실제로 보안이 적용된 네트워크 또는 IPsec 등 Exchange의 일부분이 아닌 메커니즘을 사용합니다. 이 방법은 전용 송신 커넥터 및 수신 커넥터에 대해 식별된 IP 경로에서 통신이 수행될 때 사용됩니다.
보내는 전송 서버는 메시지를 보내기 전에 받는 전송 서버에 인증할 수 있습니다. 보낸 사람이 인증되고 나면 받는 전송 서버에서는 해당 사용 권한을 해당 받는 사람에게 허용된 세션 액세스 토큰에 적용합니다.
Exchange 2007에서는 송신 커넥터 및 수신 커넥터에서 메일 흐름을 관리합니다. 이들 커넥터에는 전자 메일 보내기 및 받기와 연결된 사용 권한을 정의하는 DACL(임의 액세스 제어 목록)이 있습니다. 수신 커넥터의 사용 권한이 가장 중요합니다. 수신 커넥터의 DACL은 수신 커넥터를 통해 전송된 메시지에 대한 보낸 사람의 사용 권한을 결정합니다. 수신 커넥터에 대한 SMTP 세션이 설정되고 나면 해당 세션에 대한 익명 액세스 토큰으로 세션이 시작됩니다. 후속 인증이 성공하면 액세스 토큰이 변경됩니다. 세션이 인증되지 않으면 액세스 토큰의 사용 권한 그룹이 동일하게 유지됩니다. 인증된 세션에는 개별 계정이나 역할에 할당되는 사용 권한 및 해당 계정이 속하는 보안 그룹에 할당되는 사용 권한이 부여됩니다.
그림 2의 순서도에서는 Exchange 2007 전송 서버가 SMTP 세션에서 인증 및 권한 부여를 사용하는 방법을 보여줍니다.
그림 2 SMTP 세션 인증 및 권한 부여 프로세스
.gif "SMTP 세션 인증 처리 순서도")
인증 구성
수신 커넥터에 대해 구성되는 인증 메커니즘 집합에 따라 수신 커넥터로 메시지를 전송하는 세션에서 사용할 수 있는 인증 메커니즘이 결정됩니다. 송신 커넥터에 대해 구성되는 인증 메커니즘에 따라 송신 커넥터가 스마트 호스트를 인증하는 데 사용될 인증 메커니즘이 결정됩니다.
수신 커넥터 인증
수신 커넥터에 대해 여러 인증 메커니즘을 구성할 수 있습니다. 수신 커넥터의 경우 인증 설정에 따라 해당 서버로 메시지를 전송하는 세션을 인증하기 위해 서버가 사용할 수 있도록 하는 인증 메커니즘 집합이 결정됩니다. 메시지를 보내는 서버가 사용할 인증 메커니즘을 결정합니다.
표 1에서는 수신 커넥터에 대해 구성할 수 있는 인증 메커니즘을 보여줍니다. 수신 커넥터 인증 메커니즘을 구성하려면 Exchange 관리 콘솔의 수신 커넥터 속성에 있는 인증 탭을 사용하거나 AuthMechanism 매개 변수를 Exchange 관리 셸의 Set-ReceiveConnector cmdlet와 함께 사용합니다.
표 1 수신 커넥터 인증 메커니즘
| 인증 메커니즘 | 설명 |
|---|---|
없음 |
인증 옵션이 제공되지 않습니다. |
전송 계층 보안(TLS) |
커넥터에서 클라이언트에 대해 STARTTLS를 제공합니다. |
Windows 통합 인증 |
커넥터에서 클라이언트에 대해 AUTH와 NTLM GSSAPI를 제공합니다. GSSAPI를 통해 클라이언트에서는 NTLM 또는 Kerberos를 협상할 수 있습니다. |
기본 인증 |
커넥터에서 클라이언트에 대해 AUTH와 LOGIN을 제공합니다. 클라이언트에서 보낸 암호화되지 않은 텍스트 형식의 사용자 이름과 암호가 수신됩니다. 이 메커니즘을 사용하려면 Windows 계정에서 자격 증명의 유효성을 확인해야 합니다. |
TLS를 통한 기본 인증 |
이것은 기본 인증의 정책 한정자입니다. 커넥터에서는 클라이언트가 TLS를 협상한 후에만 AUTH와 LOGIN을 제공합니다. 또한 이 메커니즘을 사용하려면 TLS를 인증 메커니즘으로 설정해야 합니다. |
Exchange Server 인증 |
커넥터에서는 이전 버전의 Exchange Server를 실행 중인 Exchange Server에 대해 EXPS와 GSSAPI를 제공하며 Exchange 2007 Server 클라이언트에 대해서는 X-ANONYMOUSTLS를 제공합니다. |
외부 보안(예: IPsec 사용) |
이 옵션은 모든 연결을 다른 인증 서버에서 들어오는 연결로 간주합니다. |
스마트 호스트 송신 커넥터 인증
송신 커넥터의 경우에는 SmartHostAuthMechanism 설정에 따라 보내는 서버를 대상 스마트 호스트에 대해 인증하는 방법이 결정됩니다. SmartHostAuthMechanism에는 값이 하나만 있을 수 있습니다. SmartHostAuthMechanism을 구성하는 경우에는 메일을 보내려면 인증에 성공해야 합니다. 메일을 보내는 Exchange 2007 서버에서 사용하는 인증 메커니즘을 스마트 호스트에서 제공하지 않는 경우에는 서버에서 전자 메일 메시지를 보내지 않으며 세션이 종료됩니다. 메일을 보내는 Exchange 2007 서버에서 사용하는 인증 메커니즘이 제공되지만 인증이 실패하는 경우에도 서버에서는 전자 메일을 보내지 않으며 세션이 종료됩니다.
표 2에서는 송신 커넥터에 대해 구성할 수 있는 인증 메커니즘을 보여줍니다. 송신 커넥터 인증 메커니즘을 구성하려면 Exchange 관리 콘솔의 송신 커넥터 속성에 있는 네트워크 탭의 스마트 호스트 인증 구성 대화 상자를 사용하거나 SmartHostAuthMechanism 매개 변수를 Exchange 관리 셸의 Set-SendConnector cmdlet와 함께 사용합니다.
표 2 스마트 호스트 커넥터의 인증 메커니즘
| 인증 메커니즘 | 설명 |
|---|---|
없음 |
익명 액세스가 허용됩니다. |
기본 인증 |
커넥터에서는 AUTH와 LOGIN을 사용해야 합니다. 이를 위해서는 사용자 이름과 암호를 제공해야 합니다. 기본 인증은 자격 증명을 일반 텍스트로 보냅니다. 이 송신 커넥터가 인증을 받는 모든 스마트 호스트는 동일한 사용자 이름과 암호를 수락해야 합니다. RequireTLS 매개 변수도 |
기본 인증에 TLS 필요 |
이것은 기본 인증의 정책 한정자입니다. 커넥터에서 AUTH를 시도하려면 TLS를 사용해야 하며 보내는 서버에서 받는 서버에 대해 X.509 인증서 유효성 검사를 수행해야 합니다. 인증서 유효성 검사에는 AUTH를 시도하기 전에 CRL(인증서 해지 목록)을 확인하고 서버 ID를 커넥터에 대해 구성된 스마트 호스트 목록과 일치시키는 작업이 포함됩니다. 이름 일치 작업이 성공하려면 스마트 호스트 목록에 있는 FQDN(정규화된 도메인 이름) 중 하나가 서버 인증서에 있어야 합니다. 그러므로 스마트 호스트의 FQDN이 XM 레코드를 가리키는 경우 목록에 있는 스마트 호스트 FQDN이 인증서에 있어야 합니다. |
Exchange Server 인증 |
커넥터에서 이전 버전의 Exchange Server를 실행 중인 Exchange Server에 대해 EXPS와 GSSAPI를 사용하거나 Exchange 2007 Server 클라이언트에 대해 X-ANONYMOUSTLS를 사용해야 합니다. |
외부 보안(예: IPsec 사용) |
네트워크 연결은 Exchange Server 외부의 메서드를 사용하여 보안됩니다. |
전송 계층 보안
TLS 프로토콜은 RFC 2246에 설명되어 있습니다. TLS에서는 전자 형식 자격 증명인 X.509 인증서를 사용합니다. TLS는 다음과 같이 사용할 수 있습니다.
기밀 유지로만 사용
서버 인증서 유효성 검사를 수행하는 경우 기밀 유지로 서버 인증에 사용
클라이언트와 서버 인증서에 대해 모두 유효성 검사를 수행하는 경우 기밀 유지로 상호 인증에 사용
SMTP 프로토콜 대화의 경우 클라이언트에서는 SMTP STARTTLS 명령을 실행하여 해당 세션에 대해 TLS를 협상하도록 요청합니다. 클라이언트에서는 TLS 프로토콜 협상의 일부분으로 서버로부터 X.509 인증서를 받습니다. 그러면 클라이언트 인증 정책에 따라 받는 서버 인증서에 대해 유효성 검사를 수행할지 여부와 이름 일치 등의 다른 조건을 인증서에 적용할지 여부가 결정됩니다.
TLS 협상에는 받는 서버에서도 보내는 서버의 인증서를 요청할 수 있도록 하는 선택 요소가 있습니다. 보내는 서버에서 받는 서버로 인증서를 보내면 받는 서버의 로컬 정책에 따라 해당 인증서에 대해 유효성 검사를 수행하는 방법 및 인증을 통해 보내는 서버에 부여하는 사용 권한이 결정됩니다.
서버 인증에 TLS를 사용하는 경우 받는 서버 인증서에 대해서만 유효성 검사를 수행합니다. 상호 인증에 TLS를 사용하는 경우에는 보내는 서버 인증서 및 받는 서버 인증서에 대해 모두 유효성 검사를 수행해야 합니다.
Exchange 2007 수신 커넥터에 대해 TLS를 구성하는 경우 서버에는 X.509 인증서가 있어야 합니다. 이 인증서는 자체 서명한 인증서일 수도 있고 CA(인증 기관)에서 서명한 인증서일 수도 있습니다. Exchange Server에서는 커넥터의 FQDN과 일치하는 인증서를 로컬 저장소에서 찾습니다. 보내는 서버에서는 TLS 프로토콜을 사용하는 방법을 선택합니다. Exchange에서 기밀 유지로만 TLS를 사용하는 경우 Exchange 클라이언트는 인증서에 대해 유효성 검사를 수행하지 않습니다. 예를 들어, Exchange에서 TLS 프로토콜을 통해 Kerberos를 사용하는 방법으로 허브 전송 서버 간에 TLS를 사용하는 경우 해당 서버 간의 기밀 채널이 설정되며 인증서에 대해서는 유효성 검사가 수행되지 않습니다. 서버 간의 인증은 TLS 프로토콜이 완료된 후에 Kerberos를 사용하여 수행됩니다.
TLS 인증이 필요한 경우에는 Exchange에서 인증서에 대해 유효성 검사를 수행해야 합니다. Exchange에서는 직접 신뢰나 X.509 유효성 검사 중 한 가지 방법으로 인증서 유효성을 검사할 수 있습니다. Edge 전송 서버와 허브 전송 서버 간 통신에 TLS를 사용하는 경우에는 인증서 유효성 검사에 직접 신뢰 메커니즘이 사용됩니다.
직접 신뢰란 Exchange에서 Active Directory 또는 ADAM(Active Directory Application Mode) 같은 신뢰할 수 있는 저장소를 사용하는 것입니다. 직접 신뢰에서는 저장소에 있는 인증서는 유효한 것으로 간주됩니다. 직접 신뢰를 사용하는 경우 인증서가 자체 서명한 것인지 아니면 인증 기관에서 서명한 것인지는 관계가 없습니다. Exchange 조직에서 Edge 전송 서버를 구독하는 경우 해당 구독에서는 유효성을 검사할 허브 전송 서버에 대해 Active Directory에 Edge 전송 서버 인증서를 게시합니다. Microsoft Exchange Edgesync Service에서는 유효성을 검사할 Edge 전송 서버에 대해 허브 전송 서버 인증서 집합을 사용하여 ADAM을 업데이트합니다.
Exchange에서 인증서 유효성을 검사하는 데 사용하는 또 다른 방법은 X.509 인증서입니다. X.509 유효성 검사를 사용하는 경우에는 인증서가 인증 기관에서 서명한 것이어야 합니다. Exchange에서는 스마트 호스트를 인증할 때나 도메인 보안을 사용할 때 X.509 유효성 검사를 사용합니다. 도메인 보안에 대해서는 다음 섹션에서 설명합니다.
도메인 보안
도메인 보안은 비교적 저렴한 가격으로 S/MIME 또는 기타 메시지 수준 보안 솔루션을 대체할 수 있는 Exchange 2007 및 Microsoft Office Outlook 기능 집합을 의미합니다. 도메인 보안은 관리자에게 비즈니스 파트너와 함께 인터넷을 통해 보안 메시지 경로를 관리할 수 있는 방법을 제공하기 위한 것입니다. 이러한 보안 메시지 경로를 구성하고 나면 인증된 보낸 사람이 전송하여 보안 경로를 통과한 메시지는 Outlook 및 Outlook Web Access 인터페이스에 "도메인 보안됨"으로 표시됩니다.
송신 커넥터는 다음 조건이 충족되는 경우 대상 도메인이 도메인 보안에 대해 구성된 보낸 사람 도메인 목록에 있음을 확인합니다.
송신 커넥터가 DNS(Domain Name System) MX(메일 교환) 리소스 레코드를 사용하여 메시지를 라우팅하도록 구성되어 있습니다.
송신 커넥터가 도메인 보안으로 구성되어 있습니다.
대상 도메인이 목록에 있으면 전송 서버에서는 도메인으로 전자 메일을 보낼 때 상호 TLS 인증을 적용합니다.
받는 서버에서는 다음 조건이 충족되는 경우 SMTP QUIT 명령으로 응답합니다.
Exchange에서 TLS를 협상할 수 없습니다.
서버 인증서 유효성 검사 또는 CRL 유효성 검사가 실패합니다.
그런 다음 메시지는 보내는 서버의 큐에 보관됩니다. 이 큐는 다시 시도 상태입니다. 이 작업은 이름 확인이 실패하는 경우에도 발생합니다.
수신 커넥터가 도메인 보안된 경우 전송 서버에서는 수신한 메일을 검사합니다. 그러면 보낸 사람이 도메인 보안에 대해 구성된 받는 사람 도메인 목록이 있으면 전송 서버에서는 상호 TLS 인증을 적용합니다. 모든 검사에 통과하는 경우 수신 메시지는 "도메인 보안됨"으로 표시됩니다. 보낸 사람이 TLS를 협상할 수 없거나 서버 인증서 유효성 검사 또는 CRL 유효성 검사가 실패하면 전송 서버는 SMTP 프로토콜 REJECT 명령을 사용하여 메시지를 거부합니다. 이름 확인이 실패하는 경우에도 SMTP 프로토콜 REJECT 명령이 실행됩니다. 그러면 Exchange Server에서는 일시적인 SMTP 오류(4xx)가 포함된 메시지를 보내는 서버로 보냅니다. 이 메시지를 받는 경우 보내는 서버에서는 나중에 다시 시도할 수 있습니다. 이 작업은 일시적인 CRL 유효성 검사 실패에 의해 잠시 동안 발생하는 문제 때문에 보내는 사람에게 즉시 NDR이 전송되는 일이 없도록 합니다. 즉, 이 실패가 발생해도 메시지 배달이 지연될 뿐입니다.
자세한 내용은 도메인 보안 관리를 참조하십시오.
외부 보안 인증
서버 간의 네트워크 연결을 확실히 신뢰할 수 있는 경우에는 외부 보안 인증 옵션을 선택할 수 있습니다. 이 연결은 IPsec 연결이거나 가상 개인 네트워크일 수 있습니다. 또는 서버가 실제로 제어되는 신뢰된 네트워크에 상주할 수 있습니다. 다음과 같은 경우에 이 구성을 사용하면 유용합니다.
Exchange 2007 전송 서버와 이전 버전의 Exchange Server 또는 기타 SMTP 서버 간에 메일 흐름을 설정한 경우
기본 인증을 사용하지 않으려는 경우
외부 보안으로 구성된 Exchange 커넥터에서는 전용 송신 커넥터 및 수신 커넥터를 사용해야 합니다. 해당 커넥터에 대한 모든 연결은 보안된 것으로 간주되기 때문입니다. 그러므로 외부 보안으로 구성된 송신 커넥터에서는 메시지를 라우팅하는 데 스마트 호스트를 사용해야 합니다. 또한 대상 스마트 호스트의 IP 주소를 커넥터에서 구성해야 합니다. 외부 보안으로 구성된 수신 커넥터의 경우에는 RemoteIPRanges를 보내는 서버의 IP 주소 범위로 설정해야 합니다. TLS를 외부 보안 인증 옵션과 결합하여 세션 기밀을 보다 높은 수준으로 유지할 수도 있습니다. 이렇게 하려면 Exchange 관리 셸에서 커넥터의 RequireTLS 매개 변수를 $True로 설정하면 됩니다.
권한 부여
메시지 전송 중에 수행되는 권한 부여는 메일 보내기 등의 요청한 작업이 SMTP 세션에서 허용되는지 여부를 결정하는 프로세스입니다.
Exchange 2007 전송 권한
Exchange 2007 전송 서버에서는 SMTP 세션에 대해 Windows 권한 부여 모델을 사용하여 보낸 사람이 특정 커넥터와 특정 받는 사람에 대해 특정 보낸 사람 자격으로 메시지를 전송할 수 있는지 여부를 결정합니다. SMTP 세션에서는 초기 사용 권한 집합(익명)을 받습니다. 세션이 인증되고 나면 해당 세션에 대해 더 많은 사용 권한을 사용할 수 있습니다. 이로 인해 세션에 대해 권한이 부여되는 작업 집합도 변경됩니다.
Windows 권한 부여 모델에서는 액세스 토큰과 ACL(액세스 제어 목록)을 비교하는 액세스 제어 상호 작용을 통해 사용 권한이 부여됩니다. 액세스 토큰은 보안 주체 집합을 나열합니다. 보안 주체는 사용자 계정, 컴퓨터 계정 또는 보안 그룹이 될 수 있습니다. 모든 보안 주체에게는 SID(보안 식별자)가 연결되어 있습니다. 각 세션에는 액세스 토큰이 할당됩니다. ACL은 Active Directory 또는 ADAM의 커넥터 개체에서 정의됩니다. DACL에는 ACE(액세스 제어 항목) 집합이 포함되어 있습니다. 각 ACE는 보안 주체에 대해 사용 권한을 허용하거나 거부합니다. 전송 서버에서는 세션에 대해 전자 메일 전송 등의 사용 권한이 부여되는지 여부를 결정할 때 Windows 액세스 검사 API를 호출하고 세션 액세스 토큰과 커넥터의 DACL을 요청된 사용 권한과 함께 매개 변수로 제공합니다.
이 프로세스는 파일 읽기 권한을 결정하는 방법과 같습니다. 액세스 토큰, 파일 DACL 및 요청된 사용 권한이 동일한 API로 전송됩니다. API에서는 액세스 토큰의 목록에 있는 모든 보안 주체를 DACL에 있는 각 ACE와 대조하여 요청된 사용 권한을 허용할지 아니면 거부할지를 결정합니다. Active Directory, ADAM 또는 컴퓨터의 로컬 SAM(보안 계정 관리자) 데이터베이스에서 제공되는 Windows SID 외에 Exchange 2007에서는 추가 SID를 정의합니다. 이러한 SID는 논리 그룹을 나타냅니다. 표 3에서는 전송 인증 과정에서 사용하기 위해 Exchange 2007에서 정의하는 SID를 보여줍니다.
표 3 Exchange 2007 SID
| 표시 이름 | SID | 논리 그룹 |
|---|---|---|
파트너 서버 |
S-1-9-1419165041-1139599005-3936102811-1022490595-10 |
도메인 보안에 대해 구성된 보낸 사람 및 받는 사람 도메인 |
허브 전송 서버 |
S-1-9-1419165041-1139599005-3936102811-1022490595-21 |
동일한 Exchange 조직의 허브 전송 서버 |
Edge 전송 서버 |
S-1-9-1419165041-1139599005-3936102811-1022490595-22 |
트러스트된 Edge 전송 서버 |
외부 보안 서버 |
S-1-9-1419165041-1139599005-3936102811-1022490595-23 |
동일한 신뢰할 수 있는 도메인에 있는 트러스트된 타사 서버 |
레거시 Exchange Server |
S-1-9-1419165041-1139599005-3936102811-1022490595-24 |
동일한 Exchange 조직에 있는 Exchange Server 2003 서버 |
수신 커넥터 사용 권한
수신 커넥터에서는 서버로 들어오는 세션을 처리합니다. 이 세션은 인증된 보낸 사람이나 익명 보낸 사람이 설정할 수 있습니다. 세션이 인증되면 세션 액세스 토큰의 SID가 업데이트됩니다. 표 4에서는 수신 커넥터에 연결되는 세션에 부여할 수 있는 사용 권한을 보여줍니다.
표 4 수신 커넥터 사용 권한
| 사용 권한 | 표시 이름 | 설명 |
|---|---|---|
ms-Exch-SMTP-Submit |
서버로 메시지 전송 |
세션에 이 사용 권한이 부여되지 않으면 해당 수신 커넥터로 메시지를 전송할 수 없습니다. 세션에 이 사용 권한이 없으면 MAIL FROM 명령이 실패합니다. |
ms-Exch-SMTP-Accept-Any-Recipient |
모든 받는 사람에게 메시지 전송 |
이 사용 권한은 세션에서 해당 커넥터를 통해 메시지를 릴레이할 수 있도록 허용합니다. 이 사용 권한이 부여되지 않으면 허용되는 도메인의 받는 사람에게 보내는 메시지만이 해당 커넥터에서 허용됩니다. |
ms-Exch-SMTP-Accept-Any-Sender |
모든 보낸 사람 허용 |
이 사용 권한은 세션에서 보낸 사람 주소 스푸핑 검사를 건너뛸 수 있도록 허용합니다. |
ms-Exch-SMTP-Accept-Authoritative-Domain-Sender |
신뢰할 수 있는 도메인 보낸 사람 허용 |
이 사용 권한은 세션에서 신뢰할 수 있는 도메인의 전자 메일 주소에서 보낸 인바운드 메시지를 차단하는 검사를 건너뛸 수 있도록 허용합니다. |
ms-Exch-SMTP-Accept-Authentication-Flag |
인증 플래그 허용 |
이 사용 권한이 있는 경우 이전 버전의 Exchange Server를 실행 중인 Exchange Server에서 내부 보낸 사람의 메시지를 전송할 수 있습니다. Exchange 2007 서버에서는 해당 메시지를 내부 메시지로 인식합니다. |
ms-Exch-Accept-Headers-Routing |
라우팅 헤더 허용 |
이 사용 권한은 세션에서 모든 수신 헤더가 변경되지 않은 상태인 메시지를 전송할 수 있도록 허용합니다. 이 사용 권한이 부여되지 않으면 서버에서 수신한 헤더를 모두 제거합니다. |
ms-Exch-Accept-Headers-Organization |
조직 헤더 허용 |
이 사용 권한은 세션에서 모든 조직 헤더가 변경되지 않은 상태인 메시지를 전송할 수 있도록 허용합니다. 조직 헤더는 모두 "X-MS-Exchange-Organization-"으로 시작됩니다. 이 사용 권한이 부여되지 않으면 받는 서버에서 모든 조직 헤더를 제거합니다. |
ms-Exch-Accept-Headers-Forest |
포리스트 헤더 허용 |
이 사용 권한은 세션에서 모든 포리스트 헤더가 변경되지 않은 상태인 메시지를 전송할 수 있도록 허용합니다. 포리스트 헤더는 모두 "X-MS-Exchange-Forest-"로 시작됩니다. 이 사용 권한이 부여되지 않으면 받는 서버에서 모든 포리스트 헤더를 제거합니다. |
ms-Exch-Accept-Exch50 |
Exch50 허용 |
이 사용 권한은 세션에서 XEXCH50 명령이 포함된 메시지를 전송할 수 있도록 허용합니다. XEXCH50 명령은 Exchange 2000 Server 및 Exchange 2003과의 상호 운용에 필요하며, 메시지에 대해 SCL(스팸 지수) 등의 데이터를 제공합니다. |
ms-Exch-Bypass-Message-Size-Limit |
메시지 크기 제한 무시 |
이 사용 권한은 세션에서 커넥터에 대해 구성된 메시지 크기 제한을 초과하는 메시지를 전송할 수 있도록 허용합니다. |
Ms-Exch-Bypass-Anti-Spam |
스팸 방지 무시 |
이 사용 권한은 세션에서 스팸 방지 필터를 무시할 수 있도록 허용합니다. |
송신 커넥터 사용 권한
송신 커넥터에서는 다른 서버로 나가는 세션을 처리합니다. 이 세션은 인증된 받는 사람이나 익명 받는 사람에 대해 보낸 사람이 설정할 수 있습니다. 세션이 인증되면 세션 액세스 토큰의 SID 집합이 업데이트됩니다. 송신 커넥터 사용 권한에 따라 해당 커넥터를 사용하여 보내는 메시지에 포함할 수 있는 헤더 정보 유형이 결정됩니다. 조직의 다른 Exchange Server 또는 포리스트 간 시나리오의 트러스트된 Exchange 조직으로 보내는 메시지의 경우에는 보통 모든 헤더를 보낼 수 있습니다. 그러나 인터넷 또는 Exchange가 아닌 SMTP 서버로 보내는 메시지의 경우에는 모든 헤더를 포함할 수 없습니다. 메시지에 포함된 헤더는 Exchange 2007의 헤더 방화벽 기능에 의해 삭제됩니다. 표 5에서는 송신 커넥터에 연결되는 세션에 부여할 수 있는 사용 권한을 보여줍니다.
표 5 송신 커넥터 사용 권한
| 사용 권한 | 표시 이름 | 설명 |
|---|---|---|
ms-Exch-Send-Exch50 |
Exch50 보내기 |
이 사용 권한은 세션에서 XEXCH50 명령이 포함된 메시지를 보낼 수 있도록 허용합니다. 이 사용 권한이 부여되지 않으면 서버에서 보내는 메시지에는 EXCH50 명령이 포함되지 않습니다. |
Ms-Exch-Send-Headers-Routing |
라우팅 헤더 보내기 |
이 사용 권한은 세션에서 받은 모든 헤더가 그대로 포함된 메시지를 보낼 수 있도록 허용합니다. 이 사용 권한이 부여되지 않으면 서버에서 수신한 헤더를 모두 제거합니다. |
Ms-Exch-Send-Headers-Organization |
조직 헤더 보내기 |
이 사용 권한은 세션에서 모든 조직 헤더가 그대로 포함된 메시지를 보낼 수 있도록 허용합니다. 조직 헤더는 모두 "X-MS-Exchange-Organization-"으로 시작됩니다. 이 사용 권한이 부여되지 않으면 보내는 서버에서 모든 조직 헤더를 제거합니다. |
Ms-Exch-Send-Headers-Forest |
포리스트 헤더 보내기 |
이 사용 권한은 세션에서 모든 포리스트 헤더가 그대로 포함된 메시지를 보낼 수 있도록 허용합니다. 포리스트 헤더는 모두 "X-MS-Exchange-Forest-"로 시작됩니다. 이 사용 권한이 부여되지 않으면 보내는 서버에서 모든 포리스트 헤더를 제거합니다. |
사용 권한 그룹
사용 권한 그룹은 수신 커넥터에 대해 부여할 수 있는 미리 정의된 사용 권한 집합이며 수신 커넥터에서만 사용할 수 있습니다. 사용 권한 그룹을 사용하면 수신 커넥터에서 사용 권한 구성 작업을 간단하게 수행할 수 있습니다. PermissionGroups 속성은 수신 커넥터로 메시지를 전송할 수 있는 그룹 및 역할과 해당 그룹에 대해 허용되는 사용 권한을 정의합니다. 사용 권한 그룹 집합은 Exchange 2007에 미리 정의되어 있으므로 추가로 만들 수는 없습니다. 또한 사용 권한 그룹 구성원이나 연결된 사용 권한을 수정할 수도 없습니다.
표 6에서는 Exchange 2007에서 사용할 수 있는 사용 권한 그룹, 사용 권한 그룹 구성원 및 연결된 사용 권한을 보여줍니다.
표 6 수신 커넥터 사용 권한 그룹 및 연결된 사용 권한
| 사용 권한 그룹 이름 | 보안 주체 | Edge 전송 서버에 부여되는 사용 권한 | 허브 전송 서버에 부여되는 사용 권한 |
|---|---|---|---|
익명 |
익명 사용자 |
|
|
ExchangeUsers |
인증된 사용자(잘 알려진 계정은 제외) |
사용할 수 없음 |
|
Exchange Server |
Exchange 2007 server |
모든 받기 권한 |
|
ExchangeLegacyServers |
Exchange 2003 및 Exchange 2000 server |
사용할 수 없음 |
|
파트너 |
파트너 서버 계정 |
|
|
커넥터 사용 유형
새 커넥터를 만들 때 해당 커넥터의 사용 유형을 지정할 수 있습니다. 사용 유형에 따라 커넥터의 기본 설정이 결정됩니다. 기본 설정에는 인증되는 SID, 해당 SID에 할당되는 사용 권한 및 인증 메커니즘이 포함됩니다.
표 7에서는 수신 커넥터에 대해 사용할 수 있는 사용 유형을 보여줍니다. 수신 커넥터에 대해 사용 유형을 선택하면 사용 권한 그룹이 커넥터에 자동으로 할당됩니다. 또한 기본 인증 메커니즘도 구성됩니다.
표 7 수신 커넥터 사용 유형
| 사용 유형 | 기본 사용 권한 그룹 | 기본 인증 메커니즘 |
|---|---|---|
클라이언트 |
ExchangeUsers |
|
사용자 지정 |
없음 |
없음 |
내부 |
|
Exchange Server 인증 |
인터넷 |
AnonymousUsers 파트너 |
없음 또는 외부 보안 |
파트너 |
파트너 |
해당 없음. 원격 도메인으로 상호 TLS 인증을 설정하면 이 사용 유형이 선택됩니다. |
표 8에서는 송신 커넥터에 대해 사용할 수 있는 사용 유형을 보여줍니다. 송신 커넥터에 대해 사용 유형을 선택하면 사용 권한이 SID에 자동으로 할당됩니다. 또한 기본 인증 메커니즘도 구성됩니다.
표 8 송신 커넥터 사용 유형
| 사용 유형 | 기본 사용 권한 | 보안 주체 | 스마트 호스트의 기본 인증 메커니즘 |
|---|---|---|---|
사용자 지정 |
없음 |
없음 |
없음 |
내부 |
|
|
Exchange Server 인증 |
인터넷 |
라우팅 헤더 보내기 |
익명 사용자 계정 |
없음 |
파트너 |
라우팅 헤더 보내기 |
파트너 서버 |
해당 없음. 원격 도메인으로 상호 TLS 인증을 설정하면 이 사용 유형이 선택됩니다. |
송신 커넥터 또는 수신 커넥터에 대해 사용자 지정 사용 유형을 선택하는 경우에는 인증 방법 및 인증된 SID를 수동으로 구성해야 하며 해당 SID에 대해 사용 권한을 할당해야 합니다. 커넥터 사용 유형을 지정하지 않으면 자동으로 사용자 지정으로 설정됩니다.
Enable-CrossForestConnector 스크립트를 사용하여 사용 권한 설정
Enable-CrossForestConnector.ps1 스크립트를 사용하면 포리스트 간 커넥터에 대해 사용 권한을 간편하게 구성할 수 있습니다. 이 스크립트는 사용 권한 그룹과 비슷한 방식으로 사용 권한을 할당합니다. 즉, 정의된 사용 권한 집합이 송신 커넥터 또는 수신 커넥터에 할당됩니다. Enable-CrossForestConnector.ps1 스크립트의 내용을 수정하여 사용할 연결 시나리오에 필요한 대로 이 사용 권한 집합을 수정할 수 있습니다. 자세한 내용은 포리스트 간 커넥터 구성을 참조하십시오.
Add-AdPermission cmdlet를 사용하여 사용 권한 설정
Exchange 관리 셸의 Add-AdPermission cmdlet는 Active Directory에 저장된 개체에 대해 사용 권한을 할당하는 데 사용되는 글로벌 cmdlet입니다. Add-AdPermission cmdlet를 사용하여 송신 커넥터 또는 수신 커넥터에 대해 개별 사용 권한을 부여할 수 있습니다. 일반적으로 Add-AdPermission cmdlet는 전송 권한 관리에는 사용되지 않지만 다음과 같은 시나리오에서는 사용 권한을 구성하는 데 사용해야 합니다.
포리스트 간 시나리오에서 메일 흐름을 설정하는 경우
신뢰할 수 있는 도메인의 보낸 사람이 인터넷으로 보낸 익명 전자 메일을 허용하려는 경우
Exchange 2007 전송 권한은 이 cmdlet를 사용하여 할당할 수 있는 확장된 권한 집합의 일부분입니다. 다음 절차에서는 Add-AdPermission cmdlet를 사용하여 허브 전송 서버 수신 커넥터에 대해 사용 권한을 설정함으로써 익명 세션에서 메시지를 전송할 수 있도록 하는 방법을 보여줍니다.
Exchange 관리 셸을 사용하여 수신 커넥터에 대해 사용 권한을 설정하는 방법
다음 명령을 실행합니다.
Add-AdPermission -Identity "Default Hub1" -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights ms-Exch-SMTP-Submit,ms-Exch-SMTP-Accept-Any-Recipient,ms-Exch-Bypass-Anti-Spam
Get-AdPermission cmdlet를 사용하여 송신 커넥터 또는 수신 커넥터의 DACL을 볼 수 있습니다. 수신 커넥터에 할당된 사용 권한을 검색하여 해당 결과를 형식이 지정된 표에 표시하려면 다음 명령 중 하나를 실행합니다.
Exchange 관리 셸을 사용하여 수신 커넥터에 대한 확장된 사용 권한을 보는 방법
다음 명령 중 하나를 실행합니다.
Get-AdPermission -Identity "Default ServerName" | format-table -view User Get-AdPermission -Identity "Default ServerName" | format-table -view Identity
Remove-AdPermission cmdlet를 사용하여 이전에 할당한 사용 권한을 제거할 수 있습니다.
Exchange 관리 셸을 사용하여 사용 권한을 보고 설정하고 제거하는 방법에 대한 자세한 내용은 다음 항목을 참조하십시오.
ADSI Edit을 사용하여 사용 권한 설정
ADSI(Active Directory Service Interfaces) Edit은 Windows 지원 도구에서 제공되는 Microsoft Management Console입니다. ADSI Edit은 다른 관리 인터페이스에 표시되지 않는 Active Directory 또는 ADAM 개체의 속성을 수정하는 저급 편집기로 사용됩니다. ADSI Edit은 숙련된 관리자만 사용해야 합니다.
ADSI Edit을 사용하면 송신 커넥터 및 수신 커넥터의 ACL을 보고 수정할 수 있습니다. ADSI Edit을 연 후에는 커넥터 개체를 찾습니다. Exchange 2007 커넥터는 디렉터리 서비스의 구성 파티션에 저장되어 있습니다. 송신 커넥터는 연결 컨테이너의 개체로 저장되어 있으며 수신 커넥터는 Exchange 2007 전송 서버의 하위 개체로 저장되어 있습니다.
ADSI Edit을 사용하여 수신 커넥터 사용 권한을 수정하려면 다음을 수행합니다.
다음 위치로 이동하여 수신 커넥터를 찾습니다.
CN=Configuration\CN=Services\CN=Microsoft Exchange\CN=<Organization>\CN=Administrative Groups\CN=Exchange Administrative Group (FYDIBOHF23SPDLT)\CN=Servers\CN=<Server Name>\CN=Protocols\CN=SMTP Receive Connectors
결과 창에서 수신 커넥터를 선택합니다. 마우스 오른쪽 단추를 클릭한 다음 속성을 클릭합니다.
보안 탭을 클릭합니다. 다음 화면이 표시됩니다.
.gif "ADSI 편집의 수신 커넥터 보안 탭")
추가를 클릭하여 사용 권한을 부여할 사용자 또는 그룹을 선택하거나 기존 그룹 또는 사용자 이름 항목을 선택합니다.
계정에 할당할 사용 권한을 선택하고 허용 열의 확인란을 선택합니다.
ADSI Edit을 사용하여 송신 커넥터 사용 권한을 수정하려면 다음을 수행합니다.
다음 위치로 이동하여 송신 커넥터를 찾습니다.
CN=Configuration\CN=Services\CN=Microsoft Exchange\CN=<Organization>\CN=Administrative Groups\CN=Exchange Administrative Group(FYDIBOHF23SPDLT)\CN=Routing Groups\CN=Routing Group (DWBGZMFD01QNBJR)\CN=Connections
결과 창에서 송신 커넥터를 선택합니다. 마우스 오른쪽 단추를 클릭한 다음 속성을 클릭합니다.
보안 탭을 클릭합니다. 다음 화면이 표시됩니다.
.gif "ADSI 편집의 송신 커넥터 보안 탭")
추가를 클릭하여 사용 권한을 부여할 사용자 또는 그룹을 선택하거나 기존 그룹 또는 사용자 이름 항목을 선택합니다.
계정에 할당할 사용 권한을 선택하고 허용 열의 확인란을 선택합니다.
사용 권한 문제 해결
프로토콜 대화 중에 사용 권한이 부족하여 SMTP 서버에서 특정 명령을 거부할 수 있습니다. 표 9에서는 일반적인 프로토콜 거부 메시지 및 오류의 원인이 되는 사용 권한 구성을 보여줍니다.
표 9 일반적인 프로토콜 거부 메시지 및 해당 원인
| SMTP 서버 응답 | 원인 |
|---|---|
530 5.7.1 클라이언트가 인증되지 않았습니다. |
SMTP 프로토콜의 MAIL FROM 필드에 지정된 보낸 사람에게 해당 서버로 전송할 수 있는 사용 권한이 없습니다. ms-Exch-SMTP-Submit 권한을 보낸 사람에게 부여해야 합니다. |
535 5.7.3 인증하지 못했습니다. |
SMTP 프로토콜 대화의 AUTH 단계 중에 제공된 자격 증명이 잘못되었거나 인증된 사용자에게 해당 서버로 전송할 수 있는 사용 권한이 없습니다. |
550 5.7.1 클라이언트에 해당 서버로 전송할 수 있는 사용 권한이 없습니다. |
SMTP 프로토콜 대화의 MAIL FROM 필드에 지정된 보낸 사람이 인증되었지만 해당 서버로 전송할 수 있는 사용 권한이 없습니다. |
550 5.7.1 클라이언트에 해당 보낸 사람으로 보낼 수 있는 사용 권한이 없습니다. |
SMTP 프로토콜 대화의 MAIL FROM 필드에 지정된 보낸 사람이 신뢰할 수 있는 도메인에 속한 주소입니다. 그러나 세션에 ms-Exch-SMTP-Accept-Authoritative-Domain-Sender 사용 권한이 없습니다. Exchange 조직이 신뢰할 수 있는 보낸 사람 주소로부터 메시지를 인터넷에서 Edge 전송 서버로 전송한 경우 이러한 현상이 발생할 수 있습니다. |
550 5.7.1 클라이언트에 보낸 사람 주소를 대신해 보낼 수 있는 사용 권한이 없습니다. |
인증된 사용자에게 메시지 헤더에 지정된 보낸 사람을 대신하여 메시지를 전송할 수 있는 사용 권한이 없습니다. 또한 세션에 ms-Exch-SMTP-Accept-Any-Sender 사용 권한이 없습니다. |
550 5.7.1. 릴레이할 수 없습니다. |
메시지를 보내는 받는 사람 도메인이 해당 조직에 대해 정의된 허용되는 도메인 내에 포함되어 있지 않습니다. 또한 세션에 ms-Exch-SMTP-Accept-Any-Recipient 사용 권한이 없습니다. |
자세한 내용
자세한 내용은 다음 항목을 참조하십시오.