Może uzyskać dostęp do udziału Windows za pomocą adresu IP lub FQDN, ale nie według nazwy hosta

Jeden z komputerów laboratoryjnych w zarządzanej przeze mnie szkole nie ma dostępu do żadnych udziałów w katalogu \\ ad \ data $. Mogę uzyskać do niego dostęp z dowolnego innego komputera w sieci. Jeśli korzystam z adresu IP \\ 192.168.1.248 \ data $, mogę prawidłowo uzyskać dostęp do plików. Jeśli użyję nazwy FQDN: \\ ad.domain.name \ data $, to również działa. Każdy inny komputer w szkole może również prawidłowo uzyskiwać dostęp do tego udziału.

Gdy próbuję uzyskać dostęp do udziału za pomocą \\ ad \ data $, pojawia się komunikat „Nie masz uprawnień dostępu do \\ ad \ data $. Skontaktuj się z administratorem, aby poprosić o dostęp”. Jestem zalogowany za pomocą konta administratora domeny.

Masz pomysł, co sprawiłoby, że komputer z jedną domeną nie miałby dostępu do udziału, do którego powinien mieć dostęp?

Na serwerze działa system Windows Server 2008, a na komputerze jest uruchomiony system Windows 7 SP1.

AKTUALIZACJA

Problem występuje teraz na wielu innych komputerach w sieci, komputerach personelu i komputerach studentów. Zaczynam myśleć, że coś jest nie tak z serwerem Active Directory.

Właśnie miałem podobny problem.

Mamy domenę i AD, a foldery domowe wszystkich użytkowników są ustawione w AD.

Użytkownik pracuje na serwerze terminali, a jej folder domowy działa dobrze Na nowym notebooku, który dla niej konfigurowaliśmy, dysk został zamapowany, ale jeśli próbowałeś uzyskać do niego dostęp za pomocą unc lub przez dwukrotne kliknięcie zamapowanego dysku, to dał błąd lokalizacji nie można znaleźć.

Przeglądając kilka innych forów zauważyłem, że ktoś zapytał, czy do folderu domowego można uzyskać dostęp przez IP lub FQDN. Kiedy próbowałem, mogłem uzyskać dostęp do folderu.

Na początku myślałem też, że to problem z DNS.

Czytając dalej, ktoś powiedział: „spróbuj usunąć pamięć podręczną CSC”, a potem prawie przeklnąłem na siebie. Wiedząc, że ten notatnik był używany przez innego użytkownika, który korzystał z plików offline (także ich folderu domowego na tym samym serwerze). Znalazłem szybki sposób na usunięcie pamięci podręcznej CSC na Win 7 (jest to o wiele łatwiejsze na XP). Uruchomiono ponownie komputer i problem został rozwiązany.

Oto linki, na których znalazłem informacje:

http://www.petri.co.il/forums/showthread.php?t=60629

http://support.microsoft.com/kb/942974

Widziałem taki problem i było to spowodowane tym, że DNS nie ustawiał automatycznego dodawania nazwy domeny.

Sprawdziłbym więc, czy wybrana jest opcja Dołącz sufiksy DNS podstawowe i specyficzne dla połączenia oraz czy zaznaczone są Sufiksy nadrzędne podstawowego sufiksu DNS .

Można to znaleźć za pośrednictwem

Control Panel\Network and Internet\Network and Sharing Center
Local Area Connection Status
Properties
Internet Protocol Version 4 (TCP/IPv4) and/or Internet Protocol Version 6 (TCP/IPv6) 
Properties
Advanced
DNS

Win7 / server 2008> wpisz panel sterowania w „Menedżerze poświadczeń” i usuń wszystkie zapisane poświadczenia.

Miałem ten sam problem (zdarzyło mi się kilka razy) i rozwiązałem go, usuwając wszystkie połączone udziały i odtwarzając je ponownie. Było wiele połączeń z tymi samymi lokalizacjami (używając różnych adresów URL) i podejrzewam, że to była przyczyną problemów.

Za pomocą wiersza polecenia:

1. Aby zobaczyć aktualnie podłączone udziały
   net use
2. Aby usunąć połączenie, udostępnij Y na xxx.xxx.xxx.xxx
   net use \\xxx.xxx.xxx.xxx\Y /delete
3. Aby usunąć połączenie, udostępnij Y w XXX
   net use \\XXX\Y /delete
4. Aby usunąć zmapowany dysk sieciowy
   net use Y: /delete
5. Aby ponownie podłączyć zmapowany dysk sieciowy
   net use Y: \\xxx.xxx.xxx.xxx\Y /PERSISTENT:YES /USER:XXX\user /SAVECRED

Kolejnym potencjalnym podejrzanym jest menedżer Samsung PC Share. Po odinstalowaniu go z hosta problem zniknął.

Możliwe, że komputer kliencki używa zapisanych poświadczeń. Możesz to sprawdzić za pomocą Menedżera poświadczeń systemu Windows w Panelu sterowania.

Czy dzieje się tak na koncie administratora lokalnego, np. Nazwa_komputera \ Administrator?

