Microsoft Office 365

Office 365를 Okta에 연동하기 위한 초간단 설명서

Okta 공식문서

1. Microsoft Azure AD and Office 365 app integration guide

2. Get started with Office 365 provisioning and deprovisioning

주요 사항

1. 필요 Microsoft Office 365 라이선스:

   • Microsoft 365 Personal/Family를 제외한 모든 기업/교육용 라이선스인 경우, "Entra ID"에서 WS-Federation을 기본(Free)으로 제공하기에 Okta와 SSO 구성에 있어 라이선스 제한 사항은 없습니다.

2. Okta 구성을 위한 별도 계정 필요

   • "[email protected]" 형태에 전역 관리자 (Global Administrator) 권한이 부여된 계정 필요

   • Okta와 구성 단계에서 특정 직원의 관리자 계정을 통한 인증은 권장 드리지 않습니다. 이는, 직원의 퇴사 및 계정 정지로 인해 API 및 토큰 갱신 이슈에 영향을 주며, 이로 인해 프로비저닝 오류가 발생합니다.

3. 별도 커스텀 도메인 필요

   • Okta와 구성 시 Office 365에 "테넌트 도메인(onmicrosoft.com)"은 페더레이션이 불가합니다.

   • 이는, '비상구(Break Glass)' 개념으로 외부 IDP에 이슈가 발생되면, 외부 IDP 의존성을 무시하고 관리자가 직접 Microsoft에 연결하여 관리(Managed)하기 위한 Microsoft 관리/운영 방안이기 때문입니다.

   • 그래서 Office 365에 "테넌트 도메인(onmicrosoft.com)"만 존재한다면 별도 커스텀 도메인이 필요합니다. (도메인 추가 가이드)

주의 사항

1. Okta PoC / Trial 을 통한 Office 365 검증

   • 현재 내부에서 정상적으로 운영 중인 Office 365를 통해 Okta와 Office 365 구성 및 테스트는 권장 드리지 않습니다. 별도 Office 365의 테스트 테넌트 환경을 구현하고 Okta와 구성 및 검증하시길 권장 드립니다.

2. 사용자 로그인 경험 변경에 따른 공지 및 교육

   • Okta를 통한 IDP 인증 구성을 전환(Managed → Federated)하는 순간 구성한 도메인의 모든 사용자는 Okta를 통한 인증으로 전환됩니다. 이에 따라 Okta 구성 작업 간에 로그인 이슈가 발생함을 사전에 공지하고, IDP 인증으로 전환되는 사용자에 대해 교육이 필요합니다.

3. 서비스 계정 (Service Accounts) 식별 및 조치

   • 프린터, SMTP 발송 등에 사용되는 서비스 계정이 커스텀 도메인(@company.com)으로 적용되어 있다면, Okta로 페더레이션 됨에 따라 서비스 계정 또한 Okta로 인증을 요청하기 때문에 서비스 계정의 로그인 이슈가 발생할 수 있습니다. 그렇기에 페더레이션 전환 전, 서비스 계정들의 UPN(@company.com)을 테넌트 도메인(@...onmicrosoft.com)으로 변경하시길 권장드립니다.

Ⅰ. Okta-Office 365 연동

1. SSO 통합 가능

WS-Federation

• WS-Federation은 SSO를 구현하기 위한 XML 기반의 표준 프로토콜이며, 보안 토큰(SAML Assertion)을 포함한 XML 을 통해 ID 정보를 전송하고 검증하여 인증을 처리합니다.

왜 SAML/OIDC의 인증 프로토콜이 아닌 WS-Federation으로 SSO 구성을 하는가?

SAML과 WS-Fedaration은 모두 같은 XML 기반의 표준 프로토콜을 사용하는 것은 같지만, Microsoft 제품군 특성상 "웹 브라우저"와 "설치형 앱" 2가지 모두의 인증을 지원하는 최적화된 WS-Fedaration을 통해 SSO를 구성합니다. (OIDC는 지원하지 않음)

---

2. 프로비저닝 기능

해당 기능은 Okta의 Lifecycle Management License가 필요합니다.

프로비저닝 기능은 2가지 방향성의 타입으로 제공되며, 양방향으로 구성 시 출동과 오류가 발생할 수 있습니다. 아래 기능 사항을 참고하시어 1가지 타입의 단방향으로 기능을 구성하시길 권장드립니다.

Okta to App (Okta → Office 365)

• Okta의 사용자를 기준으로 Office 365에 다양한 프로비저닝 유형으로 Push/동기화 하는 기능을 제공합니다.

  

아래와 같은 운영/관리 사항에 대해 프로비저닝 기능을 지원합니다.

1. 사용자 및 그룹 통합 관리: Office 365의 사용자 그룹과 해당 그룹에 속한 사용자를 Okta를 통해 중앙에서 통합 관리할 수 있습니다.

2. 계정 자동 프로비저닝(Create/Update/Deactivate): Okta에서 Office 365 애플리케이션에 사용자를 할당(Assign)하면, Office 365에도 계정이 자동으로 생성되며, 이후 정보 업데이트 및 비활성화(사용 안 함) 상태가 자동으로 적용됩니다.

3. 프로필 정보 동기화(Attribute Sync): Okta에서 사용자의 프로필 정보(이름, 전화번호, 부서 등)가 변경되면, 해당 변경 사항이 Office 365 사용자 정보에도 자동으로 동기화(Sync)됩니다.

