Kontroler domeny na Linux’ie

IV. Tematy dodatkowe 14. Infrastruktura szyfrująca W kolejnych krokach zainstalujemy certyfikat centrum certyfikującego, klucz prywatny oraz publiczny (certyfikat szyfrujący). 14.1. Instalacja certyfikatu CA Po otrzymaniu certyfikatu CA z centrum certyfikacji […]

IV. Tematy dodatkowe

14. Infrastruktura szyfrująca

W kolejnych krokach zainstalujemy certyfikat centrum certyfikującego, klucz prywatny oraz publiczny (certyfikat szyfrujący).

14.1. Instalacja certyfikatu CA

Po otrzymaniu certyfikatu CA z centrum certyfikacji (plik cacert.pem) umieszczamy go w katalogu /etc/ssl/created .

-r--r--r-- root root 568 Feb 01 13:43 cacert.pem

14.2. Instalacja certyfikatu szyfrującego i klucza prywatnego

Zakładamy że certyfikat CA został poprawnie zainstalowany zgodnie z opisem w poprzednim rozdziale 14.1. Instalacja certyfikatu CA.

Aby obsługiwać szyfrowane połączenia LDAP należy posiadać certyfikat szyfrujący oraz jego klucz prywatny (pliki newcert.pem i newreq.pem) wygenerowane dla hosta na którym znajduje się serwer LDAP. Należy upewnić się, iż certyfikat szyfrujący i klucz prywatny zostały wygenerowane na bazie zainstalowanego certyfikatu CA


-r--r----- root root 568 Feb 01 13:43 newreq.pem
-r--r--r-- root root 568 Feb 01 13:43 newcert.pem

Oba pliki umieszczamy pliki w katalogu /etc/ssl/created/local.

Kopiujemy plik newreq.pem do pliku pod nazwą newreq-for-ldap.pem (w tej samej lokalizacji) i zmieniamy mu prawa użytkownika (poleceniem chown):

-r--r----- ldap ldap 568 Feb 01 13:43 newreq-for-ldap.pem

Uwaga: Zazwyczaj wszystkie usługi wspierające szyfrowanie połączeń i znajdujące się na tym samym fizycznym serwerze mogą korzystać z jednego wspólnego zestawu ceryfikatu szyfrującego, klucza prywatnego oraz certyfikatu CA.

15. LDAP

15.1. Obsługa szyfrowanych połączeń na serwerze LDAP

Domyślnie serwer LDAP komunikuje się z klientami bez szyfrowania (otwartym tekstem) nasłuchujac na porcie 389, natomiast połączenia szyfrowane są odbierane domyślnie na porcie 636.

W zasadzie szyfrowana komunikacja jest potrzebna tylko, gdy klient LDAP znajduje się na zdalnym hoście.

Zakładamy, że w tej chwili serwer LDAP działa i obsługuje połączenia bez szyfrowania.

15.1.1. Instalacja infrastruktury szyfrującej

Wykonujemy instrukcje z rozdziału 14. Infrastruktura szyfrująca.

15.1.2. Konfiguracja wsparcia dla szyfrowanych połączeń na serwerze LDAP

Modyfikujemy plik /etc/openldap/slapd.conf:


#/etc/openldap/slapd.conf (TLS/SSL)#...

TLSCACertificateFile /etc/openldap/ssl/cacert.pem
TLSCertificateFile /etc/openldap/ssl/newcert.pem
TLSCertificateKeyFile /etc/openldap/ssl/newreq-for-ldap.pem

#...

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

Ustawiamy opcje startowe serwera LDAP w pliku /etc/conf.d/slapd:


#/etc/conf.d/slapd (TLS/SSL)OPTS="-h ‘ldaps:// ldap:// ldapi://%2fvar%2frun%2fopenldap%2fslapd.sock’"

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

I na końcu restartujemy serwer LDAP. Po restarcie serwer LDAP będzie oczekiwał połączeń nie szyfrowanych na porcie 389 natomiast połączeń szyfrowanych na porcie 636.