Czy urządzenie uwierzytelnia się prawidłowo na kontrolerze domeny?

Upewnij się, że nie łączysz się jeszcze z \ ad przy użyciu różnych (lub starych) danych logowania. Podobne problemy występowały, gdy miałem zmapowany dysk podłączony do udziału na serwerze za pomocą mojego „zwykłego” konta domeny, a następnie próbowałem połączyć się z innym udziałem na tym samym serwerze za pomocą konta „admin” mojej domeny.

Czy ponowne uruchomienie rozwiązuje problem?

Miałem powiązany problem. Miałem maszynę XP Home uzyskującą dostęp do udziałów / folderów współdzielonych i dysków na komputerze z systemem Windows 7. Bawiłem się ustawieniami grupy roboczej / grupy domowej w systemie Windows 7 i zmieniłem opcję „Udostępnianie chronione hasłem”. Widziałem moje udostępnione foldery na komputerze XP Home, ale nie mogłem ich czytać ani pisać z / do nich. Doprowadzało mnie to do szału - ponieważ kiedy utworzyłem nowego użytkownika na komputerze XP Home i uzyskałem dostęp do moich udziałów na komputerze z Win 7, nie było żadnych problemów - mogłem czytać i pisać pliki!

Wróciłem więc do mojego starego (głównego) konta użytkownika i nadal nie mogłem uzyskać dostępu do udostępnionych plików ...

Próbowałem różnych rozwiązań - użycie netto * / del i próbowałem usunąć konta użytkowników net user / delete - próbowałem pozbyć się danych z pamięci podręcznej - ale nic nie działało. Dostęp do udziałów przez adres IP DID pracy! Argggh !!

Próbowałem ustawić Workgroup na obu komputerach na Workgroup (maszyną XP HOME był MSHOME)

W końcu musiałem zmienić NAZWĘ KOMPUTERA na moim komputerze z systemem Windows 7, ponownie uruchomić komputer, a następnie uzyskać dostęp do moich folderów współdzielonych z komputera z systemem XP HOME. Następnie poprosił mnie o podanie loginu / hasła, które wprowadziłem ponownie. Jednak miałem ścieżki i rzeczy, które używały mojej starej nazwy komputera, więc zmieniłem komputer z Win 7 z powrotem na pierwotny. Alleluja! Udało się - ponownie zostałem poproszony o podanie hasła / użytkownika i mogłem uzyskać dostęp do moich udziałów z maszyny XP HOME!

Podsumowując: istnieje problem z buforowanymi poświadczeniami i nie ma oczywistego sposobu na ich usunięcie (nic nie zostało pokazane w Menedżerze haseł sieciowych na koncie użytkownika). Dlatego zmień tymczasowo nazwę komputera i zmień ją z powrotem, co może rozwiązać niektóre problemy.

Na podobnych forach natknąłem się na kilka podobnych problemów, ale żaden z nich nie jest taki sam jak mój.

Miałem ten problem po aktualizacji Box Server 2008 R2 do Server 2012 R2 z aktualizacją. Dla mnie przejście do Menedżera poświadczeń i usunięcie poświadczeń systemu Windows -> Ogólne poświadczenia rozwiązało problem.

Ku mojemu zdziwieniu w jednym z moich przypadków okazało się, że muszę dodatkowo opróżnić pamięć podręczną DNS oprócz włączenia funkcji obsługi SMB 1.0 w systemie Windows 8.1. To był komputer przyłączony do domeny, który został odłączony od swojej domeny.

W innym przypadku komputer nie przyłączony do domeny, opróżnianie pamięci podręcznej DNS nie pomógł. Co ciekawe, w pełni kwalifikowana nazwa \\Name.działała, gdy \\Namenie działała (nie próbowałem tego syna na pierwszej maszynie). Nie jestem pewien, na czym polega problem, ale zgaduję, że ma to związek z brakiem nazwy domeny.

Wystąpiło to tylko w jednym określonym folderze. Okazuje się, że przyczyną problemu były foldery offline, ponieważ korzystamy z przekierowanych folderów. Tak więc Windows dosłownie łączy się z tym udziałem z poświadczeniami innych użytkowników, gdy tylko Windows się uruchomi, więc odmawia połączenia zalogowanemu użytkownikowi.

Zastosowanym rozwiązaniem było wyłączenie synchronizacji offline.

Mogą to być sieciowe listy ACL. W jednym środowisku, w którym pracowałem, zostały one zmienione na blok portu 445. Tak więc:

\ nazwa_hosta \ udział

• Klient próbował połączyć się przez SMB na porcie 445 protokołu TCP / IP
• Zablokowane przez sieciowe listy ACL
• Klient nie łączy się

\ nazwa_hosta.fqdn \ udział

• Klient próbował połączyć się przez SMB na porcie 445 protokołu TCP.IP
• Zablokowane przez sieciowe listy ACL
• Klient łączy się przez NetBT na porcie 139
• Udane połączenie

Tak się właśnie stało, że połączenie z FQDN próbuje użyć NetBT, a port 139 był otwarty, więc się udało.

Rozwiązaniem było więc odblokowanie portu 445.