4. 계정 비활성화 및 권한 회수: Okta에서 사용자를 비활성화(Deactive)하거나 앱 할당을 해제하면, 즉시 Office 365 계정이 Okta에서 설정한 Deactivation 옵션(로그인 차단/라이선스 회수/사용자 삭제/유예 기간)에 의해, Office 365에 동기화 됩니다. (로그인 차단 : 계정은 즉시 비활성화되며, 기존 로그인한 사용자의 세션은 유지되고 세션 만료 이후 접속이 불가합니다.)

5. 비밀번호 관리(Password Sync): Okta의 비밀번호를 Office 365와 동일하게 동기화(Sync)하거나, 보안을 위해 Okta에서 Office 365용 비밀번호를 랜덤하게 생성하여 관리할 수 있습니다.

App to Okta (Office 365 → Okta)

• 사용자의 프로필 원본(Profile Master)은 Office 365에서 관리 주체로 운영하며, Office 365에 사용자를 Okta로 Import하여 Okta의 다른 기능을 활용하기 위해 지원하는 기능입니다.

  

아래와 같은 운영/관리 사항에 대해 프로비저닝 기능을 지원합니다.

1. Office 365의 사용자 및 그룹 가져오기(Import): Office 365에 존재하는 사용자 계정과 그룹 정보를 Okta로 가져와서 Okta 내의 사용자로 생성하거나 매칭할 수 있습니다. (Import한 그룹은 Okta에서 Edit/Delete 불가, Import Groups 옵션을 통해 Okta에 Office 그룹을 제거 할 수 있습니다.)

2. 프로필 동기화(Update User Attributes): Office 365에서 사용자의 속성(이름, 부서, 직함 등)이 변경되면, 해당 변경 사항이 Okta의 사용자 프로필에도 자동으로 동기화(Sync)됩니다.

3. 사용자 매칭(User Matching): Office 365에서 가져온 사용자가 이미 Okta에 존재하는 경우, 이메일 등의 기준을 통해 기존 계정과 자동으로 연결(Link)하여 중복 생성을 방지합니다.

4. Office 365 그룹 연동: Office 365의 보안 그룹(Security Group)이나 배포 그룹(Distribution Group) 등을 Okta로 가져와, Okta 내의 그룹 정책이나 할당(Assign)에 활용할 수 있습니다.

5. Profile Master 설정: 필요한 경우 Office 365를 'Profile Master'로 설정하여, 사용자 정보의 수정 권한을 Office 365에만 부여하고 Okta에서는 수정을 제한할 수 있습니다.

구분	Okta to App	App to Okta
"주체/객체"의 방향성	Okta (주체) ➔ Office 365 (객체)	Office 365 (주체) ➔ Okta (객체)
관리/운영 목적	Okta 계정을 기반으로 O365 계정 자동 생성 및 관리	기존 O365 계정을 Okta로 가져오거나, O365 변경사항을 Okta에 반영
주요 기능	Okta를 통한 계정 생성(Create), 수정(Update), 비활성화(Deactivate)	가져오기(Import), 매칭(Matching), 프로필 마스터링
비밀번호 (참고사항)	Okta가 Office 365의 패스워드를 관리하는 주체	Office 365의 패스워드를 Okta가 수집하여 적용할 수 없음

---

Ⅱ. Okta-Office 365 연동 구성

1. Office 365 SSO 구성

1.1 [Office 365] 보안 기본값 설정

SSO를 구성하면 Okta(IDP)를 통한 보안 인증 주체가 변경되기에 Microsoft Entra ID에서 제공하는 "보안 기본값(Security Defaults)" 정책을 비활성화로 변경해주시기를 권장드립니다. "보안 기본값(Security Defaults)" 정책을 활성화로 유지하면, Okta와 Microsoft가 개별로 사용자에게 불필요한 보안 인증을 반복적으로 요구할 수 있어 혼란과 불편 사항이 증가합니다.

경로: portal.azure.com ➡ Microsoft Entra ID ➡ 관리 ➡ 속성 ➡ 보안 기본값 관리 ➡ 비활성화(권장하지 않음) ➡ 저장

1.2 [Office 365] 도메인 확인

• Microsoft Office 365에는 여러 도메인 중 하나를 반드시 기본(Default) 도메인으로 설정해야 합니다. (새 사용자를 만들 때 기본적으로 선택되는 도메인입니다.) 해당 기본(Default) 도메인은 페더레이션(SSO 연동) 대상으로 설정할 수 없습니다. 이는 신규 사용자 및 서비스 계정에 대한 치명적인 문제가 발생할 수 있는 부분을 방지하기 위한 안전 장치입니다.

• Custom 도메인을 페더레이션 하는 부분은 "1.4 [Okta] Office 365 앱 추가 및 설정"에서 설정합니다.

경로: portal.azure.com ➡ Microsoft Entra ID ➡ 관리 ➡ 사용자 지정 도메인 이름

• Okta와 SSO 구성을 하고자 하는 도메인은 기본(Default) 도메인으로 적용되어 있으면 안됩니다. (Okta와 구성한 이후 다시 기본(Default) 도메인으로 변경 불가)

1.3 [Office 365] Office 365 계정 생성

• Okta에 연동시킬 Office 365 계정을 생성하고 해당 계정은 반드시 전역 관리자의 역할을 부여해야 합니다.

• Federation 도메인이 아닌 "onmicrosoft.com" 도메인의 계정으로 생성해야 합니다.

• Ws-Federation 및 Provisioning 시에 기재해야 하는 Admin ID, PW에 해당 계정 ID, PW를 넣어줍니다.

1.4 [Okta] Office 365 앱 추가 및 설정