Aby dopełnić rekonfigurację serwera LDAP modyfikując lokalnego klienta LDAP (plik /etc/openldap/ldap.conf na hoście serwera LDAP):


#/etc/openldap/ldap.conf (TLS/SSL)HOST 127.0.0.1
BASE dc=bogus,dc=com,dc=pl
TLS_CACERT /etc/openldap/ssl/cacert.pem

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

Zmiana podyktowana jest wymaganiami stawianymi przez serwer LDAP dla przyjmowanych połączeń SSL.

16. Zarządzanie użytkownikami, grupami i komputerami w domenie

Zakładamy, że skrypty smbldap-tools są poprawnie zainstalowane na hoście.

16.1. Zarządzanie użytkownikami w domenie

Dodawanie użytkownika do domeny:

root / #/usr/local/bin/smbldap-useradd -a <user_name>

Po stworzeniu konta koniecznie należy nadać hasło dla nowego użytkownika w przeciwnym wypadku zalogowanie się użytkownika będzie niemożliwe:


root / #/usr/local/bin /smbldap-passwd <user_name>
New password:
Re-enter new password:

Modyfikacja ustawień użytkownika domeny:

root / #/usr/local/bin/smbldap-usermod

Usuwanie użytkownika z domeny:

root / #/usr/local/bin /smbldap-userdel <user_name>

16.2. Zarządzanie grupami w domenie

Dodawanie grupy do domeny:

root / #/usr/local/bin /smbldap-groupadd -a <group_name>

Usuwanie grupy z domeny:

root / #/usr/local/bin /smbldap-groupdel <group_name>

16.3. Zarządzania stacjami roboczymi w domenie

Dodawanie stacji roboczej do domeny:

root / #/usr/local/bin /smbldap-useradd -w <workstation_name>

Nazwa <workstation_name> musi być identyczna z nazwą dołączanego komputera (do odczytu w jego ustawieniach lokalnych).

Uwaga: Nazwy stacji roboczych odróżniają się od nazw innych tworzonych obiektów znakiem dolara umieszczanym automatycznie na końcu nazwy pierwotnej.

Usuwanie stacji roboczej z domeny

root / #/usr/local/bin /smbldap-userdel <workstation_name_followed_by_$>

17. Samba

17.1. Zarządzanie polityką haseł użytkowników

Zarządzanie polityką haseł użytkowników w serwerze Samba odbywa się poprzez modyfikację zbioru atrybutów przez wydanie polecenia pdbedit:

root / #pdbedit –P „<atrybut w cudzyslowiu>” –C <wartość>

gdzie:

Nazwa atrybutu Opis wartości atrybutu
Minimum password age minimalny okres ważności hasła (liczba sekund)
Maximum password age maxymalny okres ważności hasła (liczba sekund)
min password length minimalna długość hasła (liczba znaków)
Password history wymusza tworzenie historii haseł (liczba haseł w historii)
bad lockout attempt ilość złych prób logowania zanim konto zostanie zablokowane
lockout duration czas wymuszonej blokady konta

Przykładowo, aby ustalić minimalną długość hasła na 8 znaków należy wydać następujące polecenie:

root / #pdbedit –P „min password length” –C 8

17.2. Roaming profiles

Zakładamy ze profile zdalne będą utrzymywane w katalogu /home/profiles, który oczywiście należy stworzyć.


drwxr-xr-x root root 568 Feb 01 13:43 profiles
root / #/chown root.root /home/profiles
root / #/chmod 755 /home/profiles

Do pliku konfiguracyjnego Samby (/etc/samba/smb.conf) należy dodać udział [profiles] wskazujący na katalog /home/profiles.


#/etc/samba/smb.conf#...

#profile directory makes sense only if roaming profiles are enabled
[profiles]
path = /home/profiles
read only = no
create mask = 0600
directory mask = 0700
browseable = No
guest ok = Yes
profile acls = yes
csc policy = disable
# next line is a great way to secure the profiles
force user = %U
# next line allows administrator to access all profiles
valid users = %U @"Domain Admins"
#next line creates profile directory for each user
root preexec = PROFILE=/home/profiles/%u; if [ ! -e $PROFILE ]; \
then mkdir -pm700 $PROFILE; chown "%u"."%g" $PROFILE; fi

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

