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 - członkowie stow. fatty
  • cn=starving - członkowie stow. starving
  • cn=zarzad - członkowie zarządu stow.
  • cn=rewizja - członkowie komisji rewizyjnej stow.
  • cn=wiki-user - konta użytkowników z dostępem do większości wiki (z wyjątkiem stron finansowych i głosowań)
  • cn=wiki-admin - konta z prawami admina na wiki
  • cn=xmpp-users - konta z dostępem do serwera XMPP
  • cn=ldap-admin - konta z dostępem admin do serwera LDAP
  • cn=mifare-authority - konta z dostępem do hashy kart w zamku
  • cn=calendar - konta z możliwością postowania w kalendarzu?
  • cn=twitter - konta z możliwością postowania na Twittera
  • cn=itanic-shell - konta z dostępem shellowym do serwera itanic (teraz boston)
  • cn=zbigniew-shell - konta z dostępem shellowym do serwera Zbigniew
  • cn=vpn-users - konta z możliwością dostępu przez VPN
• 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. Stworzona na jej podstawie ACLka na wiki umożliwia dostęp do strony finansowej 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

Staging / Mini - Backup \ restore HowTo

LDAP postawiony na zbigniewie i b-p służy do celów produkcyjnych. Jeśli ktoś nie czuje się pewnie ze zmianą, którą chce wprowadzić, do dyspozycji jest wirtualka ldap-staging (10.13.37.9) dostępna w Zoo.

Procedura przygotowania staging wygląda następująco:

- na serwerze produkcyjnym wykonujesz 'wydmuszkę' ldap, która nie zawiera danych wrazliwych, typu, hasła, hashe mifare:

# ldapsearch -x | head -n -5 > ldap-$(date +%F).ldif

- logujesz się na ldap-staging i orientujesz, czy nikt inny nie przeprowadza testów

# who

- zatrzymujesz slapd

# rc-service slapd stop

- sprawdzasz, czy plik konfiguracyjny slapd pokrywa się w istotnych kwestiach z konfiguracją serwera, z którego zgrana była wydmuszka. Następnie czyścisz obecną bazę ldapa:

rm /var/lib/openldap-data/*

- wgrywasz wydmuszkę jako user ldap:

# sudo -u ldap slapadd -vl ldap-$(date +%F).ldiff

- na pewno, pokaże się błąd, że brakuje niektórych atrybutów, np:

"##############        71.06% eta    09s elapsed             22s spd   1.5 k/s added: "ou=Boxen,dc=hackerspace,dc=pl" (0000007e)
50bac69a Entry (cn=proliant,ou=Boxen,dc=hackerspace,dc=pl): object class 'simpleSecurityObject' requires attribute 'userPassword'
slapadd: dn="cn=proliant,ou=Boxen,dc=hackerspace,dc=pl" (line=3143): (65) object class 'simpleSecurityObject' requires attribute 'userPassword'

- dopisz odpowiedni atrybut do swojej 'wydmuszki' (ldiff'a) - dla powyższego przykładu w linii 3143:

userPassword: test

- czyścimy ponownie /var/lib/openldap-data/ i wgrywamy wydmuszkę do skutku. Po wgraniu ldiff'a w całości (100% sygnalizowane przez slapadd), startujemy slapd:

#rc-service slapd start

- W razie problemów, włącz debug w /etc/conf.d/slapd do zmiennej OPTS dopisując parametr -d i informacje, które Cie interesują (do znalezienia w man slapd.conf). Przykładowy OPTS z debugiem:

OPTS="${OPTS_CONF} -h 'ldaps:// ldap:// ldapi://%2fvar%2frun%2fopenldap%2fslapd.sock' -d conns filter config ACL stats stats2 shell parse"

And let the hack fest begin!

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: cn=wikiuser,ou=Group,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)
  • 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…?)