העברת אפליקציות מדור קודם ל-Azure: מתי לבחור ב-Microsoft Entra Domain Services ומתי בבקרי דומיין IaaS

By Mirko Peters · 2026-08-14

השוואה בין Microsoft Entra Domain Services לבקרי דומיין IaaS ב-Azure. מדריך לפשרות הארכיטקטוניות בהעברת אפליקציות מדור קודם.

Automatically translated with AI from the original post. Read the English original

בהעברה של אפליקציות Windows מדור קודם ל-Azure, ארכיטקטים נתקלים בדילמת זהויות קריטית: האם להקים מכונות וירטואליות של בקרי דומיין Active Directory מסורתיים, או להשתמש בשירותי ענן מנוהלים? המדריך הזה בוחן את הפשרות הארכיטקטוניות, עלות התפעול וההשלכות הכספיות של בחירה ב-Microsoft Entra Domain Services על פני בקרי דומיין IaaS מותאמים אישית לעומסי עבודה מדור קודם ב-Azure.

עיקרי הדברים

• Microsoft Entra Domain Services מספק יכולות של דומיין Windows מסורתי כשירות מנוהל, בלי שצוותי IT יצטרכו לפרוס, לעדכן או לשחזר מכונות וירטואליות של בקרי דומיין.
• פריסת בקרי דומיין IaaS ב-Azure מעניקה למנהלים שליטה מלאה, כולל גישת RDP והרשאות Domain Admin, אך מגדילה משמעותית את עומס התפעול.
• עומסי עבודה שתלויים ב-LDAP, Kerberos, NTLM או Group Policy יכולים לרוץ ב-Azure בצורה חלקה, באמצעות שכבת תאימות של דומיין מנוהל.
• Entra Domain Services אוכף מודל סנכרון זהויות חד-כיווני וקפדני, שבו רשומות המשתמשים חייבות להיות מנוהלות במקור הסמכות ולא ישירות בדומיין המנוהל.
• בחירת ארכיטקטורת הזהויות הנכונה תלויה במידה רבה בדרישות האפליקציה, כמו גישת כתיבה ב-LDAP ושינויים בסכמה.

דילמת ההעברה לענן של אפליקציות מדור קודם

העברת אפליקציה עסקית מדור קודם מחדר שרתים מקומי למכונה וירטואלית ב-Azure לא הופכת אותה אוטומטית ל-cloud-native. אפליקציות Windows רבות ומבוססות – כגון מערכות ERP ישנות, פלטפורמות פיננסיות ואפליקציות .NET מותאמות אישית – נבנו סביב Active Directory מסורתי. כשעומסי עבודה כאלה עוברים לענן, הם עדיין מצפים לשאול שירותי מדריך באמצעות LDAP, לאמת באמצעות כרטיסי Kerberos או להחיל הגדרות דרך Group Policy.

ארכיטקטים בענן נדרשים מיד לקבל החלטה אסטרטגית. אפשר לחבר את Azure Virtual Network בחזרה לבקרי הדומיין המקומיים באמצעות מנהרת VPN היברידית, אבל זה מוסיף השהיה ויוצר נקודת כשל יחידה מסוכנת אם הקישוריות נפסקת. לחלופין, אפשר להקים מכונות Windows Server חדשות לגמרי ב-Azure, להפוך אותן לבקרי דומיין וליצור יער או דומיין רפליקה חדשים לגמרי.

בניית מכונות וירטואליות משלכם של בקרי דומיין ב-Azure נותנת שליטה מלאה, אבל היא גם הופכת את צוות תשתיות הענן למנהלי Active Directory בפועל. אתם נושאים לבד באחריות מלאה לעדכוני מערכת ההפעלה, לניטור שכפול הספרייה, לתכנון שחזור מאסון ולאבטחת חשבונות עם הרשאות גבוהות מפני גניבת אישורים. עבור ארגונים שרוצים למזער את עומס התפעול ועדיין להפעיל אפליקציות מדור קודם, זה לעיתים קרובה עומס מיותר.

Entra Domain Services מול בקרי דומיין IaaS: ההבדלים הארכיטקטוניים המרכזיים

