OpenLDAP - dalsza integracja z katalogiem + “hartowanie”

18 czerwiec 2008, autorstwa: kozik

Powoli kolejne usługi w laboratorium integruję z katalogiem pracującym na OpenLDAP. Początkowo z katalogu korzystała tylko Samba udostępniająca dyski sieciowe i zarządzająca domeną Windows. Teraz lista poszerzyła się o…

W połączeniu z mechanizmem do zmiany haseł przez WWW mamy centralne zarządzanie bazą użytkowników oraz ich haseł, a sami użytkownicy mają jeden login i jedno hasło na wszystkie usługi. To jest piękne, choć nie idealne :) .

Zabezpieczenie samego OpenLDAP-a nie jest trywialne tym bardziej, że nie chciałem wymuszać szyfrowania dla każdej transmisji. Dokładniej mówiąc - nieszyfrowany może być dostęp z localhosta, a wszystko zdalne - już odpowiednio zabezpieczone. Da się zrealizować to dzięki rozbudowanym ACL-om w konfiguracji slapd.conf i pozwoleniu na dowolne połączenia z 127.0.0.1 oraz na pozostałe przy SSF (Security Strength Factor) równym 256.

# Atrybuty SambaLMPassword, SambaNTPassword:
# - do zapisu przez konto-proxy Samby
# - do zapisu przez właściciela danego elementu
# - anonimowi mogą spróbować się do tego uwierzytelnić
# - reszcie odmówić
# Ograniczenia szyfrowania:
# - lokalnie - bez ograniczeń SSF
# - Inaczej - SSF 256
access to attrs=SambaLMPassword,SambaNTPassword
by peername.regex=127\.0\.0\.1 dn="cn=samba_proxy,dc=ldap,dc=com" write
by ssf=256 dn="cn=samba_proxy,dc=ldap,dc=com" write
by peername.regex=127\.0\.0\.1 self write
by ssf=256 self write
by peername.regex=127\.0\.0\.1 anonymous auth
by ssf=256 anonymous auth
by * none
# Atrybut userPassword
# - do zapisu przez konto-proxy Samby
# - do odczytu przez konto-proxy MediaWiki
# - do zapisu przez właściciela danego elementu
# - anonimowi mogą spróbować się do tego uwierzytelnić
# - reszcie odmówić
# Ograniczenia szyfrowania:
# - lokalnie - bez ograniczeń SSF
# - Inaczej - SSF 256
access to attrs=userPassword
by peername.regex=127\.0\.0\.1 dn="cn=samba_proxy,dc=ldap,dc=com" write
by ssf=256 dn="cn=samba_proxy,dc=ldap,dc=com" write
by peername.regex=127\.0\.0\.1 dn="cn=wiki_proxy,dc=ldap,dc=com" read
by ssf=256 dn="cn=wiki_proxy,dc=ldap,dc=com" read
by peername.regex=127\.0\.0\.1 self write
by ssf=256 self write
by peername.regex=127\.0\.0\.1 anonymous auth
by ssf=256 anonymous auth
by * none
# reszta katalogu:
# - do zapisu przez konto-proxy Samby
# - do odczytu przez konto-proxy dla MediaWiki
# - do zapisu przez właściciela danego elementu
# - do odczytu przez użytkowników
# - reszcie odmówić
# Ograniczenia szyfrowania:
# - lokalnie - bez ograniczeń SSF
# - Inaczej - SSF 256
access to *
by peername.regex=127\.0\.0\.1 dn="cn=samba_proxy,dc=ldap,dc=com" write
by ssf=256 dn="cn=samba_proxy,dc=ldap,dc=com" write
by peername.regex=127\.0\.0\.1 dn="cn=wiki_proxy,dc=ldap,dc=com" read
by ssf=256 dn="cn=wiki_proxy,dc=ldap,dc=com" read
by peername.regex=127\.0\.0\.1 self write
by ssf=256 self write
by peername.regex=127\.0\.0\.1 users read
by ssf=256 users read
by * none
# Zabronienie anonimowego dostępu:
require authc

Jedyny zgrzyt następuje przy próbie rozpoczęcia sesji TLS przez lokalną stronę PHP (a dokładniej przez LaboPasswordChanger) - raz się udaje, raz wykrzacza się na TLS negotiation failed. Pomijając to niedociągnięcie, to konfiguracja wydaje się bezpieczna, wydajna i co ważne - działa w praktyce oferując ogromne uproszczenie i wygodę dla użytkowników.

Wysłano w Blog - Kozik | Tags: , , , |

Adres dla trackback. RSS dla komentarzy w tym wpisie.
Dodaj komentarz




Uwaga: Włączona jest moderacja komentarzy, więc nowy komentarz nie ukaże się bezpośrednio po jego wysłaniu.

Uwaga: Działa filtr antyspamowy. Jeśli umieścisz w komentarzu odnośniki, to może on zostać błędnie zakwalifikowany jako spam.