경로: Application ➡ Application ➡ Browse App Catalog

"Microsoft Office 365" 검색 후 앱 선택

"Add Integration" 선택

Microsoft Tenant Name 확인 방법 모르겠어요.

• 경로 : Microsoft 365 관리 센터(https://admin.cloud.microsoft) 연결 → "모두 표시" 선택 → "설정" → "도메인" 선택 후 ".onmicrosoft.com" 도메인 앞에 이름으로 테넌트 이름입니다.

Office 365에서 지원하는 서비스 리스트이며, Office 365 앱에 사용자를 할당하면 선택된 서비스 항목이 사용자 대시보드에서 제공됩니다.

옵션 선택 후 "Next" 선택

1. Seats (optional):

   • Office 365 라이선스의 초과 사용을 제한하기 위해 Okta를 통해 Assign 사용자의 수로 제한하는 기능입니다.

2. Application visibility:

   • Okta 사용자 대시보드에서 Office 365의 서비스 앱이 노출되지 않도록 설정하는 기능입니다.

3. Browser plugin auto-submit:

   • Okta 브라우저 플러그인을 통해 Office 365 앱 연결을 지원하는 기능입니다.

"Sign-On Options" 항목에서 "WS-Federation" 선택

"WS-Federation"은 2가지의 구성 방식을 지원합니다.

• 자동(Automatic) 방식은 Okta가 API(Graph API)를 통해 하나의 Office 365 앱에서 여러 도메인을 통합하여 구성할 수 있습니다. (Okta 사용자 도메인을 자동으로 매핑)

• 수동(Manual using PowerShell)의 경우, Office 365 앱에 1개의 도메인만 구성이 가능합니다. (Office 365 앱에 고유값으로 특정 도메인만 1:1로 매핑되어 구성됨)

1. Automatic(recommend)

관리자가 구성 시 인증한 Microsoft 계정의 권한을 위임 받아 API(Graph API)를 통해 자동으로 페더레이션 구성을 지원합니다.

• Okta 공식 문서 : Configure SSO using WS-Federation - automatic method

  1. "Automatic (recommended)" → "Authenticate with Microsoft Account"을 선택합니다.

     

  2. 전역 관리자(Global administrator) 권한의 Microsoft 계정을 입력 합니다.

     

  3. 암호를 통해 인증 진행합니다.

     

  4. "수락"을 선택하여 Okta에 Graph API 권한을 부여 합니다.

     

  5. 정상적으로 인증이 완료되면, "WS-Federation has been completed." 메세지가 확인됩니다. "Fetch and Select"를 통해 Office 365 앱에 인증할 도메인 대상을 선택합니다.

     

  6. 페더레이션 도메인 선택 완료 후 "Select" 선택합니다.

     

     기본(Default) 도메인은 구성 불가

  7. 추가 옵션 사항은 필수가 아닌 선택사항으로 검토 후 "Done"을 통해 구성을 마칩니다.

     

2. Manual using PowerShell

---

2. 프로비저닝 구성

주요사항

• 프로비저닝 기능에 상세한 설명은 2.프로비저닝 기능 을 통해 확인 바랍니다.

• Okta가 전역 관리자 권한이 부여 된 Office 365 테넌트 계정(.onmicrosoft.com)을 통해 API 권한이 부여되며 이를 통해 프로비저닝 구성이 적용됩니다.

• Office 365 테넌트 계정에 대한 주요 사항은 해당 링크를 통해 확인 바랍니다.

2.1 [Okta] API Integration 설정

• 프로비저닝 구성을 위한 테넌트 계정은 SSO 자동 구성에서 권한을 부여한 계정을 사용하시면 되며, 만약 수동으로 SSO 구성을 하였다면 "1.3 [Office 365] Office 365 계정 생성"에서 가이드 한 테넌트 계정을 통해 인증 및 권한 부여를 진행해 주시길 권장 드립니다.

경로: Application ➡ Application ➡ Microsoft Office 365 검색 ➡ Microsoft Office 365 앱 선택

프로비저닝 항목에서 "Configure API Integration" 선택

"Enable API integration" 체크(활성화)

"Authenticate with Microsoft Account" 선택

Office 365 테넌트 계정으로 로그인 후 권한을 "수락"합니다.

"Save" 선택하여 프로비저닝 구성을 완료합니다.

2.2 프로비저닝 설정(세부기능)

경로: Application ➡ Application ➡ Microsoft Office 365 앱 ➡ Provisioning

---

2.2.1 Okta to App (Okta → Office 365)

• Okta의 사용자를 기준으로 Office 365에 다양한 프로비저닝 유형으로 Push/동기화 하는 기능을 제공합니다.

  

• Provisioning to App

• Office 365 Provisioning Type

  • Okta 공식 문서 : Provisioning options for Office 365

    

Licenses/Roles Management Only (라이선스/역할 관리 전용)

• [핵심 기능]:

  • Okta를 통한 Office 365 사용자 생성(Create)은 지원하지 않습니다.

  • 기존에 존재하는 Office 365 사용자에 대해 라이선스 및 역할(Role)을 부여하거나 회수하는 기능만 제공합니다.

  • 사용자 비활성화(Deactivate) 시, 계정을 삭제하는 것이 아니라 로그인 차단 및 라이선스 회수 동작을 수행합니다. * 어떠한 환경에서 사용되나 ?

    • 하이브리드(Hybrid) 환경: 사내 AD(Active Directory)에서 임직원을 생성하고, Microsoft Entra Connect (AAD Connect)를 통해 Office 365로 사용자를 동기화하는 환경에서, Okta는 오직 '라이선스/역할(Role) 자동 할당' 용도로만 사용할 때 적합합니다.

• [동일한 온프레미스 AD 환경 필수 구성 요소]:

  • 해당 기능에 대해 Okta는 사용자를 생성하지 않고 기존 Office 365 사용자에 대해 라이선스/역할 의 제어만을 수행하므로, 동일한 사용자를 식별하기 위해 필수 구성 요건이 필요합니다.

    • Microsoft Entra Connect (AAD Connect):

      • AD의 사용자 정보를 기반으로 Microsoft Office 365 계정 생성/관리

    • Okta Active Directory agent :

      • AD를 사용자 주체로 Okta로 Import 하여, Microsoft Office 365에 Assign 하고 매핑하기 위한 객체 구성

Profile Sync (프로필 동기화)

• [핵심 기능]:

  • Okta를 통해 Office 365 앱에 Assign 된 사용자에 대해 Office 365에 생성 가능합니다.

  • 프로필 동기화: 사용자의 기본 프로필 속성(Basic Profile Attributes)만 Office 365로 동기화합니다. > 기본 프로필 속성(Basic Profile Attributes) : 로그인에 꼭 필요한 최소 정보 사용자 이름 (First/Last Name), 이메일 (UPN), 표시 이름 (Display Name), 이메일

    • 수정 권한: Okta & Microsoft 365 관리 센터에서 사용자 정보를 직접 수정하는 것이 허용(Y)됩니다. 즉, 사용자 정보에 대해 어느 한 곳에서 종속성을 가지지 않고 모든 곳에서 사용자 정보를 수정할 수 있는 유연한 모드입니다. * 어떠한 환경에서 사용되나 ?

      • 유연한 관리 환경: Okta를 통해 사용자의 기본 정보는 동기화 적용하며 확장 속성(Extended Attributes)까지는 동기화할 필요가 없는 경우에 활용되며, Office 365 쪽에서는 관리자가 수동으로 기본/확장 속성 정보를 수정해야 할 필요가 있는 상황처럼 사용자 관리 주체를 변경하기 위한 마이그레이션 작업에서 주로 활용됩니다.

User Sync (사용자 동기화)

• [핵심 기능]:

  • Okta를 통해 Office 365 앱에 Assign 된 사용자에 대해 Office 365에 생성 가능합니다.

  • 프로필 동기화: Okta를 통해 사용자의 기본 프로필 속성(Basic Profile Attributes)과 확장 속성(Extended Attributes)까지 모두 Office 365 사용자 정보에 동기화 하기 위한 기능입니다. > 확장 속성(Extended Attributes) : 사용자의 상세 속성 정보 부서 (Department), 매니저 정보 (Manager), 사번 (Employee ID) 등

    • 수정 권한(중요): Okta가 사용자의 주체가 되어 Office 365 관리 센터에서 사용자 수정이 불가능합니다. Okta를 통해서만 Office 365 사용자의 정보를 업데이트할 수 있습니다. * 어떠한 환경에서 사용되나 ?

      • 클라우드 전용(Cloud Only) 환경: 사내 AD 서버가 없고 Okta를 메인 유저 디렉터리(사용자 원장)로 사용하는 기업의 표준 설정입니다. 모든 인사 정보의 주체가 Okta로 구성된 환경에서 Office 365 사용자를 관리하기 위한 용도로 활용됩니다.

• [제약 사항 (필수)]:

  • 해당 기능은 Okta가 사용자의 원장(주체)가 되므로 Office 365의 사용자 정보를 보호(충돌 방지)하기 위해 Microsoft Entra Connect (AAD Connect)와 함께 사용이 불가합니다.

Universal Sync (유니버설 동기화)

• [핵심 기능]:

  • User Sync의 모든 기능(사용자 생성, 확장 속성 동기화)을 포함합니다.

  • 추가적으로 보안 그룹(Security Groups), 배포 목록(Distribution Lists), 연락처(Contacts), 리소스 사서함(Resource Mailboxes) 등 모든 디렉터리 개체를 동기화합니다. * 어떠한 환경에서 사용되나 ?

    • Okta를 통한 완전 통합 관리 환경: Office 365 관리 센터에 접속할 필요 없이, 그룹 생성이나 배포 리스트 관리까지 모든 것을 Okta를 통해 모든 Office 365 관리를 통합하기 위해 활용됩니다. 상세한 주요 기능은 "Office 365 Provisioning Type: Universal Sync" 를 참고 바랍니다.

• [제약 사항 (필수)]:

  • 해당 기능은 User Sync와 마찬가지로 Okta가 사용자의 원장(주체)가 되므로 Office 365의 사용자 정보를 보호(충돌 방지)하기 위해 Microsoft Entra Connect (AAD Connect)와 함께 사용이 불가합니다.

• Provisioning Default Options

  

Create Users (사용자 생성)

• [핵심 기능]:

  • Okta에서 Office 365 앱에 Assign한 사용자에 대해 M365에 자동으로 계정을 생성합니다.

  • 만약 M365에 동일한 ID(UPN)의 사용자가 존재 한다면, 신규 사용자를 생성하지 않고 기존 사용자의 계정과 연결(Link)합니다.

  • M365에 ID와 매칭되는 기본 정보는 Okta의 Username 입니다.

• [주의사항]:

  • 라이선스 제한 이슈: 앱에 사용자가 Assign 되면 프로비저닝에 의해 M365 계정이 생성되면서 M365 라이선스가 자동으로 부여될 수 있습니다. M365에서 할당할 수 있는 최대 라이선스를 초과하면 Okta의 프로비저닝 오류가 발생됩니다.

  • 사용자 매칭 주의: M365에 사용자와 Okta 사용자가 서로 같은 사용자인지 판별하는 기준의 ID(UPN)가 정확히 매칭이 잘 되었는지 확인이 필요합니다.

Update User Attributes (사용자 속성 업데이트)

• [핵심 기능]:

  • Okta에서 사용자 프로필 정보(이름, 부서, 전화번호 등)가 변경되면, M365에 해당 사용자의 정보도 자동으로 업데이트(덮어쓰기)합니다.

  • Okta에 "사용자 원장(Source of Truth)"과 프로비저닝 구성이 되어있다면, 사용자 원장에 의해 변경된 사용자 프로필에 대해서도 Okta를 통해 M365에 업데이트를 할 수 있습니다.

• [주의사항]:

  • M365 직접 수정 금지(충돌 방지): M365 관리 센터에서 관리자가 수동으로 사용자 정보를 변경하여도, Okta는 다음 동기화 때 Okta가 가진 사용자 정보로 다시 덮어씌워집니다. (Overwrite) 그렇기에 M365에서 사용자 정보 변경이 필요할 시 Okta를 통해 업데이트 되도록 하여야 합니다.

Deactivate Users (사용자 비활성화)

• [핵심 기능]:

  • 해당 기능은 기본적으로 Office 365 앱에 사용자가 Assign이 제거되거나, Okta에서 사용자의 상태가 Deactivate로 전환되면 자동으로 M365에 해당 사용자의 상태를 로그인 차단(EntraID 기준 : 사용 안 함)으로 변경합니다.

  • "Microsoft Office 365 user status on deactivation" 옵션을 통해 사용자 비활성화에 따른 다양한 기능을 제공 합니다. (라이선스 회수 / 유예 기간 / 사용자 삭제)

• [주의사항 (중요!!)]

  • 데이터 삭제 위험 : M365에서 라이선스가 회수(Remove licenses)되면, 해당 사용자에 OneDrive 및 이메일 등의 데이터 보관 기간(보통 30일) 이후 자동으로 영구 삭제가 됩니다. M365 보존 정책(Retention Policy)을 확인 바랍니다.

  • Grace Period (유예 기간): Okta에서 사용자가 앱에서 Assign 제거되고, Deactivate로 전환되어도 M365 사용자에 대해 보존을 위한 유예 기간 기능을 제공합니다.

    

    Day 기준으로 유예 기간을 설정 할 수 있습니다. (최소 1일 ~ 최대 180일 까지 설정 가능)

• "Microsoft Office 365 user status on deactivation" 옵션 설명

  • Okta 공식 문서 : Deprovisioning options for Office 365

옵션	주요 기능 및 활용 사례
Block sign-in (로그인 차단)	[주요 기능] 사용자의 로그인만 즉시 차단합니다. ('활성 사용자' 목록 유지) 라이선스에 대해 관여하지 않습니다. (M365 에서 별도 관리) [활용 사례] 장기 휴직자: 퇴사는 아니지만 접속은 막아야 하고, 이메일/데이터는 유지해야 할 때. 감사(Audit) 대상: 법적/보안 이슈로 계정을 절대 건드리지 말고 '동결'해야 할 때.
Block sign-in and remove licenses (로그인 차단 및 라이선스 제거)	[주요 기능] 로그인 차단 및 라이선스를 회수(제거)합니다. ('활성 사용자' 목록에 "Unlicensed User" 상태로유지) MS 보존 정책에 따라 데이터는 유예 기간(Default:30일) 이후 영구 삭제됩니다. [활용 사례] 비용 절감 : 라이선스 미사용에 대한 비용 최소화. 기록 보존: 데이터는 삭제되어도 "사용자가 누구 였는지" 계정 기록은 보존하고자 하는 경우.
Block sign-in and remove licenses after grace period (로그인 차단 및 유예 기간 후 라이선스 제거)	[주요 기능] 즉시 로그인은 차단 되며, Okta에서 설정한 유예 기간(Grace Period) 동안 라이선스는 유지됩니다. ('활성 사용자' 목록에 유지되며, 유예 기간 이후 "Unlicensed User"로 전환) Okta의 유예 기간(Grace Period)이 종료되어 라이선스 회수 되면, 해당 일자 기준으로 MS 보존 정책에 따라 유예 기간(Default:30일) 이후 데이터는 영구 삭제됩니다. [활용 사례] 안전한 라이선스 회수: 복직/재계약으로 라이선스 재사용이 필요한 요건에 따라, 유예 기간 내에 원복(Assign)으로 데이터 손실 없이 원상복구가 필요한 경우. 관리 목적 : 매니저가 퇴사자의 전자결제 결과 확인 및 데이터 백업할 시간이 필요한 경우.
Block sign-in, remove licenses, and delete user (로그인 차단, 라이선스 제거 및 사용자 삭제)	[주요 기능] M365에서 사용자의 로그인 차단 + 라이선스 회수 + 계정 삭제를 즉시 모두 수행합니다. ('삭제된 사용자' 목록으로 이동) MS 보존 정책에 따라 유예 기간(Default:30일) 이후 데이터와 사용자 계정에 대해 영구 삭제됩니다. [활용 사례] 빠른 사용자 정리(Clean-up): 퇴사자를 사용자 목록에 남기지 않고 영구 삭제 대상자로 적용할 경우. 중요도가 낮은 사용자 타입 : 단기 계약직이나 임시직원 등 데이터 보존 중요도가 낮은 경우.
Block sign-in, remove licenses, and delete user after grace period (로그인 차단, 유예 기간 후 라이선스 제거 및 사용자 삭제)	[주요 기능] 즉시 로그인은 차단 되며, Okta에서 설정한 유예 기간(Grace Period) 이후 라이선스 회수(제거) 및 계정 삭제를 수행합니다. MS 보존 정책에 따라 유예 기간(Default:30일) 이후 데이터와 사용자 계정에 대해 영구 삭제됩니다. [활용 사례] (권장) 표준 관리/운영 절차 : "유예 기간을 통한 원복 전환 및 운영 안정화"와 "컴플라이언스 절차에 따른 관리 방안"의 모든 요건이 충족되는 환경 사안.

Sync Password (비밀번호 동기화)

• [핵심 기능]:

  • 사용자의 Okta 비밀번호를 M365 계정의 비밀번호로 단방향 동기화(Push)하는 기능입니다.

  • Okta에서 Office 365 앱에 사용자를 Assign(할당) 또는 Okta에서 사용자의 비밀번호가 변경되면, 해당 Okta 비밀번호가 M365에 사용자 비밀번호로 동기화되어 사용자는 M365 인증 시 Okta 패스워드로 인증이 가능합니다.

  • 임의 비밀번호 부여: 사용자가 Okta 비밀번호를 아직 설정하지 않은 상태에서 패스워드 동기화가 적용되면, Okta는 사용자의 패스워드를 임의로 난수 비밀번호(Random Password)를 생성하여 M365로 동기화 합니다.

• [주의사항 (중요!!)]

  • Microsoft Entra Connect (AAD Connect) 환경에서는 사용 불가 :

    • 사내 AD 서버와 AAD Connect를 통해 동기화 중인 환경에서는 해당 기능을 활성화(Enable)해서는 안 됩니다.

    • 비밀번호의 관리 권한(Master)이 온프레미스 AD에 있으므로, Okta가 비밀번호를 덮어쓰려 할 경우 충돌 및 프로비저닝 오류가 발생합니다.

  • 페더레이션(SSO)만 적용한 환경 시 비활성화 권장:

    • Okta를 통해 인증(SSO) 하는 경우, M365에 사용자 비밀번호를 요구하지 않으므로 M365 계정에 비밀번호를 동기화할 필요가 없습니다. (보안상 Disable 권장)

• [Sync Password Option]

  • Password type :

    1. Sync a randomly generated password : Okta가 무작위로 생성한 비밀번호(Random Password)를 M365 사용자의 암호로 동기화 시킵니다. (해당 기능은 Okta 패스워드 유출/도용 된 경우 확산되는 보안 위험을 방지하기 위한 기능입니다.)

       • Generate a new random password whenever the user's Okta password changes (선택사항): Okta의 패스워드 변경 주기 옵션을 통해, Okta의 패스워드 변경 시점에서 무작위로 생성된 패스워드를 M365 패스워드로 동기화 하는 옵션입니다.

       

       • Reset All Microsoft Office 365 Passwords : Microsoft Office 365 앱에 할당(Assign)된 모든 사용자를 대상으로 Okta 관리자가 수동으로 패스워드를 강제 동기화 하는 기능입니다. (주의사항 : PC / 모바일에 설치된 Office 365 앱에 기존 인증된 패스워드가 변경됨에 따라 연결이 실패되며, 사용자는 Okta를 통해 변경된 패스워드로 재인증이 필요합니다.)

       

    2. Sync Okta Password : Okta에 사용자 패스워드를 M365의 사용자 패스워드와 동기화 합니다. (Okta 비밀번호를 설정하지 않은 사용자에 대해서는 Random Password를 Okta가 생성하여 M365로 동기화 적용됩니다.)

       

---

2.2.2 App to Okta (Office 365 →Okta)

• Microsoft Office 365에 존재하는 사용자 정보와 프로필 속성을 Okta로 가져와(Import), Okta 내의 기존 계정과 연결(Match)하거나 새로운 Okta 계정을 생성/업데이트하는 기능을 제공합니다.

  

Microsoft Office 365 사용자를 Okta로 가져오기 전 주요 검토 사항

1. M365에서 사용자는 활성화 상태여야 합니다.

2. Office 365 라이선스가 부여된 사용자에 한하여 Okta로 가져올 수 있습니다.

[주의사항]

M365에 구성원 중, 특정 도메인의 사용자만 Okta로 Import 할 수 없습니다.

• Okta의 Office 365 통합은 Microsoft 365 테넌트(Tenant) 단위로 연결됩니다. Okta가 Microsoft Graph API를 통해 사용자를 조회할 때, 테넌트 전체를 대상으로 호출하며 API 호출 단계에서 특정 도메인(@domain.com)만 필터링하는 기능을 제공하지 않습니다. 따라서 M365(Entra ID) 테넌트 내에 라이선스가 할당된 모든 사용자가 Import 대상으로 수집되며, 특정 도메인 사용자만 선별적으로 가져오는 것은 구조적으로 지원하지 않습니다

Q1) 위의 가져오기 조건이 모두 충족되어 있는 사용자인데, Okta로 사용자 가져오기(Import)가 안 돼요!