הבנת ההבדל הארכיטקטוני בין שימוש ב-Microsoft Entra Domain Services לבין בניית בקרי דומיין IaaS מותאמים אישית היא תנאי הכרחי לתכנון סביבות ענן Azure עמידות. Entra Domain Services פועל כשכבת תאימות מנוהלת. Microsoft מפעילה ומתחזקת את תשתית בקר הדומיין הבסיסית מאחורי הקלעים, ומבטיחה זמינות גבוהה, גיבויים אוטומטיים וסנכרון ברקע מול Entra ID.

כאשר אתם משתמשים ב-Entra Domain Services, מכונות הווירטואליות שלכם ב-Azure יכולות להצטרף לדומיין, להריץ שאילתות LDAP ולטפל בכניסות Kerberos או NTLM, בלי שהמהנדסים שלכם יצטרכו להתחבר בשולחן עבודה מרוחק לבקר דומיין. עם זאת, הפשרה של שירות מנוהל כזה כוללת ויתור על שליטה ניהולית ישירה. אין לכם גישה למערכת ההפעלה הבסיסית, אינכם יכולים לשנות את הסכמה של Active Directory, ואינכם מקבלים הרשאות Domain Admin או Enterprise Admin.

לעומת זאת, פריסת בקרי דומיין IaaS מעניקה לכם שליטה מלאה על ארכיטקטורת הספרייה. אפשר להרחיב את הסכמה, להגדיר יחסי אמון מותאמים אישית, להוסיף יחידות ארגוניות לפי הצורך וליישם אובייקטי מדיניות קבוצה ייעודיים ללא הגבלה. המחיר של הגמישות הזו הוא תחזוקה. הצוות שלכם צריך לנהל את מחזור החיים המלא של הדומיין, כולל בדיקות בריאות פרואקטיביות, דפרגמנטציה של מסד הנתונים ונהלי שחזור חירום אם בקר דומיין קורס.

פשרות תפעוליות ומגבלות ניהוליות

לפני שמתחייבים לגישת דומיין מנוהלת ב-Azure, מנהלי הענן צריכים להעריך בקפידה כיצד משתנות הפעולות השוטפות. בבקרי דומיין IaaS מותאמים אישית, לצוות שלכם יש שליטה גרעינית בכל היבט של הספרייה. אפשר לכתוב סקריפטים מותאמים ב-PowerShell לאוטומציה של משימות ניהול, להתקין סוכני אבטחה של צד שלישי ישירות על בקרי הדומיין, ולפתור שגיאות שכפול באמצעות כלים מקוריים כמו repadmin.

Microsoft Entra Domain Services מחליף את הגישה הידנית הזו במגבלות ניהוליות מובנות. הניהול מתבצע דרך קבוצה ייעודית בשם Entra Domain Services Administrators, באמצעות כלי ניהול המותקנים על מכונה וירטואלית נפרדת של Windows המצורפת לדומיין. אמנם אפשר ליצור יחידות ארגוניות מותאמות, לנהל רשומות DNS ולהחיל הגדרות נתמכות של מדיניות קבוצה, אך אתם מנותקים בתקיפות מהתשתית המרכזית.

יתר על כן, ניהול זהויות פועל לפי מודל סנכרון חד-כיווני מחמיר. זהויות של משתמשים וקבוצות זורמות ממקור הסמכות שלכם, בין אם מדובר במשתמשים שקיימים רק בענן ב-Entra ID ובין אם מזהויות מסונכרנות מ-Active Directory מקומי, אל הדומיין המנוהל. לעולם אל תנסו להתייחס ל-Entra Domain Services כספרייה ראשית לשינוי מאפייני משתמשים, מכיוון ששינויים כאלה לא יסתנכרנו בחזרה למעלה ובסופו של דבר ייכתבו מחדש.

מסגרת החלטה: בחירת הארכיטקטורה הנכונה

בחירת הגישה הנכונה דורשת הערכה של דרישות הטכניות הספציפיות של הארגון ושל אסטרטגיית הענן ארוכת הטווח שלו. אם המטרה העיקרית שלכם היא להעביר עומסי עבודה מדור קודם ל-Azure ולבטל את העלות התפעולית של הפעלת מכונות וירטואליות של Windows Server כבקרי דומיין, שירות מנוהל הוא כמעט תמיד הדרך המועדפת.

