User Tools

Site Tools


projects:ldap

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…?)
projects/ldap.1352854420.txt.gz · Last modified: 2014/04/02 06:57 (external edit)

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki