Prywatność& Pliki cookie
Ta strona używa plików cookie. Kontynuując, zgadzasz się na ich użycie. Dowiedz się więcej, w tym jak kontrolować pliki cookie.
aktualizacja: zdałem sobie sprawę, że dziś napisałem ten sam temat dwa razy, w dwóch różnych postach., Ten należy uznać za połączony wysiłek, ale może czytać trochę jak Frankenstein blog. Oryginał z drugiej pozostaje tutaj:
ten post jest częścią 5 nowej serii LDAP zacząłem pomagać ludziom stać się bardziej świadomi, czym jest LDAP i jak to działa.
część pierwsza została zamieszczona tutaj:
Co to w ogóle jest LDAP?
ten post skupi się na serwerach i klientach LDAP.,
Serwery vs klienci
w królestwie zwierząt często można zobaczyć związki symbotyczne, takie jak rzekoma relacja między krokodylami a siewką, która zjada martwe rzeczy z zębów krokodyla.
relacja klient-serwer LDAP jest również symbiotyczna. Serwer potrzebuje klienta do zadawania pytań, a klient potrzebuje serwera do przekazywania informacji.,
Jeśli natura nie jest twoja, zawsze istnieje symbiotyczna relacja Spider-Man/Venom:
w przypadku LDAP, klient będzie pytał o nazwy użytkowników, lokalizacje katalogów domowych, członkostwo w grupach itp. Serwer byłby odpowiedzialny za dostarczenie tych informacji.
LDAP nie różni się od innych protokołów, takich jak HTTP, NFS itp. Istnieje relacja klient-serwer. I tak jak każdy udany związek, musi być ktoś mówiący, a ktoś słuchający.
mam dwuletniego syna. Mówi, ale większość to tylko praktyka dla niego., Powie coś w stylu „tato, ciężarówka z ptakami.”A ja powiem” ptak? Ciężarówka? Super!”Jest to głównie jednostronna rozmowa, w której zasadniczo ACK jego SYNs.
czasami jest to „doda czyta książkę.”I podporządkowuję się.
rozmowy klienta/serwera LDAP nie różnią się zbytnio. Klient to mój dwuletni syn. Serwer LDAP to ja.
„LDAP, Znajdź informacje o użytkowniku”
„informacje o użytkowniku? Super! Proszę bardzo!”
u samej podstawy rozmowy LDAP są niczym innym jak synami TCP i ACK. Tak więc, podczas konfigurowania lub rozwiązywania problemów, powinny być traktowane jako takie.,
Kiedy sprawy się komplikują, zaczynasz zastanawiać się, co trzeba zrobić, aby relacja klient-serwer zakończyła się sukcesem. Nie jest dobrym pomysłem, aby pozostawić kanały komunikacji szeroko otwarte dla wszystkich na świecie, aby zobaczyć, więc są pewne zasady, których musimy przestrzegać, gdy klienci chcą rozmawiać z serwerami.
Konfiguracja klienta/serwera
klientami LDAP może być dowolne działające oprogramowanie, które może odpytywać LDAP za pomocą standardów RFC-2307. Windows, Linux, systemy operacyjne systemów pamięci masowej itp. mogą działać jako klienci., Niektóre systemy operacyjne zawierają wbudowane funkcje LDAP (takie jak Windows), które nie wymagają instalowania niczego specjalnego. Niektóre systemy pamięci masowej, takie jak NetApp clustered Data ONTAP, w pełni obsługują LDAP, który jest zgodny ze standardem RFC-2307. Aby uzyskać więcej informacji, zobacz TR-4073: bezpieczne ujednolicone uwierzytelnianie.
podstawowe informacje o sieci.
pamiętaj, że u podstawy jest to prosta rozmowa TCP.
- nazwy serwerów LDAP, URI lub adresy IP (czy serwer jest w DNS? Czy są zapisy SRV dla LDAP?,)
- port LDAP (domyślne porty to 389 dla LDAP, 636 dla LDAP przez SSL, 3268 dla Global Catalog; zmieniłeś port serwera?)
- czy klient może rozmawiać z serwerem (routing?)
zanim klient może rozpocząć rozmowę z serwerem, musi być skonfigurowany z informacjami o tym serwerze. Konfiguracja będzie zgodna z podstawami modelu OSI, zaczynając od kilku pierwszych warstw stosu, aby rozpocząć rozmowę TCP z serwerem.
popularne klienty LDAP
klienci LDAP również mają tendencję do przestrzegania tych samych standardów, co serwery. Dlaczego?, Bo to ma sens. Klienci mogą być niezależni od systemu operacyjnego, ale niektóre OSE domyślnie integrują LDAP w swojej konfiguracji. Windows jest tego przykładem ze względu na to, jak integralny jest LDAP w Active Directory.
inni klienci to (ale z pewnością nie są ograniczone do):
- SSSD
- OpenLDAP
mam nadzieję, że informacje zawarte w tym poście pomogły wyjaśnić wszelkie nieporozumienia na klientach i serwerach LDAP.
niektóre serwery LDAP pozwalają nawet na modyfikacje portu, na którym nasłuchuje do komunikacji z LDAP., Ma to pomóc zabezpieczyć serwery LDAP, nie wykorzystując dobrze znanych portów. W przypadku popularnych serwerów LDAP, takich jak Active Directory, trudno jest jednak używać innych portów niż te popularne. Podczas konfigurowania klientów konfiguracja serwera LDAP zawsze wymaga przeglądu.
Po przejściu połączenia TCP spędzamy czas w warstwie aplikacji modelu OSI.
najpierw musimy się martwić o uwierzytelnienie na serwer LDAP. Jest to również znane jako Wiązanie., Poziom uwierzytelniania będzie zależał od tego, na co serwer został ustawiony. Najniższy możliwy poziom uwierzytelniania to „anonimowy”, ale żaden nowoczesny serwer LDAP nie dopuszcza domyślnie anonimowych wiązań. Ogólnie rzecz biorąc, konto tylko do odczytu na serwerze LDAP jest wymagane do uwierzytelnienia na serwerze w celu wysyłania zapytań LDAP.
niezbędne informacje bind są zawarte w konfiguracji klienta. W przypadku najbezpieczniejszej konfiguracji preferowane jest korzystanie z systemu uwierzytelniania opartego na bilecie lub kluczu niż korzystanie z haseł.,
informacje o wyszukiwaniu LDAP
Po wywołaniu wiązania zapytania są wykonywane. Charakter zapytań zależy od konfiguracji klienta. Jakiego schematu używamy? Jakich informacji potrzebujemy? Czy skonfigurowaliśmy klienta, aby upewnić się, że cały czas próbuje LDAP informacji (przez nsswitch.konfiguracja konf)? Czy powiedzieliśmy klientowi, od czego ma zacząć szukać informacji na serwerze LDAP, podając podstawowy DN?
To mówi klientowi, od czego zacząć szukać informacji na serwerze LDAP.,Format tych informacji to Distinguished Names (DNs), które omówiłem w części 4. Możesz ustawić bazowy DN, a następnie określony DNs dla użytkowników, grup, grup sieciowych itp. Możesz nawet określić wiele lokalizacji do wyszukiwania. Chodzi o to, aby filtrować nasze wyszukiwania, aby przyspieszyć sprawy dla klientów.
ciekawostka: Apple automatycznie koryguje DNs Do DNS. Niefajnie, Apple. Niefajnie.
gdy klient LDAP zdobędzie niezbędne informacje, powinien się odłączyć – nie chcemy pozostawać zalogowani na czas nieokreślony. To wieprz zasobów.
informacje o schemacie LDAP
szczegółowo opisuję Schematy w części 3., Wielu klientów wie o domyślnych schematach używanych przez LDAP, takich jak RFC – 2307, RFC-2307BIS, itp. W większości przypadków Schematy na serwerze nie odbiegają od tego. Ale w niektórych przypadkach, na przykład za pomocą ręcznej interwencji lub narzędzi innych firm, takich jak Dell Vintela (znany również jako Centrify, Quest itp.), może zaistnieć potrzeba wprowadzenia zmian. Można to zrobić na kliencie. Pozwala to klientowi poprosić o odpowiednie informacje z serwera, co następnie pozwala serwerowi znaleźć informacje i odpowiedzieć klientowi.,
opcje specyficzne dla Klienta
wielu klientów oferuje określone opcje, takie jak buforowanie użytkowników / grup, poświadczenia, konfiguracja Kerberos itp. Są one zazwyczaj opcjonalne, ale powinny być rozpatrywane w zależności od dostawcy klienta.
Przykładowa konfiguracja klienta
poniżej przedstawiono przykład, jak wyglądałby klient LDAP z klastrem danych:
tak wygląda moja konfiguracja klienta z systemem SSSD:
Serwery
Jeśli chcesz, aby klienci pytali o informacje, potrzebujesz serwera., Serwer musi mieć poprawny schemat RFC-2307, aby zawierał niezbędne obiekty LDAP. Jeśli robisz LDAP oparte na Uniksie i chcesz używać Microsoft Active Directory do obsługi uwierzytelniania opartego na Uniksie, musisz upewnić się, że serwer ma atrybuty UNIX w schemacie. Podczas gdy Microsoft Active Directory działa na backendzie LDAP, nie jest to prawdą, że serwer LDAP oparty na Uniksie, dopóki nie rozszerzysz schematu. Trochę o tym mówię w moim wpisie na blogu na IDMU.
jak wspomniano w sekcji klient, potrzebujesz kilku informacji, aby skonfigurować klientów. Serwer to miejsce, z którego pochodzą te informacje., Oto rzeczy, które musisz sprawdzić na serwerze, aby upewnić się, że poprawnie skonfigurujesz swoich klientów:
- informacje o sieci serwera (adres IP, nazwa hosta, wpisy DNS, rekordy SRV, porty serwera LDAP itp.)
- obsługiwany poziom bind (użyj najsilniejszego dostępnego, jeśli to możliwe)
- poprawny użytkownik bind lub SPN
- informacje DN
- typ schematu/atrybuty
serwery LDAP mogą hostować mnóstwo informacji. Unix user creds, Windows creds, netgroups, IP addresses, SPNs, name mapping rules…. To zależy tylko od tego, co klienci obsługują, które określają, z czego możesz korzystać.,
popularne serwery LDAP
wszystkie serwery LDAP mają tendencję do przestrzegania wspólnego zestawu standardów zdefiniowanych przez IETF. Ma to zapewnić szeroki zakres wsparcia dla klientów., Niektóre z bardziej popularnych serwerów LDAP obejmują (ale nie są ograniczone do):
- Active Directory
- OpenLDAP
- RedHat Directory Server/389 Directory Server
- Apple Open Directory
- Oracle Internet Directory
- Apacheds
polecenia LDAP
Jeśli używasz wielu serwerów LDAP, a Klient nie jest w stanie Znajdź obiekt w podanej domenie serwera LDAP, może on próbować użyć polecenia LDAP, aby zajrzeć do innych serwerów., Zasadniczo pobiera informacje z serwera LDAP o innych serwerach, o których wiemy i próbuje połączyć się z nimi za pomocą URI LDAP, dopóki a) nie znajdzie obiektu lub b) nie skończy się serwer, aby spróbować. Może się to zdarzyć zarówno na serwerach LDAP Windows, jak i innych niż Windows. Niektórzy klienci LDAP nie obsługują „poszukiwania poleceń”, dlatego ważne jest, aby wiedzieć, czy dzieje się to w Twoim środowisku i czy twój Klient jest w stanie ścigać polecenia.,
globalne wyszukiwanie katalogów
W Active Directory możliwe jest przechowywanie kopii atrybutów z wielu domen w lesie na lokalnych kontrolerach domen działających jako globalne serwery katalogów. Domyślnie atrybuty Uniksa nie są replikowane do katalogu globalnego, ale można zmienić to zachowanie w razie potrzeby. Opisuję jak to zrobić w TR-4073. Jeśli potrzebujesz odpytywać wiele domen w tym samym lesie i chcesz uniknąć poleceń LDAP, możesz po prostu replikować niezbędne atrybuty I zmienić port LDAP na 3268, aby dać serwerom znać, aby zamiast tego używali globalnego katalogu!,
moje środowisko
w moim środowisku używam Active Directory LDAP z zarządzaniem tożsamościami. Ale byłem znany z korzystania z usług katalogowych OpenLDAP i RedHat. Oba są w pełni poprawne w użyciu. Jednak, jeśli chcesz zrobić multiprotocol NAS (CIFS / SMB i NFS), zdecydowanie sugeruję użycie Microsoft Active Directory do uwierzytelniania użytkowników UNIX i Windows. Sprawia, że życie jest nieskończenie łatwiejsze.
Jeśli już używasz LDAP opartego na Linuksie, to w porządku. Jeśli to możliwe, spróbuj upewnić się, że nazwy użytkowników Uniksa (atrybut UID LDAP) są zgodne z nazwami użytkowników systemu Windows (atrybut sAMAccount)., W ten sposób, jeśli używasz multiprotocol NAS, nie musisz się martwić o mapowanie nazw.
Jeśli chcesz zobaczyć coś dodanego do tego wpisu dotyczącego serwerów i klientów LDAP, zapraszam do komentowania lub śledzenia mnie na Twitterze @Nfsdudeabides!
podsumowanie
aby uzyskać bardziej szczegółowe informacje na temat konfiguracji LDAP (szczególnie z NetApp clustered Data ONTAP), zobacz TR-4073: Secure Unified Authentication.
Więcej informacji na temat serii podstaw LDAP znajdziesz na tym blogu!,
linki do innych działów można znaleźć w pierwszym poście z tej serii:
Co to w ogóle jest LDAP?