대체로 이런 경우는 사용자의 프로필 속성에 정보 부족으로 인한 이슈로, 아래 항목을 통해 확인이 가능합니다.

• Okta는 사용자 생성 시 기본 사용자의 필수 속성 정보 "ID, 이름, 성, 이메일" 4개의 항목을 요구합니다. (이름, 성은 옵션 사항으로 변경 가능함.) 그러나, Office 365 / AAD는 이름(First Name)과 성(Last Name) 속성이 사용자의 필수 속성 정보가 아니므로 사용자 프로필에서 누락되어 있는 경우가 많습니다.

• 아래 가이드를 통해 Office 365/AAD에서 사용자의 프로필 속성에 Okta의 사용자 필수 정보 요건이 입력 되어 있는지 체크바랍니다.

  1. Azure AD Portal 에서 사용자 프로필 확인

  2. Microsoft 365 관리 센터 에서 사용자 정보 확인

Q2) M365에서 Okta로 가져오기 조건을 현재 충족할 수 없는 상태인데.. 우선은 Okta 사용자로 구성하는 방법은 없나요?

이런 경우, M365에서 전체 사용자 내보내기를 통해 CSV 파일 형태로 Okta에 Import 가능합니다. 아래 M365에서 사용자 내보내기 기능으로 사용자 추출 후 "CSV Import" 가이드를 통해 Okta로 구성하시기 바랍니다.

