Kontroler domeny na Linux’ie

  I. Konfiguracja głównego kontrolera domeny PDC Zakładamy, iż serwer usług katalogowych LDAP typu master oraz serwer plików skonfigurowany jako główny kontroler domeny (primary domain controller - PDC) będą działały […]

 

I. Konfiguracja głównego kontrolera domeny PDC

Zakładamy, iż serwer usług katalogowych LDAP typu master oraz serwer plików skonfigurowany jako główny kontroler domeny (primary domain controller - PDC) będą działały na tym samym hoście.

Przyjmujemy, iż komunikacja miedzy serwerami oraz między serwerem a lokalnymi klientami odbywać się będzie otwartym tekstem bez szyfrowania danych (SSL/TLS). Konfiguracja szyfrowanych połączeń zostanie przedstawiona w dalszej części tego opisu.

Główny kontroler domeny nosi nazwę PDC-BOGUS.

2. Konfiguracja serwera usług katalogowych LDAP typu MASTER

Zakładamy, iż konfigurowany serwer LDAP jest serwerem typu master i będzie stanowił backend dla głównego kontrolera domeny (PDC) działającego na bazie serwera plików Samba.

2.1. Instalacja

2.1.1. Pierwsza instalacja

Wykorzystany zostanie serwer usług katalogowych OpenLDAP. Serwer ten w dystrybucji Gentoo jest dostarczany wraz z oprogramowaniem klienckim. Całość można zainstalować podając jedno polecenie w linii komend:

root / #emerge openldap

2.1.2. Reinstalacja lub upgrade

Reinstalacja/upgrade serwera LDAP zazwyczaj jest równoznaczne z przeniesieniem katalogu LDAP miedzy instancjami serwera OpenLDAP. Taka operacja nie jest sprawą trywialną nawet, jeśli nowa instancja serwera LDAP jest instalowana w miejscu swojego poprzednika.

W każdym razie istnieją dwie metody przeniesienia zawartości katalogu LDAP: skopiowanie plików katalogu LDAP w postaci binarnej lub export/import katalogu z pomocą pliku LDIF.

2.1.2.1. Uwagi dot. wersji oprogramowania

Zasoby katalogowe serwera LDAP istnieją w postaci binarnej (zazwyczaj w katalogu /var/lib/openldap-data) i są zarządzane przez backend bazodanowy BerkeleyDB (sys-libs/db w Gentoo Portage). Serwer OpenLDAP bardzo ściśle współpracuje z pakietem BerkeleyDB podczas przetwarzania danych katalogowych.

Niestety pakiet BerkeleyDB jest b. rozwojowy i istnieje wiele niekompatybilności nawet między jego kolejnymi podwersjami. Jeśli chcemy dokonać upgradu pakietu BerkeleyDB przy okazji upgradu serwera OpenLDAP wówczas export katalogu do pliku LDIF oraz import z pliku LDIF do nowego serwera LDAP może okazać się jedynym rozwiązaniem.

Na dzien dzisiejszy (2006.04.13) pracujący serwer OpenLDAP w wersji 2.2.28 wykorzystuje pakiet BerkeleyDB w wersji 4.2.52_p2.

Jeśli Gentoo Portage oferuje pakiet BerkeleyDB w wersji wyższej wówczas należy wymusić instalację w wersji, która nas interesuje:

root / #emerge =sys-libs/db-4.2.52_p2

I następnie zainstalować serwer OpenLDAP. Może się okazać że wymagana jest odpowiednia (nie najnowsza) wersja serwera LDAP zdolna do współpracy z serwerem LDAP.

root / #emerge =net-nds/openldap-2.2.28

2.1.2.2. Przeniesienie katalogu LDAP

Uwaga: Wcześniejsze przetestowanie procedury przeniesienia zawartości katalogu LDAP przed wykonaniem tego w środowisku produkcyjnym jest bardzo zalecane.

Uwaga: Warto wykonać eksport całego katalogu LDAP do pliku w formacie LDIF na serwerze źródłowym (tak na wszelki wypadek).

Podczas przenoszenia katalogu źródłowy serwer LDAP jak i docelowy serwer LDAP powinny być zatrzymane.

Jeśli nowy serwer LDAP ma zostać zainstalowany w miejsce swojej starszej wersji wówczas dokonujemy exportu/backupu zasobów katalogowych, reinstalujemy serwer LDAP, a następnie importujemy zasoby katalogowe z powrotem do serwera LDAP. Dopiero po zakończeniu takiej procedury można uruchomić serwer LDAP

2.1.2.2.1. Bezpośrednie kopiowanie plików katalogu LDAP

