Obecnie konta lokalne dla użytkowników nie są już tak powszechnie wykorzystywane jak kiedyś. To, co dla użytkowników systemów Windows 7 i wcześniejszych było często jedyną znaną formą, dzisiaj pozostaje opcjonalną funkcjonalnością najnowszych wersji systemu. Obecnie instalując system Windows, czy tworząc w nim nowe konto, system próbuje wymusić na nas dodanie konta Microsoft. Takie konto nie jest oczywiście kontem lokalnym i wymaga ono rejestracji w bazie Microsoftu. Skoro więc Microsoft próbuje przekonać nas do zapomnienia o kontach lokalnych, oferując jednocześnie w pełni funkcjonalne konta Microsoft, to czy są one wyłącznie reliktem przeszłości? Nie. Konta lokalne nadal znajdują swoje zastosowanie w szeregu różnych scenariuszy.
Konto lokalne a konto Microsoft
Zacznijmy od różnic, jakie dzielą konta lokalne oraz konta Microsoft. Wspomniałem już, że obecnie posiadając system Windows jesteśmy niejako przymuszani do tworzenia właśnie takich kont. Choć oczywiście nadal mamy możliwość korzystania wyłącznie z kont lokalnych, to konto Microsoft zawsze jest domyślnym wyborem, który jest na podsuwany przez system. Wynika to min. z tego, że konto Microsoft jest obecnie niezbędne do wykorzystania wszystkich funkcjonalności Windows 11. Bez niego będziemy mieli ograniczoną możliwość korzystania z Microsoft Store, czy z OneDrive-a, czyli przestrzeni dyskowej w chmurze. Dzięki temu konto Microsoft pozwala nam na logowanie się na wielu komputerach i stosunkowo łatwe przenoszenie danych pomiędzy nimi.
Wykorzystywanie konta Microsoft nie jest naturalnie pozbawione wad. Chodzi tu np. o niższy poziom bezpieczeństwa związany ze stałą dostępnością konta z poziomu internetu, potencjalny brak możliwości odblokowania komputera w przypadku odcięcia go od internetu czy przesyłanie do Microsoft wielu danych dotyczących np. naszych nawyków czy sposobu użytkowania urządzenia.
Konta lokalne są niejako odwrotnością kont Microsoft. Z jednej strony uniemożliwiają one korzystanie z części funkcjonalności dostępnych w ramach Windows 11 czy logowanie i przenoszenie swoich danych pomiędzy urządzeniami. Z drugiej, istotnie poprawiają bezpieczeństwo i prywatność użytkowników, jak również nie ograniczają możliwości logowania w przypadku braku internetu.
Zastosowanie kont lokalnych
Gdzie więc konta lokalne znajdują swoje zastosowanie? Mówiąc najogólniej: wszędzie tam, gdzie bezpieczeństwo i prywatność stawiane są na pierwszym miejscu. Z punktu widzenia zwykłego użytkownika systemu wykorzystanie konta lokalnego będzie miało zastosowanie raczej rzadko. Oczywiście, jeżeli ktoś jest w stanie poświęcić funkcjonalność na rzecz bezpieczeństwa i prywatności – nic nie stoi na przeszkodzie, żeby je wykorzystywać. Jednak w zdecydowanej większości przypadków szczególnie brak możliwości synchronizacji danych może być dość dużym minusem. Szczególnie biorąc pod uwagę statystyczną częstotliwość robienia backup’ów i fakt, że w przypadku OneDrive są one niejako robione automatycznie.
Z biznesowego punktu widzenia zastosowanie kont lokalnych może znaleźć zastosowanie dla większej ilości scenariuszy. W tym przypadku mamy jeszcze szereg innych typów kont, które mogą zostać wykorzystane – konta domenowe, z lokalnego Active Directory czy np. konta dodane do Active Directory w chmurze. Konta lokalne znajdą więc zastosowanie w podobnym typie scenariuszy – tam gdzie bezpieczeństwo danych będzie na pierwszym miejscu. Specyficzne wymagania bezpieczeństwa określają niekiedy konieczność całkowitego odizolowania danego urządzenia od sieci. W takich przypadkach wykorzystanie kont lokalnych będzie nie tylko odpowiednią, ale być może jedyną możliwością.
Uwierzytelnianie użytkowników w Windows 11
Mówiąc o kontach lokalnych wypada również wspomnieć o procesie ich uwierzytelniania. Uwierzytelnianie jest najprościej mówiąc procesem potwierdzania tożsamości użytkownika (o uwierzytelnianiu oraz różnicy między uwierzytelnianiem i autoryzacją pisałem tutaj). W przypadku kont lokalnych uwierzytelnianie będzie najczęściej sprowadzało się do podania hasła do konta lokalnego.
W Windowsie 11, podobnie jak we wcześniejszych wersjach, hasła do kont użytkowników przechowywane są w bazie SAM (Security Account Manager). Naturalnie, zgodnie z dobrymi praktykami bezpieczeństwa, hasła nie są przechowywane w niej w tzw. plain text, czyli formie jawnej. Baza SAM zawiera hash-e haseł, czyli hasła zaszyfrowane za pomocą tzw. funkcji jednostronnych. Funkcje jednostronne z kolei to funkcje kryptograficzne, które szyfrują hasło i z definicji nie pozostawiają możliwości jego odszyfrowania (stąd nazwa). Taki sposób przechowywania haseł istotnie podnosi poziom bezpieczeństwa, utrudniając atakującemu dostęp do haseł nawet w przypadku wycieku ich bazy. Więcej o samych hasłach, hash-ach haseł oraz ich złożoności pisałem tutaj.
Skoro więc system nie zna hasła w postaci, w której je wpisujemy, skąd więc wie czy jest ono poprawne? Tutaj dochodzimy do tego, w jaki sposób działa uwierzytelnianie w zasadzie w każdym systemie. Skoro funkcje jednostronne nie pozostawiają możliwości odszyfrowania hasła, nie jesteśmy w stanie porównywać ich w postaci jawnej. Jednak nic nie stoi na przeszkodzie, aby porównywać je w postaci zaszyfrowanej. Funkcje jednostronne generują zawsze dokładnie taki sam hash dla takiego samego hasła. W praktyce oznacza to, że najlepszą metodą weryfikacji poprawności hasła jest utworzenia hash-a z hasła wprowadzonego przez użytkownika, a następnie porównanie go z tym, który znajduje się w bazie. Jeżeli hash-e będą identyczne – wprowadzone hasło jest poprawne.
Jeżeli chodzi o samą bazę SAM – jest ona oczywiście przechowywana lokalnie na urządzeniu. Możemy ją znaleźć w domyślnym katalogu Windows w następującym miejscu – „C:\Windows\System32\config\SAM”. Ze względów bezpieczeństwa odczytanie zawartości bazy jak również skopiowanie jej w inne miejsce na dysku teoretycznie nie jest możliwe.
Wbudowane konta lokalne
Oprócz kont użytkowników, które mamy możliwość utworzyć, możemy również zauważyć kilka kont, które znajdują się w bazie od samego początku. Są to tzw. konta wbudowane, ponieważ są one tworzone automatycznie wraz z instalacją systemu operacyjnego na urządzeniu. Kont wbudowanych nie możemy usunąć. Domyślnie, tworzone są cztery wbudowane konta lokalne:
- Administrator – czyli pierwsze konto, które jest tworzone podczas instalacji systemu. Jest to konto administracyjne posiadające najwyższe, pełne uprawnienia do zarządzania systemem. Wbudowane konto administratora posiada w niektórych przypadkach wyższe uprawnienia niż utworzone później konta administracyjne. Pozwala to na odzyskanie kontroli nad komputerem np. w przypadku błędnej konfiguracji GPO, która uniemożliwi dostęp nawet kontom administracyjnym. W przypadku tego typu newralgicznych mechanizmów, domyślnie nie będą one działały na konto wbudowanego administratora (chyba, że skonfigurujemy odpowiednie opcje). Z punktu widzenia bezpieczeństwa – ze względu na bardzo szerokie uprawnienia, nie powinniśmy wykorzystywać go do codziennej pracy. Mimo, że nie można go usunąć, to istnieje możliwość jego wyłączenia. Utworzenie niezbędnych do codziennej pracy kont, wyłączenie wbudowanego konta administratora i wykorzystywanie uprawnień tylko wtedy, gdy jest to niezbędne jest stanowczo zalecaną dobrą praktyką, pozwalającą na podniesienie naszego poziomu bezpieczeństwa
- DefaultAccount – znane również jako „Default System Managed Account” (DSMA). Konto to tworzone jest w bazie SAM wraz z pierwszym uruchomieniem urządzenia. Jest kontem posiadającym uprawnienia na poziomie zwykłego użytkownika, które jest zarządzane przez system. Jest wykorzystywane do uruchamiania procesów, które są obsługiwane przez wielu użytkowników lub są od nich całkowicie niezależne.
- Guest – konto, które jest tworzone wraz z instalacją systemu, ale pozostaje domyślnie wyłączone. Jest kontem posiadającym bardzo ograniczone uprawnienia oraz domyślnie nieposiadającym hasła. Było ono wykorzystywane w starszych wersjach systemu do umożliwienia zalogowania się do komputera osobom nie posiadającym konta na danym urządzeniu. Ze względu na ryzyko jakie niesie za sobą włączenie i umożliwienie wykorzystania tego typu konta, jest to stanowczo niezalecana praktyka.
- WDAGUtilityAccount – konto tworzone wraz z instalacją systemu, które jest wykorzystywane przez system w ramach Windows Defender Application Guard. Jest ono domyślnie wyłączone, dopóki sama funkcjonalność nie zostanie włączona na urządzeniu.
Tworzenie kont lokalnych
Windows 11 umożliwia tworzenie kont lokalnych na wiele różnych sposobów. Możemy to robić zarówno z poziomu GUI (Graphical User Interface), jak i z poziomu dostępnych w systemie konsoli systemowych. Przechodząc więc od razu do konkretów:
Poprzez Local Users and Groups
Do tworzenia kont lokalnych w tym miejscu możemy dostać się na kilka różnych sposobów. Jednym z nich jest wyszukanie na urządzeniu i uruchomienie „Computer Management” oraz odnalezienie tam opcji „Local Users and Groups”:
Do samego „Local Users and Groups” możemy dostać się również poprzez uruchomienie „lusrmgr.msc” z poziomu konsoli „Run” (Win+R):
Taki sam efekt da również wpisanie w Command Line polecenia „lusrmgr” lub „lusrmgr.msc”:
Konto nowego użytkownika możemy utworzyć klikając PPM na pustą przestrzeń, a następnie wybierając opcję „New User…”:
W wyświetlonym nam kreatorze musimy uzupełnić podstawowe dane dotyczące nowo tworzonego użytkownika.
- Pole „User name” pozwala na określenie nazwy konta użytkownika
- W polu „Full name” określamy nazwę konta użytkownika, która będzie wyświetlana np. na ekranie logowania
- Pole „Description” pozwala nam na opcjonalne dodanie opisu do tworzonego konta
- W polu „Password” podajemy hasło do konta tworzonego użytkownika
- W polu „Confirm Password” ponownie podajemy hasło do konta tworzonego użytkownika, w celu potwierdzenia
Poniżej dostępne mamy również 4 opcje dotyczące haseł. Część z nich jest wyklucza się wzajemnie, więc staje się możliwa do wybrania dopiero po wyłączeniu innych, wykluczających jej opcji:
- User must change password at next logon – Opcja zalecana i zgodna z dobrymi praktykami bezpieczeństwa. Wymusza na użytkowniku zmianę ustawionego przez nas hasła zaraz po pierwszym zalogowaniu do systemu;
- User cannot change pasword – opcja uniemożliwiające użytkownikowi zmianę jego hasła (dostępna po odznaczeniu pierwszej opcji);
- Password never expires – opcja pozwalająca na nadpisanie np. ustawionych w GPO ustawień dotyczących częstotliwości zmiany hasła. Zaznaczenie opcji powoduje, że użytkownik nie będzie musiał (i nie będzie miał możliwości) zmieniać hasła do swojego konta;
- Account is disabled – czyli opcja pozwalająca na czasowe wyłączenie konta. Tą opcję możemy wykorzystać np. jeżeli tworzone konto nie będzie wykorzystywane w najbliższym czasie.
Po kliknięciu przycisku „Create” konto użytkownika zostaje utworzone, a użytkownik ma możliwość zalogowania na nie:
Poprzez Family & other users
Tutaj też możemy dostać się na co najmniej kilka różnych sposobów. Jednym z nich jest otworzenie ustawień za pomocą zaznaczonego poniżej przycisku w menu Start:
Następnie należy wybrać „Accounts”:
oraz odnaleźć na liście po lewej stronie „Family & other users”. Opcja ta nie będzie oczywiście widoczna, jeżeli nasze konto nie posiada uprawnień administratora:
Inną metodą, umożliwiającą dostanie się w to samo miejsce, jest wykorzystanie Control Panel-u. Uruchamiamy więc Control Panel i wyszukujemy opcję „User Accounts”:
Następnie ponownie wybieramy opcję „User Accounts”. W zależności od szczegółowości głównego menu w Control Panelu, ten krok może w ogóle nie pojawić.
W kolejnym korku odnajdujemy opcję „Manage another account”. Tarcza, czyli charakterystyczny symbol UAC (o którym pisałem tutaj) informuje nas o konieczności posiadania uprawnień administratora:
Następnie wybieramy opcję „Add a new user in PC settings”:
Teraz, będąc finalnie w odpowiednim miejscu, mamy możliwość kliknięcia w „Add account”:
Jeżeli maszyna ma połączenie z internetem, w pierwszym korku kreator będzie starał się „zachęcić” nas do zalogowania się na konto Microsoft osoby, której konto dodajemy. Na tym etapie wybieramy opcję „I don’t have this person’s sign-in information”:
Następnie kreator ponownie będzie zachęcał nas do skorzystania z konta Microsoft – tym razem oferując możliwość jego stworzenia. Z racji, że nie chcemy tego robić, wybieramy opcję „Add a user without a Microsoft account”:
W tym momencie trafiamy do właściwego kreatora, który pozwoli nam na stworzenie konta lokalnego. Jak widać, jest on nieco mniej rozbudowany niż w przypadku poprzedniego sposobu. Określamy więc nazwę użytkownika. W Windowsie 10 od wersji 1803 możliwe jest również samodzielne resetowanie haseł przez użytkowników. W tym celu kreator oferuje nam możliwość ustawienia trzech pytań, na które będzie trzeba w takim przypadku odpowiedzieć. Nie jest to delikatnie mówiąc idealne rozwiązanie z punktu widzenia bezpieczeństwa, choć ujmuje nieco pracy administracyjnej w tym zakresie. Wypełniając tego typu pytania należy pamiętać, aby odpowiedzi z jednej strony były łatwe do odtworzenia, ale z drugiej ciężkie do odgadnięcia na podstawie np. publicznie dostępnych danych:
Po przejściu tego krótkiego kreatora konto lokalne zostaje utworzone na komputerze. Z tego poziomu możemy również nadać mu odpowiednie uprawnienia, klikając na wybrane konto, następnie na „Change account type” oraz wybierając odpowiednią rolę z listy:
Poprzez Command Line
Tworząc konta z poziomu Command Line-a będziemy posługiwali się poleceniem „net user”, które pozwala na zarządzanie kontami lokalnymi. Do jego wykorzystania niezbędne są oczywiście uprawnienia administratora, czyli de facto uruchomienie Command Line-a jako administrator. Konto lokalne możemy stworzyć posługując się prostym poleceniem:
net user /add <Nazwa użytkownika> <Hasło do tworzonego konta> Przełącznik „/add” odpowiada tutaj oczywiście za tworzenie nowego konta. W praktyce polecenie może wyglądać np. tak:
Nie zawsze jednak pokazywanie hasła użytkownika na ekranie komputera będzie dobrym pomysłem. Hasło możemy również wprowadzić w formie zamaskowanej korzystając z polecenia:
net user /add <Nazwa użytkownika> *„*” spowoduje w tym przypadku ukrycie hasła. Konsola poprosi nas o dwukrotne wprowadzenia hasła w konsoli, nie ujawniając przy tym wpisywanego hasła na ekranie:
Polecenie „net user” oferuje nam oczywiście o wiele więcej dodatkowych opcji przy okazji tworzenia konta. Możemy dodatkowo określić takie parametry jak „Full Name” czyli wyświetlana nazwa użytkownika, określić czy tworzone konto ma być od razu włączone czy ograniczyć możliwość logowania na konto do konkretnych dni i godzin. Dostępnych opcji jest wiele, a ich pełną listę można znaleźć np. w dokumentacji Microsoft-u dla tego polecenia. Przykładowe polecenie tworzące nowe konto oraz określające wymienione wyżej kwestie może wyglądać następująco:
net user /add <Nazwa użytkownika> * /active:<yes/no> /fullname:"<Wyświetlana nazwa użytkownika>" /times:<zakres dni złożony z skrótów angielskich nazw>,<godziny w notacji 24h lub 12h>W praktyce polecenie może wyglądać np. tak:
Poprzez PowerShell
Tworzenie kont lokalnych za pomocą PowerShell-a jest w moim odczuciu nawet prostsze, niż w przypadku Command Line. Podstawowym poleceniem, którym należy posługiwać się przy okazji tworzenia kont lokalnych poprzez PowerShell-a jest polecenie „New-LocalUser”. W przypadku PowerShell-a hasło możemy wczytywać do odpowiedniej zmiennej przed utworzeniem konta – odczytując je z pliku czy wpisując je ręcznie. Przykładowe polecenie, a w zasadzie polecenia, pozwalające na utworzenie nowego konta mogą wyglądać następująco:
$Password = Read-Host -AsSecureString
New-LocalUser "<nazwa użytkownika>" -Password $PasswordW tym przypadku hasło wpisywane będzie przez nas ręcznie i zapisywane do zmiennej w postaci zaszyfrowanej. Polecenie Net-LocalUser będzie tworzyło konto, a hasło będzie w tym przypadku odczytywane ze zmiennej, w której zostało przed chwilą zapisane. W praktyce polecenie może wyglądać następująco:
Oczywiście PowerShell, podobnie jak Command Line, pozwala nam na zastosowanie wielu przełączników, pozwalających na jeszcze bardziej precyzyjną konfigurację konta użytkownika. Pełną listę przełączników również można znaleźć w poświęconej poleceniu dokumentacji Microsoftu.
Ten artykuł został pierwotnie opublikowany w marcu 2021 roku i dotyczył kont lokalnych w Windows 10. Powyższy artykuł stanowi aktualizację związaną z kwestią kont lokalnych w ramach Windows 11.
Coś jest dla Ciebie niezrozumiałe? Chciałbyś wyrazić opinię na temat artykułu? Znalazłeś jakiś błąd? Koniecznie daj mi o tym znać wysyłając maila lub wypełniając formularz!
Bardzo czytelnie napisany artykuł. Wyjaśniłem sobie wiele wątpliwości. Dziękuję.