מה משותף ב-Office 365 היברידיות?

כלאיים

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

הגדרה זו פועלת מעבר ל-' תכלת ' אך רוב עומסי העבודה בMicrosoft 365. אם אינך יודע מהו עומס עבודה, דרך אגב, זהו יישום הפועל בפלטפורמת הענן Microsoft 365 – Skype For Business Online, Exchange Online ו-SharePoint online הם דוגמאות. ' עומס עבודה ' מהווה דרך להבדיל אותם מהעמיתים המקומיים שלהם, שימושיים לשמירת הכתיבה והשיחה מפני התבלבלות.

תלבושות היברידיות להשתמש בכל המשאבים בהישג יד, ללא קשר למקום שבו הם חיים.

משאבי חומרה מבוססי-פרם במשותף

כל ההיברידים שאני מדבר עליהם כאן מחברים סביבת לקוח באמצעות האינטרנט לMicrosoft 365 (ולתכלת Active Directory – ברקע מכיוון שהיא פועלת כמדריך לMicrosoft 365 ). התשתית עשויה להישמע קשה לקביעת התצורה. למרות מה שאולי שמעת, הדבר אינו מתייחס לתואר אסטרולוגיה '. למעשה, רוב ההיברידים פועלים באותו אופן עם (ברוב המקרים) את אותן דרישות חומרה.

החל מ-2016 הנה הרכיבים שכל ההיברידיות צריכים. כאשר הדברים הם אופציונליים, אני אומר זאת.

כל הMicrosoft 365 עומסי עבודה היברידיים מכילים את הדברים הטובים האלה:

1. מספר שרתים במחשב ה-פרם (כגון חוות SharePoint או סביבת Skype for Business).

2. Active Directory מקומי שבו המשתמשים גרים או ממוקמים ' (במינוח של S4B).

3. שרת של תכלת Active Directory (התחבר ל-עמ) (שעשוי להיות ברשות עצמו או בשילוב עם שרת אחר, כגון WA-P). אפשרות זו מיוצגת על-ידי סמל ' סינכרון ' מאחר שחיבור ה-עמ-משמש לסינכרון חשבונות מהמתחם לענן בתוך היברידית.

4. [אופציונלי] שרת proxy הפוך, אשר, בכל הדוגמאות שלי, יהיה שרת Proxy של יישום אינטרנט (WA-P) server.

5. [אופציונלי] באפשרותך גם להשתמש בשרת האיחוד של Active Directory (או ADFS).

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

אם אין לך ADFS, אין לך דרישות תאימות שדורשות זאת, ואינך מעוניין במורכבות הנוספת, אל תשתמש בה. התחברות של ה-עמ ' מיועדת לבצע את המשימה (ומרווח השכפול כלפי מטה החל מ-3 שעות עד 30 דקות, שהוא שיפור שימושי לביצוע).

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

מה השרתים האלה עושים?

דלג על מקטע זה אם אתה כבר יודע מה השרתים האלה עושים.

רוב האנשים רגילים לפעולות של Active Directory (AD)--כיצד היא מונה משתמשים ואובייקטים בתחום או ביער (בין היתר) – ובמקרה של היברידית, זהו בסיס ביתי עבור המשתמשים שישוכפלו לענן של Microsoft. משימות הסינכרון (התחברות עם התחברות), ADFS ו-WA-P (הדוגמה שלנו-Proxy הפוכה) הן מעט חדשות יותר, ומרכזיות יותר כדי לעבד בקשות HTTPS היברידיות וזהויות אז בוא נדבר על האנשים האלה.

ADFS