Dodatkowo należy zmienić parametr userProfile w pliku /etc/smbldap-tools:


#/etc/smbldap-tools/smbldap.conf#...

userProfile="\PDC-BOGUS\profiles\%U"

#...

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

Po restarcie serwera Samby można będzie w domenie tworzyć użytkowników posiadających zdalne profile.

Uwaga: Zawartość zdalnego profilu jest umieszczana/update-owana na kontrolerze domeny zawsze podczas wylogowywania użytkownia z konta domenowego.

17.3. Tworzenie udziałów z różnymi prawami dostępu

Standardowy udział powinien mieć zdefiniowane następujące parametry pozwalające na dostęp do zasobów wg praw nadanych na systemie plików:


#/etc/samba/samba.conf#...

[share_1]
path = <full_path_to_directory>
read only = No
nt acl support = Yes

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

17.3.1. Udział osobisty użytkownika na serwerze

Tworzymy udział [homes] w Sambie dodając następujący fragment do pliku /etc/samba/smb.conf:


#/etc/samba/samba.conf#...

[homes]
comment = repertoire de %U, %u
read only = No
nt acl support = Yes
create mask = 0644
directory mask = 0775
browseable = No
admin users = %U
#guest ok = No

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

A następnie użytkownikowi który ma posiadać katalog osobisty tworzymy w katalogu /home nowy podkatalog o nazwie takiej samej jak login użytkownika. Prawa dostępu do katalogu powinny być następujące:

drwx------ <user_name> Domain Users 568 Feb 01 13:43 <user_name>

Dokładnie taki katalog może być tworzony automatycznie jeśli wykorzystamy parametr –m podczas tworzenia konta użytkownika za pomocą skryptu ./smbldap-useradd:

root / #/usr/share/samba/scripts/smbldap-useradd –a –m <user_name>

17.3.2. Udział z dostępem dla wielu grupy i/lub wielu użytkowników

Uwaga: Tego rodzaju udostępnienie jest możliwe do zrealizowania tylko w oparciu o rozszerzone listy kontroli dostępu (extended ACLs) definiowane na obiektach systemu plików dla użytkowników i grup eksponowanych przez system operacyjny.

Zakładamy, że w systemie operacyjnym są eksponowane posixowe grupy użytkowników: A oraz B. Grupa A otrzyma pełne prawa do zasobu, grupa B otrzyma możliwość odczytywania zasobu. Pozostali użytkownicy i grupy nie będą posiadali żadnych praw dostępowych do zasobu.

17.3.2.1. Extended ACLs

Aby włączyć obsługę rozszerzonych atrybutów dla wykorzystywanego systemu plików należy przekompilować jądro systemu operacyjnego i w trakcie konfiguracji wkompilować w jądro moduły w sekcji „File Systems” (w przykładzie dodajemy obsługę rozszerzonych atrybutów dla ext2, ext3 i reiserfs):


[*] Ext2 extended attributes
[*] Ext2 POSIX Access Control Lists
[*] Ext2 Security Labels
....
<*> Ext3 journalling file system support
[*] Ext3 extended attributes
[*] Ext2 POSIX Access Control Lists
[*] Ext2 Security Labels
....
<*> Reiserfs support
....
[*] ReiserFS extended attributes
[*] ReiserFS POSIX Access Control Lists
[*] ReiserFS Security Labels
....
------------- END --------------

Poza tym w pliku /etc/fstab należy dodać parametry acl i user_xattr dla wszystkich partycji, na których chcemy włączyć obsługę rozszerzonych list kontroli dostępu, np.:


#/etc/fstab
#...
/dev/sda2 /boot ext2 noatime,acl,user_xattr 0 1
/dev/sda3 / reiserfs noatime,notail,acl,user_xattr 0 0
#...
#------------- END --------------

17.3.2.2. Nadanie praw dostępu wybranym grupom

Na katalogu zasobu do udostępnienia aktywujemy bit set-gid:

