หลีกเลี่ยง Windows Task Scheduler สำหรับ Microsoft 365 PowerShell

มีวิธีที่ดีกว่าในการเรียกใช้สคริปต์ Microsoft 365 PowerShell

ฉันรู้สึกสับสนเมื่ออ่านบทความที่แนะนำให้ผู้ดูแลระบบผู้เช่า Microsoft 365 เรียกใช้สคริปต์ PowerShell โดยใช้ Windows Task Scheduler ฉันเข้าใจเหตุผลว่าทำไมผู้คนถึงใช้ Task Scheduler เป็นเรื่องง่าย มีอยู่ใน Windows ช่วยให้สคริปต์ทำงานได้โดยไม่ต้องดูแล (จะได้เปรียบเสมอเมื่อต้องรับมือกับสคริปต์ที่ใช้เวลานาน) และทำงานให้เสร็จ ในทางกลับกัน ตัวกำหนดเวลางานเป็นยูทิลิตี้ล้าสมัยที่พยายามดิ้นรนเพื่อจัดการกับการใช้งาน PowerShell สมัยใหม่ มีวิธีการที่ดีกว่าสำหรับผู้เชี่ยวชาญด้านไอทีให้ใช้ ให้ฉันอธิบายว่าทำไม

การเรียกใช้สคริปต์ Microsoft Graph PowerShell SDK

เพื่ออธิบายประเด็นต่างๆ ฉันได้สร้างสคริปต์ PowerShell แบบง่ายๆ ที่ใช้ Microsoft Graph PowerShell SDK เพื่อค้นหาบัญชีผู้ใช้ที่สร้างขึ้นในปีที่แล้วและส่งออกรายละเอียดเป็นไฟล์ CSV นี่คือรหัส:

Connect-MgGraph
[array]$Users = Get-MgUser -Filter "usertype eq 'Member' and CreatedDateTime ge $([datetime]::UtcNow.AddYears(-1).ToString("s"))Z" -All -Property Id, DisplayName, UserPrincipalName, CreatedDateTime
$Users = $Users | Select-Object Id, UserPrincipalName, DisplayName, CreatedDateTime
$Users | Export-CSv -NoTypeInformation c:\temp\UsersLastYear.CSV

หลังจากตรวจสอบให้แน่ใจว่าสคริปต์ทำงานได้สำเร็จในเซสชันแบบโต้ตอบ ฉันจึงสร้างงานขึ้นมา ทุกอย่างดำเนินไปอย่างที่คาดไว้เมื่อรันงานด้วยบัญชีที่ลงชื่อเข้าใช้ ปัญหาเริ่มต้นขึ้นเมื่อพยายามเรียกใช้สคริปต์เมื่อผู้ใช้ไม่ได้ลงชื่อเข้าใช้เนื่องจาก Task Scheduler จะไม่ยอมรับข้อมูลประจำตัวจากบัญชี Entra ID (รูปที่ 1)

คุณสามารถโต้แย้งได้ว่านี่ไม่ใช่ปัญหาใหญ่ ในกรณีส่วนใหญ่ ผู้คนจะลงชื่อเข้าใช้เวิร์กสเตชันของตน และงานต่างๆ สามารถทำงานได้สำเร็จ

สคริปต์ทำงานต่อจากข้อมูลประจำตัวที่จำเป็นในการเชื่อมต่อกับตำแหน่งข้อมูล PowerShell โดยไม่มีปัญหา เนื่องจากตัวกำหนดเวลางานเปิดใช้ PowerShell และเรียกใช้ Connect-MgGraph cmdlet Microsoft Graph PowerShell SDK จะใช้ข้อมูลประจำตัวที่แคชไว้โดยอัตโนมัติ และเลือกชุดสิทธิ์อนุญาตกราฟที่ได้รับความยินยอมซึ่งถือโดยบริการหลักสำหรับแอป SDK ส่งผลให้งานทำงานเหมือนกับว่าเจ้าของเวิร์กสเตชันเริ่ม PowerShell และรันสคริปต์