כדי לסקור, העבודה של שירותי האיחוד של Active Directory היא לסייע לשני הצדדים של ההייבריד לזהות אחד את השני, ולפי שאני מתכוון, Microsoft 365 הולך להכיר ולבטוח בADFS (או באשכול ADFS) ששמו שייך שם תחום ציבורי מאומת. אפשרות זו מאפשרת כניסה יחידה. משמעות הדבר היא שכאשר משתמשים בעלי UPN משויך מופיעים כדי לאמת כנגד משאבים מקוונים, Microsoft 365 הולך להכיר את ה-upn שלהם ולאיזה שרת ADFS ספציפי לשלוח את המשתמשים לאימות. כאשר Heidi@contoso.com עובר את תהליך הכניסה עבור Exchange Online, Microsoft 365 מתכוון לשלוח בקשה לשטח שלך כדי שADFS יוכלו להתערב באימות ולאשר שהיא מי שהיא טוענת, או לדחות אותה. פעולה זו עשויה להתרחש במהירות אם הרשת והתצורה מאפשרות זאת. ADFS משמש אם ברצונך למנף כניסה יחידה: לאחר שהמשתמשים נכנסים להפעלת ADFS, השרת של ADFS מיירט בצורה שקטה את כל בקשות האימות האחרות (כפי שקורה בעת מעבר בין עומסי עבודה, למשל) כדי להזכיר Microsoft 365 שאתה עדיין מי שאתה אומר שאתה. מאחר שמחלקות IT מסוימות כוללות תאימות או הגדרות אבטחת מידע הדורשות שסיסמאות יישארו מקומיות וחלק לא, ADFS הוא אופציונלי.

Proxy הפוך

Web Access-Proxy הוא proxy לאחור (RP) שנבנה במערכות הפעלה של Windows Server מאז 2012 R2 שוחרר. Proxy הפוך עומד בנקודת היציאה שלך כדי לפעול בשמו של החווה שלך. יש לו ' צד ' הפונה לאינטרנט ומכיר את שם התחום הציבורי של הMicrosoft 365 ההיברידי, ו-' side ' שפונה לאינטרא-נט או לרשת ההיקפית שלך ויודע את שם התחום של המשאבים הפנימיים שלך (כגון כתובת ה-URL של אתר SharePoint שלך). היא מיירטת את כל הבקשות המגיעות לעסק שלך ומאפשרת לך לחסום יציאות, לצמצם את התעבורה שתקבל מהאינטרנט ולהסתיר את הכתובות הפנימיות וכתובות ה-Url של הרשת שלך מהעולם החיצון. כמו כל RPs, זהו proxy עבור שרתים פנימיים ברשת כאשר משתמשים מחוץ לרשת מנסים להגיע למשאב.

ההיברידיות של SharePoint 2013 משתמשים בפרוקסי לאחור כגון WA-P כדי ליירט תעבורה נכנסת (ממשתמשים ב-SPO ביצוע שאילתות לגבי אינדקס חיפוש מסוג ' משתמשים ' במקרה של פדרציית החיפוש), אך מאחר שההיברידים של SharePoint 2016 מניחים את האינדקס כולו בענן, הדור הבא אינו זקוק עוד לאחד (שהוא הסיבה היחידה לכך שהוא מסומן כאופציונלי בדיאגרמות). אך SharePoint 2013 אינו המקום היחיד שבו תראה proxy הפוך המשמש ליירוט תעבורה שלא התבקשה מהאינטרנט. Skype for Business 2016 משתמש באחד עם תצורת הקצוות שלו, ו-Exchange 2016 משתמש באחד הקצוות שלו. מאחר שמצבים מסוימים דורשים זאת, ווה-P הוא אופציונלי.

סינכרון

הגרפיקה שאני משתמש בה מציגה את האפשרות ' סנכרן ' עבור תכלת Active Directory Connect. באמת, הסינכרון המתבצע על-ידי התחברות כרוך במעבר המתמשך של משתמשים ו/או פרטי משתמש מתוך מקומי ובענן. התכונה ' חיבור ל-עמ ' יכולה לבצע שני דברים: היא משכפלת חשבונות משתמשים לתוך Microsoft 365 (שכפול), והיא יכולה לסנכרן פרטי סיסמה בMicrosoft 365 (באמת שהוא אינו מסנכרן את הסיסמה, אך hash שאינו הפיך המייצג את הסיסמה – סינכרון). אין צורך לסנכרן את הסיסמה שלך, אך הוא תמיד מסתנכרן (משכפל) את חשבונות המשתמש שלך מ-Active Directory (או גירסה מסוננת מסוימת של מדריך המשתמשים המקומי שלך)!

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

רכיבי היברידיות באינטרנט ובאינטרנט זמינים במשותף

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

• רשומות DNS ציבוריות

• רשויות אישורים ציבוריות

• תכלת Active Directory (עמ מ)

• Microsoft 365 (רשיונות/צוללות) ואשפים היברידיים Microsoft 365