• M365에서 전체 사용자 추출 방법

  

• General: Office 365 사용자를 Okta로 가져오기(Import) 위한 스케줄 기능을 제공하며, Okta 사용자 생성 및 매칭을 위한 ID 기준을 정의하여 설정할 수 있습니다.

  

Full Import Schedule (전체 가져오기 스케줄)

• [주요 기능]

  • Office 365에 있는 사용자 및 그룹 데이터를 Okta로 가져오는(Import) 작업을 얼마나 자주 자동으로 앱에서 수행할지 주기를 설정합니다. (예: 요일(일자), 시간 등)

• [참고 사항]

  • 스케줄 옵션 변경 : 아래와 같이 매시간 단위, 하루 몇 회 등의 스케줄링으로 구성은 가능하며, Cron 형태에 "요일/시간"의 상세한 구성 기능은 별도의 Features옵션을 활성화해야 합니다.

    • Okta 관리 콘솔에서 "Settings" → "Features" → "Cron based User Import scheduling" 활성화

      

  • "Cron based User Import scheduling" 기능이 활성화 되면 아래와 같이 스케줄링 옵션이 변경 됩니다.

    

Okta username format (Okta 사용자 ID 형식 정의)

• [주요 기능]

  • Office 365에서 사용자를 가져와서 Okta 계정을 생성할 때, Office 365에 어떤 사용자 정보를 Okta의 사용자 ID(Username)로 구성할지 지정합니다.

