Kontroler domeny na Linux’ie

III. Konfiguracja zapasowego kontrolera domeny BDC Zakładamy, iż serwer plików skonfigurowany jako zapasowy kontroler domeny (backup domain controller – BDC) oraz skojarzony z nim serwer LDAP typu slave będą razem […]

III. Konfiguracja zapasowego kontrolera domeny BDC

Zakładamy, iż serwer plików skonfigurowany jako zapasowy kontroler domeny (backup domain controller – BDC) oraz skojarzony z nim serwer LDAP typu slave będą razem działały na tym samym hoście. Zapasowy kontroler domeny nosi nazwę BDC-BOGUS.

Główny kontroler domeny (PDC) o nazwie PDC-BOGUS oraz skojarzony z nim serwer LDAP typu master oraz znajdują się na zdalnym hoście i na tym etapie powinny być prawidłowo skonfigurowane i uruchomione.

Przyjmujemy, że docelowo komunikacja miedzy serwerami LDAP typu master oraz slave będzie szyfrowana.

10. Konfiguracja serwera usług katalogowych LDAP typu SLAVE

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

Uruchamiamy serwer LDAP typu master zgodnie ze wskazówkami w rozdziale 2. Konfiguracja serwera usług katalogowych LDAP typu MASTER a zwłaszcza w podrozdziale 2.1.2. Reinstalacja lub upgrade. W rezultacie otrzymujemy serwer usług katalogowych LDAP bez żadnych obiektów katalogowych.

10.1. Konfiguracja konta replikującego

Konto replikujące pozwoli replikować zmiany dokonane na serwerze typu master do serwera typu slave.

Konto będzie miało następującą nazwę dc=replicator,ou=DSA,dc=bogus,dc=com,dc=pl.

Uwaga: Konto replikujące w zasadzie powinno być przechowywane tylko na serwerze LDAP typu slave jednak warto je stworzyć wcześniej na źródłowym serwerze LDAP w celu zachowania spójności baz danych LDAP.

Na źródłowym serwerze LDAP typu master dodajemy konto replikujące:
root / #ldapadd -x -h localhost -D “cn=Manager,dc=bogus,dc=com,dc=pl” -f replicat-dsa.ldif -W
gdzie plik replicat-dsa.ldif ma następującą strukturę:


#/replicat-dsa.ldif
dn: cn=replicator,ou=DSA,dc=bogus,dc=com,dc=pl
objectclass: organizationalRole
objectClass: top
objectClass: simpleSecurityObject
userPassword: MAY_BE_CHANGED_LATER
cn: replicator#------------- END --------------

Uwaga: Jesli w katalogu LDAP brak jednostki organizacyjnej ou=DSA,dc=bogus,dc=com,dc=pl należy ją stworzyć wcześniej lub zmienić DN konta replikującego.

W końcu należy ustawić odpowiednie hasło dla konta replikującego:


root / #ldappasswd –x –h localhost –D “cn=Manager,dc=bogus,dc=com,dc=pl” –s \
moje_sekretne_haslo_dla_replikatora –W „cn=replicator,ou=DSA,dc=bogus,dc=com,dc=pl”

10.2. Pierwsza replikacja katalogu LDAP

Po stworzeniu konta replikującego dokonujemy kopiowania wprowadzonych już informacji z bazy danych źródłowego serwera LDAP (master) do bazy danych nowego serwera LDAP (slave), aby uzyskać dwa spójne katalogi LDAP.

Pierwsza replikacja katalogu LDAP musi być wykonana ręcznie. Istnieją dwie metody ręcznej replikacji katalogu LDAP: skopiowanie plików katalogu LDAP lub z pomocą pliku LDIF.

W obu wypadkach na wstępie należy zatrzymać oba działające serwery LDAP:
root / #/etc/init.d/slapd stop
Pierwsza replikacja katalogu LDAP jest równoznaczna z przeniesieniem jego zasobów na nowy serwer, co zostało opisane w rozdziale 2.1.2. Reinstalacja lub upgrade (bardzo proszę uważnie przeczytać ten rozdział).

