במחשב הראשי בבית יש וינדוס 7 שבו אני רק מאכסן מידע היוזר שלו הוא server כלומר (server-pc).
עכשיו אני רוצה לתת הרשאה לתיקיה אבל רק למשתמש ספציפי שמחובר לרשת, נגיד במחשב נייד של אחותי היוזר הוא adi.
עכשיו במחשב הראשי (server-pc) שאני בא לתיקיה מסויימת ועושה properties - sharing - advanced sharing - permission ואז מקיש add בכדי להוסיף את היוזר adi שנמצא במחשב נייד שמחובר לרשת, אז מופיע החלון המעצבן הזה שאומר לי תוסיף את היוזר, אבל הקטע שהוא לא מוצא את זה כי הוא מחפש את הויוזר ב server-pc, אז בטח שהוא לא ימצא, ואין דרך לשנות את זה..




איך בכל זאת אפשר לגרום רק ל adi לקבל הרשאות מסויימות?

Nikon D90 and others...
לגלריה שלי

תקים דומיין

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

נמאס לכם לזכור סיסמאות? לחצו כאן!

http://en.wikipedia.org/wiki/Single_sign-on ?
ומה ההבדל בין ליצור אותו משתמש וסיסמה לבין לתת הרשאות למשתמש ממחשב אחר מבחינת אבטחה? איך זה פחות טוב?

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

אם לא ברור לך למה - דמיין את הסנריו הבא: אני מקים אתר שנראה כמו אתר של בנק. במחשב שלך יש את שם המשתמש והסיסמא לניהול חשבון הבנק שלך. אתה נכנס לאתר שלי - שאולי קשור לבנק המקורי שלך - ואולי לא (אף אחד לא שאל אותך, ואני לא הצגתי שום credential / תעודה שמאפשר למחשב שלך לדעת שאנחנו קשורים...) - והמחשב שלך שולח את שם המשתמש והסיסמא של הבנק שלך - אלי - רק כי ביקשתי. מה אתה אומר?

נמאס לכם לזכור סיסמאות? לחצו כאן!

אבל לא שולחים את הסיסמה. שולחים HMAC-MD5 על ה-challenge של השרת תוך שימוש בסיסמה כמפתח ל-HMAC.

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

תמיד אפשר לסמוך עלייך, פסטן, שתבוא ותסביר איך זה עובד

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

עכשיו שעברנו את השלב הזה - האם זה אומר שהסיסמא לא נשמרת בהצפנה בלתי הפיכה?

נמאס לכם לזכור סיסמאות? לחצו כאן!

לא, זה לא אומר שהסיסמה מוצפנת בצורה בלתי הפיכה...
http://technet.microsoft.com/en-us/library/cc783557(v=ws.10).aspx

מה-גם שאם אני מאפשר למשתמש קולולו ממחשב בלהבלהבלה גישה לשירותים שלי, האם זה אומר שלא ניתן להקים מחשב בלהבלהבלה אחר עם משתמש קולולו שייגש לאותו משאב?

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

ושוב, איך זו בעיית אבטחה? הרי עדיין הוא יכול לנסות לגשת ל c$ (או לshare לינוקסי עם root) והאבטחה היא עדיין ברמה של הסיסמה... שוב - לא אומר מה טוב יותר, אבל זה בוודאי לא נורא כמו שאתה מצייר את זה.

לגבי מה נוח יותר - זה כבר משהו סובייקטיבי יותר.

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

אם סיסמאות מאוחסנות בצורה לא מוצפנת (או מוצפנת הפיכה, כאשר מפתח הפענוח שמור מקומית), משתמש מקומי יכול להגיע אליה, על פניו. אם הן כן מוצפנות בצורה בלתי הפיכה, קשה לי לראות איך משתמשים ב cleartext שלהן כדי להיות חלק מה HMAC (כי מאיפה משיגים את ה clear אם היוזר לא מקליד אותו, והוא לא, כאמור). אופציה אחרת תהיה להשתמש בתוצאת hash חד כיווני כלשהו בתור הבסיס ל HMAC, אבל זה אומר שעדיין משתמשים באותו אלגוריתם hash חד כיווני מאז שזה קיים (ימי NT4 פחות או יותר?)

נמאס לכם לזכור סיסמאות? לחצו כאן!

בגדול (בעבודה מול דומיין, אני מניח שזה זהה לעבודה בתחנות עבודה) ההזדהות היא מול שרת (או מי שמאשר לך להזדהות, במקרה הזה - התחנה עצמה) ואז אתה מקבל access token, מן hash שמכיל את כל ההרשאות שלך, הוא לא אמור לכלול את הסיסמה (כי זה יהיה דבילי)
זו ההגדרה לפי מייקרוסופט