• יחסי אמון של שרת לשרת (S2S)

• ניתוב מהיר ו/או תעבורת אינטרנט

• מודולי PowerShell

רשמי DNS ציבוריים, כגון GoDaddy, נהל ואפשר רישום של שמות תחומים. אם ברצונך להשתמש בהייבריד, יהיה עליך לרשום שם תחום עם DNS ציבורי (ייתכן שכבר תבוצע עבורך בחברות גדולות). שם תחום זה יתווסף לMicrosoft 365, אשר גם יאמת שאתה הבעלים של שם התחום הציבורי שאתה מוסיף.

באופן מסורתי, שם תחום ציבורי זה זהה לזה של ה-UPN של Active Directory המצורף למשתמשים היברידיים מקומיים, אך לא להיתפס בפירוט זה. עם הופעתו של התכונה ' onpremisessecurityidentifier ' ב-PowerShell, הממפה זהויות למזהה האבטחה המקומי, התאמת התחום הרשום בMicrosoft 365 עם ה-UPN של משתמשים ב-פרם אינו קריטי יותר כפי שהיה פעם. חשוב יותר לדעת שתצטרך שם תחום ציבורי שניתן להוכיח, שם תחום ציבורי זה יירשם בMicrosoft 365 ויייצג את נוכחותך Microsoft 365 משני צדי החיבור ההיברידי.

רשויות אישורים ציבוריים מעניקות לך אישורי SSL/TLS מהימנים כדי להצפין את תעבורת הרשת שלך. בכל עומס עבודה, תקשורת היברידית מתקיימת בחיבור מוצפן. תזדקק לאישור מרשות אישורים ציבורית באינטרנט. האישורים ' התקבל ' ו-SSL/TLS הם תרגול סטנדרטי ובדרך כלל קיימים תהליכי אישורים ציבוריים בחברות גדולות כדי להקל על פעולה זו. בחברות קטנות יותר, ייתכן שתצטרך להיוועץ באדם ה-IT שלך, בתיעוד Microsoft 365 ובספק שירותי האינטרנט שלך.

' תכלת Active Directory ', או ' תכלת לספירה ', נמצא ברקע בעת סינכרון/שכפול משתמשים מהמיקום המקומי למנוי הMicrosoft 365 שלך (מתחם הענן שלך). זהו מדריך הכתובות הפעיל בדיוק שנמצא בשימוש בתכלת רחב יותר. עוצמתי והתמזג בצורה חלקה בMicrosoft 365. תוכל לנהל את המשתמשים ורשיונות משתמשים במדריך זה. ניהול רשיונות ב- Microsoft 365 אינו מתבצע באופן אוטומטי על-ידי אשף היברידי כלשהו. הרשיונות עולים ללקוחות כסף, ולכן ההחלטה של מי ומספר הרשיונות שהתקבלו אינם מתבצעים באופן אוטומטי.

הMicrosoft 365 באופן מלא בחצי מהיברידית. הוא כולל אשפים היברידיים מקוונים לכל עומס עבודה. פעולה זו אינה יעילה במיוחד, אך זוהי הדרך שבה היברידית פועלת מתוך 2016 (או, במילים אחרות, בהתאם למהדורה של SharePoint Server 2016, Exchange Server 2016 ו-Skype for Business Server 2015, מקומי). אך זו אינה הדרך הפשוטה ביותר לקבוע את התצורה של כל הרכיבים בהייבריד. אשף היברידי יחיד שיאפשר ללקוחות לבחור אילו עומסי עבודה ליצור היברידי, ולצעוד דרך תהליך זה לכל עומס העבודה, וכן מרכז פקודות היברידי – לוח מחוונים ניהולי של Microsoft 365-שיכול לדווח אם טכנולוגיות הנמצאות בשימוש על-ידי כל היברידית הן תקינות ו/או שכבר אינן קיימות.

מה זה אומר? משמעות הדבר היא שכל אשף מבצע שלבים אלה, ולעתים קרובות יותר מפעם אחת. כל אשף מפעיל את OAuth (S2S trust) לדוגמה (נדבר על OAuth מאוחר יותר). אשפים מסוימים, כגון הבורר ההיברידי של עומס העבודה של SharePoint Online, התקן את OAuth ללא קשר לכפתור שעליו אתה לוחץ (עבור כל בחירה שאתה מבצע), בין אם נדרש OAuth עבור התרחיש ההיברידי. אשפים אחרים, כגון אשף היברידית של Exchange, הגדר את OAuth ברקע ופעם אחת בלבד.