10.2.3. Uwagi na temat ról pełnionych przez serwery LDAP

W chwili obecnej – po wykonaniu ręcznej replikacji – mamy do dyspozycji dwa równorzędne serwery LDAP zawierające spójne katalogi LDAP.

Uwaga: Do czasu uruchomienia jednego z serwerów mamy 100% pewności, że ich katalogi LDAP są spójne – brak możliwości updatu informacji w katalogu.

W tej chwili należy ostatecznie zdecydować, który serwer jest serwerem LDAP typu slave, a który typu master.

Update katalogu LDAP dokonywany jest zawsze na serwerze typu master. Replikacja zawsze przebiega od serwera typu master do serwera typu slave.

Przyjęło się, że serwer typu master jest skojarzony z kontrolerem PDC, natomiast serwery typu slave są uruchamiane na kontrolerach BDC. Ale nic nie stoi na przeszkodzie by serwer typu master znajdował się na jednym z działających BDC lub też został wyniesiony na osobny host.

10.3. Konfiguracja replikacji katalogu LDAP bez szyfrowania

Powinno się unikać dystrybucji zawartości katalogu LDAP bez szyfrowania (otwartym tekstem), gdyż replikowane dane zostać podsłuchane i wykorzystane do złamania zabezpieczeń kontrolera domeny lub innej usługi, której atrybuty są utrzymywane w katalogu LDAP.

Jeśli chcemy zastosować szyfrowaną replikację katalogu LDAP należy wykonać polecenia dot. replikacji otwartym tekstem opisana w tym rozdziale, a następnie dokonać niezbędnych modyfikacji opisanych w rozdziale 10.4. Konfiguracja replikacji katalogu LDAP.

Zakładamy, że w tej chwili serwery master i slave są zatrzymane a zawartość ich baz danych jest spójna.

10.3.1. Rekonfiguracja serwera LDAP typu SLAVE dla replikacji bez szyfrowania

Rekonfiguracja serwera LDAP typu slave polega na modyfikacji jego pliku konfiguracyjnego (/etc/openldap/slapd.conf ), a dokładnie na dodaniu dodatkowych informacji dot. konta replikującego, położenia serwera typu master oraz dodania dodatkowego ACL-a, tak by możliwa była pełna modyfikacja zasobów bazy danych w ramach replikacji:


#/etc/openldap/slapd.conf (SLAVE)
#....
updatedn "cn=replicator,ou=DSA,dc=bogus,dc=com,dc=pl"
updateref ldap://ldap_master_server_address
#....
# replication (always 1st ALC in the list)
access to *
by dn="cn=replicator,ou=DSA,dc=bogus,dc=com,dc=pl" =xw
by * none break
# 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 --------------

10.3.2. Rekonfiguracja serwera LDAP typu MASTER dla replikacji bez szyfrowania

Rekonfiguracja serwera LDAP typu master polega na dodaniu dodatkowych informacji do jego pliku konfiguracyjnego /etc/openldap/slapd.conf:


#/etc/openldap/slapd.conf (MASTER)#....

replogfile /var/lib/openldap-slurp/slapd.replog
replica host=ldap_slave_server_address:389
suffix="dc=bogus,dc=com,dc=pl"
binddn="cn=replicator,ou=DSA,dc=bogus,dc=com,dc=pl"
credentials=moje_sekretne_haslo_dla_replikatora
bindmethod=simple
tls=no

#....

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

Uwaga: Dla każdego serwera LDAP typu slave tworzymy osobną definicję typu replica.

Tworzymy katalog dla utrzymywania replikowanych informacji:


root / #mkdir /var/log/openldap-slurp
root / #chown ldap:ldap /var/log/openldap-slurp
root / #chmod 700 /var/log/openldap-slurp