Access token

A data structure containing the SID for a security principal, SIDs for the groups that the security principal belongs to, and a list of the security principal’s rights on the local computer. An access token is created for every security principal that logs on locally at the computer or remotely through a network connection. Each process has a primary access token that it inherits by default from its creating process. The access token provides a security context for the security principal’s actions on the computer. It also provides a security context for any application threads that act on the security principal’s behalf.

וסה"ך, זה התיאור של איך דברים עובדים, בקצרה ( כי המסמך ארוך) דברים שיעיינו אותך:

When a user logs on, an access token is created. The access token contains key security-related information, including the user’s SID, the SIDs of the groups to which the user belongs, and other information about the user’s security context. This access token is then attached to every process that the user runs during that logon session.

והדבר היחידי שנראה כאילו הוא קשור לסיסמה:

Security context

Information that describes a particular security principal’s identity and capabilities on a computer. In Windows XP Professional, all users in an organization exist in a specific security context that is redefined every time they log on

יותר מידע על תהליך ההתחברות עצמו (ללא קשר להעברת הטוקן למחשים אחרים, כולל יותר פירוט על access tokens ופרוטוקולי התחברות שונים
http://technet.microsoft.com/en-us/...y/bb457114.aspx

ומשהו מעניין שמצאתי (לפותח האשכול האמת) - עושה רושם שאנחנו מדברים על workgroup שלמעשה זה שונה לחלוטין מ homegroup
http://www.sevenforums.com/network-...e-accounts.html

אישית מאז שהתקנתי חלונות 8 באמת לא התעסקתי עם זה (וחיברתי את הDVD שלנו והטלוויזיה ל homegroup וזה פשוט עבד, אבל השיתוף הוא לא למשתמש מסויים בתצורה הזו אלא לכול מי שחבר ב homegroup והוזנה לו הסיסמה שלו/ה, אז אני לא בטוח מה התצורה העדיפה עלייך - תצטרך לחשוב (או לשאול שאלות מנחות לפי הצרכים שלך)

למה אתה מניח שעבודה מול דומיין זהה לעבודה בין שתי תחנות עבודה שאינן קשורות בדומיין? (NTLM, SAM, Kerberos...)

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

נמאס לכם לזכור סיסמאות? לחצו כאן!

בגלל ש ntlm/ntlm2 משמש אותך להזדהות מול workgroup בדיוק כפי שהוא משמש אותך להזדהות מול דומיין...
אם זה לא זהה אז זה אמור להיות מאוד דומה, המקום היחידי שהסיסמה נשמרת ב reversable encription זה אם אתה מפעיל/משתמש ב cached logon שדי מיותר בסביבה שאינה דומיינית.

עד עכשיו לא דיברנו על האופן בו הסיסמה מאוחסנת במחשב, מלכתחילה הטענה שלך הייתה ש(ואני לא מצטט אבל זה די קרוב למה שאמרת) באבטחה המיוחדת של חלונות המחשב מעביר את השם והסיסמה שלך למחשב אחר שמשווה למה שרשום אצלו ובגלל זה מאפשר לך להתחבר.
הטענה שלי הייתה שהמחשב לא מעביר את המשתמש והסיסמה כי-אם את ה access token ואפילו ציינתי מה הוא מכיל,
איך בדיוק המחשב השני מאשר אותו מול המשתמש המקומי? אני לא יודע כי זה לא עניין אותי ולכן לא חקרתי,
ההימור שלי הוא שמשתמשים באלגוריתם דומה להחלפת מפתחות כך שה access token משמש להזדהות במחשב המקומי והסיסמה עצמה לא מועברת, אבל זה רק הימור וייתכן שאני ממש רחוק מהתשובה.
בכול מקרה מכיוון שלסיסמה יש שימוש רק ביצירת ה AT ולא מעבר לזה - התשובה לשאלה הספציפית שלך היא לא - הסיסמה אינה נשמרת בהצפנה ברת פיענוח. אם זה היה המצב אז בכול אתגרי הפריצות חלונות היה מדורג אחרון ונפרץ אחרי 20 שניות ולא רק ביום השלישי אחרי שמוסיפים flash שפותח חורים במידה שווה בכול הפלטפורמות.

ועדיין - כל זה רלוונטי ל workgroup שזו לא השאלה המקורית של wolf, לפחות לא עד שיחליף את הטופולוגיה אצלו

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

Nikon D90 and others...
לגלריה שלי

אם אתה לא רוצה להפעיל דומיין אז הפתרון השני של שימי (אותו משתמש וסיסמה) אמור להספיק לך

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

Access Token הוא אובייקט קרנל שיוצא ה-LSA (ויכולים ליצור גם פרוססים עם הרשאות גבוהות במיוחד שלא קיימים בברירת-המחדל, וכמובן דרייברים). בכלל לא צריך סיסמה כדי ליצור אותו. ה-LSA בודק "איכשהו" שבאמת "זכותך" לקבל token ומייצר כזה. ה"איכשהו" הזה הוא אולי באמצעות סיסמה, ואולי באמצעות אמצי זיהוי ביומטרי, ואולי באמצעות כרטיס חכם, ואולי בכל דרך אחרת שכתבת עבורה פלאג-אין. מאחר והסיסמה אינה נדרשת, די ברור שזה לא קשור לשאלה איך מאוחסנת הסיסמה. בוא נזכור שוב שאם אתה דרייבר או שהשגת איכשהו את SeCreateTokenPrivilege אתה יכול לייצר איזה token שבא לך ולכתוב שם מה שבא לך.

כמובן שאין גם דבר כזה "העברת הטוקן למחשבים אחרים", כי access token, כמו כל kernel object או executive object אחר רלבנטי רק בהקשר של המחשב הנוכחי.

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

כבר כתבתי לו בתגובה המקורית שאליה הוא הגיב שזה לא קשור לשאלה שלי :\

ראיתי שכתבת לו את זה, אבל אחרי זה הוא כתב שוב את הדברים האלה:

ציטוט:

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

וכדי להסביר למה לא רק שזה לא נכון שה-access token עובר בין מחשבים, אלא שזה אפילו לא הגיוני, היה צריך להסביר מה זה ומאיפה זה מגיע.
כמו של-file descriptor אין משמעות מחוץ לפרוסס (אני לא יכול בתוכנה first לעשות int fd = open(...); printf("%d\n", fd);‎, בתוכנה second לעשות int fd; scanf("%d", &fd); read(fd, ...);‎‎‎‎, להריץ first | second ולצפות שה-read יפעל) לאובייקטי קרנל (ובתוך כך access token-ים) אין משמעות מחוץ למחשב.

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

תודה על התגובה, אני נהנה להחכים, אבל יש משהו שאני מפספס...
http://en.wikipedia.org/wiki/Access_token

ציטוט:

A token is composed of various fields, including but not limited to: an identifier. the identifier of the associated logon session. The session is maintained by the authentication service, and is populated by the authentication packages with a collection of all the information (credentials) the user provided when logging in. Credentials are used to access remote systems without the need for the user to re-authenticate (single sign-on), provided that all the systems involved share an authentication authority (e.g. a Kerberos ticket server)

זה לא אומר שהtoken כן חי מחוץ למכונה המקומית?

לא. מה שה-access token מכיל זה מה שמצוין כאן או כאן או כאן:

• The security identifier (SID) for the user's account
• SIDs for the groups of which the user is a member
• A logon SID that identifies the current logon session
• A list of the privileges held by either the user or the user's groups
• An owner SID
• The SID for the primary group
• The default DACL that the system uses when the user creates a securable object without specifying a security descriptor
• The source of the access token
• Whether the token is a primary or impersonation token
• An optional list of restricting SIDs
• Current impersonation levels
• Other statistics

לכל הדברים האלה יש משמעות לוקאלית: SID-ים וכו'. אגב, שים לב גם שבקישור השלישי מוסבר מה זה שדה ה-origin:

Introduced with Windows Server 2003. If the token resulted from a logon using explicit credentials, then the token will contain the ID of the logon session that created it. If the token resulted from network authentication, then this value will be zero.

עכשיו ה-logon SID הזה מצביע ל-logon session, וזה שמישהו אחר (הקרנל/LSASS) אולי מחזיק שם את ה-credentials זה סיפור אחר לגמרי. ה-access token עצמו לא זז מהמכונה.

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

ציטוט:

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

טוב שיש על מי לסמוך.

ציטוט:

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

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

ציטוט:

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

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

שאלה שקשורה לנושא היא "ומה-HAMC שהלקוח שולח לשרת אין לשרת דרך להוציא את הסיסמה?" או "מה תוקף מהצד שמסוגל לראות את התקשורת בין שני הצדדים לעשות עם ה-HMAC הזה?"

"איך הסיסמה שמורה על המחשב המקומי" זה פשוט... לא קשור.


(*טוב, בעצם אני כן יודע, אבל זה לא קשור. בעצם, זה אפילו לא משנה. הסיסמה לא שמורה על המחשב המקומי אלא רק hash עליה, אבל ה-hash הזה עשוי להיות מה שנקרא password-equivalent כי כל מה שאתה צריך כדי להזדהות מול שרת, בין אם מדובר ב-NTLM ובין אם מדובר בקרברוס הוא להשתמש ב-hash כדי להצפין מידע שהשרת דורש ממך. הדבר הנכון היה להשתמש ב-hash אחד ללוגין לתחנה, ב-hash אחר ל-NTLM וה-hash שלישי עבור קרברוס. אני לא בטוח כרגע, אבל שמעתי שמועה מצערת שזה לא מה שעושים.)

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

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

את נושא השימוש ב HMAC כבר עברנו (ואני מכיר. זוכר ששאלת אותי לא מעט על OpenVPN? גם שם יש HMAC...), מבחינתי הוא סגור, ולכן אין מה עוד לשאול עליו. נשארה לי רק השאלה על כיצד הסיסמא מאוחסנת מקומית כדי לאפשר את כל זה, והאם זה לא אומר שהם כבולים לאלגוריתם hashing מימים ימימה, ולעולם לא יוכלו לשנות אותו, כי זה יגרום לחסימת הפיצ'ר הזה שכל כך הרבה אנשים מסתמכים עליו, או... מה?

בקיצור:

צור לאחותך משתמש על השרת שאיתו היא תוכל לגשת לקבצים על השרת.
(זה ממש הגיוני שהרשאות על השרת יתבססו על משתמשים שקיימים על השרת.)

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

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

עכשיו לצורך העניין שאני עושה בשרת שיתוף על כונן E, נכנס ל Advanced Sharing
שם נכנס ל Permissions. מוסיף את המשתמש ונותן לו הרשאות Full.
לאחר פעולה כזו המשתמש לא יכול לכתוב או להעתיק קובץ לאחד התיקיות שבתוך הכונן E
כמו לדוגמא e:\temp וצועק שאין הרשאות...

איך אפשר לעשות שאני משתף כונן שלם ונותן פול הרשאות, תיהיה גישה לכתוב בשאר התיקיות שבתוך הכונן?

Nikon D90 and others...
לגלריה שלי

תבדוק לא רק בטאב Sharing , ש-ל-Everyone יש Full Control (או לחלופין למשתמש המסויים יש הרשאת Full Control), אלא גם בטאב Security, שקובע את הרשאות ה NTFS של האובייקט. משום מה יש שני "פילטרים" של הרשאות בשיתוף הקבצים - כמובן שהחמור יותר הוא הקובע. אינני בטוח למה צריכים שניים (אולי כדי לתת סט הרשאות שונה לקובץ בגישה מקומית ובגישה מרחוק? זה קצת לא הגיוני בעיני, משום שאם יש גישה מקומית ממילא, הגבלה מרחוק היא קצת מיותרת כי אפשר להתחבר למחשב ישירות, ואם אין מקומית ממילא, אזי ה ACL של NTFS כבר יכול להיות הקובע גם עבור גישה מרחוק...), אבל אני חי בסדר עם אי הידיעה. אולי פסטן יודע

נמאס לכם לזכור סיסמאות? לחצו כאן!

עזבתי קצת את השיתוף כי לא הסתדרתי, שמע אני דיי מיואש
הגדרתי את היוזר adi במחשב הנייח עם אותו שם משתמש וססמא כמו בנייד, עכשיו שאני עושה לתיקיה מקש ימני
share with - specific user, שם כותב adi. נותן לו הרשאות Read Write. אחכ במאפיינים של התיקיה אני נכנס ל sharing - advanced sharing - permission - add- adi ושם נותן גם Full control
לאחר מכן עובר ללשונית security ושם מסמן את adi רואה שיש הרשאות מלאות. נכנס ל Advanced - effective permissions כותב שם adi כדי ראות בריפורט שבאמת יש הכל מסומן ב V. אני פשוט משתגע
מה שמצחיק הוא שאם אני עושה שיתוף ל everyove אז כן אני כן יכול להכנס אבל אני לא רוצה לכל הרשת, רק למשתמש ספציפי

מה לא עשיתי בסדר ?

Nikon D90 and others...
לגלריה שלי

השאלה היא אם המשתמש המרוחק אכן עושה לוגין למחשב שלך (ואם לא, למה לא...)

תוכל לפתוח (בשרת המשתף) קונסולת MMC ושם להוסיף Snap-In של Open Files (או משהו כזה, מצטער, אין לי חלונות בסביבה כדי לבדוק), ותוכל לראות שם את החיבור של המחשב המרוחק, באיזה שם משתמש הוא מתרחש...

וייתכן שזה קשור לפיצ'ר הטפשי הזה של ה HomeGroup או משהו כזה... אם הוא מופעל, אולי שווה לבטל אותו...