This is an old revision of the document!
Lightweight Directory Access Protocol - usługa katalogowa, metoda przechowywania informacji “o czymkolwiek”. U nas na początek planujemy wykorzystywać do centralnego przechowywania informacji o użytkownikach, grupach, do czego kto ma dostęp…
Aktualnie drzewo jest dla dc=hackerspace,dc=pl
Planujemy tam trzymać:
- Użytkowników w
ou=People,dc=hackerspace,dc=pl
- Grupy w
ou=Group,dc=hackerspace,dc=pl
- cn=fatty,ou=Group,dc=hackerspace,dc=pl - członkowie stow. fatty
- cn=starving,ou=Group,dc=hackerspace,dc=pl - członkowie stow. starving
- cn=wiki-admin,ou=Group,dc=hackerspace,dc=pl - konta z prawami admina na wiki
- Możliwe że aliasy? Wtedy w
ou=Aliases,dc=hackerspace,dc=pl
Obecnie, ponieważ wiki uznaje dc=wiki,dc=hackerspace,dc=pl za base dn swoich zapytań o istniejące grupy, istnieje też grupa cn=ngo-members,dc=wiki,dc=hackerspace,dc=pl zawierająca wszystkie konta członków stowarzyszenia. Obecnie ta grupa utrzymywana jest ręcznie, bo jest tymczasowa. Chcę zmienić istniejącą grupę cn=admin,dc=wiki,dc=hackerspace,dc=pl na cn=wiki-admin,ou=Group,dc=hackerspace,dc=pl oraz przekonfigurować dokuwiki, żeby korzystała z ou=Group,dc=hackerspace,dc=pl
Aktualnie dostęp do odczytu do całego drzewa mają wszyscy, nawet użytkownicy nieautoryzowani - jedynym wyjątkiem jest hasło, gdzie dostęp masz (również do zapisu) tylko do swojego po udanej autoryzacji, albo każdy by próbować się zalogować (odpowiedź typu tak/nie, nie ma odczytu). Wszelkie zmiany może dokonywać wyłącznie użytkownik administracyjny. Jest to realizowane następującym ACL:
access to * attrs=userPassword by self write by * auth access to * by * read
Aktualnie z usługi korzystają:
- logowanie na itanic'a za pomocą PAM
- prosody (serwer XMPP)
- OpenVPN
- (testowo) dokuwiki na itanicu
Planowana funkcjonalność:
- Centralne miejsce przechowywania informacji o użytkownikach.
- Kto ma mieć prawo edytować informacje?
- Jak dobrze dodawać użytkowników? Chyba najtrudniejsze jest upewnienie się, że UIDy będą unikalne. Najprawdopodobniej da się to uzyskać za pomocą Attribute Uniqueness opisanego tutaj - obecnie włączone są te więzy na uidNumber i uid obiektów klasy posixAccount. może grupy też warto by tym objąć?
- Kontrola kto ma dostęp do czego
- Lista dostępów
- Stworzenie odpowiednich grup
- Upewnienie się, że potrafimy odpowiednio po grupach filtrować
- Znalazłem 2 polecane metody kontroli dostępu do serwerów:
- Obiekt Host per maszyna, ludzie dodawani do memberOf, w PAM filtrowanie po członkostwie
- Każdy użytkownik ma właściwość 'host' gdzie wpisuje sie maszyny na jakie może się zalogować, w PAM łatwo włączyć sprawdzanie tego (require_host ??)
- Integracja z systemami
- PAM @ itanic (posixGroup; dn: cn=itanic-shell,ou=Group,dc=hackerspace,dc=pl)
- Dokuwiki @ itanic (domain; dn: dc=wiki,dc=hackerspace,dc=pl)
- XMPP @ itanic (groupOfNames; dn: cn=xmpp-users,ou=Group,dc=hackerspace,dc=pl)
- Wordpress @ itanic
- OpenVPN @ itanic (posixGroup; dn: cn=vpn-users,ou=Group,dc=hackerspace,dc=pl)
- mail @ itanic (inetLocalMailRecipient; objectClass: person)
- PAM @ proliant (posixGroup; dn: cn=proliant-shell,ou=Group,dc=hackerspace,dc=pl)
- sudo @ proliant / itanic (posixGroup; dn: cn=staff,ou=Group,dc=hackerspace,dc=pl)
- checkinator @ proliant
Pytania:
- Jakie grupy tworzymy?
- Czy aliasy też chcemy przetrzymywać?
- Jaki ma być dostęp dla “świata” i użytkowników niezalogowanych?
- Jaki ma być dostęp dla poszczególnych usług (i czy tworzymy dla nich dedykowane loginy?)
- Kto ma mieć prawo edytować jakie informacje?
- Jakie procedury potrzebujemy zdefiniować? (nowy członek, czasowy lockout, nowy wikipedysta…?)