User Tools

Site Tools


projects:ldap

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
Last revisionBoth sides next revision
projects:ldap [2012/03/09 09:25] tomekprojects: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''**   * Użytkowników w **''ou=People,dc=hackerspace,dc=pl''**
   * Grupy w **''ou=Group,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''**   * Możliwe że aliasy? Wtedy w **''ou=Aliases,dc=hackerspace,dc=pl''**
 +
 +<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: 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:
Line 22: Line 39:
   * (testowo) dokuwiki na itanicu   * (testowo) dokuwiki na itanicu
  
-Planowana funkcjonalność:+**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) 
 +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'</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.   * Centralne miejsce przechowywania informacji o użytkownikach.
     * Kto ma mieć prawo edytować informacje?     * Kto ma mieć prawo edytować informacje?
-    * Jak dobrze dodawać użytkowników? Chyba najtrudniejsze jest upewnienie się, że UIDy będą unikalne.+    * 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   * Kontrola kto ma dostęp do czego
     * Lista dostępów     * Lista dostępów
     * Stworzenie odpowiednich grup     * Stworzenie odpowiednich grup
     * Upewnienie się, że potrafimy odpowiednio po grupach filtrować     * 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   * Integracja z systemami
-    * Lista systemówjakie mają z tego korzystać+    * 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:+**Pytania:**
   * Jakie grupy tworzymy?   * Jakie grupy tworzymy?
   * Czy aliasy też chcemy przetrzymywać?   * Czy aliasy też chcemy przetrzymywać?

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki