« wróć do listy
Następny Wpis NA LIŚCIE (W DÓŁ)
Polecenia useradd i newusers - Dodawanie nowych użytkowników - cz.5 Fragmenty artykułów z książek wydawnictwa Helion.pl
39 osób twierdzi: warto przeczytać
Następny Wpis NA LIŚCIE (W GÓRĘ)
Kororaa Linux 15.1 KDEFamily.pl
4 osoby twierdzą:: warto przeczytać

Szósta i ostatnia część rozdziału nr 7 książki:
Unix i Linux. Przewodnik administratora systemów. Wydanie IV

7.7. USUWANIE UŻYTKOWNIKÓW

Gdy użytkownik opuszcza organizację, jego konto i pliki powinny zostać usunięte z systemu. Procedura ta wymaga usunięcia wszystkich odwołań do nazwy użytkownika, które były dodane przez Ciebie lub przez program useradd. Jeśli usuwasz użytkownika ręcznie, możesz posłużyć się poniższą listą czynności do wykonania:

  • usuń użytkownika ze wszystkich spisów telefonów i lokalnych baz danych o użytkownikach,
  • usuń użytkownika z pliku aliases lub dodaj adres do przekazywania poczty,
  • usuń plik crontab użytkownika i wszystkie jego zadania at lub kolejki wydruku,
  • zabij wszystkie działające procesy użytkownika,
  • usuń użytkownika z plików passwd, shadow, group i gshadow, (/etc/security/ passwd, group w systemie AIX)
  • usuń katalog domowy użytkownika,
  • usuń skrzynkę pocztową użytkownika,
  • usuń jego wpisy z kalendarzy grupowych, systemów rezerwacji pomieszczeń itd.,
  • usuń lub przekaż uprawnienia do list dyskusyjnych prowadzonych przez usuniętego użytkownika.

Zanim usuniesz czyjś katalog domowy, pamiętaj o tym, aby przenieść w inne miejsce wszelkie pliki, które mogą być potrzebne innym użytkownikom. Zazwyczaj trudno określić, o jakie pliki może chodzić, dlatego przed ich usunięciem zawsze warto wykonać dodatkową kopię zapasową katalogu domowego użytkownika i skrzynki pocztowej.

Po usunięciu użytkownika możesz sprawdzić, czy jego stary numer UID nie jest właścicielem plików w systemie. Aby wyszukać takie osierocone pliki, możesz użyć polecenia find z argumentem –nouser. Ponieważ polecenie find potrafi „uciec” na serwery sieciowe, jeśli nie zachowasz ostrożności, zwykle najbezpieczniej sprawdzać osobno poszczególne systemy plików za pomocą opcji –xdev:

$ sudo find system_plików -xdev -nouser

Zabicie działających procesów usuniętego użytkownika może być nieco utrudnione w środowiskach rozproszonych. W kalendarzach grupowych i systemach rezerwacji pomieszczeń mogą istnieć aktywne wpisy wprowadzone przez nieistniejącego już użytkownika i należy je stamtąd usunąć. Prawdopodobnie w swoim środowisku znajdziesz więcej tego rodzaju miejsc, z których trzeba usunąć ślady po użytkowniku — zrób własną listę, np. w formie skryptu czyszczącego.

Jeśli w Twojej organizacji przydziela się użytkownikom własne stacje robocze, na ogół najprostszym i najbardziej wydajnym rozwiązaniem jest powtórne odtworzenie całego systemu z głównego obrazu przed przekazaniem go nowemu użytkownikowi. Przed przeprowadzeniem nowej instalacji warto jednak wykonać kopię lokalnych plików znajdujących się na dysku twardym na wypadek, gdyby były potrzebne w przyszłości.

W każdym z naszych przykładowych systemów występuje polecenie userdel, które automatyzuje proces usuwania użytkownika. Najprawdopodobniej nie przeprowadzi ono tego zdania tak dokładnie, jak byś sobie tego życzył, chyba że skrupulatnie wprowadzisz do niego nowe funkcje, rozszerzające liczbę miejsc, w których przechowywane są informacje związane z użytkownikiem.