W tej metodzie należy przekopiować zawartość katalogu opisanego parametrem directory w pliku /etc/openldap/slapd.conf z źródłowego serwera LDAP do odpowiedniej lokalizacji na nowym serwerze LDAP (w obu wypadkach powinien to być katalog /var/lib/openldap-data).

Jeśli mamy do czynienia z upgradem na tej samej maszynie wówczas warto jedynie dokonać archiwizacji katalogu do pliku tar.gz.

Na źródłowym serwerze robimy archiwum bazy danych do pliku:

root / #tar zvf /var/lib/openldap-data > /var/lib/openldap-data.tgz

Na nowym serwerze wykonujemy download pliku bazy danych i rozpakowujemy go:


root / #scp root@192.168.1.105:/var/lib/openldap-data.tgz /var/lib/openldap-data.tgz
root / #tar xvf openldap-data.tgz –C /

Powyższa metoda ma sens tylko dla dwóch serwerów LDAP wykorzystujących taki sam silnik DB jako backend serwera LDAP – w naszej konfiguracji jest to silnik Berkeley DB (sys-libs/db). W grę wchodzi również zapewnienie zgodności na poziomie byte-ordering-u (litte-endian / big-endian).

2.1.2.2.2. Kopiowanie katalogu przez plik LDIF

Bezpieczne przeniesienie danych między serwerami może być wykonane poprzez eksport/import pliku LDIF. Taki sposób przeniesienia zawartości katalogu LDAP jest b. bezpieczna.

Na źródłowym serwerze tworzymy plik contents.ldif zawierający pełną informacje zawartą w drzewie DIT katalogu LDAP (dc=bogus,dc=com,dc=pl):


root / #slapcat –b “dc=bogus,dc=com,dc=pl” –l contents.ldif
–D “cn=Manager,dc=bogus,dc=com,dc=pl” –W

Po skopiowaniu pliku contents.ldif na nowy serwer LDAP dokonujemy jego importu do bazy danych serwera LDAP:

root / #slapadd –l contents.ldif –D „cn=Manager,dc=bogus,dc=com,dc=pl” –W

Podczas eksportu oraz importu należy podać hasło Manager-a.

I w koniecu nadpisujemy właściciela binarnych zasobów katalogu LDAP powstałych po imporcie z pliku LDIF:

root / #chown ldap:ldap /var/lib/openlda-data/*

2.2. Konfiguracja serwera LDAP

Zakładamy że serwer OpenLDAP został zainstalowany po raz pierwszy i jeszcze nie istnieje katalog LDAP.

Skopiowanie schematu samby do zasobów LDAP:


root / #cd /usr/share/doc/samba-3.0.20b/examples/LDAP
root / #cp samba.schema /etc/openldap/schema

Generacja hasła dla roota do zasobów serwera LDAP:


root / #slappasswd –h {SSHA} –s moje_sekretne_haslo_managera_LDAP
New password:
Re-enter new password:
{SSHA}RuDzh41/7fQzw6MWYO+JNJNzcUMIxmmg

Hasło moje_sekretne_haslo_managera_LDAP jest wymagane przy każdej modyfikacji bazy danych LDAP z poziomu admina katalogu,  dn=Manager,dc=bogus,dc=com,dc=pl.

Uwaga: Zaszyfrowane hasło będzie wartością parametru rootpw w pliku /etc/openldap/slapd.conf  (patrz listing poniżej).

Atrybut rootpw utrzymuje zaszyfrowane hasło dla rootdn - oba parametry będą potrzebne w dalszej części procedury do wykonania niezbędnych modyfikacji bazy danych serwera LDAP z wykorzystaniem narzędzi typu ldapadd, ldappasswd, itp.

Aby sprawnie umieścić hasło administratora w pliku konfiguracyjnym serwera LDAP wykonujemy następującą komendę:
root / #echo rootpw `slappasswd –h {SSHA}` >> /etc/openldap/slapd.conf
W kolejnym kroku dokonujemy edycji plik konfiguracyjnego serwera OpenLDAP:


#/etc/openldap/slapd.confinclude     /etc/openldap/schema/core.schema
include     /etc/openldap/schema/cosine.schema
include     /etc/openldap/schema/inetorgperson.schema
include     /etc/openldap/schema/nis.schema
include     /etc/openldap/schema/samba.schemaschemacheck on

# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral   ldap://root.openldap.org

pidfile     /var/run/openldap/slapd.pid
argsfile    /var/run/openldap/slapd.args

#######################################################################
# dbm database definitions
#######################################################################

