ZimaOS obecnie nie dokumentuje natywnego uwierzytelniania LDAP ani Active Directory dla kont właściciela/członków ani udziałów Samby. Obsługiwany model wielu użytkowników nadal opiera się na lokalnych kontach członków ZimaOS i uprawnieniach przypisanych do poszczególnych udziałów.
Źródłowy wątek był zgłoszeniem funkcji od użytkowników domowych laboratoriów i małych firm, którzy chcieli korzystać z tożsamości domenowych. Żadna odpowiedź IceWhale nie ogłaszała obsługi LDAP, dlatego nie należy konfigurować serwera LDAP w Dockerze i zakładać, że Samba w ZimaOS automatycznie zacznie z niego korzystać.
Co obecnie obsługuje ZimaOS
Aktualny przewodnik ZimaOS dotyczący obsługi wielu użytkowników Samby opisuje lokalne konta członków, hasła, dostęp gościnny i uprawnienia do folderów.
Dlaczego samo uruchomienie OpenLDAP w Dockerze nie wystarczy
Kontener LDAP może udostępniać usługę katalogową aplikacjom obsługującym LDAP, ale warstwa kont i Samby w ZimaOS nadal wymaga jawnej integracji z LDAP/SSSD/winbind. Aktualna dokumentacja ZimaOS nie opisuje takiej integracji.
Korzystaj z LDAP na poziomie aplikacji tam, gdzie jest obsługiwany
Nadal możesz uruchomić dostawcę tożsamości i połączyć z nim poszczególne aplikacje — takie jak Nextcloud lub inne oprogramowanie obsługujące LDAP/OIDC. Pozwala to scentralizować logowanie do aplikacji, nawet jeśli ZimaOS nadal korzysta z lokalnych kont NAS.
Administrację NAS trzymaj oddzielnie
W systemie domowym lub małym biurze lokalna tożsamość właściciela/administratora zmniejsza ryzyko utraty dostępu do zarządzania pamięcią masową w razie awarii katalogu.
Mapuj dostęp SMB za pomocą lokalnych członków
Utwórz członka ZimaOS dla każdego użytkownika potrzebującego dostępu SMB, przydziel mu tylko wymagane udziały i wyłącz dostęp gościnny do poufnych folderów.
Nie modyfikuj Samby bezrefleksyjnie, aby dołączyć ją do domeny
Dołączenie Samby do AD zwykle obejmuje Kerberos, winbind/SSSD, NSS/PAM, dane uwierzytelniające komputera, DNS i trwałą konfigurację. ZimaOS jest systemem typu appliance, dlatego niezarządzane zmiany pakietów lub konfiguracji mogą zostać utracone albo wejść w konflikt z wbudowaną usługą udostępniania.
Hybrydowa architektura tożsamości
Dostawca LDAP / OIDC
├─ Nextcloud
├─ Inne aplikacje Docker
└─ Usługi wewnętrzne
Lokalne konta ZimaOS
├─ Właściciel/administrator
└─ Konta członków SMB
Nie zapewnia to jednokrotnego logowania wszędzie, ale pozostaje łatwe w utrzymaniu przy obecnych granicach produktu.
Przewodnik po kontroli dostępu zawiera przydatny kontekst dotyczący bezpieczeństwa.
Używaj jednego źródła tożsamości dla każdej warstwy
Jeśli aplikacje korzystają z LDAP, a SMB w ZimaOS z lokalnych członków, jasno opisz ten podział użytkownikom. Unikaj tworzenia identycznych nazw użytkowników z różnymi hasłami, chyba że masz zasady zarządzania hasłami, ponieważ może to wyglądać jak niedziałające jednokrotne logowanie.
Twórz osobne kopie zapasowe usługi katalogowej
Jeśli uruchamiasz OpenLDAP, Authentik, Keycloak lub inną usługę tożsamości w Dockerze, jej baza danych oraz dane podpisywania i konfiguracji wymagają własnej kopii zapasowej. Utrata dostawcy tożsamości może pozbawić użytkowników dostępu do każdej podłączonej do niego aplikacji.
Nie uzależniaj odzyskiwania NAS od LDAP
Zachowaj co najmniej jedno lokalne konto właściciela ZimaOS, które może administrować pamięcią masową nawet wtedy, gdy kontener katalogu, DNS lub sieć są niedostępne. Zapewnia to ścieżkę odzyskiwania podczas awarii usługi tożsamości.
FAQ
Czy ZimaOS może obecnie dołączyć do Active Directory?
Nie. W aktualnej dokumentacji ZimaOS nie opisano firmowej procedury dołączania do AD/LDAP.
Czy mogę uruchomić OpenLDAP w ZimaOS?
Tak, jako aplikację Docker, ale nie sprawi to automatycznie, że Samba w ZimaOS zacznie uwierzytelniać użytkowników za jego pomocą.
Czy aplikacje Docker mogą korzystać z LDAP?
Tak, jeśli dana aplikacja obsługuje LDAP lub inny protokół tożsamości.
Czego używać dla użytkowników SMB?
Korzystaj z aktualnych lokalnych kont członków ZimaOS i uprawnień przypisanych do poszczególnych udziałów.