W systemie Ubuntu deluser to skrypt Perla, który wywołuje tradycyjne polecenie userdel; cofa on wszystkie operacje wykonane przez adduser. Aby ułatwić lokalizację ustawień, wywołuje skrypt deluser.local, jeśli taki istnieje. Plik konfiguracyjny /etc/deluser.conf umożliwia ustawienie następujących opcji.

  • Czy usunąć katalog domowy i skrzynkę pocztową użytkownika?
  • Czy wykonać kopię plików użytkownika i gdzie je umieścić?
  • Czy usunąć wszystkie pliki należące do użytkownika?
  • Czy usunąć grupę, jeśli nie ma już żadnych członków?

SUSE obsługuje zestaw skryptów do wykonywania zadań wstępnych i końcowych, a także skrypt userdel.local, który wspomaga polecenie userdel, informując domyślne narzędzie o lokalnych ustawieniach. Możesz je skonfigurować w pliku /etc/login.defs.

W systemie Red Hat istnieje skrypt userdel.local, ale nie ma żadnych skryptów do wykonywania zadań wstępnych i końcowych, które automatyzowałyby takie rzeczy jak wykonywanie kopii plików użytkownika przeznaczonego do usunięcia.

Systemy Solaris i AIX mają kilka dodatkowych miejsc, w których przechowywane są informacje o użytkownikach, przede wszystkich chodzi tu o pliki kontrolujące role i klasy autoryzacji. Dlatego też polecenia userdel w tych systemach mają nieco więcej pracy do wykonania przy czyszczeniu wszystkich odwołań do usuniętego użytkownika.

Przykładowo, oprócz /etc/passwd i /etc/group, polecenie userdel w systemie Solaris aktualizuje również pliki /etc/shadow, /etc/project i /etc/user_attr. W systemie AIX polecenie userdel modyfikuje w katalogu /etc/security następujące pliki: user, user.roles, lastlog, environ, audit/config, limits, passwd i group. Solaris nie jest tak skrupulatny, jak można by oczekiwać: jego polecenie userdel pozostawiło testowy login z profilem skonfigurowanym w pliku user_attr, który powinien zostać wyczyszczony.

W systemie HP-UX polecenie userdel to banalny, prosty skrypt, który usuwa zmiany wprowadzone przez useradd. Modyfikuje tylko pliki passwd, shadow i group.

7.8. WYŁĄCZANIE KONT

Czasami zdarza się, że konto użytkownika musi zostać tymczasowo wyłączone. Najprostszym sposobem jest dopisanie gwiazdki lub innego znaku na początku zaszyfrowanego hasła użytkownika w plikach /etc/security/passwd (AIX) lub /etc/shadow. Uniemożliwi to większość prób dostępu na hasło, ponieważ tak zmodyfikowanego hasła nie da się sensownie odszyfrować. Jednak takie polecenia jak ssh, które niekoniecznie muszą sprawdzać hasła systemowe, mogą nadal funkcjonować.

We wszystkich dystrybucjach Linuksa polecenia usermod -L użytkownik i usermod -U użytkownik umożliwiają łatwe zablokowanie i odblokowanie hasła. Jest to po prostu szybszy sposób wykonania na haśle opisanych powyżej operacji: opcja -L umieszcza znak ! na początku zaszyfrowanego hasła w pliku /etc/shadow, a opcja -U go usuwa.

W systemie Solaris użytkownik root może zablokować konto za pomocą polecenia passwd -l nazwa_użytkownika, zmusić użytkownika do zmiany hasła za pomocą opcji -f lub odblokować konto za pomocą opcji –u. Zablokowanie konta powoduje wstawienie znaków *LK* do pola z hasłem w pliku /etc/shadow. Jest to również wartość ustawiana dla użytkowników przez polecenie useradd.

System HP-UX obsługuje tylko hasła zaszyfrowane algorytmem crypt. Znak * nigdy nie występuje w polu hasła wygenerowanym przez crypt, dlatego dopisanie go do zaszyfrowanego hasła uniemożliwi zalogowanie się użytkownika.

