퇴사자의 Active Directory(AD) 계정을 정리할 때 서버의 예약 작업도 확인해야 합니다. 사람이 로그인하지 않는 시간에 실행되는 파일 복사나 보고서 생성 작업이 개인 계정을 사용하고 있을 수 있기 때문입니다. 계정 삭제 전에는 어느 장비의 어떤 작업이 그 계정을 쓰는지 확인하고, 필요한 작업의 실행 주체를 넘겨야 합니다.
작성자보다 실행 계정을 먼저 확인합니다
작업 스케줄러에 표시되는 작성자와 실행 계정은 구분해야 합니다. 작성자 이름에 퇴사자가 있다고 해서 해당 계정으로 실행된다고 단정할 수는 없습니다. 작업 속성의 일반 탭에서 보안 옵션에 지정된 계정을 확인하고, PowerShell에서는 Principal.UserId를 살펴봅니다.
Principal은 작업이 실행될 보안 주체를 뜻합니다. 예약 작업은 지정된 사용자나 그룹의 보안 컨텍스트, 즉 해당 주체의 권한으로 동작합니다. 따라서 조사 대상은 작성자 목록보다 실행 계정과 그 권한입니다. [1]
아래는 도메인에 가입된 Windows Server에서 ScheduledTasks 모듈을 사용할 수 있다는 전제의 읽기 전용 조회 예시입니다. 해당 서버의 작업 정의를 조회하며, AD 전체 서버를 자동으로 검색하지는 않습니다. 관리 권한으로 열람 범위를 확인한 뒤 대상 장비별로 수행합니다. [2]
Get-ScheduledTask | Select-Object TaskPath, TaskName, State,
@{Name='RunAs'; Expression={$_.Principal.UserId}},
@{Name='LogonType'; Expression={$_.Principal.LogonType}},
@{Name='RunLevel'; Expression={$_.Principal.RunLevel}}RunAs가 퇴사자의 도메인 계정이나 SID인지 대조합니다. SID는 계정을 구별하는 보안 식별자입니다. 계정이 문자열과 SID 중 어느 형태로 표시되는지 살펴보고, 이름만 검색해 누락하지 않도록 합니다. 조회 실패 장비나 권한 때문에 보지 못한 작업은 별도로 남겨야 합니다.
계정 이름 밖에 남은 의존성도 살펴봅니다
실행 계정을 찾았다면 작업의 동작 탭에서 프로그램, 인수, 시작 위치를 함께 확인합니다. 실행 계정만 바꾸어도 스크립트가 퇴사자의 프로필 경로를 참조하거나 별도 설정의 개인 자격 증명을 사용하면 의존성이 남을 수 있습니다. 이런 항목은 실제 설정을 읽고 확인할 후보이며, 모든 작업에 존재한다고 가정하지 않습니다.
로그온 방식도 중요합니다. Interactive 방식은 해당 사용자의 기존 로그인 세션이 있어야 실행됩니다. S4U는 시스템에 비밀번호를 저장하지 않지만 해당 로그온 컨텍스트에서 네트워크와 암호화 파일에 접근할 수 없습니다. 공유폴더를 쓰는 작업을 옮길 때는 이 차이를 먼저 검토해야 합니다. [3]
예를 들어 퇴사자 계정으로 공유폴더에 보고서를 복사하는 작업을 가정하겠습니다. 새 계정에 로컬 스크립트 실행 권한만 주면 원격 저장 위치 접근까지 확인한 것이 아닙니다. 실제 입력·출력 경로와 필요한 권한을 연결해 다음과 같이 점검합니다.
| 점검 대상 | 확인할 내용 | 이관 판단 |
|---|---|---|
| 실행 주체 | Principal.UserId와 로그온 방식 | 대체 계정과 실행 조건 확정 |
| 로컬 파일 | 스크립트·시작 위치·프로필 경로 | 새 계정의 읽기·실행·쓰기 범위 확인 |
| 외부 자원 | 공유 경로·접속 설정·사용 자격 증명 | 목적지 접근과 개인 계정 참조 확인 |
| 운영 정보 | 일정·산출물·담당자 | 검증 시점과 인수 담당자 지정 |
대체 계정으로 옮긴 뒤 산출물까지 검증합니다
이관할 작업은 기존 설정과 되돌릴 변경 항목을 기록하고, 필요한 권한을 가진 업무용 계정으로 전환합니다. 비밀번호나 사용자별 비밀정보는 원고·점검표에 복사하지 않습니다. 작업 실행을 위해 퇴사자의 개인 계정을 계속 활성 상태로 유지하는 방식은 피하고, 퇴사 시 접근 차단 일정과 업무 이관을 함께 관리합니다.
대체 계정에는 무조건 관리자 권한을 부여하지 않습니다. Password·S4U 방식은 배치 작업으로 로그온할 권한이 필요하므로 유효한 정책을 확인합니다. 환경과 프로그램이 지원한다면 비밀번호를 자동 관리하는 gMSA도 검토할 수 있습니다. 다만 도메인 준비와 허용 호스트 설정 등이 필요하므로 계정 이름만 교체하는 작업으로 보아서는 안 됩니다. [1] [5]
전환 후에는 Get-ScheduledTaskInfo로 최근 실행 정보를 확인하고, 작업 기록과 프로그램 로그를 함께 봅니다. 마지막 실행 결과만으로 보고서 내용이나 파일 전달까지 정상이라고 판단하지 않습니다. 업무 산출물의 생성 시각·저장 위치·내용을 확인하고, 사용자 로그인에 기대지 않는 실제 예약 실행 조건에서도 검증합니다. [4]
매월 실행되는 작업을 당일 수동 실행 한 번으로 검증 완료 처리하지 않도록 합니다. 담당자가 시험 범위와 다음 예약 실행 확인 시점을 남긴 뒤, 의존 작업의 이관 여부를 조직의 계정 삭제 절차와 연결합니다. 이미 시작된 작업의 상태와 이후 새로 시작할 작업의 인증 문제도 구분해서 기록합니다.
결론
AD 퇴사자 계정을 삭제하기 전에는 대상 장비의 예약 작업에서 실행 계정을 확인하고, 스크립트와 외부 자원에 남은 의존성을 찾아야 합니다. 필요한 작업은 담당자와 대체 계정을 정해 옮기고 실제 예약 조건의 결과를 검증합니다. 이관이 덜 된 업무와 퇴사자 접근 차단은 별도 관리 항목으로 남겨, 계정 정리가 업무 공백이나 개인 계정의 장기 사용으로 이어지지 않게 합니다.