השתמשו ב-Microsoft Entra Domain Services כאשר:

• אתם מעבירים יישומים מדור קודם ל-Azure שדורשים חיפושי קריאה מסוג LDAP, Kerberos, NTLM או יכולות הצטרפות לדומיין.
• הארגון שלכם רוצה להימנע מהתקורה של עדכון, ניטור והתאוששות של מכונות וירטואליות מותאמות של בקר דומיין ב-Azure.
• אתם פועלים כארגון שמתבסס על הענן תחילה או על הענן בלבד, ואתם זקוקים לשירותי דומיין מסורתיים עבור קבוצת משנה קטנה של עומסי עבודה ב-Azure, בלי לבנות נוכחות מקומית.
• יישומים דורשים החלה סטנדרטית של מדיניות קבוצה או ניהול חשבונות שירות בתוך רשת וירטואלית מאובטחת.

בחרו בבקרי דומיין IaaS מותאמים אישית כאשר:

• היישומים המדור קודמים שלכם דורשים גישת כתיבה ב-LDAP או מחייבים שינויים בסכמה של Active Directory.
• ארכיטקטורת הארגון שלכם דורשת יערות מרובי דומיינים מורכבים, תצורות אמון מותאמות אישית, או גישה ישירה למערכות ההפעלה של בקרי הדומיין.
• צוות האבטחה שלכם מחייב שליטה ניהולית מלאה, כולל הרשאות Enterprise Admin ופריסה ישירה של כלי ביקורת ספרייה מיוחדים.

סיכום וצעדים הבאים

תכנון ארכיטקטורת זהות יציבה ב-Azure דורש התאמה של כל עומס עבודה למודל האימות המדויק שהוא צריך. בעוד שאפליקציות ענן מודרניות מסתמכות על Microsoft Entra ID לכניסה יחידה מאובטחת מבוססת אסימונים ולאימות רב-שלבי, עומסי עבודה מדור קודם דורשים לעתים קרובות שירותי דומיין מסורתיים של Windows. ההחלטה אם לפרוס שירותי ענן מנוהלים או לבנות תשתית IaaS משלכם קובעת את עומס התפעול המתמשך של הצוות שלכם.

לחקירה נוספת של הנושא ולשמיעת תובנות מומחים על אבטחת מקום העבודה המודרני, ארכיטקטורת ענן ואסטרטגיות Microsoft 365, האזינו לדיון המלא בפודקאסט. האזינו לפרק המלא כדי להעמיק בניהול הזהויות של Microsoft.

שאלות נפוצות

האם אפשר להתחבר בשולחן עבודה מרוחק (RDP) לבקרי דומיין כשמשתמשים ב-Entra Domain Services?

לא. Microsoft מנהלת במלואה את תשתית בקרי הדומיין הבסיסית, כלומר אין לכם גישת ניהול למערכת ההפעלה או אפשרות להתחבר לבקרי הדומיין דרך שולחן עבודה מרוחק.

מה קורה לסיסמאות המשתמשים בעת הפעלת Entra Domain Services?

כדי שאימות Kerberos ו-NTLM יצליח, Entra Domain Services דורש נתוני hash מיוחדים. במשתמשים הקיימים בענן בלבד, זה בדרך כלל אומר שהמשתמשים צריכים לשנות סיסמה לאחר הפעלת הדומיין המנוהל, כדי ליצור את ערכי ה-hash הקריפטוגרפיים הנדרשים.

האם אפשר לשנות את הסכמה של Active Directory ב-Entra Domain Services?

לא. מכיוון שמדובר בשירות ענן מנוהל במלואו, מנהלים אינם יכולים לשנות את הסכמה הבסיסית של Active Directory או לבצע פעולות כתיבה ב-LDAP שמשנות מבני מדריך ליבה.

כיצד זהויות מסתנכרנות ל-Entra Domain Services?

זהויות זורמות בכיוון אחד ממקור הסמכות שלכם (Entra ID למשתמשי ענן, או Active Directory מקומי דרך Entra Connect) אל הדומיין המנוהל. שינויים שנעשים ישירות בתוך הדומיין המנוהל אינם מסתנכרנים חזרה למקור.