W systemie AIX konto jest zablokowane, jeśli plik /etc/passwd zamiast znaku ! zawiera *. Za pomocą polecenia pwdadm można wymusić na użytkowniku zmianę hasła lub zablokować jego konto, tak aby tylko administrator mógł zmienić hasło.

Niestety, zmodyfikowanie hasła użytkownika po prostu uniemożliwi logowanie. Użytkownik nie zostanie powiadomiony o zawieszeniu konta ani poinformowany o powodach, dla których konto nie działa. Innym sposobem wyłączenia konta jest zastąpienie powłoki użytkownika programem, który wyświetli komunikat z wyjaśnieniem i wytłumaczy, co należy zrobić w takiej sytuacji. Następnie program zakończy działanie, zamykając sesję logowania.

Takie podejście ma zarówno zalety, jak i wady. Nie zostaną wyłączone te formy dostępu, które sprawdzają hasło, ale nie zwracają uwagi na powłokę. Aby ułatwić przeprowadzenie sztuczki z wyłączeniem powłoki, wiele demonów zapewniających dostęp bez logowania do systemu (np. ftpd) sprawdza, czy powłoka logowania użytkownika jest wymieniona w pliku /etc/shells; jeśli jej tam nie ma, następuje odmowa dostępu. O takie zachowanie nam chodzi. Niestety, nie jest ono powszechne, jeśli więc zdecydujesz się na wyłączanie kont przez modyfikowanie powłoki, będziesz musiał przeprowadzić dość wyczerpujące testy.

Kolejny problem polega na tym, że jeśli użytkownik spróbuje się zalogować przez system X Window lub za pośrednictwem emulatora terminala, który nie pozostawia widocznego wyjścia po wylogowaniu, może nigdy nie zobaczyć Twojego starannie napisanego wyjaśnienia powodów zawieszenia konta.

Domyślnie program sendmail nie dostarczy poczty użytkownikowi, którego powłoka nie występuje w pliku /etc/shell. Zakłócanie przepływu poczty to zły pomysł, nawet jeśli odbiorca i tak nie może jej natychmiast przeczytać. Możesz obejść to domyślne zachowanie programu sendmail, dodając do pliku /etc/shells fałszywą powłokę o nazwie /SENDMAIL/ANY/SHELL/.

7.9. ZARZĄDZANIE UŻYTKOWNIKAMI ZA POMOCĄ NARZĘDZI SYSTEMOWYCH

