Mapowanie udziału plików VPN za pomocą konta Samba, które zna serwer

Połącz tunel, a udział nadal prosi o hasło, które użytkownik uważa za poprawne. W samodzielnym wdrożeniu Samba logowanie VPN i logowanie SMB to niepowiązane poświadczenia: jedno autoryzuje tunel, drugie sprawdza serwer plików. Dlatego mapowanie dysku za pomocą konta VPN kończy się niepowodzeniem, nawet gdy hasło jest poprawne, a ścieżka sieciowa idealna. Ta różnica wyjaśnia większość niepowodzeń mapowania przez VPN.

Rozwiązaniem nie jest zresetowanie konta VPN. Należy wskazać tożsamość, którą serwer Samba faktycznie zna, a następnie sprawdzić, czy ta sama tożsamość ma uprawnienia do udziału i katalogu.

Logowanie VPN i logowanie SMB to różne tożsamości

Konto VPN jest oceniane przez bramę VPN zgodnie z jej własną polityką. Odpowiada, czy ten klient może wejść do sieci prywatnej. Nie mówi nic o tym, które konto SMB istnieje na serwerze plików w tej sieci.

Konto Samba żyje w backendzie uwierzytelniania serwera, z własną bazą haseł i własną nazwą. Dwa komputery mogą mieć użytkownika o nazwie alice, nie dzieląc systemu tożsamości, hasła ani identyfikatora użytkownika. Nazwy się zgadzają; konta nie.

Serwer Samba zintegrowany z domeną zmienia obraz: tożsamość pochodzi z katalogu i z Kerberosa, a nie z lokalnej listy kont. W takim przypadku użyj tożsamości z katalogu i obsługiwanej konfiguracji SMB zamiast tworzyć lokalne duplikaty imitujące przynależność do domeny. Sprawdź, którego modelu używa serwer, zanim utworzysz jakiekolwiek konto.

Sprawdź, której tożsamości Windows naprawdę używa

Windows buforuje połączenia na serwer. Jeśli istniejąca sesja do tego samego serwera została otwarta z innego konta, nowe mapowanie może użyć tej sesji lub zakończyć się błędem uwierzytelniania wskazującym niewłaściwego użytkownika. Tak poprawne hasło wygląda na błędne. Sprawdź bieżące połączenia, zanim zmienisz poświadczenia.

net use
cmdkey /list
klist

Pierwsze polecenie pokazuje zamapowane dyski i otwarte sesje, drugie pokazuje zapisane poświadczenia, które mogą być stosowane automatycznie, a trzecie pokazuje bilety Kerberosa, gdy używana jest domena. Zapisane poświadczenie może po cichu zastąpić konto, które zamierzałeś wpisać.

Usuń tylko połączenie lub poświadczenie należące do tego problemu. Odłączanie wszystkich dysków lub zastępowanie nazwy serwera adresem IP ukrywa wybór tożsamości i może zepsuć podpisywanie lub polityki oparte na nazwach.

Zamapuj udział za pomocą konta rozpoznawanego przez serwer

Podaj konto w formie oczekiwanej przez serwer i pozwól Windowsowi zapytać o hasło, aby hasło nie trafiło do historii poleceń ani skryptu:

net use Z: \\files.corp.example\team * /user:FILESERVER\alice /persistent:no

Część serwera przed ukośnikiem wstecznym to kontekst tożsamości serwera Samba, a nie brama VPN. Gwiazdka żąda interaktywnego monitu o hasło, a /persistent:no trzyma mapowanie poza następnym logowaniem. Wybierz wolną literę dysku.

Jeśli serwer jest zintegrowany z domeną, częścią użytkownika może być zamiast tego nazwa katalogu lub tożsamość kwalifikowana domeną. Użyj formy udokumentowanej przez administratora; wymyślenie lokalnego konta o tej samej nazwie tworzy drugą tożsamość i drugie hasło do utrzymania.

Ważność konta, dostęp do udziału i uprawnienia systemu plików to trzy kontrole

Samba sprawdza, czy tożsamość się uwierzytelnia, czy definicja udziału ją dopuszcza, oraz czy system plików przyznaje żądaną operację. Przejście pierwszej kontroli nie oznacza pozostałych dwóch. Udział może być widoczny i nadal odmawiać zapisu, bo tak mówią uprawnienia katalogu.

Udział ograniczony przez valid users dopuszcza tylko wymienione konta lub grupy. Konto może uwierzytelnić się poprawnie i mimo to zostać odrzucone przez tę linię. Sprawdź definicję udziału, zanim uznasz, że hasło jest błędne.

Po stronie systemu plików znaczenie mają zarówno proces Samba, jak i zamapowana tożsamość. Katalog należący do root z trybem 700 nie przyjmie zapisów od zwykłego konta, nawet gdy definicja udziału na to pozwala. Przetestuj odczyt, a potem zapis w katalogu, którego konto ma używać.

Wyczyść konfliktową sesję bez łamania polityki

Gdy przyczyną jest nieaktualna sesja, zamknij to jedno połączenie i zamapuj ponownie z zamierzonym kontem. Jeśli zapisane poświadczenie wciąż powraca, usuń je zamiast całej listy dysków. Następnie potwierdź nową sesję za pomocą net use.

Zachowaj wymagane podpisywanie SMB, szyfrowanie i politykę kont. Serwer, który odmawia niepodpisanej lub nieszyfrowanej sesji, egzekwuje politykę, a nie czyta błędnie hasła, a osłabianie jej, aby mapowanie się udało, wymienia bezpieczeństwo na objaw.

Zapisz nazwę serwera, dokładną formę konta oraz uprawnienia do udziału i katalogu, które zadziałały. Inaczej następna osoba mapująca dysk najpierw spróbuje logowania VPN, bo to poświadczenia, z którymi dotarła do sieci.