• [참고 사항]

  • 사용자 매칭 기준: 이미 Okta에 계정이 있는 사용자를 Office 365에서 가져올 때, 설정한 값이 Okta에서 해당 계정의 ID로 구성되어 있어야 서로 일치하는 동일 사용자로 식별되어 계정이 연결(Link)할 수 있습니다. 만약 일치하지 않는 정보로 Okta 계정이 구성되어 있는 경우, 같은 사용자여도 별도의 Okta 계정이 생성될 수 있으니 충분한 검토가 필요합니다.

Update application username on (Import 할 때 수행할 동작)

• [주요 기능]

  • M365의 경우, 단순히 이메일 값을 비교하여 사용자를 식별하고 매핑하는 것이 아니라 Graph API를 통한 복합 매핑(UPN+ImmutableID)을 사용하므로 Okta의 프로비저닝 제약 요건에 따라 "Create only" 옵션만 지원합니다.

  • M365는 Okta의 Username(UPN)을 통해 사용자를 1차 식별하고, 2차로 Immutable ID(고유 식별자)까지 일치하여야 인증이 성공합니다. 만약 'Update' 옵션을 통해 Okta의Username(UPN)이 변경될 때, 이 고유 식별자와의 매핑이 어긋나면 즉시 SSO 로그인이 불가능해지는(Lockout) 치명적인 장애가 발생할 수 있습니다.

  • 결론적으로 M365 앱의 경우, 온프레미스AD & Entra ID를 통해 제공하는 SP(Service Provider)입니다. 이는 사용자 신원을 보증할 수 있는 앱이 아닙니다. 그래서 사용자 Source로 사용할 수 없도록 Okta에서 "Create only" 옵션만 제공하여 안전장치를 적용한 것입니다.

