Konfiguruję maszynę wirtualną serwera Ubuntu 11.04 do użytku jako serwer bazy danych. Ułatwiłoby to wszystkim życie, gdybyśmy mogli zalogować się przy użyciu poświadczeń systemu Windows, a może nawet sprawić, że komputer będzie działał z obecnymi zabezpieczeniami opartymi na AD, które mamy gdzie indziej.

Pierwsza część tego była naprawdę łatwa do zrealizowania - apt-get install likewise-opena ja byłem prawie w interesach. Problem, który mam, polega na tym, że dostaję naszych administratorów do grup sudoersów - wydaje mi się, że nie mogę dostać nic do wzięcia. Próbowałem:

a) usermod -aG sudoers [username]
b) dodawanie nazw użytkowników w kilku formatach (DOMAIN \ użytkownik, użytkownik @ domena) do pliku sudoers.

Nic z tego nie wydawało się, nadal pojawia się komunikat „DOMAIN \ użytkownik nie znajduje się w pliku sudoers. Ten incydent zostanie zgłoszony”.

Jak więc dodać nielokalnych użytkowników do sudoers?

Napotykam ten problem i oto moje rozwiązanie:

Edycja /etc/sudoers: z następującymi wpisami

Najpierw sprawdź aduser za pomocą identyfikatora polecenia

#id <AD user>( #id domain\\aduser01 )

Wyniki na moim:

SMB\aduser01@linux01:~/Desktop$ id smb\\aduser02
uid=914883676(SMB\aduser02) gid=914883073(SMB\domain^users) groups=914883073(SMB\domain^users),1544(BUILTIN\Administrators),1545(BUILTIN\Users),914883072(SMB\domain^admins)

getent passwdi gid NUMBERSnie działa dla mnie. DOMAIN\\domain^userspracuje dla mnie

%SMB\\domain^users ALL=(ALL) ALL

jak wszyscy wiemy, działa również indywidualny użytkownik AD

SMB\\<aduser01> ALL=(ALL) ALL

mamy długą nazwę domeny z sufiksem .local,

bliżej

%domainname\\group ALL=(ALL) ALL

ani

%domainname.local\\group ALL=(ALL) ALL

pracował ...

ale jeśli użyję tylko nazwy grupy w ten sposób:

%Domain^Admins ALL=(ALL) ALL

to działa.

Problem z innymi sugestiami jest taki

• działają tylko wtedy, gdy masz dostęp do korporacyjnej sieci LAN (lub VPN)
• musisz utrzymywać plik sudoers na każdym komputerze przez cały czas
• jako bonus, dla mnie nie działały

Zamiast tego chciałem czegoś takiego

• buforuje zarówno poświadczenia, jak i dostęp sudo
• jest zarządzany centralnie

Rzeczywistym rozwiązaniem jest użycie SSSD i rozszerzenie schematu AD. W ten sposób SSSD okresowo pobiera ustawienia sudo i poświadczenia użytkownika z AD i utrzymuje ich lokalną pamięć podręczną. Reguły sudo są następnie przechowywane w obiektach AD, w których można ograniczyć reguły do ​​komputerów, użytkowników i poleceń, a wszystko to bez dotykania pliku sudoers na stacjach roboczych.

Dokładny samouczek jest zbyt długi, aby go tu wyjaśnić, ale możesz znaleźć przewodnik krok po kroku i kilka skryptów ułatwiających automatyzację tutaj:

• Integracja Ubuntu z Active Directory

TL; DR:

OGŁOSZENIE

Pobierz najnowszą wersję sudo , pobierz plik doc / schema.ActiveDirectory , a następnie zaimportuj go (pamiętaj, aby zmodyfikować ścieżkę domeny zgodnie z nazwą domeny):

ldifde -i -f schema.ActiveDirectory -c "CN=Schema,CN=Configuration,DC=X" "CN=Schema,CN=Configuration,DC=ad,DC=foobar,DC=com" -j .

Sprawdź to za pomocą Edycji ADSI: otwórz kontekst nazewnictwa schematu i poszukaj klasy sudoRole .

Teraz utwórz jednostkę sudoers w katalogu głównym domeny, ta jednostka organizacyjna będzie przechowywać wszystkie ustawienia sudo dla wszystkich stacji roboczych z systemem Linux. W ramach tej jednostki organizacyjnej utwórz obiekt sudoRole. Aby utworzyć obiekt sudoRole, musisz użyć Edycji ADSI, ale po utworzeniu możesz go zmodyfikować za pomocą Użytkownicy i komputery usługi Active Directory .

Załóżmy, że mam komputer o nazwie foo32linux , użytkownik o nazwie stewie.griffin i chcę pozwolić mu uruchamiać wszystkie polecenia z sudo na tym komputerze. W takim przypadku tworzę obiekt sudoRole pod OU sudoers . W sudoRole możesz użyć dowolnej nazwy - trzymam się nazwy komputera, ponieważ używam reguł dla poszczególnych komputerów. Teraz ustaw jego atrybuty w następujący sposób:

• sudoHost : foo32linux
• sudoCommand : ALL
• sudoUser : stewie.griffin

Do poleceń możesz także użyć określonych pozycji, takich jak / bin / less lub cokolwiek innego.

SSSD

Dodaj do swojego /etc/sssd/sssd.conf przynajmniej:

[sssd]
services = nss, pam, sudo

[domain/AD.FOOBAR.COM]
cache_credentials = True

SSSD odświeża lokalną pamięć podręczną przy użyciu zaktualizowanych reguł co kilka godzin, ale najprostszym sposobem przetestowania jest ponowne uruchomienie komputera. Następnie zaloguj się z użytkownikiem AD i sprawdź:

sudo -l

Powinien zawierać listę wszystkich powiązanych wpisów dodanych do tego użytkownika i komputera. Bułka z masłem!

Najlepsze informacje, jakie mogłem znaleźć na ten temat, znajdują się tutaj:

http://www.mail-archive.com/likewise-open-discuss@lists.likewisesoftware.com/msg00572.html

Zasadniczo prosi o zmodyfikowanie /etc/sudoerspliku za pomocą prawidłowej konfiguracji, aby umożliwić osobom z grupy administratora w AD dostęp do wszystkich uprawnień.

Jeśli musisz być wybiórczy i ograniczyć użytkownika, możesz to zrobić. Ostrzega jednak, że musisz się dowiedzieć, jak nazywa się nazwa użytkownika w systemie Linux, używając getend passwdpolecenia, jak pokazano.

Za pomocą Centify direct dodałem użytkownika domeny do pliku / etc / sudoers.

(Użytkownik domeny) ALL = (ALL) ALL

Używam wspólnego polecenia

sudo usermod -a -G sudo DOMAIN\username 

i wymienić DOMAIN\userz DOMAIN\\\username.