10.4. Konfiguracja replikacji katalogu LDAP z szyfrowaniem

Na tym etapie powinna być już skonfigurowana replikacja bez szyfrowania opisana w rozdziale 10.3. Konfiguracja replikacji katalogu LDAP bez szyfrowania.

Zakładamy, że serwery typu master i slave wspierają obsługę szyfrowanych połączeń, której konfiguracja została opisana w rozdziale 15.1. Obsługa szyfrowanych połączeń na serwerze LDAP.

Zakładamy, że serwery typu master i slave są zatrzymane oraz zawartość ich katalogów jest spójna.

10.4.1. Rekonfiguracja serwera LDAP typu SLAVE dla replikacji z szyfrowaniem

Po stronie slave modyfikujemy plik /etc/openldap/slapd.conf w następujący sposób:


#/etc/openldap/slapd.conf(SLAVE-SSL)#...

updatedn "cn=replicator,ou=DSA,dc=bogus,dc=com,dc=pl"
updateref ldaps://ldap_master_server_address:636/

#...

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

W ten sposób na serwerze typu slave został zdefiniowany referral dla operacji zapisu do katalogu LDAP. Jeśli klient zwórci się z żądaniem zapisu do serwera LDAP typu slave, wówczas serwer zwróci adres właściwego serwera obsługującego operacje zapisy (zdefiniowany pod atrybutem updateref).

10.4.2. Rekonfiguracja serwera LDAP typu MASTER dla replikacji z szyfrowaniem

W wypadku konfiguracji replikacji dla serwera typu master mamy do wyboru dwa rodzaje szyfrowanych połączeń – SSL lub TLS. Dwa typy szyfrowania różnią się sposobem inicjalizowania szyfrowanego połączenia jednak z punktu widzenia bezpieczeństwa obie metody są sobie równoważne.

Aby aktywować replikację przez SSL po stronie master zmieniamy definicję sekcji replica w pliku /etc/openldap/slapd.conf:


#/etc/openldap/slapd.conf(MASTER-SSL)#...

replogfile /var/lib/openldap-slurp/slapd.replog
replica uri=ldaps://ldap_slave_server_address:636
suffix="dc=bogus,dc=com,dc=pl"
binddn="cn=replicator,ou=DSA,dc=bogus,dc=com,dc=pl"
credentials=moje_sekretne_haslo_dla_replikatora
bindmethod=simple

#...

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

Jednakże aby aktywować replikację przez TLS po stronie master zmieniamy definicję sekcji replica w pliku /etc/openldap/slapd.conf w następujący sposób:


#/etc/openldap/sldapd.conf(MASTER-TLS)#...

replogfile /var/lib/openldap-slurp/slapd.replog
replica host=ldap_slave_server_address:389
suffix="dc=bogus,dc=com,dc=pl"
binddn="cn=replicator,ou=DSA,dc=bogus,dc=com,dc=pl"
credentials=moje_sekretne_haslo_dla_replikatora
bindmethod=simple
tls=critical

#...

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

10.5. Uruchomienie automatycznej replikacji

Uruchomienie automatycznej replikacji polega na uruchomieniu obu zaangażowanych serwerów LDAP (slapd) oraz serwera replikacji katalogu (slurpd) po stronie master.

Procedura uruchamiania serwerów powinna być następująca:

1) Najpierw startujemy obie serwery LDAP

root / #//etc/init.d/slapd start

W zasadzie nie ma znaczenia, który serwer zostanie uruchomiony jako pierwszy, ale zawsze staram się najpierw uruchomić mastera.

2) W kolejnym kroku uruchamiamy serwer replikacji slurpd (tylko na hoście utrzymującym serwer LDAP typu master):

root / #//etc/init.d/slurpd start

I tyle – replikacja katalogów LDAP powinna prawidłowo działać.

 

10.6. Weryfikacja