אמון של S2S אינו צריך לחצות את האינטרנט, אך במקרה של היברידית, אמון זה חייב להתבצע. S2S אינו דומה לתחום או לאמון ביער. אין מספר גדול של יציאות לפתיחה ואין שילוב מעמיק יותר כדי ליצור בין ספריות פעילות. S2S בונה חיבור מהימן בין חוות SharePoint המקומית לבין חלק מענן הMicrosoft 365 שנקרא שירות בקרת הגישה או ACS (שרת הרשאות). יחסי האמון מבוססים על אישור SSL/TLS שחותם על אסימונים שהונפקו בשם משתמשים, שהמיקום המקומי שלך והMicrosoft 365 acs מסכימים באופן אמין – חשוב עליו כחמישה גבוהים בין משתמשים בגירסת ה-פרם (לבין שירות ה-PROXY של acs) ו-Acs של תכלת עבור כל משתמש חוקי הניגש לשירות. תקשורת אודות זהויות משתמשים (הסיבה לאמון זה) מתבצעת באמצעות HTTP/443.

כלאיים יכולים להשתמש בסוכריות בעלי חתימה עצמית או בשירות ציבורי כאן. חברות גדולות רבות יבחרו באישורים ציבוריים בשל הסטנדרטים הInfoSec שלהם – במידה רבה מכיוון שהתנועה חוצה/עשויה לחצות את האינטרנט, מקטע לא מהימן. עבור SharePoint כלאיים, אישור זה יכול להיות אישור חדש בחתימה עצמית או אחד שחולץ מתוך האישור המקומי לחתימת אסימון של SP STS. (אם השתמשת באישור חדש (ציבורי או בחתימה עצמית) במחשב היברידי של SharePoint, עליך להחליף את אישור החתימה של האסימון SP STS בכל הצמתים בחוות SharePoint.)

תעבורה ב-היברידית עוזבת את חברת הלקוח/ארגון, מעבירה את האינטרנט ומזינה את Microsoft Office/Microsoft Microsoft 365 Cloud. קיימת דרך לעקוף מקטע לא מהימן ולא מבוקר זה, והוא משתמש בנתיב אקספרס מבוסס ספק של ספק חיצוני מתוך החברה או הארגון שלך אל ענן הMicrosoft 365. המסלול המהיר עוקף את האינטרנט על-ידי הצעת חיבור WAN פרטי לענן של Microsoft. עם זאת, חשוב להבין שבמקרים שבהם ה-WAN סובל מכישלון, הנסיגה היא עדיין האינטרנט.

כל ההיברידים עושים שימוש במודולים של PowerShell עבור חלקים של כל אחד מההנהלה או התצורה. מרבית המודולים שתזדקק להם ייכללו ככל הנראה את מסייע הכניסה של Microsoft Online Servicesואת מודול הכניסה של תכלת Active Directory עבור Windows PowerShell. באפשרותך להכין שרתים לקביעת התצורה והניהול של ההיברידיות שלך לפני זמן על-ידי התקנת מודולי PowerShell נפוצים אלה הנמצאים בשימוש.

יציאות ופרוטוקולים במשותף

ההיברידים הם 1/2 המקומי שלך, ו-1/2 Microsoft 365 (תכלת סאס או PaaS hybrids אינם מכוסים במסמך זה). סביר להניח ששני החצאים פועלים ב-HTTPs, אך לכל הפחות, החצי הMicrosoft 365 הוא 100% HTTPs/מוצפן על-ידי אישורי TLS, ומשמעות הדבר היא שהיא פועלת מעל היציאה הרגילה 443. יהיה עליך לוודא שהאישור הציבורי משויך לתעבורה שתצא מנקודת היציאה שלך מדי. כלומר, תצטרך להתקין אישור במחשב שבו אתה מדבר בקצה הרשת – תעבורה זו תפעל מעל 443 ויוצפנו.