• [참고 사항]

  • ImmutableID: 온프레미스 Active Directory(AD)에서 AAD Sync를 통해 관리되는 사용자의 경우, 기본적으로 Immutable ID가 포함되어 있어 Import 이후 인증시 에러가 발생하지 않습니다. 다만, Azure AD에서 직접 생성한 사용자는 아래와 같이 Immutable ID가 부여되어 있지 않습니다.

  • ImmutableID가 없는 사용자는 Office 365에 Assign 되어 있어도 아래와 같이 "Office 365 로그인 실패" 오류가 발생하며 인증이 불가합니다.

  • 이런 경우, 프로비저닝 옵션 설정과 사용자를 재할당(Assign) 하여 ImmutableID 부여를 할 수 있습니다.

    1. Provisioning 항목에서 To App 설정에 Office 365 Provisioning Type을 Profile Sync로 선택 후 저장합니다.

    2. "Assignments"에서 "ImmutableID" 가 없는 사용자에 대해 "X"를 눌러 Assign을 해제합니다.

    3. 이후 "Assign to People" 옵션을 통해 다시 재할당(Assign) 합니다.

    4. Assign이 완료 후 사용자의 프로필을 확인합니다.

    5. 그러면 아래와 같이 "ImmutableID"가 부여된 것을 확인할 수 있습니다.

