בקרי הדומיין שמופעלים על ידי שירות מנוהל ל-Microsoft Active Directory חושפים מספר שירותים, כולל LDAP, DNS, Kerberos ו-RPC. בהתאם לתרחישי השימוש, יכול להיות שמכונות וירטואליות (VM) שנפרסו ב- Google Cloud, וגם מכונות שפועלות במקום, יצטרכו גישה לשירותים האלה כדי להשתמש ב-Active Directory.
כדי לצמצם את שטח הפנים של בקרים של דומיין ומכונות וירטואליות, כדאי להשתמש בחומות אש כדי למנוע תקשורת ברשת שלא נדרשת באופן מוחלט. במאמר הזה מוסבר איך להגדיר חומות אש כדי להתאים לתרחישי שימוש נפוצים ב-Active Directory, תוך מניעת תקשורת אחרת ברשת.
כניסה לעומת אימות
למרות שהמונחים 'כניסה' ו'אימות' משמשים לעיתים קרובות לסירוגין, יש להם משמעויות שונות בהקשר של אבטחת Windows. כניסה לחשבון מתארת את התהליך שמתרחש במערכת שלמשתמש יש גישה אליה. לעומת זאת, אימות מתבצע על ידי המחשב שבו נמצא החשבון של המשתמש.
כשמשתמשים בחשבון מקומי כדי להתחבר למחשב, גם ההתחברות וגם האימות מתבצעים על ידי מחשב היעד. בסביבת Active Directory, נפוץ יותר להשתמש במשתמש דומיין כדי להתחבר. במקרה כזה, הכניסה לחשבון מטופלת על ידי מכונת היעד, והאימות מתבצע על ידי בקר הדומיין.
כדי לבצע אימות, לקוח יכול להשתמש ב-Kerberos או ב-NTLM . אחרי שהלקוח מאומת, מכונת היעד צריכה לעבד את הכניסה. בהתאם לסוג הכניסה שהלקוח ביקש, יכול להיות שיידרש אינטראקציה נוספת עם בקרי הדומיין באמצעות פרוטוקולים כמו Kerberos, NTLM, LDAP, RPC או SMB .
אימות וכניסה לחשבון דורשים פרוטוקולים שונים, ולכן חשוב להבחין בין שני המושגים האלה כשמזהים את ההגדרה הנכונה של חומת האש.
תרחישים נפוצים לדוגמה
בקטעים הבאים מתוארים תרחישי שימוש נפוצים לגישה לשירות מנוהל ל-Microsoft AD, ומוצגים כללי חומת האש שצריך להגדיר לכל תרחיש שימוש.
אם אתם לא מתכננים לשלב את Managed Microsoft AD עם Active Directory מקומי, אתם צריכים לקרוא רק את החלק הראשון במאמר הזה, גישה ל-Managed Microsoft AD מתוך ה-VPC. אם אתם מתכוונים ליצור יחסי אמון בין שירות מנוהל ל-Microsoft AD לבין Active Directory מקומי, המאמר כולו רלוונטי.
אתם יכולים להשתמש ביומני הרישום של כללי חומת האש כדי לנתח אם נדרשות יציאות נוספות. כי בכלל הדחייה המשתמעת של תעבורת נתונים נכנסת, רישום ביומן מושבת. לכן, קודם צריך ליצור כלל מותאם אישית של חומת אש עם עדיפות נמוכה, שדוחה את כל תעבורת הנתונים הנכנסת, אבל רישום ביומן של חומת האש מופעל בו. אם הכלל הזה מוגדר, כל ניסיון חיבור שנכשל גורם לפרסום רשומה ביומן ב-Stackdriver. כללים של חומת אש יכולים ליצור נפח גדול של יומנים, לכן מומלץ להשבית שוב את הרישום ביומן של חומת האש אחרי השלמת הניתוח.
גישה לשירות מנוהל ל-Microsoft AD מתוך ה-VPC
כשמשתמשים ברשת ברירת המחדל כדי לפרוס שירות מנוהל ל-Microsoft AD, לא נדרש שום שינוי נוסף בהגדרות כדי לאפשר למכונות וירטואליות ב-VPC לגשת ל-Active Directory.
אם התאמתם אישית את הגדרת ה-VPC או את כללי חומת האש, אתם צריכים לוודא שהגדרת חומת האש עדיין מאפשרת תקשורת עם שירות מנוהל ל-Microsoft AD. בקטעים הבאים מתוארים כללים של חומת אש שאולי תצטרכו ליצור.
תרגום שם הדומיין
כשמכונה וירטואלית מנסה לפתור שם DNS, היא לא שולחת שאילתה ישירות לבקר דומיין. במקום זאת, שאילתת ה-DNS נשלחת לשרת המטא-נתונים, שהוא שרת ה-DNS שמוגדר כברירת מחדל למכונות וירטואליות ב-Compute Engine. לאחר מכן, שרת המטא-נתונים מעביר את השאילתה לאזור העברת DNS פרטי ב-Cloud DNS שנוצר על ידי שירות מנוהל ל-Microsoft AD. אזור ההעברה הזה מעביר את השאילתה לבקר הדומיין המתאים.
אין צורך להגדיר כללי חומת אש כדי להפעיל את תרחיש השימוש הזה. התקשורת עם Cloud DNS תמיד מותרת למכונות וירטואליות ב-VPC, ושירות מנוהל ל-Microsoft AD מאפשר כברירת מחדל העברה של בקשות DNS מ-Cloud DNS .
אימות ל-VM באמצעות Kerberos
משתמש שהתחבר למכונה וירטואלית אחת עשוי להזדקק לגישה לשירות שמופעל על ידי מכונה וירטואלית אחרת. לדוגמה, משתמש יכול לנסות לפתוח חיבור RDP, לגשת לשיתוף קבצים או לגשת למשאב HTTP שנדרש אימות כדי לגשת אליו.
כדי לאפשר למשתמש לעבור אימות למכונה הווירטואלית של השרת באמצעות Kerberos, המכונה הווירטואלית של הלקוח צריכה קודם לקבל כרטיס Kerberos מתאים מאחד הבקרים של שירות מנוהל ל-Microsoft AD.
כדי לאפשר למכונות וירטואליות לבצע אימות למכונה וירטואלית אחרת באמצעות Kerberos, צריך לאפשר את התקשורת הבאה באמצעות כללים של חומת אש:
| פעולה | מאת | אל | פרוטוקולים | |
|---|---|---|---|---|
| 1 | אישור | Client VM | Managed Microsoft AD subnet |
Kerberos (UDP/88, TCP/88) LDAP (UDP/389, TCP/389) |
| 2 | אישור | Client VM | Server VM | הפרוטוקול שמשמש לגישה למכונה הווירטואלית, כמו HTTP (TCP/80, TCP/443) או RDP (TCP/3389) |
| 3 | אישור | Server VM | Managed Microsoft AD subnet | לעיון ביומן העיבוד של הכניסות |
אימות ל-VM באמצעות NTLM
למרות שברוב המקרים, Windows מעדיף את Kerberos על פני NTLM, יכול להיות שלקוחות יצטרכו מדי פעם לחזור להשתמש ב-NTLM לאימות. אימות NTLM מסתמך על אימות מעבר, ולכן השרת צריך לתקשר עם אחד מבקרי הדומיין של שירות מנוהל ל-Microsoft AD כדי לאמת את המשתמש.
כדי לאפשר למכונות וירטואליות לאמת מכונות וירטואליות אחרות באמצעות NTLM, צריך להתיר את התקשורת הבאה בכללי חומת האש:
| פעולה | מאת | אל | פרוטוקולים | |
|---|---|---|---|---|
| 1 | אישור | Client VM | Server VM | הפרוטוקול שמשמש לגישה למכונה הווירטואלית, כמו HTTP (TCP/80, TCP/443) או RDP (TCP/3389) |
| 2 | אישור | Client VM | Managed Microsoft AD subnet | לעיון ביומן העיבוד של הכניסות |
צירוף לדומיין ועיבוד של התחברויות
כדי שמחשב יוכל לפעול כחבר בדומיין ולעבד התחברויות של משתמשים, הוא צריך להיות מסוגל לבצע אינטראקציה עם Active Directory. הקבוצה המדויקת של הפרוטוקולים שבהם נעשה שימוש תלויה בסוג הכניסה שלקוחות פרטיים מבקשים. כדי לתמוך בכל התרחישים הנפוצים, צריך לאפשר את השילוב הבא של פרוטוקולים.
| פעולה | מאת | אל | פרוטוקולים | |
|---|---|---|---|---|
| 1 | אישור | Server VM | Managed Microsoft AD subnet |
Kerberos (UDP/88, TCP/88) NTP (UDP/123) RPC (TCP/135, TCP/49152-65535) LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) LDAP GC (TCP/3268) |
בנוסף, בהתאם לתרחיש השימוש הספציפי שלכם, יכול להיות שתרצו גם לאפשר את הפרוטוקולים הבאים:
| פעולה | מאת | אל | פרוטוקולים | |
|---|---|---|---|---|
| 1 | אישור | Server VM | Managed Microsoft AD subnet |
שינוי סיסמה ב-Kerberos (UDP/464, TCP/464) LDAP מאובטח (TCP/636, TCP/3269) |
ניהול שירות מנוהל ל-Microsoft AD
כדי לנהל את שירות מנוהל ל-Microsoft AD, צריך להשתמש במכונה וירטואלית שמצורפת לדומיין. כדי להשתמש בכלים כמו Active Directory Administrative Center במכונה הווירטואלית הזו, המכונה הווירטואלית צריכה גם לקבל גישה לשירותי האינטרנט של Active Directory שנחשפים על ידי בקרי הדומיין של שירות מנוהל ל-Microsoft AD.
| פעולה | מאת | אל | פרוטוקולים | |
|---|---|---|---|---|
| 1 | אישור | Admin VM | Managed Microsoft AD subnet | שירותי אינטרנט של AD (TCP/9389) |
חיבור של שירות מנוהל ל-Microsoft AD ל-Active Directory מקומי
כדי לקשר בין שירות מנוהל ל-Microsoft AD לבין Active Directory מקומי, צריך ליצור יחסי אמון בין יערות. בנוסף, צריך להפעיל את התרת שמות DNS בין Google Cloud לבין הסביבה המקומית.
יצירת אמון ואימות
כדי ליצור ולאמת יער מהימן, בקרי הדומיין של שירות מנוהל ל-Microsoft AD ובקרי הדומיין הבסיסיים של היער המקומי צריכים להיות מסוגלים לתקשר דו-כיוונית.
כדי לאפשר יצירה ואימות של יחסי אמון, צריך להגדיר את חומת האש המקומית כך שתאפשר תעבורת נתונים נכנסת ויוצאת שתואמת למאפיינים הבאים:
| פעולה | מאת | אל | פרוטוקולים | |
|---|---|---|---|---|
| 1 | אישור | AD מקומי | Managed Microsoft AD |
DNS (UDP/53, TCP/53) Kerberos (UDP/88, TCP/88) שינוי סיסמה ב-Kerberos (UDP/464, TCP/464) RPC (TCP/135, TCP/49152-65535) LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) |
| 2 | אישור | Managed Microsoft AD | AD מקומי |
DNS (UDP/53, TCP/53) Kerberos (UDP/88, TCP/88) שינוי סיסמה ב-Kerberos (UDP/464, TCP/464) RPC (TCP/135, TCP/49152-65535) LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) |
שירות מנוהל ל-Microsoft AD מוגדר מראש כך שיאפשר תעבורת נתונים שתואמת למאפיינים האלה, כך שלא צריך להגדיר כללי חומת אש נוספים ב-Google Cloud.
פענוח שמות DNS משרת מקומי Google Cloud
יש שתי דרכים לאפשר למכונות מקומיות לפתור שמות DNS בשירות מנוהל ל-Microsoft AD: העברת הרשאה ל-DNS והעברת DNS מותנית.
העברת הרשאה של DNS
דומיין ה-DNS שבו נעשה שימוש בשירות מנוהל ל-Microsoft AD עשוי להיות תת-דומיין של דומיין ה-DNS שבו נעשה שימוש בפריסה מקומית. לדוגמה, אתם יכולים להשתמש ב-cloud.example.com עבור שירות מנוהל ל-Microsoft AD, וב-example.com עבור פתרון מקומי. כדי לאפשר ללקוחות מקומיים לפענח את שמות ה-DNS של משאבי Google Cloud , אפשר להגדיר העברת DNS.
כשמשתמשים בהענקת הרשאות ל-DNS, כשמנסים לזהות את שם ה-DNS של Google Cloud משאב, קודם מתבצעת שאילתה בשרת DNS מקומי. שרת ה-DNS מפנה מחדש את הלקוח אל Cloud DNS, שבתורו מעביר את הבקשה לאחד מבקרי הדומיין של שירות מנוהל ל-Microsoft AD.
כדי לחשוף את Cloud DNS לרשתות מקומיות, צריך ליצור מדיניות שרתים נכנסת. המערכת תיצור כתובת IP להעברת הודעות נכנסות, שהיא חלק מה-VPC.
כדי להשתמש בכתובת של המעביר משרת מקומי, צריך להגדיר את חומת האש המקומית כך שתאפשר תעבורת נתונים יוצאת שתואמת למאפיינים שמופיעים בהמשך.
| פעולה | מאת | אל | פרוטוקולים | |
|---|---|---|---|---|
| 1 | אישור | AD מקומי | Managed Microsoft AD |
DNS (UDP/53, TCP/53) Kerberos (UDP/88, TCP/88) שינוי סיסמה ב-Kerberos (UDP/464, TCP/464) RPC (TCP/135, TCP/49152-65535) LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) |
| 2 | אישור | Managed Microsoft AD | AD מקומי |
DNS (UDP/53, TCP/53) Kerberos (UDP/88, TCP/88) שינוי סיסמה ב-Kerberos (UDP/464, TCP/464) RPC (TCP/135, TCP/49152-65535) LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) |
העברת DNS מותנית
דומיין ה-DNS שבו נעשה שימוש בשירות מנוהל ל-Microsoft AD לא יכול להיות תת-דומיין של דומיין ה-DNS שבו נעשה שימוש בפריסה מקומית. לדוגמה, אפשר להשתמש ב-cloud.example.com עבור שירות מנוהל ל-Microsoft AD בזמן שמשתמשים ב-corp.example.local במקום.
בתרחישים שבהם דומייני ה-DNS לא קשורים זה לזה, אפשר להגדיר העברת DNS מותנית ב-DNS של Active Directory המקומי. כל השאילתות שתואמות לשם ה-DNS שבו נעשה שימוש בשירות מנוהל ל-Microsoft AD יועברו ל-Cloud DNS.
כדי להשתמש בהעברת DNS מותנית, קודם צריך להגדיר מדיניות DNS שמאפשרת העברת DNS נכנסת. כדי להשתמש בכתובת המעביר שמתקבלת משרת מקומי, צריך להגדיר את חומת האש המקומית כך שתאפשר תעבורת נתונים יוצאת שתואמת למאפיינים שמופיעים בהמשך.
| פעולה | מאת | אל | פרוטוקולים | |
|---|---|---|---|---|
| 1 | אישור | AD מקומי | כתובת ה-IP להעברת DNS | DNS (UDP/53, TCP/53) |
בצד Google Cloud , יוצרים כלל לחומת האש כדי לאפשר תעבורת נתונים נכנסת שתואמת לקריטריונים האלה.
אין צורך להגדיר כללים של חומת אש כדי לאפשר תקשורת מ-DNS Forwarder אל Cloud DNS (2).
פענוח שמות DNS מקומיים מ- Google Cloud
שירות מנוהל ל-Microsoft AD משתמש בהעברת DNS מותנית כדי לפתור שמות DNS ביער המקומי. כדי לאפשר גם ללקוחות שפועלים ב- Google Cloud לפתור שמות DNS שמנוהלים על ידי Active Directory מקומי, אפשר ליצור אזור העברה פרטי ב-Cloud DNS DNS שמעביר שאילתות לבקרי דומיין מקומיים.
כדי להפעיל את הפתרון של שמות DNS מקומיים מ- Google Cloud, צריך להגדיר את חומת האש המקומית כך שתאפשר תעבורת נתונים נכנסת לפי הטבלה הבאה.
| פעולה | מאת | אל | פרוטוקולים | |
|---|---|---|---|---|
| 1 | אישור | Managed Microsoft AD | AD מקומי | DNS (UDP/53, TCP/53) |
| 2 | אישור | Cloud DNS (35.199.192.0/19) | AD מקומי | DNS (UDP/53, TCP/53) |
Google Cloud מאפשרת תעבורת נתונים יוצאת (egress) תואמת כברירת מחדל.
גישה למשאבים של שירות מנוהל ל-Microsoft AD מתוך רשת מקומית
אם שירות מנוהל ל-Microsoft AD מוגדר כך שהוא מהימן ליער המקומי, יכול להיות שתרצו שמשתמשים ומכונות מקומיים יוכלו לגשת למשאבים ביער שירות מנוהל ל-Microsoft AD.
אימות ל-VM משרת מקומי באמצעות Kerberos
משתמש שהתחבר למכונה מקומית עשוי לדרוש גישה לשירות שמופעל על ידי מכונה וירטואלית שפועלת ב- Google Cloud ושייכת ליער של שירות מנוהל ל-Microsoft AD. לדוגמה, משתמש יכול לנסות לפתוח חיבור RDP, לגשת לשיתוף קבצים או לגשת למשאב HTTP שנדרש אימות כדי לגשת אליו.
כדי לאפשר למשתמשים לבצע אימות ל-VM של השרת באמצעות Kerberos, מכונת הלקוח צריכה לקבל כרטיס Kerberos מתאים. כדי לעשות זאת, צריך לתקשר עם אחד מבקרי הדומיין המקומיים וגם עם אחד מבקרי הדומיין של שירות מנוהל ל-Microsoft AD.
כדי לאפשר למכונות וירטואליות מקומיות לבצע אימות באמצעות Kerberos, צריך להגדיר את חומת האש המקומית כך שתאפשר את תעבורת הנתונים היוצאת הבאה.
| פעולה | מאת | אל | פרוטוקולים | |
|---|---|---|---|---|
| 1 | אישור | מכונת לקוח (במקום) | Managed Microsoft AD subnet |
LDAP (UDP/389, TCP/389) Kerberos (UDP/88, TCP/88) |
| 2 | אישור | מכונת לקוח (במקום) | מכונה וירטואלית של שרת (Google Cloud) | הפרוטוקול שבו האפליקציה משתמשת, כמו HTTP (TCP/80, TCP/443) או RDP (TCP/3389) |
| 3 | אישור | Server VM | Managed Microsoft AD subnet | לעיון ביומן העיבוד של הכניסות |
בצד Google Cloud , יוצרים כללים של חומת אש כדי לאפשר תעבורת נתונים נכנסת (ingress) עבור (1) ו-(2). תנועת יציאה אל Managed Microsoft AD (3) מותרת כברירת מחדל.
אימות למכונה וירטואלית משרת מקומי באמצעות NTLM
כשמשתמשים ב-NTLM כדי לאמת משתמש מיער Active Directory מקומי למכונה וירטואלית של שרת שמצורפת ליער של שירות מנוהל ל-Microsoft AD, בקרי הדומיין של שירות מנוהל ל-Microsoft AD צריכים לתקשר עם בקרי הדומיין המקומיים.
כדי לאפשר למכונות וירטואליות מקומיות לבצע אימות באמצעות NTLM, צריך להגדיר את חומת האש המקומית כך שתאפשר תעבורת נתונים נכנסת ויוצאת באופן הבא.
| פעולה | מאת | אל | פרוטוקולים | |
|---|---|---|---|---|
| 1 | אישור | מכונת לקוח (במקום) | מכונה וירטואלית של שרת (Google Cloud) | הפרוטוקול שבו האפליקציה משתמשת, כמו HTTP (TCP/80, TCP/443) או RDP (TCP/3389) |
| 2 | אישור | Server VM | Managed Microsoft AD subnet | לעיון ביומן העיבוד של הכניסות |
| 3 | אישור | Managed Microsoft AD subnet | AD מקומי |
LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) |
בצד Google Cloud , יוצרים כללים של חומת אש כדי לאפשר תעבורת נתונים נכנסת (ingress) עבור (1). תנועת היציאה עבור (2) ו-(3) מותרת כברירת מחדל.
עיבוד של התחברויות למשתמשים ביער המקומי
כדי לעבד התחברות של משתמש ביער המקומי, מכונה וירטואלית צריכה להיות מסוגלת ליצור אינטראקציה עם Active Directory המקומי. הקבוצה המדויקת של הפרוטוקולים שבהם נעשה שימוש תלויה בסוג הכניסה שהלקוח ביקש. כדי לתמוך בכל התרחישים הנפוצים, צריך להגדיר את חומת האש המקומית כך שתאפשר תעבורת נתונים נכנסת שתואמת למאפיינים האלה.
| פעולה | מאת | אל | פרוטוקולים | |
|---|---|---|---|---|
| 1 | אישור | מכונה וירטואלית של שרת (Google Cloud) | רשת משנה של AD מקומי |
Kerberos (UDP/88, TCP/88) NTP (UDP/123) RPC (TCP/135, TCP/49152-65535) LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) LDAP GC (TCP/3268) |
בהתאם לתרחיש השימוש המדויק שלכם, יכול להיות שתרצו גם לאפשר את הפרוטוקולים הבאים.
- שינוי סיסמה ב-Kerberos (UDP/464, TCP/464)
- LDAP מאובטח (TCP/636, TCP/3269)
בצד של Managed Microsoft AD, תנועת היציאה המתאימה מותרת כברירת מחדל.
יכול להיות שלא תרצו לאפשר כניסה למכונות וירטואליות לניהול ממשתמשים ביער המקומי. אבל יש פעילות אחת שסביר להניח שתצטרכו לבצע במכונות וירטואליות אדמיניסטרטיביות, והיא ניהול של חברות בקבוצות. בכל פעם שמשתמשים בכלי לבחירת אובייקטים כדי להפנות למשתמש או לקבוצה מהיער המקומי, הכלי לבחירת אובייקטים ידרוש גישה לבקרי הדומיין המקומיים. כדי שהתהליך הזה יפעל, ל-VM האדמיניסטרטיבי צריכה להיות אותה גישה לבקרי הדומיין של Active Directory המקומיים, כמו הגישה שנדרשת לעיבוד של התחברויות של משתמשים ביער המקומי.
גישה למשאבי Active Directory בארגון מ- Google Cloud
אם היער המקומי שלכם מוגדר כך שהוא מהימן לשירות מנוהל ל-Microsoft AD, יכול להיות שתרצו שהמשתמשים משירות מנוהל ל-Microsoft AD יוכלו לגשת למשאבים מקומיים.
אימות ל-VM מקומי באמצעות Kerberos
משתמש שהתחבר למכונה וירטואלית שפועלת ב- Google Cloud ושמשתייכת ליער של שירות מנוהל ל-Microsoft AD, עשוי לדרוש גישה לשירות שניתן על ידי מכונה מקומית שמשתייכת ליער המקומי. לדוגמה, המשתמש יכול לנסות לפתוח חיבור RDP, לגשת לשיתוף קבצים או לגשת למשאב HTTP שנדרש אימות כדי לגשת אליו.
כדי לאפשר למשתמש לבצע אימות למכונה המקומית באמצעות Kerberos, המכונה הווירטואלית צריכה לקבל כרטיס Kerberos מתאים. כדי לעשות זאת, צריך קודם לתקשר עם אחד מהבקרי של שירות מנוהל ל-Microsoft AD, ואז עם בקרי הדומיין המקומיים.
כדי לאפשר למכונות וירטואליות מקומיות לבצע אימות באמצעות Kerberos, צריך להגדיר את חומת האש המקומית כך שתאפשר תעבורת נתונים נכנסת שתואמת למאפיינים שמופיעים בהמשך.
| פעולה | מאת | אל | פרוטוקולים | |
|---|---|---|---|---|
| 1 | אישור | מכונה וירטואלית של לקוח (Google Cloud) | Managed Microsoft AD subnet |
Kerberos (UDP/88, TCP/88) LDAP (UDP/389, TCP/389) משתמע מעיבוד התחברויות |
| 2 | אישור | מכונה וירטואלית של לקוח (Google Cloud) | AD מקומי |
Kerberos (UDP/88, TCP/88) LDAP (UDP/389, TCP/389) |
| 3 | אישור | מכונה וירטואלית של לקוח (Google Cloud) | מכונת שרת (במקום) | הפרוטוקול שבו האפליקציה משתמשת, כמו HTTP (TCP/80, TCP/443) או RDP (TCP/3389) |
בצד Google Cloud , תנועת היציאה המתאימה מותרת כברירת מחדל.
אימות למכונה וירטואלית מקומית באמצעות NTLM
כשמשתמשים ב-NTLM כדי לאמת משתמש מיער מנוהל של Microsoft AD לשרת שמצורף ליער המקומי, בקרי הדומיין המקומיים צריכים להיות מסוגלים לתקשר עם בקרי הדומיין המנוהלים של Microsoft AD:
כדי לאפשר למכונות וירטואליות מקומיות לבצע אימות באמצעות Kerberos, צריך להגדיר את חומת האש המקומית כך שתאפשר תעבורה נכנסת ויוצאת שתואמת למאפיינים האלה.
| פעולה | מאת | אל | פרוטוקולים | |
|---|---|---|---|---|
| 1 | אישור | מכונה וירטואלית של לקוח (Google Cloud) | מכונת שרת (במקום) | הפרוטוקול שבו האפליקציה משתמשת, לדוגמה HTTP (TCP/80, TCP/443) או RDP (TCP/3389) |
| 2 | אישור | AD מקומי | Managed Microsoft AD subnet |
LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) |
בצד Google Cloud , תנועת היציאה (egress) של (1) ותנועת הכניסה (ingress) של (2) מותרות כברירת מחדל.
עיבוד של התחברויות למשתמשים ביער מנוהל של Microsoft AD
כדי לעבד התחברות של משתמש ביער של שירות מנוהל ל-Microsoft AD, מחשב שפועל בפריסה מקומית צריך להיות מסוגל ליצור אינטראקציה עם בקרי הדומיין של שירות מנוהל ל-Microsoft AD. הקבוצה המדויקת של הפרוטוקולים שנעשה בהם שימוש תלויה בסוג הכניסה שהלקוח ביקש. כדי לתמוך בכל התרחישים הנפוצים, צריך לאפשר את השילוב הבא של פרוטוקולים.
| פעולה | מאת | אל | פרוטוקולים | |
|---|---|---|---|---|
| 1 | אישור | מכונת שרת (במקום) | Managed Microsoft AD subnet |
Kerberos (UDP/88, TCP/88) NTP (UDP/123) RPC (TCP/135, TCP/49152-65535) LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) LDAP GC (TCP/3268) |
בהתאם לתרחיש השימוש המדויק שלכם, יכול להיות שתרצו גם לאפשר את הפרוטוקולים הבאים.
- שינוי סיסמה ב-Kerberos (UDP/464, TCP/464)
- LDAP מאובטח (TCP/636, TCP/3269)
חשוב לוודא שחומות האש המקומיות מאפשרות תנועת נתונים יוצאת (egress) שתואמת למאפיינים האלה. אין צורך להגדיר כללי חומת אש ב-Google Cloud כדי לאפשר תעבורת נתונים נכנסת (ingress) לשירות מנוהל ל-Microsoft AD.
במכונות ניהוליות, יכול להיות שלא תרצו לאפשר כניסה של משתמשים משירות מנוהל ל-Microsoft AD. פעילות אחת שסביר להניח שתצטרכו לבצע במכונות אדמיניסטרטיביות היא ניהול של חברויות בקבוצות. בכל פעם שמשתמשים בכלי לבחירת אובייקטים כדי להפנות למשתמש או לקבוצה משירות מנוהל ל-Microsoft AD, הכלי לבחירת אובייקטים ידרוש גישה לבקרי הדומיין המנוהלים של שירות מנוהל ל-Microsoft AD. כדי שהפעולה הזו תתבצע, למחשב הניהולי צריכה להיות אותה גישה לבקרי הדומיין של שירות מנוהל ל-Microsoft AD כמו הגישה שיש לו לעיבוד של התחברויות של משתמשים ביער של שירות מנוהל ל-Microsoft AD.