Systemy HP-UX i AIX wyposażono we wszechstronne narzędzia do administracji systemem, które potrafią zarządzać użytkownikami, przynajmniej w podstawowym zakresie. W systemie AIX jest to SMIT (ang. System Management Interface Tool), a w HP-UX nosi ono obecnie nazwę smh (ang. System Management Homepage) (We wcześniejszych wersjach systemu HP-UX miało ono nazwę sam (ang. System Administration Manager).
Każde z tych narzędzi zawiera ekrany przeznaczone do dodawania użytkowników i zarządzania nimi, przy wykorzystaniu interfejsu graficznego lub w formie terminala z menu opartym na bibliotece curses. Jeśli jesteś zupełnie początkującym administratorem lub wcześniej pracowałeś w całkiem innym systemie operacyjnym, narzędzia te będą sensownym punktem wyjścia dla wielu często wykonywanych zadań administracyjnych.

Program SMIT z systemu AIX ma przydatną opcję: jeśli naciśniesz klawisz F6, wyświetlone zostaną polecenia i argumenty zaplanowane do wykonania. Ponadto rejestruje on całą interakcję i przechowuje plik skryptowy zawierający polecenia, które zostały wykonane w Twoim imieniu. Może to być dobre narzędzie do nauki w miarę zapoznawania się z zawiłościami systemu AIX. Oparty na bibliotece curses program smh z systemu HP-UX oferuje przydatne, jednoznakowe skróty. Są one widoczne na każdej stronie menu i umożliwiają szybkie przejście do potrzebnego polecenia.

7.10. MINIMALIZOWANIE RYZYKA ZA POMOCĄ PAM

Dołączalne moduły uwierzytelniania (PAM, ang. Pluggable Authentication Module) omawiane są w rozdziale 22., „Bezpieczeństwo”, na stronie 1113. Umożliwiają one centralne zarządzanie systemowymi funkcjami uwierzytelniania za pośrednictwem standardowych procedur bibliotecznych, dzięki czemu takie programy jak login, sudo, passwd i su nie muszą dostarczać własnego kodu uwierzytelniającego. Mechanizm PAM zmniejsza ryzyko związane z pisaniem bezpiecznego oprogramowania, umożliwia administratorom określanie zasad bezpieczeństwa w ramach całego ośrodka i definiuje łatwy sposób dodawania do systemu nowych metod uwierzytelniania.

Dodawanie i usuwanie użytkowników nie wiąże się z modyfikowaniem konfiguracji PAM, ale narzędzia biorące w tym udział działają zgodnie z regułami i ograniczeniami PAM. Poza tym wiele parametrów konfiguracyjnych PAM przypomina te, które są używane przez useradd lub usermod. Jeśli zmienisz parametry w sposób przedstawiony w tym rozdziale, a useradd nie będzie na nie zwracać uwagi, sprawdź, czy konfiguracja PAM w systemie nie nadpisuje Twoich nowych wartości.

7.11. SCENTRALIZOWANE ZARZĄDZANIE KONTAMI

Pewne formy scentralizowanego zarządzania kontami są niezbędne w średnich i dużych organizacjach, niezależnie od tego, czy będą to przedsiębiorstwa, uczelnie, czy urzędy państwowe. W całej organizacji użytkownicy potrzebują wygody i bezpieczeństwa przy stosowaniu tej samej nazwy użytkownika, numeru UID i hasła. Administratorzy muszą dysponować scentralizowanym system umożliwiającym natychmiastowe rozpropagowanie zmian (takich jak unieważnienie konta) do każdego miejsca.

Takie scentralizowanie można osiągnąć na wiele sposobów, z których większość (włącznie z systemem Active Directory firmy Microsoft) wymaga zastosowania LDAP (ang. Lightweight Directory Access Protocol), przynajmniej w pewnym zakresie. Istnieje wiele dostępnych rozwiązań: od schematycznych instalacji LDAP opartych na oprogramowaniu open source, po wyrafinowane komercyjne systemy zarządzania tożsamością, które kosztują masę pieniędzy.

LDAP a Active Directory

LDAP to uniwersalne repozytorium bazodanowe, które może przechowywać nie tylko dane związane z zarządzaniem użytkownikami, ale i inne typy danych. Używa się w nim hierarchicznego modelu klient-serwer, który może obsługiwać wiele serwerów i jednoczesnych klientów. Jedną z wielkich zalet LDAP jako repozytorium dla danych logowania w ramach całego ośrodka jest to, że może ono wymusić unikatowe numery UID i GID we wszystkich systemach. Poza tym dobrze współpracuje z systemem Windows, choć w drugą stronę tylko w niewielkim stopniu.

Więcej informacji na temat LDAP i jego implementacji można znaleźć w podrozdziale rozpoczynającym się na stronie 899.

Usługa Active Directory firmy Microsoft korzysta z protokołów LDAP oraz Kerberos i może zarządzać wieloma rodzajami danych włącznie z informacjami o użytkownikach. Jest nieco egotyczna i w interakcji z repozytoriami LDAP systemu Unix i Linux chce pełnić funkcję nadrzędną. Jeśli potrzebujesz pojedynczego systemu uwierzytelniania dla całego ośrodka, w którym oprócz systemów Unix i Linux są również komputery z systemem Windows, prawdopodobnie najprościej będzie przekazać kontrolę Active Directory, a uniksowe i linuksowe bazy danych LDAP wykorzystywać jako serwery drugorzędne.

Aby zaimplementować taką konfigurację, będziesz potrzebować Active Directory i Services for Unix firmy Microsoft lub komercyjnej platformy integracyjnej Active Directory, takiej jak Quest Authentication Services (dawniej Vintela Authorization Services). Virtual Directory firmy Sun może pomóc Ci w integracji różnych systemów autoryzujących (uwierzytelniających).

Każdy z naszych czterech przykładowych systemów ma wbudowaną obsługę LDAP, choć czasem tylko po stronie klienta (np. HP-UX). LDAP często występuje w parze z PAM w celu przeprowadzania uwierzytelnienia.

LDAP jest bazą danych, dlatego przechowywane tu informacje muszą przestrzegać ściśle określonego schematu. Schematy wyrażane są w postaci plików XML, z polami nazw pochodzących z odpowiednich dokumentów RFC; jeśli chodzi o zarządzanie użytkownikami, jest to głównie RFC 2307. Dokładniejsze informacje na ten temat znajdziesz w rozdziale 19., „Współdzielenie plików systemowych”.

Systemy pojedynczego logowania

Systemy pojedynczego logowania (SSO, ang. single sign-on) zachowują równowagę między wygodą użytkownika a względami bezpieczeństwa. Idea polega na tym, aby użytkownik mógł się uwierzytelnić po jednorazowym zalogowaniu (po znaku zachęty, na stronie WWW lub w oknie systemu Windows). Użytkownik uzyskuje wtedy potwierdzenie tożsamości (zazwyczaj niezauważalnie, więc nie jest tu wymagane aktywne zarządzanie), które może później wykorzystać do uzyskania dostępu do innych komputerów i aplikacji. Użytkownik musi zapamiętać tylko jeden login i hasło zamiast wielu.

Taki schemat dopuszcza stosowanie bardziej złożonych poświadczeń (ponieważ użytkownik nie musi o nich pamiętać ani nawet się nimi zajmować), co teoretycznie zwiększa poziom bezpieczeństwa. Jednak nieuprawnione przejęcie konta może spowodować większe szkody, ponieważ jeden login zapewni napastnikowi dostęp do wielu komputerów i aplikacji. Systemy SSO stanowią duże zagrożenie w sytuacji, gdy użytkownik odejdzie od komputera, a wciąż będzie zalogowany. Poza tym serwery uwierzytelniające stają się krytycznym wąskim gardłem. Ich awaria może sparaliżować pracę całego przedsiębiorstwa.

Systemy SSO to stosunkowo prosta idea, jednak wdrożenie jej wiąże się z wieloma komplikacjami, ponieważ poszczególne aplikacje i komputery, z których użytkownik może chcieć korzystać, muszą rozumieć proces uwierzytelniania i znać poświadczenia SSO. W niektórych systemach SSO poświadczeniami użytkowników zarządza Kerberos; zostało to omówione dokładniej w rozdziale 22., „Bezpieczeństwo”, od strony 1133.

Istnieje kilka systemów SSO na licencji open source:

  • JOSSO, serwer SSO na licencji open source napisany w języku Java,
  • CAS (ang. Central Authentication Service), opracowany na uniwersytecie Yale (również w języku Java),
  • Likewise Open, narzędzie integracyjne, które sprawia, że Active Directory dobrze współpracuje z systemami Linux i Unix.

Dostępnych jest również mnóstwo systemów komercyjnych. Większość z nich jest zintegrowana z pakietami zarządzania tożsamością, które zostaną omówione w następnym punkcie.

Systemy zarządzania tożsamością

„Zarządzanie tożsamością” to najnowsze modne hasło w dziedzinie zarządzania użytkownikami. Mówiąc po ludzku, oznacza to identyfikowanie użytkowników Twojego systemu, poświadczanie ich tożsamości i przyznawanie uprawnień na podstawie tych uwierzytelnionych tożsamości. Działania standaryzacyjne w tej dziedzinie prowadzone są przez World Wide Web Consortium i The Open Group.

Komercyjne systemy zarządzania tożsamością łączą kilka kluczowych pojęć systemu Unix w jeden miły dla oka graficzny interfejs użytkownika wypełniony marketingowym żargonem. Podstawą wszystkich tego rodzaju systemów jest baza danych zawierająca uwierzytelnienia użytkowników i dane autoryzacyjne, często zapisana w formacie LDAP. Kontrolę zapewniają takie pojęcia jak grupy systemu Unix, a ograniczone uprawnienia administracyjne wymuszane są za pośrednictwem narzędzi w rodzaju sudo. Większość tego rodzaju systemów została zaprojektowana zgodnie z wymogami prawnymi dotyczącymi odpowiedzialności, monitorowania i dzienników kontroli.

Istnieje wiele takich systemów komercyjnych: Identity Management firmy Oracle, Sun Identity Management Suite, Courion, Avatier Identity Management Suite (AIMS) i BMC Identity Management Suite, by wymienić tylko kilka z nich. (Sun Identity Management Suite - teraz, gdy firma Sun została przejęta przez Oracle, nie jest pewne, czy system ten będzie nadal oferowany jako osobny produkt.)

Dokonując oceny systemów zarządzania tożsamością, zwróć uwagę na następujące cechy:

  • generowanie globalnie unikatowych identyfikatorów użytkownika,
  • możliwość tworzenia, zmiany i usuwania kont użytkowników w całej organizacji, niezależnie od sprzętu i systemu operacyjnego,
  • bezpieczny interfejs WWW do zarządzania z możliwością dostępu z zewnątrz,
  • możliwość łatwego wyświetlania wszystkich użytkowników, którzy mają określony zestaw uprawnień,
  • prosty sposób podglądu wszystkich uprawnień przydzielonych określonemu użytkownikowi,
  • możliwość pozwolenia użytkownikowi na zmianę (i zresetowanie) własnych haseł, z wymuszeniem reguł wyboru silnych haseł,
  • możliwość globalnej zmiany swoich haseł przez użytkowników za pomocą jednej operacji,
  • mechanizm obiegowej organizacji pracy, np. warstwowy system zatwierdzeń przed przyznaniem użytkownikowi określonych uprawnień,
  • możliwość koordynacji z bazą danych działu kadr w celu automatycznego zablokowania dostępu pracownikom, którzy złożyli wypowiedzenie lub zostali zwolnieni,
  • konfigurowalne rejestrowanie wszystkich zmian i działań administracyjnych,
  • konfigurowalne raporty tworzone na podstawie zarejestrowanych danych (z podziałem na użytkowników, daty itd.),
  • kontrola dostępu oparta na rolach, w tym obsługa kont użytkowników za pomocą ról,
  • interfejs, za pomocą którego osoba odpowiedzialna za rekrutację może poprosić o skonfigurowanie kont zgodnie z określoną rolą,
  • wyjątki w działaniach opartych na rolach, łącznie z obiegiem określającym proces zatwierdzania wyjątków.

Weź również pod uwagę sposób wdrożenia systemu w miejscach, gdzie odbywa się właściwa autoryzacja i uwierzytelnianie. Czy system wymaga zainstalowania wszędzie własnego agenta, czy dopasowuje się do podległych mu systemów?

7.12. ZALECANA LITERATURA

„The Complete Buyer’s Guide for Identity Management”, dokumentacja firmy Sun Microsystems, 2008 r., sun.systemnews.com/articles/129/4/sec/20930.

7.13. ĆWICZENIA

Ćwiczenie 7.1. W jaki sposób ustalana jest domyślna grupa użytkownika? Jak można ją zmienić?

Ćwiczenie 7.2. Wyjaśnij różnice między następującymi wartościami umask: 077, 027, 022 i 755. W jaki sposób ustawiłbyś jedną z tych wartości jako domyślną maskę dla nowych użytkowników w ramach całej organizacji? Czy możesz wymusić na swoich użytkownikach używanie standardowej wartości umask?

Ćwiczenie 7.3. Do czego służy plik przesłaniania haseł (shadow)?

* Ćwiczenie 7.4. Określ system uwierzytelniania używany przez program login w Twoim systemie. Jeśli korzysta z PAM, ustal, jakie inne programy w systemie również z niego korzystają.

* Ćwiczenie 7.5. Wymień czynności wymagane w celu dodania użytkownika do systemu bez użycia programu useradd. Jakie dodatkowe czynności są wymagane w Twoim lokalnym środowisku?

* Ćwiczenie 7.6. Ustal konwencję nazewniczą dla nowych użytkowników w Twojej organizacji. Jakie rządzą nią reguły? W jaki sposób zapewniana jest niepowtarzalność nazw? Czy możesz wskazać jakieś wady? Jak są usuwani użytkownicy?

** Ćwiczenie 7.7. Znajdź listę nazwisk (np. z lokalnego spisu telefonów dostępnego on-line) i wykorzystaj je jako dane wejściowe dla skryptu tworzącego nazwy użytkowników zgodnie z konwencją nazewniczą przyjętą w Twojej organizacji. Ilu użytkowników udało Ci się dodać przed wystąpieniem kolizji? Ile kolizji było ogółem? Wykorzystaj te dane do oceny konwencji nazewniczej w Twojej organizacji i zaproponuj usprawnienia.

** Ćwiczenie 7.8. Napisz skrypt pomocny w monitorowaniu poprawności pliku /etc/passwd (punkty b i e wymagają dostępu do konta użytkownika root, chyba że jesteś zdolny):
a) znajdź wszystkie wpisy z identyfikatorem UID równym 0,
b) znajdź wszystkie wpisy bez hasła (wymaga dostępu do pliku /etc/shadow),
c) znajdź wszystkie zestawy wpisów o zduplikowanych identyfikatorach UID,
d) znajdź wszystkie wpisy ze zduplikowanymi nazwami użytkownika,
e) znajdź wszystkie wpisy bez daty wygaśnięcia (wymaga dostępu do pliku /etc/shadow).