2.3 프로비저닝 상태 확인

• Azure AD 관리 화면을 통해서 Okta에서 할당한 사용자의 External ID와 Immutble ID가 일치하는지 확인합니다.

경로: portal.azure.com ➡ Entra ID ➡ 사용자 ➡ 모든 사용자 ➡ 확인할 사용자 ID 클릭 ➡ 속성

경로: Okta 관리콘솔에서 "Applications" ➡ "Applications" ➡ Microsoft Office 365 앱 선택 ➡ Assignments ➡ 확인할 사용자 오른쪽 연필 모양 선택

---

III. 앱 할당

• Application에 사용자를 Assign 하는 방법은 개별 사용자와 그룹에 포함된 사용자를 Assign 하는 2가지 방식으로 활용할 수 있습니다.

• 프로비저닝을 구성하면 애플리케이션 할당(Assign)하는 단계에서 사용자/그룹에 M365 접근 권한뿐만 아니라 "라이선스 및 역할(Role)"을 부여할 수 있습니다.

[주의 사항]

M365 라이선스&역할(Role)에 대해 세부적으로 분리하여 부여를 구성해야 하는 경우, Okta 그룹명을 활용하여 각 라이선스와 역할을 명시하고 운영 및 관리하시기를 권장 드립니다.

1. 개별 사용자 (Individual Assignment)

특징 및 장점:

• 특정 사용자에게만 예외적인 라이선스나 권한(예: Global Admin 등)을 부여해야 할 때 유용합니다.

• 임시적인 테스트 용도로 활용이 가능합니다.

단점:

• 관리 부담: 입/퇴사자가 많거나 조직 변경 빈번한 경우, 관리자의 리소스 부담이 발생할 수 있어 대규모 사용자의 운영에는 부적합합니다.

• 관리 소홀: 개별 사용자 이기에 이력 관리와 추적이 어려울 수 있습니다.

[Assign 구성]

• Assignments > Assign to People 메뉴를 통해 수행합니다.

• Assign 할 사용자 검색 후 "Assign" 선택 후 "Done"을 통해 개별 사용자의 Assign을 완료 합니다.

  • 프로비저닝 구성이 되어 있다면, 해당 Assign 할 사용자 검색 후 "Assign" 선택 단계에서 아래와 같이 라이선스 & 역할(Role)을 할당할 수 있는 옵션이 제공됩니다.

  • 라이선스에 포함된 특정 서비스만 할당도 가능합니다.

2. 그룹에 포함된 사용자 (Group Assignment) [권장사항]

특징 및 장점:

• 자동화 및 효율성: 그룹에 사용자 추가/삭제로 앱의 권한과 라이선스/역할(Role)까지 자동 부여되어 관리에 효과적이며 이슈 발생이 적습니다. (Group-based Licensing)

• 일괄 적용: M365 정책이 바뀌면 그룹에 할당된 라이선스/Role 설정만 변경하면, 그룹에 포함된 사용자에 대해 M365 정책을 일괄 적용 할 수 있습니다.

단점:

• 과도한 그룹 관리 : 라이선스와 역할에 따른 다수의 그룹으로 운영 할 경우, 그룹 rule 또는 Workflow 등 다양한 추가 운영 구성이 필요 할 수 있습니다.

• 예외 처리 : 라이선스에 포함된 서비스 중, 특정 서비스만 예외 해야하는 경우 개별 사용자 할당 또는 별도 그룹을 통한 관리/운영이 필요합니다.

[Assign 구성]

• Assignments > Assign to Groups 메뉴를 통해 수행합니다.

• Assign 할 신규 생성한 그룹 또는 기존 그룹에 대해 검색 후 "Assign" 선택 후 "Done"을 통해 그룹에 포함된 사용자의 Assign을 완료 합니다.

  • 프로비저닝 구성이 되어 있다면, 그룹 "Assign" 선택 단계에서 아래와 같이 라이선스 & 역할(Role)을 할당할 수 있는 옵션이 제공됩니다.

  • 라이선스에 포함된 특정 서비스만 할당도 가능합니다.

[주요 사항] Office 365 그룹 할당 시 우선순위(Priority) 적용

Okta는 사용자가 애플리케이션에 할당된 여러 그룹에 중복 소속되어 있을 경우, 그룹 우선순위(Group Priority) 설정에 따라 라이선스와 역할을 결정합니다.

• 우선순위 기반 단일 적용: 사용자가 여러 할당 그룹에 동시에 속해 있을 때, 라이선스 및 역할 설정은 병합(Merge)되지 않고 가장 높은 우선순위(Priority 1)를 가진 그룹의 설정 하나만 적용됩니다.

• 순위 결정 방식: 우선순위 숫자가 작을수록(1, 2, 3...) 높은 권한을 가집니다. (Priority 1 > Priority 2)

  

• Role의 경우, Priority를 기준으로 적용되는 것이 관리/운영에 효과적일 수 있습니다.

• 다만, 라이선스는 각 개별 라이선스와 서비스로 그룹을 통해 분리 구성하여 운영하는 경우가 많기에 해당 링크를 통해 여러 그룹에 속한 사용자가 각 그룹에 부여된 라이선스 및 역할(Role)이 모두 적용되도록 구성 가능합니다.

---

IV. 최종 사용자 경험

1. Okta Dashboard 로그인

Okta Dashboard 로그인(IdP initiated SSO)

---

2. Office365에 직접 로그인

Office365에 직접 로그인(SP initiated SSO)