כל ההיברידים ישתמשו ב-443 (HTTPS) וב-53 (DNS), כברירת מחדל, עבור תעבורה משולבת. חלק משתמשים ביציאות נוספות, כגון port 25 (SMTP). אך המארז המורכב ביותר בעומסי עבודה היברידיים עבור יציאות הוא Skype for Business. למרבה המזל, היציאות מתועדות.

הפרוטוקול הבולט ביותר המשמש את כל ההיברידים (מלבד מכלאות המשמשות עבור בדיקת מידע של DNS, תעבורת HTTPS, SMTP ותקנים אחרים), is OAuth (Open הרשאות), הנמצא בשימוש גם בספריית האימות של Active Directory. הוא משמש כאשר משאב שרת בצד אחד של החיבור חייב לפעול בשמו של משתמש כדי לגשת למשאבים בשרת אחר, לעתים קרובות, בענן. משמעות הדבר שלפיה ניתן לאמוד את רמת הגישה של המשתמש לקובץ או למשאב עבור משתמש מאומת. פעולה זו נקראת גם ' אימות מודרני ' (למרות שOAuth מפנה להרשאות).

כל עומסי העבודה משתמשים ב-OAuth/S2S כאשר הם בתוך היברידית (אם לא עבור כל תכונה היברידית). אשפים היברידיים הגדירו בדרך כלל פרוטוקול שימושי זה באופן אוטומטי. עם זאת, אין איחוד של מאמץ זה לאורך עומסי העבודה, ללא דיווח על מצב OAuth ללקוח, ואין דרך מרוכזת לנהל משאב אוניברסלי זה מתוך 2016.

במקרים מסוימים, אשפים היברידיים מופעלים ב-OAuth כאשר הוא אינו נדרש (כגון בורר היברידי של SharePoint הופך את הנושא עבור OneDrive for Business לנתב מחדש לענן), או בכל מבחר של אפשרות היברידית באשף (שוב, ראה בורר היברידית של SharePoint) , או אפילו מחוץ לבורר ההיברידי בקבצי script של התקנה מותאמת אישית, כגון עם חיפוש היברידי בענן.

טבלת רכיבים משותפים בMicrosoft 365 היברידיות

כעת יש לנו רשימה של רכיבים נפוצים שנראים כך:

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

הערה בנושא ' אופציונלי '

חלק מרכיבים אלה מוגדרים לערך ' אופציונלי ', אך כיצד תוכל לדעת אם הם נחוצים? רכיבים מסוימים בMicrosoft 365 היברידיות הם אופציונליים באמת או לא אופציונליים ברחבי הלוח:

בתוך היברידית פועלת יש תכונות אחרות שמשתייכות לאזור אפור. ככל הנראה החשוב ביותר של אלה הוא S2S Trust/OAuth. אמון זה נבנה על-ידי כל אשף היברידי שנוצר בתוך Microsoft, והאמון נבנה כברירת מחדל, גם כאשר הוא אינו נדרש, כדי להעביר את ' הוראות עתידיות '. לאחר שתהפוך את היברידית באמצעות אשף, תכונה זו תהיה מופעלת. אך (כפי שראית מוקדם יותר) הוא אינו משמש כעת בכל המקרים.

Proxy הפוך (WA-P בדוגמה שלנו) נדרש בכל פעם שקיימת בקשה בלתי מבוקשת הנכנסת לארגון הלקוחות עבור נתונים או מידע (כגון בעת שימוש בסינכרון משולב של Office Web Apps או Office Online Server להצגת תצוגה מקדימה של מסמך בחיפוש תוצאות). הדבר נחוץ גם בעת פרסום נקודת קצה לתוך מפורז של החברה שלך, כגון כאשר Exchange משתמש ב-WA-P כשרת proxy של ADFS (ולכן, אם אתה משתמש ב-ADFS במסגרת היברידית של Exchange, עליך להשתמש ב-WA-P).

הקצוות דרושים כדי לשמור ערוצי תקשורת עקביים עבור שיחות צ'אט שוטפות ב-Skype for Business היברידי, וניתן להשתמש בהן כדי לנתב תעבורת SMTP לרשת מתוך היקף במסגרת היברידית של Exchange. כפי שהוזכר, ADFS משמש עבור כניסה יחידה.

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

* הבוחר היברידית של SharePoint עדיין מפעיל את OAuth, אך זה לטובת כל התצורות ההיברידיות העתידיות.