פרוטוקולים לשיתוף קבצים כמו SMB (CIFS), NFSv3 עם קבוצות מורחבות ו-NFSv4, שמשתמשים ביישות אבטחה, מסתמכים על שירותי ספריות חיצוניים כדי לספק מידע על זהות המשתמש. השירות NetApp Volumes מסתמך על Microsoft Active Directory לשירותי ספרייה. Active Directory מספק שירותים כמו שרתי LDAP לחיפוש אובייקטים – כמו משתמשים, קבוצות, חשבונות מכונה – שרתי DNS לפתרון שמות מארחים ושרתי Kerberos לאימות.
מידע נוסף זמין במאמר שיטות מומלצות להפעלת Active Directory ב-Google Cloud.
NetApp Volumes לא תומך ב-Managed Microsoft Active Directory של Google Cloud.
תרחישים לדוגמה
במקרים שמתוארים בקטעים הבאים, NetApp Volumes משתמש ב-Active Directory.
שירות דומיין SMB
Active Directory הוא שירות הדומיין המרכזי עבור SMB. פרוטוקול SMB משמש לאימות ולחיפושי זהות של משתמשים וקבוצות. NetApp Volumes מצטרפים לדומיין כחברים ולא תומכים ב-SMB במצב קבוצת עבודה.
תמיכה מורחבת בקבוצות ב-NFSv3
ב-NFSv3 עם תמיכה מורחבת בקבוצות, Active Directory מספק את שרת ה-LDAP שנדרש לחיפוש אובייקטים כמו משתמשים, קבוצות או חשבונות מכונה. בפרט, נדרש שרת LDAP שתואם ל-RFC2307bis כדי לבצע חיפושים של מזהי משתמשים ומזהי קבוצות. התמיכה ב-LDAP מופעלת במאגרי אחסון במהלך יצירת המאגר.
תמיכה מורחבת בקבוצות מתעלמת מכל מזהי הקבוצות שנשלחים על ידי לקוח ה-NFS בקריאת NFS. במקום זאת, היא לוקחת את מזהה המשתמש של הבקשה ומחפשת את כל מזהי הקבוצות של מזהה המשתמש הנתון משרת ה-LDAP כדי לבדוק את הרשאות הקובץ.
מידע נוסף מופיע במאמר בנושא ניהול מאפייני LDAP RFC2307bis POSIX.
מיפוי של NFSv4.x security principal למזהה משתמש ולמזהה קבוצה
ב-NFSv4.x, נעשה שימוש ב-Active Directory כדי למפות את הגורמים המורשים לאימות למזהי משתמשים ולמזהי קבוצות. NFSv4 משתמש במודל אימות שמבוסס על משתמשים. באימות שמבוסס על חשבונות ראשיים, המשתמשים מזוהים על ידי חשבונות ראשיים לאבטחה, שהפורמט שלהם הוא user@dns_domain (ראו https://www.rfc-editor.org/rfc/rfc7530.html#section-19), במקום על ידי מזהי משתמשים ומזהי קבוצות. כדי למפות ישויות אבטחה למזהי משתמשים ולמזהי קבוצות כשניגשים לנפח באמצעות פרוטוקול NFSv4.x, נפחי NetApp דורשים שרת LDAP שתואם ל-RFC2307bis. שרת ה-LDAP היחיד שנתמך הוא Active Directory. התמיכה ב-LDAP מופעלת במאגרי אחסון במהלך יצירת המאגר.
כדי להשתמש בנציגי אבטחה, לקוח ה-NFS והשרת צריכים להתחבר לאותו מקור LDAP, וצריך להגדיר את הקובץ idmapd.conf בלקוח. מידע נוסף על הגדרת הקובץ idmapd.conf זמין במאמר Ubuntu Manpage: idmapd.conf - configuration file for libnfsidmap.
שם הדומיין של Active Directory משמש ל-dns_domain. user הוא השם של משתמשים ב-Active Directory. משתמשים בערכים האלה כשמגדירים את מאפייני ה-POSIX של LDAP.
כדי להשתמש ב-NFSv4.1 בלי להגדיר מיפוי מזהים ולהשתמש רק במזהי משתמשים ובמזהי קבוצות בדומה ל-NFSv3, אפשר להשתמש במזהים מספריים כדי להתעלם מבעלי הרשאות אבטחה. NetApp Volumes תומך במזהים מספריים, ולקוחות NFS הנוכחיים משתמשים במזהים מספריים כברירת מחדל אם לא מוגדר מיפוי מזהים.
NFSv4.x עם Kerberos
אם משתמשים ב-Kerberos, חובה להשתמש ב-Active Directory כשרת LDAP לחיפושים של ישויות אבטחה. משתמשים ב-principals של Kerberos כמזהי אבטחה. Active Directory משמש גם כמרכז להקצאת מפתחות (KDC) של Kerberos. כדי שהפעולה הזו תתבצע, צריך לצרף למאגר מדיניות של Active Directory שמכילה הגדרות של Kerberos, ולהפעיל תמיכה ב-LDAP במאגר אחסון במהלך יצירת המאגר.
מידע נוסף זמין במאמר בנושא יצירת מאגר אחסון.
גישת LDAP ל-Active Directory
בתרחישי שימוש ב-NFS, Active Directory משמש כשרת LDAP. NetApp Volumes מצפה לנתוני זהות באמצעות סכימת RFC2307bis. Active Directory כבר מספק את הסכימה הזו, אבל צריך לוודא שמאכלסים את המאפיינים הנדרשים של המשתמשים והקבוצות.
NetApp Volumes משתמש בפרטי הכניסה שסופקו ממדיניות Active Directory כדי לבצע איגוד מול LDAP באמצעות חתימת LDAP.
אם לא נמצא משתמש או קבוצה, הגישה נדחית.
שמירה במטמון של מאפיינים
מערכת NetApp Volumes שומרת במטמון את התוצאות של שאילתות LDAP. בטבלה הבאה מפורטות הגדרות אורך החיים (TTL) של מטמון ה-LDAP. אם המטמון מכיל נתונים לא תקינים בגלל הגדרות שגויות שאתם מנסים לתקן, אתם צריכים לחכות עד שהמטמון יתרענן כדי שהשינויים שלכם ב-Active Directory יזוהו. אחרת, שרת ה-NFS ימשיך להשתמש בנתונים הישנים כדי לאמת את הגישה, וסביר להניח שהתוצאה תהיה הודעות על דחיית הרשאה בלקוח. אחרי תקופת ה-TTL, הרשומות מתיישנות כדי שלא יישארו רשומות לא עדכניות. בקשות Lookup שלא נמצאו נשמרות למשך דקה אחת של TTL כדי למנוע בעיות בביצועים.
| מטמון | זמן קצוב לתפוגה שמוגדר כברירת מחדל |
|---|---|
| רשימת חברים בקבוצה | TTL של 24 שעות |
| קבוצות Unix (GID) | TTL של 24 שעות, TTL שלילי של דקה אחת |
| משתמשי Unix (מזהה משתמש) | TTL של 24 שעות, TTL שלילי של דקה אחת |
טופולוגיות של בקרי דומיין ב-Active Directory
אחרי שמתחברים בהצלחה לבקרי הדומיין של Active Directory, אפשר להשתמש בפרוטוקולים הבאים לשיתוף קבצים:
- SMB
- NFSv3 עם קבוצות מורחבות
- NFSv4
בקטעים הבאים מוצגות טופולוגיות פוטנציאליות שונות. בתרשימים מוצג רק בקר הדומיין שמשמש את NetApp Volumes. בקרי דומיין אחרים לאותו דומיין מוצגים רק במקומות שבהם הם נדרשים.
מיקרוסופט ממליצה לפרוס לפחות שני בקרי דומיין (DC) כדי להבטיח יתירות וזמינות.
בקר דומיין של Active Directory באותו אזור כמו נפחי NetApp Volumes
בתרשים הבא מוצג מצב הפריסה הפשוט ביותר, בקר דומיין באותו אזור כמו נפחי NetApp Volumes.
בקרי דומיין של Active Directory בכמה אזורים באמצעות אתרי AD
אם אתם משתמשים בנפחים של NetApp Volumes בכמה אזורים, מומלץ למקם לפחות בקר דומיין אחד בכל אזור. השירות מנסה לבחור באופן אוטומטי את בקר הדומיין הטוב ביותר לשימוש, אבל מומלץ לנהל את בחירת בקר הדומיין באמצעות אתרי AD.
בקר דומיין של Active Directory ברשת מקומית
יש תמיכה בשימוש בבקר דומיין מקומי דרך VPN, אבל יכול להיות שהדבר ישפיע לרעה על האימות של משתמשי הקצה ועל הביצועים של הגישה לקבצים. חשוב לוודא שלא מוסיפים עוד קפיצות של VPC Peering לנתיב הרשת.
שיקולים לגבי בקרי דומיין מקומיים
חיבורים ל-DC מקומיים משתמשים ב-TCP וב-IP. החיבורים האלה נכשלים לעיתים קרובות בגלל המגבלות הבאות:
קישור (peering) בין רשתות VPC שכנות: ל-NetApp Volumes יש גישה רק למרכזי נתונים שנמצאים ב-VPC של מאגר האחסון או שמחוברים אליו באמצעות VPN. ל-NetApp Volumes אין גישה למרכזי נתונים ברשתות VPC אחרות, כולל רשתות VPC שמקושרות לרשת ה-VPC שמחוברת למאגר האחסון.
חומות אש: צריך לאפשר ל-NetApp Volumes ליצור קשר עם מרכזי הנתונים שלכם. מידע נוסף על כללי חומת האש לגישה ל-Active Directory
בקר דומיין של Active Directory ברשת VPC אחרת
אי אפשר למקם את בקר הדומיין ברשת VPC אחרת כי קישור VPC ב-Google Cloud לא מאפשר ניתוב טרנזיטיבי. אפשרות אחרת היא לחבר NetApp Volumes לרשת VPC משותפת שמארחת את בקרי הדומיין של Active Directory. אם מצרפים NetApp Volumes לרשת VPC משותפת, מבחינת הארכיטקטורה, התרחיש הזה הופך לאחד מהתרחישים שמתוארים בקטעים הקודמים.
ניהול בחירות של DC באמצעות אתרי AD
כדי לייצג את המיקומים בפועל של מרכזי הנתונים, המשרדים וטופולוגיית הרשת בצורה הכי מדויקת שאפשר, צריך למקם את בקרי הדומיין באותו אזור כמו נפחי האחסון ולהגדיר אתר Active Directory לאזור הזה.
כש-NetApp Volumes מחובר לדומיין שלכם, השירות משתמש בגילוי מבוסס-DNS כדי למצוא את בקרי הדומיין המתאימים לתקשורת. על סמך התוצאות של הגילוי, השירות שומר רשימה של מרכזי נתונים תקפים שאפשר להתחבר אליהם, ומשתמש במרכז הנתונים עם זמן האחזור הנמוך ביותר.
כשמציינים אתר בהגדרות Active Directory של NetApp Volumes, אפשר להגביל את רשימת בקרי הדומיין לאלה שצוינו באתר AD.
אם הבחירה האוטומטית של בקר תחום נכשלת, שימוש באתרים של AD יכול לעזור לפתור את הבעיה:
פורסים לפחות בקר דומיין אחד באזור NetApp Volumes ומחברים אותו ל-Active Directory הקיים.
יוצרים אתר Active Directory לאזור Google Cloud ומציבים בו את בקרי הדומיין המתאימים.
משתמשים באתר Active Directory כשמגדירים חיבורים ל-Active Directory.
כדי לאמת באופן ידני את רשימת בקרי הדומיין הפוטנציאליים שהשירות יכול להשתמש בהם, אפשר לעיין במאמר בנושא זיהוי בקרי דומיין של Active Directory שנעשה בהם שימוש ב-NetApp Volumes
מידע נוסף זמין במאמר Active Directory: שיקולי תכנון ושיטות מומלצות.