root / #chmod g+s <sciezka_do_zasobu>

Uwaga: Jeśli chcemy aby nikt poza grupami A i B nie uzyskał dostępu do wybranego udziału należy usunąć zbędne prawa dla obiektów domyślnych:


root / #chown –R root:root <sciezka_do_zasobu>
root / #chmod –R a-rwx <sciezka_do_zasobu>

Nadanie praw z pełnym dostępem dla grupy A


root / #setfacl –Rm „group:A:rwx” < sciezka_do _zasobu>
root / #setfacl –Rdm „group:A:rwx” < sciezka_do _zasobu>

Nadanie praw z dostępem read-only dla grupy B:


root / #setfacl –Rm „group:B:r-X” <nazwa_zasobu>
root / #setfacl –Rdm „group:B:r-X” <nazwa_zasobu>

17.3.2.3. Udostępnienie udziału w Sambie

Do pliku konfiguracyjnego Samby dodajemy


#/etc/samba/samba.conf
#...
[udzial_dla_grup_A_i_B]
comment = udzial dla grup A(RW) i B(R)
path = <sciezka_do_zadobu>
read only = No
browseable = Yes
guest ok = Nodos filetimes = Yes
dos filetime resolution = Yesdos filemode = Yes
nt acl support = Yes
acl map full control = Yes
inherit acls = Yes
inherit owner = Yes
inherit permissions = Yes
#------------- END --------------

Gotowe. Udział dostępny w pełni jedynie dla grupy A oraz częściowo dla grupy B.

17.4. Serwer wydruku CUPS

17.4.1. Instalacja serwera CUPS

Instalujemy serwer CUPS oraz ESP Ghostscript wykonując następującą komendę:
root / #emerge cups ghostscript
Uwaga: Zadaniem pakietu Ghostscript jest dostarczanie wirtualnego urządzenia o nazwie „cups” wykorzytywanego w trakcie przetwarzania drukowanego dokumentu źródłowego na dokument postscriptowy (weryfikacją przez wylistowanie urządzeń GS komendą: gs –h ).

Konfiguracja serwera CUPS (plik /etc/cups/cupsd.conf)


#/etc/cups/cupsd.conf#...

RequestRoot /var/spool/cups

#...

<Location />
Order Deny,Allow
Deny From All
Allow From 127.0.0.1
Allow From X.X.X.X/X
</Location>

<Location /admin>
Order Deny,Allow
Deny From All
Allow From 127.0.0.1
Allow From X.X.X.X/X
</Location>

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

Parametr RequestRoot wskazuje na położenie spool-a dla CUPS-a.

Serwer CUPS można uruchomić poleceniem:
root / #/etc/init.d/cupsd start

17.4.2. Wspomaganie drukowania natywanego (raw printing)

Wspomaganie drukowania natywnego w serwerze wydruku jest o tyle istotne iż pozwala na przetwarzanie strumienia danych PCL, niezwykle popularnego formatu opisu drukowanych dokumentów wykorzystywanego przez wiele drukarek pracujących pod kontrolą systemu Windows.

Jeśli wszystkie drukarki obsługiwane przez serwer wydruku będą obsługiwały PostScript wówczas włączanie natywnego drukowania nie ma żadnego znaczenia.

Włączenie wspomagania drukowania natywnego (raw printing) w serwerze wydruku można wykonać przez odkomentowanie/dopisanie następującej lini w pliku /etc/cups/mime.types:


#/etc/cups/mime.types
#...
application/octet-stream
#...
#------------- END --------------

Oraz przez odkomentowanie/dopisanie następującej lini w pliku /etc/cups/mime.convs:


#/etc/cups/mime.convs
#...
application/octet-stream application/vnd.cups-raw 0 -
#...
#------------- END --------------

Oczywiście po zmianach należy dokonać restartu serwera wydruku:
root / #/etc/init.d/cupsd restart

17.4.3. Instalacja drukarki w serwerze wydruku

Aby poprawnie zainstalować drukarkę w serwerze CUPs należy umieścić plik PPD opisujący daną drukarkę w katalogu /usr/share/cups/model.