นี่อาจไม่ใช่สิ่งที่คุณต้องการ ประการหนึ่ง ชุดสิทธิ์ที่มีผลใช้งานเพื่อเรียกใช้ SDK cmdlets ขึ้นอยู่กับบัญชีที่ลงชื่อเข้าใช้ หากบัญชีที่ลงชื่อเข้าใช้มีบทบาทผู้ดูแลระบบ Entra ID สิทธิ์ที่มีอยู่จะครอบคลุมมากกว่าเมื่อมีผู้อื่นลงชื่อเข้าใช้ เนื่องจากสิทธิ์ที่ยินยอมสำหรับแอป SDK ได้รับการมอบหมาย ซึ่งหมายความว่าเมื่อ SDK cmdlets ทำงาน พวกเขาสามารถเข้าถึง ข้อมูลที่มีให้สำหรับผู้ใช้นั้นและไม่มีอะไรเพิ่มเติม

ใช้แอพที่ลงทะเบียน Entra ID

แนวทางที่ดีกว่าและปลอดภัยกว่าคือการใช้แอปที่ลงทะเบียน Entra ID และเชื่อมต่อ SDK กับแอปโดยใช้ใบรับรอง ซึ่งช่วยให้สามารถควบคุมชุดสิทธิ์อนุญาตที่มีให้กับสคริปต์ได้แม่นยำยิ่งขึ้น นอกจากนี้ยังหมายความว่าสคริปต์ใช้สิทธิ์ของแอปพลิเคชันแทนสิทธิ์ที่ได้รับมอบหมาย สุดท้ายจะลบการพึ่งพาบัญชีที่ลงชื่อเข้าใช้เฉพาะออก อาการคลาสสิกของปัญหาที่เกิดจากบัญชีใดบัญชีหนึ่งคือเมื่อมีคนรายงานว่าไม่มีข้อมูลเมื่อพวกเขาเรียกใช้สคริปต์ซึ่งทำงานได้อย่างสมบูรณ์เมื่อมีบุคคลอื่น (บัญชีที่มีบทบาทผู้ดูแลระบบ) เรียกใช้โค้ด

หากต้องการเปลี่ยนเป็นการตรวจสอบสิทธิ์ตามใบรับรอง ให้ทำตามคำแนะนำในบทความนี้เพื่อสร้างใบรับรอง อัปโหลดไปยังแอป และเชื่อมต่อกับคำสั่ง เช่น:

Connect-MgGraph -TenantId "a562313f-14fc-43a2-9a7a-d2e27f4f3478" -AppId "45b178af-aaa3-4728-956f-35425fe5b6e6" -CertificateThumbprint "A6918A18EBBED10AF6B0D873A688F743020C742F"

ในกรณีนี้ สิทธิ์กราฟเดียวที่ต้องการคือ Directory.Read.All นั่นเป็นการอนุญาตที่ปลอดภัยพอสมควรในการมอบหมายให้กับแอป และดีกว่าการรันโค้ดด้วยชุดสิทธิ์อนุญาตเต็มรูปแบบที่ได้รับจากบริการหลักของ SDK

ยิ่งไปกว่านั้น Dump Task Scheduler

หากคุณเปลี่ยนไปใช้แอปที่ลงทะเบียน Entra ID เพื่อรันงานที่กำหนดเวลาไว้ ความก้าวหน้าตามธรรมชาติคือการดัมพ์ Windows Task Scheduler โดยสมบูรณ์และแทนที่ด้วย Azure Automation ข้อเสียคือจำเป็นต้องสมัครสมาชิก Azure เพื่อชำระค่าใช้จ่าย (โดยปกติจะมีขนาดเล็ก) ที่เกิดขึ้นจากการเรียกใช้สคริปต์ (runbook) ข้อดีคือ:

