OpenLDAP - dalsza integracja z katalogiem + “hartowanie”
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…
- MediaWiki (uwierzytelnienie, użytkownicy i grupy)
- Apache (uwierzytelnienie i autoryzacja z wykorzystaniem mod_authnz_ldap)
- Skrzynki IMAP-owe (Dovecot)
- Serwer jabberd2 (uwierzytelnienie do LDAP-a, dane sesji/użytkowników w MySQL)
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: bezpieczeństwo, linux, open-source, praca |

wrzesień 15th, 2008 at 14:25
Mały update ostatniego problemu (TLS przez lokalny skrypt PHP) - trzeba się po prostu przerzucić na użycie PEAR/Net_LDAP2. Rozwiązuje ten problem oraz jest całkiem wygodnym pośrednikiem do funkcji bibliotecznych PHP->LDAP.