Pliki PPD opisują (w sformalizowany sposób) nastawy dostępne przy konfiguracji danej drukarki, np. możliwość drukowania dwustronnego, liczba i położenie podajników papieru, itp. – zawartość plików PPD przekłada się na bezpośrednio na zawartość okna ustawień drukowania w systemie Windows – jeśli zabraknie pliku PPD użytkownik będzie mógł ustawić tylko podstawowe parametry wydruku, pomimo iż najprawdopodobniej drukarka będzie w stanie obsłużyć bardziej zaawansowane ustawienia.

Kilka plików PPD jest dostarczanych razem z serwerem CUPS jednak wspierają one tylko część możliwych nastaw. Najwłaściwsze pliki PPD są zazwyczaj dołączane do sterowników odpowiedniej drukarki wydanych dla systemu Linux.

W razie braku sterowników pod system operacyjny Linux można wykorzystać pliki PPD dostarczane razem ze sterownikami dla systemu Windows, jednakże w tym wypadku należy zweryfikować ich zawartość na stronie http://www.cups.org/testppd.php .

Bogaty zbiór alternatywnych plików PPD zawierają pakiety foomatic (tworzony na podstawie zawartości bazy danych drukarek utrzymywanej na serwerze serwisu linuxprinting.org) oraz pakietu hpijs (tworzonego przez dział wsparcia dla Linux-a w Hewlett-Packard) oraz ewentualnie pakietu hplip (również HP).

Uwaga: Powyższe pakiety podczas instalacji umieszczają setki plików PPD w katalogu /usr/share/ppd. Po podlinkowaniu zasobu jako podkatalogu w /usr/share/cups/model pliki PPD staną się widoczne w CUPSie.

Uwaga: Po umieszczeniu odpowiedniego pliku PPD w katalogu /usr/share/cups/models należy ponownie uruchomić serwer CUPS.