• ความสามารถในการใช้ข้อมูลประจำตัวที่มีการจัดการที่ปลอดภัยเพื่อเชื่อมต่อกับตำแหน่งข้อมูล Microsoft 365 เช่น SDK, Exchange Online และ Teams การรับรองความถูกต้องตามใบรับรองพร้อมใช้งานสำหรับปลายทางอื่นๆ
• ลบการขึ้นต่อกันที่สคริปต์ทำงานบนเวิร์กสเตชันเฉพาะ
• Azure Automation รองรับ RBAC สำหรับแอปพลิเคชันเพื่อจำกัดการเข้าถึงกล่องจดหมาย Exchange Online
• กลไกการจัดตารางเวลาที่แข็งแกร่งสำหรับ runbooks
• Microsoft ใช้ความพยายามในการพัฒนา Azure Automation มากกว่า Windows Task Scheduler (ซึ่งดูเหมือนจะไม่ได้รับความรักมากนักตั้งแต่ Windows 2003)

ต่อไปนี้เป็นตัวอย่างที่ดีของ Runbook ที่ใช้งานได้เต็มรูปแบบเพื่อตรวจสอบบันทึกการตรวจสอบแบบรวมสำหรับเหตุการณ์ที่มีลำดับความสำคัญสูงที่อาจระบุเมื่อผู้โจมตีพยายามประนีประนอมผู้เช่า

การปรับสคริปต์สำหรับ Azure Automation

วิธีการปกติในการรับสคริปต์และปรับให้ทำงานบน Azure Automation คือ:

• เลือกบัญชี Automation (หรือสร้างบัญชีในพอร์ทัล Azure)
• สร้าง runbook สำหรับสคริปต์ PowerShell
• ตรวจสอบให้แน่ใจว่าบริการหลักสำหรับบัญชี Azure Automation ได้รับความยินยอมให้ใช้สิทธิ์ที่จำเป็นทั้งหมด
• ปรับโค้ดสำหรับ Azure Automation
• ทดสอบโค้ดเพื่อให้แน่ใจว่าทำงานได้อย่างถูกต้อง
• เชื่อมโยง runbook กับกำหนดการ Azure Automation

โดยปกติแล้ว การปรับโค้ดจะมุ่งเน้นไปที่สองส่วน: การรับรองความถูกต้อง (การใช้ข้อมูลประจำตัวที่ได้รับการจัดการเป็นแนวทางที่ดีที่สุด) และเอาต์พุต ตัวอย่างเช่น สคริปต์ตัวอย่างจะสร้างไฟล์ CSV และจัดเก็บไว้ในไดรฟ์ภายในเครื่อง เนื่องจาก Azure Automation เรียกใช้สคริปต์บนเซิร์ฟเวอร์ที่ไม่มีส่วนหัว จึงต้องใช้แนวทางอื่น เช่น การสร้างไฟล์เอาต์พุตใน SharePoint Online หรือส่งเป็นไฟล์แนบอีเมล

การย้ายสคริปต์ไปยัง Azure Automation ต้องใช้เวลาและความคงอยู่ การดีบักทำได้ยากกว่าและบางครั้งก็ทำให้สับสน แต่ท้ายที่สุดแล้วมันก็คุ้มค่าและนั่นคือสิ่งสำคัญ ดัมพ์ Task Scheduler และย้ายไปยังแพลตฟอร์มที่ทันสมัยยิ่งขึ้น

การวางแผนและการรวมแพลตฟอร์มการย้าย Microsoft

ลดความซับซ้อนในการวางแผนการย้ายข้อมูล เอาชนะความท้าทายในการย้ายข้อมูล และดำเนินโครงการให้เสร็จเร็วขึ้น พร้อมทั้งลดต้นทุน ความเสี่ยง และการหยุดชะงักให้กับผู้ใช้