הקמת שרת EDGE והגדרת Anti-Spam << קורס אונליין חינם
Menu
עברית Русский Srbija العربية
מכללת פרקטיקיו
קורסים אונליין בעברית
עם הסרטונים שלנו פשוט להיות מקצוען

הקמת שרת EDGE והגדרת Anti-Spam

קורסים למנהלי רשת שלב 1 - טכנאי מחשבים - Help Desk שלב 2 - מנהל רשת מוסמך מיקרוסופט שלב 3 -מומחה בתקשורת מוסמך סיסקו שלב 4 - מומחה לינוקס ו-DevOps התמחות בשרתי דואר ווירטואליזציה התמחות ב-Storage התמחות במסדי נתונים - SQL התמחות בסייבר האקינג ואבטחת מידע קורסים נוספים למנהלי רשת
קורסי תכנות שלב 1 - יסודות התכנות שלב 2 - בניית אתרים צד שרת - Back End שלב 3 - בניית אתרים צד לקוח - Front End שלב 4 - פיתוח אפליקציות לאנדרואיד ואייפון התמחות במסדי נתונים – SQL קורסים מתקדמים בדיקות תוכנה - QA
סקר שוק נכון לתאריך – 01/09/2011
שליחת דואר ידנית בפרוטוקול SMTP POP3 / IMAP4 SMTP - Send Connector SMTP - Recieve Connector Hub Transport Rule Safty Net 2013 הקמת שרת EDGE והגדרת Anti-Spam Mail Flow - מעבר הודעות בין שרתי HUB מעקב אחרי הודעות מייל בין שרתי הארגון

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

צילמנו בסרטונים את כל ההרצאות של הקורס, כי ללמוד בכיתה לא נוח וגם יקר.
קורס בכיתה עולה מעל מ-17 אלף ₪ ואצלנו בסרטונים רק 350 ש"ח בחודש.
אם משהו לא ברור בסרטון תמיד אפשר להתקשר למרצה ולדבר איתו ישירות בטלפון.
המרצה זמין גם בווטסאפ וגם בצ'אט באתר המכללה.


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

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


מה לעשות אם לא מבינים משהו בסרט?

פשוט מאוד, מתקשרים למכללה ומדברים ישירות עם המרצה. אפשר גם להתכתב במייל או בווטסאפ או בצ'אט באתר.


האם יש לכם כיתות לימוד רגילות?

להשכיר כיתה + לשלם משכורת למרצה = 17 אלף ש"ח עלות הקורס לתלמיד.
אצלנו בסרטונים מקבלים אותו חומר לימוד
ואפילו קצת יותר, כי אין מגבלה של זמן כמו שיש בכיתה רגילה,
בנוסף מקבלים בדיוק אותה תעודה בינלאומית,
כי מבחן הוא מבחן חיצוני של מיקרוסופט
והכי חשוב שמקבלים את אותם המרצים, שמלמדים בכיתה רגילה,
רק שצילמנו אותם בסרטונים
והמחיר בסרטונים רק 350 ש"ח ולא 17 אלף כמו בכיתה רגילה.


קיימים במכללה שני מסלולי לימוד:
  1. מסלול לימוד חופשי, בלי תעודה, להעשרת ידע כללי.
    מסלול לימוד חופשי, מתאים בעיקר למי שעובד בתחום וכבר יש לו תעודות והוא לא רוצה עוד מבחנים ותעודות.

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


בסיום הקורס ניתן לקבל שני סוגי תעודות:
1. תעודה של המכללה - מותנה בהגשת פרוייקט גמר בסוף הקורס

SQL TEHNAI MCITP CCNA

2. תעודת הסמכה בינלאומית של מיקרוסופט העולמית - מותנה במעבר מוצלח של מבחן הסמכה חיצוני של מיקרוסופט (מבחן זה מתבצע כל שבוע במרכז בחינות מורשה בתל-אביב)

MCT MCTip AD2008

מידע כללי:
1. חומר הלימוד מורכב ממאגר עצום ומסודר מאוד של סרטים מקצועיים, הניתנים לצפיה מהבית. מאגר זה כולל הרצאות מוקלטות בעברית בצורה מסודרת ע"י המרצים הטובים ביותר. רשימת הסרטים המלאה נמצאת בתפריט בצד ימין.
2. כל סטודנט במכללה מקבל שם וסיסמה לצורך גישה לשרת הקבצים שלנו.
השרת מכיל את כל התוכנות הדרושות ללימוד וכן חומר עזר
3. הקורסים מועברים בהתאם לסילבוסים של החברות המובילות: Microsoft, Cisco

מאמר על LDS
בס"ד




מאמר מקצועי בנושא – Active Directory light directory services L D S






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

אחד השיקולים המרכזים הוא הרחבת הסכמה, כאשר אנו מבצעים התקנה של תוכנה הדורשת שימוש ב-AD לעיתים קרובות תידרש גם הרחבת סכמה והדוגמא הטובה ביותר לכך היא ה- 2003Exchange לאחר ביצוע התקנה של שרת דואר נוכל לראות שהתווספו שדות נוספים תחת מאפייני המשתמשים וכמו שכבר תיארתם לעצמם אם אנו מבצעים התקנה של מספר רב של תוכנות הסכמה תתרחב בהתאם לכל אחת מהן ומן הסתם גם תעבור ברפליקציה לשאר ה-DCs בארגון שלנו, באם נרצה שרק למחלקה מסויימת תהיה היכולת לעבוד עם תוכנה מסויימת האם יש מקום לחשוב שעלינו להרחיב את הסכמה של כלל הארגון?!

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

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

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