W zasadzie najbardziej niezawodną metodą wytestowania replikacji jest wykonanie zapisu do katalogu i sprawdzenia czy zmiany zostały zreplikowane. Nawet spore zmiany w katalogu LDAP powinny zostać zreplikowane w ciągu co najwyżej kliku sekund.

Można również zatrzymać serwer replikacji i rozpocząć debugging procesu replikacji poprzez uruchomienie serwera slurpd z dodatkowymi niestandardowymi parametrami:

root / #//var/lib/openldap/slurpd –f /etc/openldap/slapd.conf –d debug_level

Parametr debug_level może przyjmować następujące wartości:

Poziom Opis
4 heavy trace debugging
64 configuration file processing
65535 enable all debugging

Uwaga: Serwer replikacji w trybie debuggingu nie pracuje w tle, lecz blokuje konsolę i „wyrzuca” wszystkie informacje debugujące na konsolę.

11. Konfiguracja smbldap-tools

W przypadku konfiguracji BDC z reguły skojarzonym serwerem LDAP jest serwer typu slave, natomiast serwer LDAP typu master współpracuje z PDC.

Zakładamy, iż serwery LDAP master oraz slave są poprawnie skonfigurowane, uruchomione oraz utrzymują spójny katalog LDAP. Poza tym co najmniej serwer LDAP typu master (a najlepiej również serwer typu slave na konfigurowanym BDC) powinien obsługiwać szyfrowane połączenia SSL. Konfiguracja wsparcia dla szyfrowanych połączeń została opisana w rozdziale 15.1. Obsługa szyfrowanych połączeń na serwerze LDAP.

11.1. Instalacja

Instalujemy smbldap-tools zgodnie z opisem zamieszczonym w rozdziale 4.1. Instalacja.

11.2. Konfiguracja skryptów smbldap-tools

Konfigurujemy smbldap-tools zgodnie z opisem zamieszczonym w rozdziale 4.2. Konfiguracja skryptów smbldap-tools.

Następnie modyfikujemy plik smbldap.conf:


#/etc/smbldap-tools/smbldap.conf (SLAVE-TLS)#...

#Master LDAP : needed for write operations
masterLDAP="master_ldap_server_address"

#...

# Use TLS for LDAP
# If set to 1, this option will use start_tls for connection
# (you should also used the port 389)
ldapTLS="1"

# How to verify the server's certificate (none, optional or require)
# see "man Net::LDAP" in start_tls section for more details
verify="require"

# CA certificate
# see "man Net::LDAP" in start_tls section for more details
cafile="/etc/ssl/created/cacert.pem"

# certificate to use to connect to the ldap server
# see "man Net::LDAP" in start_tls section for more details
clientcert="/etc/ssl/created/local/newcert.pem"

# key certificate to use to connect to the ldap server
# see "man Net::LDAP" in start_tls section for more details
clientkey="/etc/ssl/created/local/newreq.pem"

#...

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

11.3. Dostęp smbldap-tools do katalogu LDAP

Konfigurujemy smbldap-tools zgodnie z opisem zamieszczonym w rozdziale 4.4. Dostęp smbldap-tools do katalogu LDAP.

12. Ekspozycja obiektów z lokalnego katalogu LDAP na systemie plików

Konfiguracja została już opisana w rozdziale 5. Ekspozycja obiektów z lokalnego katalogu LDAP na systemie plików. Proszę się kierować wskazówkami zamieszczonymi właśnie tam.

13. Konfiguracja serwera plików Samba jako  BDC

Zakładamy, iż skojarzony serwer LDAP jest poprawnie skonfigurowany i uruchomiony.

13.1. Instalacja

Serwer plików Samba instalujemy podając jedno polecenie w linii komend:

root / #emerge samba

Weryfikujemy instalację zgodnie z procedurą opisaną w rozdziale 3.1.1. Weryfikacja instalacji.

13.2. Skrypt logowania

Wykonujemy instrukcje opisane w rozdziale 6.1. Skrypt logowania.