***** Ćwiczenie 7.9. Napisz moduł PAM, który przeprowadza uwierzytelnianie za pomocą losowo generowanego kodu PIN, wysyłając go na telefon komórkowy użytkownika jako wiadomość SMS, a następnie prosi o wpisanie tego kodu w celu weryfikacji. Zainstaluj swój moduł i skonfiguruj go w stosie logowania PAM, aby uzyskać dwustopniowe uwierzytelnianie.

Koniec ostatniej części rozdziału nr 7 książki:
Unix i Linux. Przewodnik administratora systemów. Wydanie IV .

Poprzednie części:

Pierwsza część:
http://www.linuxportal.pl/artykuly/dodawanie-nowyc/.../-1-id98820

Druga część:
http://www.linuxportal.pl/artykuly/plik-etc-passwo/.../-2-id99146

Trzecia część:
http://www.linuxportal.pl/artykuly/pliki-etc-shado/.../-3-id99590

Czwarta część:
http://www.linuxportal.pl/artykuly/podstawy-dodawa/.../-4-id99882

Piąta część:
http://www.linuxportal.pl/artykuly/polecenia-usera/.../5-id100018

Udostępnij informacje o Wpisie w sieciach społecznościowych:
Polub LinuxPortal.pl:

Komentarze: 1