database  bdb
suffix "dc=bogus,dc=com,dc=pl"
rootdn "cn=Manager,dc=bogus,dc=com,dc=pl"
# Cleartext passwords, especially for the rootdn, should
# be avoid.  See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw {SSHA}RuDzh41/7fQzw6MWYO+JNJNzcUMIxmmg
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory   /var/lib/openldap-data
lastmod on

# Indices to maintain
index objectClass eq
index uidNumber eq
index gidNumber eq
index cn pres,sub,eq
index sn pres,sub,eq
index uid pres,sub,eq
index displayName pres,sub,eq
index memberUID eq,subinitial
index mail eq,subinitial
index sambaSID eq
index sambaPrimaryGroupSID eq
index sambaDomainName eq
index default eq
# Security restrictions
# if no access controls are present, the default policy is:
#Allow read by all
#
# rootdn can always write!

# users can authenticate and change their password
access to \ attrs=userPassword,sambaNTPassword,sambaLMPassword,sambaPwdLastSet, \
sambaPwdMustChange

by dn="cn=samba,ou=DSA,dc=bogus,dc=com,dc=pl" write
by dn="cn=smbldap-tools,ou=DSA,dc=bogus,dc=com,dc=pl" write
by dn="cn=nssldap,ou=DSA,dc=bogus,dc=com,dc=pl" write
by self write
by anonymous auth
by * none

# some attributes need to be readable anonymously so that 'id user' can answer correctly
access to \ attrs=objectClass,entry,gecos,homeDirectory,uid,uidNumber,gidNumber,cn, \ memberUid,loginShell

by dn="cn=samba,ou=DSA,dc=bogus,dc=com,dc=pl" write
by dn="cn=smbldap-tools,ou=DSA,dc=bogus,dc=com,dc=pl" write
by * read

# somme attributes can be writable by users themselves
access to attrs=description,telephoneNumber

by dn="cn=samba,ou=DSA,dc=bogus,dc=com,dc=pl" write
by dn="cn=smbldap-tools,ou=DSA,dc=bogus,dc=com,dc=pl" write
by self write
by * read

# some attributes need to be writable for samba
access to \ attrs=cn,sambaLMPassword,sambaNTPassword,sambaPwdLastSet,sambaLogonTime, \ sambaLogoffTime,sambaKickoffTime,sambaPasswordHistory,sambaPwdCanChange, \
sambaPwdMustChange,sambaAcctFlags,displayName,sambaHomePath, \ sambaHomeDrive,sambaLogonScript,sambaProfilePath,description, \
sambaUserWorkstations,sambaPrimaryGroupSID,sambaDomainName,sambaSID, \
sambaGroupType,sambaNextRid,sambaNextGroupRid,sambaNextUserRid, \
sambaAlgorithmicRidBase

by dn="cn=samba,ou=DSA,dc=bogus,dc=com,dc=pl" write
by dn="cn=smbldap-tools,ou=DSA,dc=bogus,dc=com,dc=pl" write
by self read
by * none

# samba need to be able to create the samba domain account
access to dn.base="dc=bogus,dc=com,dc=pl"

by dn="cn=samba,ou=DSA,dc=bogus,dc=com,dc=pl" write
by dn="cn=smbldap-tools,ou=DSA,dc=bogus,dc=com,dc=pl" write
by * none

# samba need to be able to create new users account
access to dn="ou=Users,dc=bogus,dc=com,dc=pl"

by dn="cn=samba,ou=DSA,dc=bogus,dc=com,dc=pl" write
by dn="cn=smbldap-tools,ou=DSA,dc=bogus,dc=com,dc=pl" write
by * none

# samba need to be able to create new groups account
access to dn="ou=Groups,dc=bogus,dc=com,dc=pl"

by dn="cn=samba,ou=DSA,dc=bogus,dc=com,dc=pl" write
by dn="cn=smbldap-tools,ou=DSA,dc=bogus,dc=com,dc=pl" write
by * none

# samba need to be able to create new computers account
access to dn="ou=Computers,dc=bogus,dc=com,dc=pl"

by dn="cn=samba,ou=DSA,dc=bogus,dc=com,dc=pl" write
by dn="cn=smbldap-tools,ou=DSA,dc=bogus,dc=com,dc=pl" write
by * none

# this can be omitted but we leave it: there could be other branch
# in the directory
access to *

by self read
by * none

#------------- END --------------

Uwaga: Listy dostępu ACL umieszczone w powyższym pliku odwołują się do obiektów katalogowych, które wprawdzie jeszcze nie istnieją, lecz zostaną stworzone w dalszej części opisywanej procedury.