13.3. Konfiguracja BDC z katalogiem LDAP jako backendem

Edytujemy plik smb.conf w następujący sposób


# Global parameters
[global]
workgroup = BOGUS.COM.PL
netbios name = BDC-BOGUS
server string =security = user

#bind interfaces only = Yes
interfaces = lo,eth0

domain master = No
local master = Yes
preferred master = Yes
os level = 33

logon script =
logon path =

domain logons = Yes
logon home =
logon drive = H:

wins support = Yes
time server = Yes

#admin users= @"Domain Admins"
username map = /etc/samba/smbusers

passdb backend = ldapsam:ldap://127.0.0.1/
encrypt passwords = Yes
mangling method = hash2
unix password sync = Yes
passwd program = /usr/local/bin/smbldap-passwd %u
passwd chat = "Changing password for*\nNew password*" %n\n "*Retype new \ password*" %n\n"
ldap passwd sync = Yes

ldap replication sleep = 5000

log level = 0
syslog = 0
log file = /var/log/samba/log.%m
max log size = 100000

socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192

dos charset = 852
unix charset = ISO8859-2

ldap admin dn = cn=samba,ou=DSA,dc=bogus,dc=com,dc=pl
ldap suffix = dc=bogus,dc=com,dc=pl
ldap group suffix = ou=Groups
ldap user suffix = ou=Users
ldap machine suffix = ou=Computers
ldap idmap suffix = ou=Idmap
ldap delete dn = Yes
ldap ssl = off

idmap backend = ldap:ldap://127.0.0.1
idmap uid = 10000 - 65000
idmap gid = 10000 - 65000

map acl inherit = Yes
enable privileges = Yes

add user script = /usr/local/bin/smbldap-useradd -m "%u"
#delete user script = /usr/local/bin/smbldap-userdel "%u"
add machine script = /usr/local/bin/smbldap-useradd -w "%u"
add group script = /usr/local/bin/smbldap-groupadd -p "%g"
#delete group script = /usr/local/bin/smbldap-groupdel "%g"
add user to group script = /usr/local/bin/smbldap-groupmod -m "%u" "%g"
delete user from group script = /usr/local/bin/smbldap-groupmod -x "%u" \ "%g"
set primary group script = /usr/local/bin/smbldap-usermod -g "%g" "%u"

#[homes]
#comment = repertoire de %U, %u
#read only = No
#create mask = 0644
#directory mask = 0775
#browseable = No

[netlogon]
path = /home/netlogon/
browseable = No
read only = Yes

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

Uwaga: W powyższej konfiguracji nie został ustawiony zdalny katalog domowy użytkownika [homes].

13.4. Dostęp Samby do lokalnego katalogu LDAP

Wykonujemy instrukcje opisane w rozdziale 6.3. Dostęp Samby do lokalnego katalogu LDAP.

13.5. Uruchomienie zapasowego kontrolera domeny

Startujemy serwer Samby:

root / #/etc/init.d/samba start

I oto mamy w pełni działający zapasowy kontroler domeny 🙂

13.6. Dołączenie BDC do domeny

Na hoście utrzymującym BDC z linii komend wykonujemy następujące polecenia:


root / #/net rpc join –Uroot –I PDC_address
Password: <haslo_roota>
Joined domain BOGUS.COM.PL.

oraz:


root / #/net rpc getsid –I PDC_address
Storing SID S-1-5-21-…-460829502 for domain BOGUS.COM.PL in secrets.tdb.

Dołączenie do domeny wiąże się ze stworzeniem tzw. Server Trust Account w katalogu LDAP kontrolera domeny.

13.6. Ostateczna weryfikacja

Wykonujemy instrukcje opisane w rozdziale 6.5. Ostateczna weryfikacja.

Strony: 1 2 3 4 5 6

Komentarze wyłączone

Komentarze wyłączone. Nie możesz pisać komentarzy w tym wpisie.