logo:
Aby dodać komentarz: zaloguj się ikona LinuxPortal.pl ikona Facebook.com ikona Google+
logo:
12 lat temu
W sumie to ciekawy temat :-)
Odpowiedz #174683
Przejdź na początek komentarzy

Wpisy z blogów/ TOP 30dni

Pliki /etc/shadow, /etc/security/passwd i /etc/group - Dodawanie nowych użytkowników - cz.3 Fragmenty artykułów z książek wydawnictwa Helion.pl
41 osób twierdzi: warto przeczytać
Polecenia useradd i newusers - Dodawanie nowych użytkowników - cz.5 Fragmenty artykułów z książek wydawnictwa Helion.pl
39 osób twierdzi: warto przeczytać
Prosta kompilacja jądra jack
35 osób twierdzi: warto przeczytać
Linux for Woman Beings KDEFamily.pl
35 osób twierdzi: warto przeczytać
Wpisy z blogów więcej:
W związku z wejściem w życie 25 maja 2018 roku nowego Rozporządzenia o Ochronie Danych Osobowych znanym jako "RODO" pragniemy poinformować Cię,
w jaki sposób przetwarzane są dane osobowe pozostawiane przez Ciebie podczas korzystania z LinuxPortal.pl.
Zapoznaj się z Polityką prywatności.

Klikając „Zamknij”, zamykasz ten komunikat i wyrażasz zgodę na przetwarzanie tych danych, w tym w plikach cookies, przez LinuxPortal.pl sp. z o.o. w celu realizacji usług zgodnie z Regulaminem.
Zamknij »