Dokonujemy zmiany uprawnień dla pliku /etc/openldap/slapd.conf:


-rw------- ldap ldap 568 Feb 01 13:43 slapd.confroot / #chmod 600 /etc/openldap/slapd.conf
root / #chown ldap.ldap /etc/openldap/slapd.conf

Poza tym tworzymy i ustawiamy uprawnienia dla katalogu utrzymującego obiekty LDAP (/var/lib/openldap-data):


drwx------       ldap     ldap     568      Feb 01 13:43  openldap-dataroot / #mkdir /var/lib/openldap-data
root / #chmod 700 /var/lib/openldap-data
root / #chown ldap.ldap /var/lib/openldap-data

Pierwsze uruchomienie serwera LDAP:
root / #/etc/init.d/slapd start
W celu przyspieszenia przeglądania zawartości katalogu serwera LDAP należy stworzyć zbiór indeksów w bazie danych LDAP:


root / #/etc/init.d/slapd stop
root / #slapindex –f /etc/openldap/slapd.conf
root / #/etc/init.d/slapd start

Uwaga: Każda kolejna zmiana zbioru indeksów (zdefiniowanych w pliku /etc/openldap/slapd.conf) wymaga zatrzymania serwera LDAP i ponownego wykonania powyższego polecenia.

2.3. Konfiguracja programów klienckiech dla lokalnego serwera LDAP

Uwaga: W niektórych dystrybucjach oprogramowania klienckie serwera OpenLDAP jest rozpowszechniane w osobnym pakiecie, który należy zainstalować osobno.

Zakładamy, iż serwer LDAP jest poprawnie skonfigurowany i uruchomiony. Natomiast utrzymywany katalog jest wciąż pusty.

Konfiguracja oprogramowania klienckiego dla serwera OpenLDAP jest podyktowana potrzebą wprowadzenia danych do pustego katalogu -  narzędzia klienckie serwera OpenLDAP są zdolne dokonać wszelkich modyfikacji w drzewie obiektów katalogowych.

Edytujemy plik /etc/openldap/ldap.conf w następujący sposób:


#/etc/openldap/ldap.confHOST 127.0.0.1
BASE dc=bogus,dc=com,dc=pl
#------------- END --------------

2.4. Uwagi dodatkowe na temat serwera LDAP

Przy każdej konfiguracji serwera LDAP warto rozważyć uruchomienie obsługi szyfrowanych połączeń – opisane w rozdziale 15.1. Obsługa szyfrowanych połączeń na serwerze LDAP.

W zasadzie – pomijając szyforwaną replikację - dla konfiguracji kontrolerów domeny taka funkcjonalność nie ma znaczenia, lecz znacznie poprawia elastyczność jego pracy.

3. Wstępna konfiguracja serwera plików Samba

Wstępna konfiguracja serwera plików Samba jest potrzeba do wygenerowania domenowego identyfikatora SID (security identifier).

3.1. Instalacja

Serwer plików Samba instalujemy podając jedno polecenie w linii komend:
root / #emerge samba

3.1.1. Weryfikacja instalacji

Przed konfiguracją Samby należy sprawdzić czy została skonsolidowana z biblioteką libldap:


root / #ldd `which smbd`

Libldap-2.2.so.7 => /usr/lib/libldap-2.2.so.7 (0xb7fb3000)

Uwaga: Jeśli biblioteka nie jest zlinkowana z Sambą należy przekompilować sambę z odpowiednimi flagami (np. ldap).

3.2. Prosta konfiguracja wstępna

Edytujemy plik /etc/samba/smb.conf i ustawiamy nazwę NetBIOS kontrolera oraz nazwę domeny.


#/etc/samba/smb.conf
[global]
workgroup = BOGUS
netbios name = PDC-BOGUS#------------- END --------------

Po zapisaniu poniższej konfiguracji startujemy serwer Samby:
root / #/etc/init.d/samba start
Jeśli próba uruchomienia nie powiedzie się to przyczyna najprawdopodobniej tkwi w nieprawidłowej zawartości liku konfiguracyjnego /etc/samba/smb.conf. Narzędzie testparm pozwala zwalidować zawarotść takiego pliku:
root / #testparm –s

3.3. Generacja Domain Security Identifier (Domain SID)

Jeśli serwer plików Samba pracuje poprawnie - wykonujemy następujące polecenie:


root / #net getlocalsid
SID for domain PDC-BOGUS is: S-1-5-21-1357073039-1896359966-460829502

Uwaga: SID będzie potrzebny przy konfiguracji skryptów smbldap-tools.

Strony: 1 2 3 4 5 6