Differences

This shows you the differences between two versions of the page.

--- projects:ldap [2012/03/09 08:58] – Wyjaśnienie działania aktualnych ACL viq
+++ projects:ldap [2014/04/02 06:57] – external edit 127.0.0.1
@@ Line 6: / Line 6: @@
   * 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''**
-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:
+<del>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</del>
+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:
 <code>access to * attrs=userPassword
         by self write
@@ Line 21: / Line 37: @@
   * 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:
+<code># ldapsearch -x | head -n -5 > ldap-$(date +%F).ldif</code>
+ - logujesz się na ldap-staging i orientujesz, czy nikt inny nie przeprowadza testów
+<code># who</code>
+ - zatrzymujesz slapd
+<code># rc-service slapd stop</code>
+ - 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:
+<code>rm /var/lib/openldap-data/*</code>
+ - wgrywasz wydmuszkę jako user //ldap//:
+<code># sudo -u ldap slapadd -vl ldap-$(date +%F).ldiff</code>
+ - na pewno, pokaże się błąd, że brakuje niektórych atrybutów, np:
+<code>"##############        71.06% eta    09s elapsed             22s spd   1.5 k/s added: "ou=Boxen,dc=hackerspace,dc=pl" (0000007e)
+bac69a 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'</code>
+ - dopisz odpowiedni atrybut do swojej 'wydmuszki' (ldiff'a) - dla powyższego przykładu w linii 3143:
+<code>userPassword: test</code>
+ - wyczyść ponownie /var/lib/openldap-data/ i wgrywaj wydmuszkę do skutku. Po wgraniu ldiff'a w całości (100% sygnalizowane przez slapadd), odpal slapd:
+<code>#rc-service slapd start</code>
+ - 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:
+<code>OPTS="${OPTS_CONF} -h 'ldaps:// ldap:// ldapi://%2fvar%2frun%2fopenldap%2fslapd.sock' -d conns filter config ACL stats stats2 shell parse"</code>
+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 [[http://www.openldap.org/doc/admin24/overlays.html|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...?)