Instalacja właściwej drukarki w serwerze CUPS można wykonać przez interfejs WWW serwera (http://localhost:631) wybierając Do Administrative TaskàAdd Printer, a następnie podając nazwę drukarki, jej backend oraz typ drukarki (odpowiada odpowiedniemu plikowi PPD). Należy upewnić się by drukarka byłą wystartowana i akceptowała wydruki.

Drukarka może zostać zainstalowana również z linii komend przez wykonanie polecenia lpadmin:


root / #lpadmin –p <nazwa_drukarki> -v <backend> -E –m <plik_PPD>
root / #/usr/bin/enable <nazwa_drukarki>
root / #/usr/sbin/accept <nazwa_drukarki>

np.:


root / #lpadmin –p Canon_CP660_A3 -v lpd://192.168.1.123/xjprint -E –m CA660A10.PPD
root / #/usr/bin/enable Canon_CP660_A3
root / #/usr/sbin/accept Canon_CP660_A3

Uwaga: Warto wykonać wydruk testowy (przez interfejs WWW serwera CUPS) aby zweryfikować poprawność instalacji.

17.4.4. Udostępnianie drukarek sieciowych przez serwer plików

17.4.4.1. Wstępna weryfikacja

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


root / #ldd `which smbd`

libcups.so.2 => /usr/lib/libcups.so.2 (0x40106000)

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

Jeśli Samba poprawnie wspiera CUPS-a i ten jest już uruchomiony sprawdzamy czy Samba jest w stanie „zobaczyć” drukarki eksportowane przez serwer wydruku. Wykonujemy polecenie listujące drukarki z serwera wydruku:


root / #rpcclient localhost –U root –c ‘enumprinters’ Password: <haslo_roota>

flags:[0x800000]
name:[\\fs1-bogus\CanonCP660]
description:[\\fs1-bogus\CanonCP660,CanonCP660,]
comment:[]

Jeśli polecenie nie jest w stanie wylistować drukarek zainstalowanych w CUPS-ie wówczas należy wstrzymać się od dalszej konfiguracji do czasu rozwiązania problemu, gdyż udostępnienie drukarek w Sambie za pomocą polecenia cupsaddsmb się nie powiedzie.

17.4.4.2. Konfiguracja Samby

Modyfikujemy plik konfiguracyjny Samby:


#/etc/samba/smb.conf[global]
#...sp
#printer configuration
load printers = Yes
printing = cups
printcap name = cups
printer admin = root @"Print Operators"
#...

[printers]
comment = All Printers
path = /var/spool/samba
browseable = No
public=Yes
guest ok = Yes
writable=No
printable = Yes
printer admin = root @"Print Operators"

[print$]
comment = Printer Driver Download Area
path = /var/lib/samba/printers
browseable = Yes
guest ok = No
read only = Yes
write list = root @"Print Operators"

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

W ten sposób zainicjowaliśmy współpracę serwera wydruku CUPS z serwerem plików Samba dla utrzymywania zbioru drukarek sieciowych.

Parametr path w sekcji [printers] wskazuje na spool-a Samby. Katalog /var/spool/samba powinien posiadać nadane prawa 1777 (srwx).

Uwaga: Ważne by położenie spool-a Samby było inne niż położenie spool-a serwera CUPS (parametr RequestRoot w pliku /etc/cups/cupsd.conf).

Parametr path w sekcji [print$] wskazuje katalog przechowujący sterowniki drukarek dla klientów Windows. Depozyt sterowników powinien zawierać następujące podkatalogi:


[print$]
|--COLOR #sterowniki dla
|--IA64 #sterowniki dla “Windows NT 64-bit Intel”
|--W32X86 #sterowniki dla “Windows NT x86”
|--W32ALPHA #sterowniki dla “Windows NT Alpha_AXP”
|--W32MIPS #sterowniki dla “Windows NT R4000”
|--W32PPC #sterowniki dla “Windows NT PowerPC”
|--WIN40 #sterowniki dla “Windows 95/98”
|--x64 #sterowniki dla “Windows NT 64-bit AMD”

Warto Nadać pełne prawa zapisu (777) do powyższych podkatalogów.

Udostępnienie drukarki przez serwer plików następuje po wykonaniu polecenia:
root / #cupsaddsmb –H localhost –U root <nazwa_drukarki>
np.:


root / #cupsaddsmb –H localhost –v –U root Canon_CP660_A3 Password for Administrator required to access localhost via SAMBA:
Sucessfully set Canon_CP660_A3 to driver Canon_CP660_A3

Uwaga: Wymagane jest hasło na konto administratora domeny.

Jeśli chcemy udostępnić wszystkie drukarki zainstalowane w CUPS-ie polecam wydanie komendy:


root / #cupsaddsmb –H localhost –U root -a
Password for Administrator required to access localhost via SAMBA:

Po wykonaniu polecenia cupsaddsmb warto zrestartować serwer Samby aby zmiany zostały zauważone przez demona smbd.

W tym momencie drukarki zinstalowane w serwerze wydruku powinny być już widoczne jako zasób sieciowy serwera plików Samba.

17.4.4.3. Tworzenie depozytorium sterowników dla udostępnionych drukarek sieciowych

Aby w pełni zakończyć instalację drukarki należy dokonać wgrania jej sterowników na serwer. W tym celu należy uruchomić stację Windows i przejrzeć zasoby naszego serwera plików Samba z pomocą menadżera plików.

Uwaga: Poniższa operacja powinna być wykonywana na stacji roboczej z konta root.

W głównym udziale serwera plików Samba powinien być widoczny katalog Printers and Faxes, w którym znajduje się dodana drukarka. Po znalezieniu drukarki podjąć próbę przejrzenia jej właściwości (opcja Properties w menu kontekstowym). Operacja powinna zakończyć się następującym błędem:

Device settings cannot be displayed. The driver for the specified printer is not installed, only spooler properties will be displayed. Do you want to install the driver now?

Na powyższe pytanie odpowiadamy No - tylko taka odpowiedź umożliwi nam dostęp do okna właściwości drukarki.

W oknie właściwości drukarki należy wybrać zakładkę Advanced i przycisk New Driver... co spowoduję uruchomienie wizarda Add Printer Driver. W czasie pracy wizarda APD należy wybrać przycisk Have Disk... i podać lokalizację zawierającą sterowniki instalowanej drukarki. Odpowiednie pliki zostaną skopiowane do depozytu.

17.4.4.4. Wgrywanie sterowników Postscript

Wykorzystamy sterowniki przygotowane przez zespół CUPS-a. W tym celu należy pobrać z sieci plik cups-samba-5.0rc3.tar.gz.

Rozpakowujemy archiwum do katalogu:


root / #tar xvzf cups-samba-5.0rc3.tar.gz
cups-samba.install
cups-samba.license
cups-samba.readme
cups-samba.remove
cups-samba.ss

Następnie uruchamiamy instalator - cups-samba.install - dzięki temu sterowniki Postscripta zostaną automatycznie umieszczone w katalogu /usr/share/cups/drivers. Będą to następujące pliki: cupsdrvr.dll, cupsui.dll oraz cups.hlp.

Uwaga: Powyższe sterowniki Postscript obsługują jedynie systemy operacyjne z rodziny MS Windows NT, czyli NT/2000/XP.

17.5. Synchronizacja przeglądarek netbiosowych między podsieciami

Założenie: Mamy dwie sieci lokalne 172.16.0.0/16 i 172.17.0.0/16 w których znajdują się komputery z tej samej grupy roboczej SERVER. W obu sieciach znajdują się lokalne serwery plików Samba o nazwach/adresach odpowiednio FS-GDANSK/172.16.0.1 oraz FS-KRAKOW/172.17.0.1. W sieciach lokalnych nie ma żadnych (innych) kontrolerów domeny.

Wymuszamy:

  1. lokalną przeglądarkę sieci na obu serwerach plików
  2. serwer WINS na obu serwerach
  3. przeglądarkę domenową na serwerze FS-GDANSK
  4. synchronizację lokalnych list klientów NetBIOS między serwerami

#/etc/samba/smb.conf (FS-GDANSK)
[global]
#....
workgroup = SERVER
domain master = Yes
local master = Yes
preferred master = Yes
os level = 35
remote browse sync = 172.17.0.1
wins support = Yes
#....
#------------- END --------------

#/etc/samba/smb.conf (FS-KRAKOW)
[global]
#....
workgroup = SERVER
domain master = No
local master = Yes
preferred master = Yes
os level = 33
remote browse sync = 172.16.0.1
wins support = Yes
#....
#------------- END --------------

Obie sieci mogą korzystać z jednego, wspólnego serwera WINS – wówczas na serwerze plików z sieci pozbawionej serwera WINS należy ustawić przekierowywanie lokalnych rozgłoszeń NetBIOS:


#/etc/samba/smb.conf (FS-KRAKOW)
[global]
#....
domain master = No
#....
wins support = No
wins server = 10.10.0.1
wins proxy = Yes
#....
#------------- END --------------

Na koniec dokonujemy restartu obu serwerów plików Samba.

17.6. Dostęp Samby (kontroler domeny) do zdalnego katalogu LDAP

Zakładamy, że zdalny serwer LDAP jest poprawnie skonfigurowany, uruchomiony i obsługuje szyfrowane połączenia.

Konfigurujemy oprogramowanie klienckie LDAP zgodnie z instrukcja w rozdziale 7.2. Konfiguracja programów klienckiech dla zdalnego serwera LDAP.

Poza tym modyfukujemy plik /etc/samba/smb.conf w następujący sposób:


#/etc/samba/smb.conf (SSL)
[global]
#...
ldap ssl = on
#...
idmap backend = ldap:ldaps://ldap_server_address
#...
passdb backend = ldapsam:ldaps://ldap_server_address
#...
#------------- END --------------

UFF 🙂

="-oss -apm -arts -avi -encode -gif -gpm -gtk -gtk2 -imlib -jpeg \ -kde -gnome -mad -mikmod -motif -mpeg -nls -oggvorbis -opengl -pdflib \

–png -qt -quicktime -spell -truetype -X -xmms -xv ssl sasl ldap imap pam

readline oav

 

Strony: 1 2 3 4 5 6