אז מה עושים? מצד אחד עלינו לבצע התקנה של האפליקציה ומצד שני איננו רוצים להכניס את עצמנו למצב בעייתי... התשובה: LDS

LDS – הוא תפקיד שנוסף בשרתי 2008 ומאפשר לנו לתת מענה לאותם תוכנות הדורשת שימוש במנוע של AD מבלי לחשוף את ה- AD שלנו לאפליקציה, כלומר LDS הוא בעצם תפקיד – אפלקציה למען אפליקציות המשמש כמנוע של AD לשימושן של תוכנות הזקוקות לו, תפקיד זה מתאפשר גם בעמדת קצה הנמצאת בדומיין (שרת חבר) לא מחייב DC ולא דורש הרשאות יתרות כמו תפקידים אחרים אלא רק הרשאת Administrator מקומי . התרחישים שבהם נשתמש בתפקיד זה בהתאם לשיקולים שבהם דנו הם:

1) כשנרצה לבצע הרחבת סכמה בצורה נקודתית בהתאם לאפליקציה על שרת מסויים ולא לכל השרתים בארגון.

2) כאשר נרצה לספק גישה מהירה לנתונים הנדרשים לאפליקציה – נוכל להתקין את ה-LDS בצורה מקומית על שרת נפרד ולהתקין את האפליקציה עצמה על אותו השרת ובכך לאפשר גישה מקומית מצד התוכנה מבלי שיתעורר הצורך מצד האפליקציה לפנות לרשת בכדי להשיג את המידע הדרוש לה.

3) כאשר נרצה לספק אוטנטיקציה (אימות) עבור אפליקציות WEB – מיכוון שמדובר ב-LDS ולא ב-AD נוכל למקם את השרת הכולל את תפקיד ה-LDS ברשתות החשופות לאינטרנט מבלי לחשוש מהסיכון של פגיעה כי כמו שאמרנו LDS הוא רק מנוע של AD ולא ה- AD עצמה.

4) התקנת אפליקציה למחלקה מסויימת בלבד שאפליקציה זו דרושה לה.

5) כאשר נרצה לספק גישה לאפלקציה למידע הנמצא במקומות שונים בארגון.

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

ורק למקרה ולא הבנתם את הרעיון הכללי ניתן לעיין במאמר בנושא IDA – מנגנון הזהות והגישה הנמצא בבלוג המכללה תחת קטגורית המבוא ל-AD.

ונעבור לחלק המעשי המחולק לשני חלקים הראשון התקנת התפקיד השני הגדרת ה- LDS: ראשית נבצע התקנה של התפקיד:

ניגש לתפריט ההתחל ונקיש על – Server Manager.

ומשם לרשימת התפקידים – Roles ונבצע הוספת תפקיד.

נדלג על חלון המבוא ומרשימת התפקידים נבחר את תפקיד ה- Active Directory light directory services.

לאחר מכן נקיש הבא ונסיים את ההתקנה.

שלב שני הגדרת ה-LDS:

דרך תפריט ההתחלה ניגש לכלי הניהול ונבחר AD LDS setup wizard. מיכוון שאנו מבצעים התקנה ראשונה נבחר – Unique instance. במידה ונרצה לבחור ליצור רפליקה (העתק) של Instance קיים נבחר באופיציה השניה. השלב הבא הוא להעניק שם ל – Instance שלנו, חשוב מאוד שניתן שם בעל משמעות כך שנוכל לדעת לאן משתייך ולמה משתייך כל דבר (במידה וישנם מספר Instance ולא אחד בודד). חשוב לציין ולהצביע על העובדה שיפתח שירות בהתאם לשם שסיפקתם.

לאחר שיצרנו את ה- Instance עלינו לשייך לו פורטים בכדי שיוכל לעבוד: ישנם שני פורטים שברצוני להרחיב עליהם את הדיבור האחד פורט המשמש ל-LDAP ופורט המשמש ל-LDAP תחת חיבור מאובטח SSL, מנגנון Active Directory עושה שימוש בפורטים הבאים לשתי צורות התקשורת, פורט מספר 389 לטובת LDAP ופורט מספר 636 לטובת LDAP דרך SSL לתקשורת מאובטחת, מבחינה מקצועית נכון לומר שניתן לשייך פורטים אלו אך אנו לא נעשה זאת בייחוד אם מדובר בהתקנת LDS על שרת שבו מותקן גם תפקיד AD DS (DC), אומנם המנגנון מספיק חכם בכדי לזהות שהפורטים בשימוש ומקצה פורטים אחרים לטובת LDS אך בכדי להימנע מבעיות נשייך את הפורטים הבאים:

50001 – LDAP

50002 – SSL

ניצור כמובן גם Application directory partition ונעניק לה שם הררכי לדוגמא:

CN=IDOinstance,DC=ido,DC=practicu,DC=com

השלב הבא הוא לבחור את המיקום שבו יאוחסנו הקבצים הקשורים ל-LDS אנו נדבוק בברירת המחדל ונקיש הבא.

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

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

1) הענקת שם לחשבון כשם ה-INSTANCE .

2) הענקת סיסמא קבועה.

3) שלילת היכולת לשינוי סיסמא.

4) שיוך סיסמא בעלת רמת סיבוכיות.

5) שיוך הגדרת- התחבר כמשתמש מסוג משתמש שירות, דרך מדיניות האבטחה המקומית על המערכת שתריץ את ה-Instance.

6) שיוך אפשריות התיעוד הרלוונטיות לטובת מעקב (generate security audits user right) יש לבצע זאת על כל מכונה ומכונה המריצה את ה- Instance.

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

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

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

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




מאמר זה נכתב על ידי מר.עידו שדדי מרצה במכללת PRACTICU