Samba4[.1] AD és társai Wheezy-n

Mielőtt elkezdjük az egész mókát, válasszunk host- és domain nevet. Én a adsrv01 host és example.org domain nevet fogom használni (mindkettő később lesz fontos).

Szerk.: A domain név. Itt ugye két kérdéses dolog van: akarunk-e kívülről is elérhető szolgáltatásokat üzemeltetni és akarunk-e .local TLD-t (a split dns kb. egyértelmű). Feltélezem, hogy lesznek külső szolgáltatásaink, és nem akarunk .local-lal szívni (hitvita, Wiki lapon linkelnek is néhány oldalt, hogy már az MS sem ajánlja, aztán linkelnek párat, hogy mégis, azért nem használom, hogy ne kelljen az SSL certekbe még egy raklap hostnevet felvinni :) ). A lényeg: választhatunk nem létező domain nevet is (ez nagyjából az example.org) vagy használhatunk pl. example.local-t, ekkor persze kívülről semmiképp nem lesz elérhető a zónánk.

----

Alaptelepítés:

A netinstall iso bőven elég lesz (debian-7.2.0-amd64-netinst.iso nevűt használom), Expert install-al telepítsük, mert nagyon minimalista rendszert akarunk. Locale-ből az en_US.UTF-8-at vegyük system locale-nek, és ha már arra járunk, dobjuk fel a hu_HU.UTF-8-at is, biztos, ami biztos. Üssük be a host és domain nevünket. A felhasználói fiókoknál választhatunk, hogy akarunk-e helyi fiókot, az egységesség jegyében szerintem érdemes csak a root-ot létrehozni (a shadow fájl használatát mindenképp engedélyezzük), a "felhasználói" fiókokat pedig tartsuk következetesen az AD-ben (később úgyis beállítjuk, hogy az AD-ből is tudjanak authentikálni, akik a megfelelő csoport tagjai). A root jelszavának válasszunk egy megfelelően hosszú jelszót (a távoli belépést majd úgyis letiltjuk nála és jó esetben csak disaster recovery közben kell majd használni :) ). Szinkronizáljunk NTP-vel, mert miért ne.

A partícionálásnál érdemes figyelembe venni, hogy az adatbázist tartalmazó fájlrendszerre nagyon ajánlott a barrier=1 opciót használni, ami visszafogja a sebességet, illetve a megosztásokat tartalmazó fájlrendszereken kell a user_xattr és az acl opció. Éppen ezért ajánlom, hogy a szokásos partíciókon felül hozzunk létre egy /var/lib/samba helyre felcsatolt fájlrendszert is, ami az adatbázisunkat fogja tartalmazni, illetve egy /srv/samba helyre felcsatolt fájlrendszert a megosztásoknak (természetesen LVM felett, hogy később könnyebb dolgunk legyen). A próba gépen használt partíciókiosztás:
* /dev/sda1 500 MB /boot ext3-al
* /dev/sda2 42.4 GB LVM
* 1 Volume Group vgadsrv01a néven
* vgadsrv01a/swap 1 GB swap
* vgadsrv01a/root 8 GB / ext4-el
* vgadsrv01a/srv 8 GB /srv/samba ext4-el
* vgadsrv01a/samba 8 GB /var/lib/samba ext4-el
(külön home-ot nem csináltam, jó esetben a root-on és az egy-két adminisztrátoron kívül nem sokat fognak bejárni a gépre). A mount option-ökkel egyelőre ne foglalkozzunk, telepítés után fstab-ból majd beállítjuk.

Telepítsük az alaprendszert, majd állítsunk be egy szívünknek tetsző mirrort, a tasksel-nél pedig kapcsoljunk ki mindent (ill. ha VirtualBox-ban követjük a leírást, akkor ne tegyük fel a virtualbox-ose-guest-x11 csomagot, mert minek). GRUB/LILO (ízlés kérdése) és reboot.

---
Hálózat, NAT, DHCP:

A reboot után biztos ami biztos updateljük a csomagokat:

root@adsrv01:~# apt-get --assume-yes update && apt-get --assume-yes upgrade

Konfiguráljuk az adaptereket:
root@adsrv01:~# editor /etc/network/interfaces

A végleges fájlnak valahogy így kell kinéznie:

# This file describes the network interfaces available on your system
# and how to active them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet static
address 1.2.3.4
netmask 255.255.255.0
gateway 1.2.3.1

# The internal network interface
allow-hotplug eth1
iface eth1 inet static
address 10.2.3.1
netmask 255.255.255.0

Gyorsan ellenőrizzük a /etc/resolv.conf-unkat is, egyelőre írjuk be az ISP (vagy a kugli) DNS szervereit:

nameserver 8.8.8.8

Elvileg egy networking restart nem minden esetben elegendő a hálózat felállításához és nagyon ráérünk, úgyhogy
root@adsrv01:~# reboot

A reboot után ellenőrizzük, hogy működik-e a net, például dobjunk fel egy új csomagot (nyugodtan mentsük a mostani szabályinkat, elvileg üres láncokat kéne kapnunk):
root@adsrv01:~# apt-get --assume-yes install iptables-persistent

Gyorsan lőjünk össze egy minimális iptables konfigurációt is (később szigorítunk majd a szabályokon) a /etc/iptables/rules.v4 fájlba:

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
-A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth1 -o eth0 -j ACCEPT
:OUTPUT ACCEPT [0:0]
COMMIT

Szerk.: A service iptables-persistent reload kimaradt; az is kell.

Még engedélyeznünk kell a hálózati forgalom továbbítását, úgyhogy:
root@adsrv01:~# editor /etc/sysctl.conf
Keressük meg a net.ipv4.ip_forward=1 sort és vegyük ki a # jelet az elejéről. Az újraindítás nélküli életbeléptetéshez:
root@adsrv01:~# echo "1" > /proc/sys/net/ipv4/ip_forward

A folytatás előtt fogjunk egy másik gépet, tegyük be a belső hálózatba, állítsunk be rajta egy fix címet (mondjuk 10.2.3.2) és ellenőrizzük, hogy működik-e a net.

Ennek a résznek a zárásaként még lőjünk be egy minimalista DHCP szervert:
root@adsrv01:~# apt-get --assume-yes install isc-dhcp-server

Csináljunk egy mentést egy róla, töröljük, majd szerkeszzük a /etc/dhcp/dhcpd.conf-ot és legyen ez a tartalma:

default-lease-time 300;
max-lease-time 1800;
option domain-name "example.org";
option domain-name-servers 8.8.8.8;
authoritative;
log-facility local7;

subnet 10.2.3.0 netmask 255.255.255.0 {
option broadcast-address 10.2.3.255;
option ntp-servers 10.2.3.1;
option routers 10.2.3.1;
range 10.2.3.2 10.2.3.254;
}

Egy
root@adsrv01:~# service isc-dhcp-server restart
után próbáljuk ki, kap-e címet a "vendég" gépünk, és rendben működik-e rajta a kapcsolat.

---

SSH első kör:

Dobjunk fel egy SSH szervert!
root@adsrv01:~# apt-get --assume-yes install openssh-server

Egy későbbi részben (mikor már vannak más usereink is) még ezen állítgatunk egy kicsit, egyelőre csak címszavakban: ListenAddress, PermitRootLogin, X11Forwarding.

---

Bind9 első kör

Telepítsük fel a Bind-ot és a dnsutils csomagot, utóbbi hasznos lesz (bár nem kifejezetten szükséges).

root@adsrv01:~# apt-get --assume-yes install bind9 dnsutils

Majd essünk neki a konfig fájlnak, és szerkessszük egy kicsit:
root@adsrv01:~# editor /etc/bind/named.conf.options

options {
directory "/var/cache/bind";
forwarders {
8.8.8.8; # ISP elso DNS szervere
208.67.220.220; # ISP masodik DNS szervere
};
dnssec-validation no;
auth-nxdomain no;
listen-on { 127.0.0.1; 10.2.3.1; };
listen-on-v6 {};
allow-query { 127.0.0.0/24; 10.2.3.0/24; };
};

Indítsuk újra a bind-ot (service bind9 restart), majd a resolv.conf-ban álljunk át az új DNS szerverünkre:

domain example.org
search example.org
nameserver 127.0.0.1

Egy root@adsrv01:~# nslookup index.hu-val teszteljük le, hogy működik-e, majd irány tovább.

Szerkesszük a korábbi dhcp konfigurációt, és használjuk a Google DNS-e helyett a sajátunkat (aztán természetesen indítsuk újra a szolgáltatást):

option domain-name-servers adsrv01.example.org.;

(a pont a végén fontos, egyébként lehet, hogy a DHCP server gondolkodás nélkül kiküldi a loopback interface címét)

--

Fájlrendszerek, Fstab

Telepítsük az acl és attr csomagokat

root@adsrv01:~# apt-get --assume-yes install acl attr

Essünk neki az /etc/fstab fájlnak és mindkét sorban, ahol szerepel a samba szó (/srv/samba és /var/lib/samba) a defaults helyére írjuk a user_xattr,acl,barrier=1,defaults szöveget, majd
root@adsrv01:~# mount -a

Ezután lépjünk át a /var/lib/samba könyvtárba, majd ellenőrizzük az xattr és acl támogatást:

root@adsrv01:/var/lib/samba# touch test.txt
root@adsrv01:/var/lib/samba# setfattr -n user.test -v test test.txt
root@adsrv01:/var/lib/samba# setfattr -n security.test -v test2 test.txt
root@adsrv01:/var/lib/samba# getfattr -d test.txt
# file: test.txt
user.test="test"

root@adsrv01:/var/lib/samba# getfattr -n security.test -d test.txt
# file: test.txt
security.test="test2"

root@adsrv01:/var/lib/samba# setfacl -m g:adm:rwx test.txt
root@adsrv01:/var/lib/samba# getfacl test.txt
# file: test.txt
# owner: root
# group: root
user::rw-
group::r--
group:adm:rwx
mask::rwx
other::r--

root@adsrv01:/var/lib/samba# rm test.txt
root@adsrv01:/var/lib/samba# cd ~

Ha biztosra akarunk menni, akkor ugyanezt a /srv/samba-n belül is eljátszhatjuk, ugyanezt kell kapnunk.

--

Samba AD

Ez az a lépés, ahol regisztrálnunk kell az Enterprise Samba-éknál (https://portal.enterprisesamba.com/), ahol bejelentkezés után a Samba Packages résznél több disztribúcióhoz kapunk repository linkeket. A Wheezy-hez szánt repository https-en megy, így egy kell a https plug-in az apt-hoz:

root@adsrv01:~# apt-get --assume-yes install apt-transport-https

Ezután nyissuk meg a Wheezy-hez szánt "Samba 4.0 Repository" linket, ami valójában egy apt source fájl. A tartalmát (ezért kellett az ssh :) ) copy-pasteljük be a /etc/apt/sources.list.d/sernet.list fájlba:

deb https://user:pass@download.sernet.de/packages/samba/4.1/debian wheezy main
deb-src https://user:pass@download.sernet.de/packages/samba/4.1/debian wheezy main

Szerk.: Link átírva a 4.1-re

(Pro-tip: ne próbáljuk kézzel reprodukálni azt a jelszót. Valahol el fogjuk írni. Mindig.)

Töltsük le és telepítsük az aláíró kulcsokat:
root@adsrv01:~# wget http://ftp.sernet.de/pub/sernet-samba-keyring_1.3_all.deb && dpkg -i sernet-samba-keyring_1.3_all.deb

És jöhet a telepítés:
root@adsrv01:~# apt-get update && apt-get install --assume-yes sernet-samba-ad ntp

Mielőtt provision-olnánk (szép magyar kifejezés) a domain-t, csapjuk le a külső interface-t (ifconfig eth0 down), ha több címet talál, akkor "okosan" próbál találni magának egyet (nem mindig sikerül...).

Most jön az igazság pillanata, a domain létrehozása. Ha virtuális környezetben vagyunk, EZ legyen az a pillanat, amikor csinálunk egy snapshotot, mert ezután fog rákérdezni az adminisztrátor jelszavára ÉÉS a provision közepén (a képernyőnyi stack trace-ből) fog eszünkbe jutni, hogy van megkötés a jelszavakra. Természetesen megoldható, hogy kitakarítsuk a félig elkészült domain minden nyomát a rendszerből, de 1) egyszerűbb visszaállni a snapshotra és 2) egyszerűbb újrakezdeni az egészet.

Itt felhívnám a figyelmet a --use-rfc2307 opcióra, ez annyit jelent, hogy azonnal hozzáadja az RFC2307 kiterjesztéseket az LDAP sémához, ami Microsoft-os körökben a "Unix-os kiterjesztés". Nem kifejezetten lényeges, viszont hosszú távon egyszerűsítheti az életünket, ha egy központi helyen definiálva vannak a UID/GID értékek. Cserébe (ugyebár 1:1-ben klónozni akarták az AD viselkedését) automatikusan NEM rendeli hozzá az LDAP-ban a uid/gid-et a userekhez és csoportokhoz, így erről nekünk kell gondoskodnunk.

root@adsrv01:~# samba-tool domain provision --use-rfc2307 --interactive
Realm [EXAMPLE.ORG]:
Domain [EXAMPLE]:
Server Role (dc, member, standalone) [dc]:
DNS backend (SAMBA_INTERNAL, BIND9_FLATFILE, BIND9_DLZ, NONE) [SAMBA_INTERNAL]: BIND9_DLZ
Administrator password:
Retype password:

A Realm a Kerberos realm lesz, ha jól be van állítva a resolv.conf-unk, akkor el fogja találni (nem kötelező, de szokás a dns domain név nagybetűs formáját használni). A Domain a windows domain egyszerű neve (szokás a dns domain név legbelső részét használni), a server role dc (erre pályázunk), a DNS back-endnél viszont válasszuk a BIND9_DLZ-t. Az Administrator fiók jelszavának válasszunk egy erős jelszót, legyen benne szám, betű, speciális karakter és legalább 6 jelből álljon! Miután megkaptuk a féloldanyi stack trace-t, álljunk vissza a snapshotra, és próbáljuk újra, ezúttal megfogadva a jelszó szabályokra vonatkozó tanácsokat ;)

Ezennel elkészült a tartományunk, csak még nem egészen. Hozzuk vissza külső interfészt (ifconfig eth0 up), majd kezdődhet a DNS konfigolás második fele (lesz még harmadik is, de nem ma).

Azoknak, akik végigolvasták, hogy mi mindent írt ki lehet, hogy feltűnt, hogy létrehozott egy krb5.conf fájlt, ami nekünk jó lesz, csak annyira nem. Tegyük fel a krb5-user csomagot (a megjelenő varázsló létrehozza/felülírja a krb5.conf fájlt), majd szerkesszük:

root@adsrv01:~# apt-get install krb5-user
root@adsrv01:~# editor /etc/krb5.conf

A fájl tartalma legyen:

[libdefaults]
default_realm = EXAMPLE.ORG
dns_lookup_kdc = no
dns_lookup_realm = no
ticket_lifetime = 24h

default_tgs_enctypes = rc4-hmac des-cbc-crc des-cbc-md5
default_tkt_enctypes = rc4-hmac des-cbc-crc des-cbc-md5
permitted_enctypes = rc4-hmac des-cbc-crc des-cbc-md5

[realms]
EXAMPLE.ORG = {
kdc = adsrv01.example.org
admin_server = adsrv01.example.org
default_domain = adsrv01.example.org
}

[domain_realm]
.example.org = EXAMPLE.ORG
example.org = EXAMPLE.ORG

A /etc/bind/named.conf.local fájlba írjuk be a

include "/var/lib/samba/private/named.conf";

sort. Állítsuk be a fájl jogosultságait:

root@adsrv01:~# chgrp bind /var/lib/samba/private/named.conf
root@adsrv01:~# chmod g+r /var/lib/samba/private/named.conf

A /etc/bind/named.conf.options fájlba a listen-on-v6{} sor utánra írjuk be:

tkey-gssapi-keytab "/var/lib/samba/private/dns.keytab";

És állítsuk a fájl jogosultságokat:

root@adsrv01:~# chgrp bind /var/lib/samba/private/dns.keytab
root@adsrv01:~# chmod g+r /var/lib/samba/private/dns.keytab

A következő lépés az, amit a Samba provision "elfelejt" kiírni, és legrosszabb esetben strace-el kell keresgetni. Hogy is mondjam... a bind-nál szép hosszú egy trace fájl.

root@adsrv01:~# chmod o+x /var/lib/samba/private

A másik "feature", amire sehol nem találtam utalást a named.conf.update.static fájl, amiben kézzel adhatunk meg jogosultságokat DNS update-hez. Adjunk is hozzáférést a zónáinkhoz:

Szerk.: A fájl teljes elérési útja: /var/lib/samba/private/named.conf.update.static

grant EXAMPLE.ORG ms-self * A;
grant EXAMPLE.ORG wildcard *.3.2.10.in-addr.arpa PTR;

Magyarra fordítva: az EXAMPLE.ORG Kerberos tartományból a saját A rekordok frissítésére és a (még nem létező) reverse zónában a PTR rekordok módosítására adunk jogot.

Izzítsuk be a bind-ot:

root@adsrv01:~# service bind9 restart

A mai utolsó lépés a Samba elindítása. A Sernet-es csomagban több init script is szerepel (a Samba 3 stílusú "szétbontott" [smb, nmb, winbindd] és a Samba 4-es ad stílus), és alapbeállításon egyik sem indul el. Szerkesszük a /etc/defaults/sernet-samba fájlt és írjuk át a SAMBA_START_MODE változót ad-ra. Az init scripteket copy-paste-el írtsuk ki ciklussal:

root@adsrv01:~# for SERVICE in $(ls /etc/init.d/ | grep sernet); do insserv -r $SERVICE; done
root@adsrv01:~# insserv sernet-samba-ad

Szerk.: Mielőtt elindítanánk a Samba-t, kövessük a "Samba4 csak a belső (és loopback) interface-n" részben leírtakat, hogy utólag ne kelljen kigyilkolnunk a belső DNS-ből a külső interface címeket, amiket úgyis letűzfalazunk (pár kattintás, de egyszerűbb már most elintézni)!

Indítsuk el a Samba-t!

root@adsrv01:~# service sernet-samba-ad start

Teszteljük a Kerberos-t, authentikáljunk admin-ként:

root@adsrv01:~# kinit administrator
Password for administrator@EXAMPLE.ORG:
Warning: Your password will expire in 41 days on Mon Dec 16 20:24:04 2013

Ha már erre járunk hozzuk létre a korábban már említett reverse belső zónánkat:

root@adsrv01:~# samba-tool dns zonecreate adsrv01 3.2.10.in-addr.arpa
root@adsrv01:~# samba-tool dns add adsrv01 3.2.10.in-addr.arpa 1 PTR adsrv01.example.org
root@adsrv01:~# nslookup 10.2.3.1
Server: 127.0.0.1
Address: 127.0.0.1#53

1.3.2.10.in-addr.arpa name = adsrv01.example.org.

Fogjunk egy Windows-os gépet, és léptessük be a tartományba, majd ellenőrizzük, hogy létrejött mind az A, mind a PTR rekordja (felteszem a gép neve desktop001 és a 10.2.3.2 címet használja):

root@adsrv01:~# nslookup desktop001
Server: 127.0.0.1
Address: 127.0.0.1#53

Name: desktop001.example.org
Address: 10.2.3.3

root@adsrv01:~# nslookup 10.2.3.3
Server: 127.0.0.1
Address: 127.0.0.1#53

3.3.2.10.in-addr.arpa name = desktop001.example.org.

Szerk.: Ha Windows 7-el próbálkozunk, ne várjuk, hogy a reverse rekord megjelenjen, vagy a Vista-ban vagy a 7-ben megváltoztatták a default működést és többe a kliens nem frissíti a rekordokat. A TCP/IP beállítások Speciális részén a "Use this connection's DNS suffix in DNS registration" opció kell neki. Group Policy-ból és command line-ból is orvosolható (http://setspn.blogspot.be/2010/12/windows-7-reverse-lookup-dns.html, http://setspn.blogspot.hu/2013/06/windows-7-reverse-lookup-dns.html). Ha megváltoztattuk a beállítást, egy ipconfig /registerdns -t adjunk ki (azt hiszem Rendszergazda parancssor kell neki, nem esküszöm meg rá), ekkor már lennie kell reverse PTR-nek.
Szerk2.: A második linkelt cikk alján írt kérdés (jó-e, hogy a kliensek basztatják a DNS-t és nem a DHCP) egyszerű a válasz: a másik megoldásnál (a DHCP szerveren onCommit és onRelease hook-okkal, szórakozás) szerintem jobb. Ha valakit érdekel ez a megoldás (szép nagy lease time-al még az indított plusz processzeszek se akkora probléma: http://blog.michael.kuron-germany.de/2011/02/isc-dhcpd-dynamic-dns-upda…). Kell neki egy új user az AD-ben (samba-tool user add), a user keytab-ja (exportkeytab), a fenti címen található script )van belőle pár példány a kommentek között is, ami szépen kommentelve van, azt teszteltem annó) ill. egy új bejegyzés a named.conf.options.static-ba (grant dhcp-dns_KUKAC_EXAMPLE.ORG * A PTR;)

Ennyi mára, gyorsan lőjük le a szervert és a Windowst, mert mindkettő megállás nélkül sipítozna a logokba, a Samba a nyomtatók, a Windows az NTP miatt. Ami nem jó nekünk :) Holnap folytatjuk.

---------------
---------------

Intermezzo két nap között: ellenőrizzük a serveren a hosts fájlt, a teszt rendszeren a 127.0.1.1-et sikerült az fqdn-jéhez hozzárendelnie. Töröljük a francba, nem egészséges, ha azon próbál pl. DNS-t updatelgetni, ami csak 127.0.0.1-en enged vagy a belső interface-n.

---------------
---------------

Ahogy tegnap ígértem, ma elhallgatatjuk a CUPS-ról szóló üziket (vagy megosztunk nyomtatót, ahogy tetszik), beállítjuk az NTP-t és ha még nem leszünk (leszek :) ) túl fáradt, belőjük a domain-es belépést a szerveren.

Először is egy rövid megjegyzés: tapasztalt Samba adminok már valószínűleg izommemóriából írják a testparm -v parancsot, ami baj. Ugyanis a 4-esnél az nem tökéletes (erre jó példa a későbbiekben előkerülő ntp signd socket directory direktíva), de már Petőfi is megírta, hogy "Van egy kék tó a fák alatt, ha testparm minusz vét használsz eltöröm a lábadat"; helyette a samba-tool testparm -v kell nekünk.

--------------
Printing letiltás

Ha nem akarunk a szerveren telepített nyomtatót megosztani, akkor egyszerűen szerkesszük a /etc/samba/smb.conf fájlt, és a [global] részbe vigyük fel a következő direktívákat:

load printers = no
printcap name = /dev/null
disable spoolss = yes

Indítsuk újra a sernet-samba-ad szolgáltatást, és öröljünk, hogy nem picsogja tele a logjainkat :)

Ha akarunk nyomtatót megosztani, akkor telepítenünk és konfigurálnunk kell a CUPS-ot. Ennek a mikéntjének kivételesen jó a dokumentációja a Samba wiki-ben (https://wiki.samba.org/index.php/Samba_as_a_print_server), így használhatjuk azt. Részletesebb infót erről most nem írok, mert nincs a kezem ügyében tesztelhető nyomtató, a CUPS-PDF meg nem feltétlenül jó tesztalany. Igény esetén copy-pastelem a Wiki szócikket :)

-----------------
NTP

Taknyoljunk inkább NTP-t. Az NTP amúgy azért kell, hogy ne legyen tele az EventLog NTP hibákkal, na meg a Kerberos-hoz "sem árt"...

Egy testparm megsúgja, hogy a Samba a /var/lib/samba/ntp_signd helyen hozza létre az MS aláírt NTP-hez szükséges socket-et. Egy kicsit a jogosultságokkal játszanunk kell:

root@adsrv01:~# chgrp ntp /var/lib/samba/ntp_signd
root@adsrv01:~# chmod 750 /var/lib/samba/ntp_signd

Ezután még el kell magyaráznunk az NTP-nek, hogy lesz szíves ezt használni. Windows-os szervereken az NTP úgy szokott menni, hogy kívülre egy gép szinkronizál (az, amelyiknél PdcEmulation FSMO Role van), a tartományon belül pedig ehhez szinkronizálnak a szerverek, a kliensek meg ahhoz a DC-hez, amelyikhez akarnak. Ez nálunk is ajánlott: egy gép kommunikáljon kintre, az összes többi szinkronizáljon azzal és egymás közt.

Essünk neki a /etc/ntp.conf fájlnak:

driftfile /var/lib/ntp/ntp.driftfile
server 0.debian.pool.ntp.org iburst
server 1.debian.pool.ntp.org iburst
server 2.debian.pool.ntp.org iburst
server 3.debian.pool.ntp.org iburst

restrict default mssntp
restrict 127.0.0.1
restrict 10.2.3.0 netmask 255.255.255.0 nomodify notrap
ntpsigndsocket /var/lib/samba/ntp_signd

Majd indítsuk újra az NTP-t:

root@adsrv01:~# service ntp restart

Indítsuk be a Windows-t és egy parancssorban adjuk ki a w32tm /resync parancsot; jó esetben tudnia kell frissítenie az időt.

------------------
Helyi winbind

Első lépésként hozzunk létre magunknak egy sima felhasználói fiókot:

root@adsrv01:~# samba-tool user add szamba4.ezek --surname "Szamba Négy" --given-name "Ezek"

A következőben beállítjuk, hogy csak egy csoport tagjai léphessenek be a gépre (protip: ahány ssh ablakunk csak lehet, legyen nyitva, amikor PAM-ot állítgatunk), ehhez kell maga a csoport:

root@adsrv01:~# samba-tool group add "Linux Admins"

Majd adjuk hozzá a userünket a csoporthoz:

root@adsrv01:~# samba-tool group addmembers "Linux Admins" szamba4.ezek

Módosítsuk az nsswitch-et, hogy a user és csoport tagságokat a winbind-ból is megpróbálja elővakarni a rendszer:

root@adsrv01:~# editor /etc/nsswitch.conf

A passwd: és group sorok végére írjuk be, hogy winbind:

passwd: compat winbind
group: compat winbind

Próbáljuk is ki:

root@adsrv01:~# getent passwd | grep Administrator
EXAMPLE\Administrator:*:0:100::/home/EXAMPLE/Administrator:/bin/false

Itt azonnal feltűnik, hogy a /bin/false a default shell, ami nekünk nem jó. Testparm barátunk megmondja, hogy a template shell felelős ezért, így vegyük fel az smb.conf global részébe:

template shell = /bin/bash

(rövid megjegyzés: a Samba4-es Winbind még erősen work-in-progress, így bár az RFC2307 miatt tárolhatnánk a shell-t az ldap-ban userenként is, azt nem fogja figyelembe venni.)

Indítsuk újra a sambát és újra kiadva a getent-et ellenőrizzük le, hogy jó lett-e.

Most jön a PAM konfigja. Sorban a common-auth, common-account és common-session fájlokat kell szerkeszteni a /etc/pam.d/ könyvtárban.

Az auth a legbonyolultabb. Jelenleg valahogy így kellene kinéznie:

# here are the per-package modules (the "Primary" block)
auth [success=1 default=ignore] pam_unix.so nullok_secure
# here's the fallback if no module succeeds
auth requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth required pam_permit.so
# and here are more per-package modules (the "Additional" block)
# end of pam-auth-update config

Ezt a részt cseréljük le erre:

auth [success=3 default=ignore] pam_unix.so nullok_secure
auth [success=ok default=1] pam_winbind.so try_first_pass
auth [success=1 default=ignore] pam_succeed_if.so user ingroup [EXAMPLE\Linux Admins]
auth requisite pam_deny.so
auth required pam_permit.so

Ez mit jelent? Először a /etc/passwd fájlból próbál authentikálni, ha sikerül, előre ugrik hármat, a pam_permit-re. Ha nem sikerült, akkor tovább lép a winbind alapú belépésre, ami ha sikerül, akkor még ellenőrizzük, hogy tagja-e a Linux Admins csoportnak, ha bármelyik hibát jelez, akkor a pam_deny-al megtagadjuk a belépést.

A csoportra szűrést hivatalosan a winbind pam modul tudja, nem hivatalosan nem sikerült sehogy működésre bírnom (sem csoportnévvel, sem GUID-al)

A common-account fájlba vigyük fel az első nem-komment sorba, hogy:

account sufficient pam_winbind.so

Szintén az első nem-komment sorba, de már a common-session fájlba vegyük fel a:

session required pam_mkhomedir.so
session required pam_winbind.so

bejegyzéseket.

Próbáljuk ki, hogy be tudunk-e lépni a szamba4.ezek userrel, illetve hogy nem tudunk belépni az Administrator fiókkal. Ha minden stimmel, akkor a mai napnak is vége van. Holnap visszatérünk még egy kicsit az SSH-hoz, lövünk egy jobb fajta tűzfalat és elkezdünk játszani az SSL cert-ekkel.

---------------
---------------

Megcsúsztam egy kicsit, de jön az ígért folytatás.

---------------
---------------

Kerberizált SSH

Nyissuk meg a /etc/ssh/sshd_config fájlt és a következőket tiltsuk le:
* PermitRootLogin legyen no
* Adjuk hozzá a külső és belső címet ListenAddress-ként (így később ha új interface-ünk lesz pl. egy VPN miatt, akkor is biztosan tudjuk, hol figyelünk):
ListenAddress 10.2.3.1
ListenAddress 1.2.3.4
* Kapcsoljuk be a Kerberos authentikációt (KerberosAuthentication yes, KerberosTicketCleanup yes yes)
* Kapcsoljuk be a GSSAPI-t (GSSAPIAuthentication yes és GSSAPICleanupCredentials yes)
* Tiltsuk le az X11Forwarding-ot (X11Forwarding no)
Adjuk ki a:

root@adsrv01:~# samba-tool domain exportkeytab /etc/krb5.keytab --principal=host/adsrv01.example.org

utasítást a keytab előállítására.

Ellenőrizzük a keytab-ot:

root@adsrv01:~# klist -k -t /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp Principal
---- ---------------- ---------------------------------------------------------
1 10/11/2013 08:09 host/adsrv01.example.org@EXAMPLE.ORG
1 10/11/2013 08:09 host/adsrv01.example.org@EXAMPLE.ORG
1 10/11/2013 08:09 host/adsrv01.example.org@EXAMPLE.ORG

Indítsuk újra az SSH service-t és próbáljuk ki, be tudunk-e lépni az új konfigurációval:

Egy másik Linux-os gépen tegyük fel a krb5-user/krb5-utils/krb5-client vagy hasonló csomagot (ami tartalmazza a kinit-et), majd szerkesszük a /etc/krb5.conf-ot:

[libdefaults]
default_realm = EXAMPLE.ORG
use_dns = yes

[logging]
kdc = FILE:/var/log/krb5/krb5kdc.log
admin_server = FILE:/var/log/krb5/kadmind.log
default = SYSLOG:NOTICE:DAEMON

Az azt hiszem gyári konfiggal a 12.3-as openSUSE-ban le van tiltva a GSSAPI authentikáció, így elképzelhető, hogy azt engedélyeznünk kell (/etc/ssh/ssh_config):

GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

Ezután:

user@masik_gep:~# kinit szamba4.ezek
user@masik_gep:~# ssh szamba4.ezek@adsrv01

Próbáljuk ki a root-ként és Administrator-ként való csatlakozást is (előbbit az sshd configban, utóbbit a PAM-ban tiltottuk le), így egyiknek sem kellene működnie.

Szerk.: Itt két dologgal még adós maradtam: a domain-be léptetett Win-es gépekről a Putty-al is működik a Single Sign-On, az adott kapcsolathoz a Connections -> Data -> Use system username, SSH fül -> 2 only, SSH -> Auth fülön mindent kikapcsolva kérdés nélkül a saját fiókunkba kerülünk. A domain-be léptetett (winbind) Linux-os klienseken az smb.conf-ba a winbind use default domain = no beállítással a usernevünk nem TARTOMÁNY\user alakú lesz, hanem simán user, így működik az ssh adsrv01 utasítás.

---------------

Sudo

Most, hogy szamba4.ezek-ként vagyunk benn, jön a probléma, hogy nincs sudo-nk. Telepítsük (ha SSH-n vagyunk benn, su-val még mindig átléphetünk root-ra)!

root@adsrv01:~# apt-get install sudo

Majd szerkesszük a /etc/sudoers fájlt és szúrjuk be ezt a sort:

%EXAMPLE\\Linux\ Admins ALL=(ALL:ALL) ALL

Innentől kezdve a Linux Admin-ok azt csinálnak, amit akarnak.

---------------

Tűzfalazás

Kicsit térjünk vissza a tűzfalazáshoz, és szedjük rendbe a dolgokat azon a fronton is. Szerkesszük a /etc/iptables/rules.v4 fájlt:

# Generated by iptables-save v1.4.14 on Mon Nov 4 22:31:39 2013
*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
*filter
:internalinput - [0:0]
:externalinput - [0:0]
-A internalinput -m comment --comment "Kivulre engedelyezett szolgaltatasok engedelyezese bentre is" -j externalinput
-A internalinput -p icmp -m comment --comment "ICMP [internal]" -j ACCEPT
-A internalinput -p tcp -m comment --comment "Kerberos" --dport 88 -j ACCEPT
-A internalinput -p udp -m comment --comment "Kerberos" --dport 88 -j ACCEPT
-A internalinput -p udp -m comment --comment "NTP" --dport 123 -j ACCEPT
-A internalinput -p tcp -m comment --comment "DCE/RPC Locator Service" --dport 135 -j ACCEPT
-A internalinput -p udp -m comment --comment "NetBIOS NS" --dport 137 -j ACCEPT
-A internalinput -p udp -m comment --comment "NetBIOS Datagram" --dport 138 -j ACCEPT
-A internalinput -p tcp -m comment --comment "NetBIOS Session" --dport 139 -j ACCEPT
-A internalinput -p udp -m comment --comment "LDAP [UDP]" --dport 389 -j ACCEPT
-A internalinput -p tcp -m comment --comment "LDAP [TCP]" --dport 389 -j ACCEPT
-A internalinput -p tcp -m comment --comment "SMB over TCP" --dport 445 -j ACCEPT
-A internalinput -p tcp -m comment --comment "Kerberos Kpasswd" --dport 464 -j ACCEPT
-A internalinput -p tcp -m comment --comment "LDAPS" --dport 636 -j ACCEPT
-A internalinput -p tcp -m comment --comment "RPC portok" --dport 1024:5000 -j ACCEPT
-A internalinput -p tcp -m comment --comment "Global Cataloge" --dport 3268 -j ACCEPT
-A internalinput -p tcp -m comment --comment "Global Catalogue SSL" --dport 3269 -j ACCEPT
-A internalinput -p udp -m comment --comment "MDNS [UDP]" --dport 5353 -j ACCEPT
-A internalinput -p tcp -m comment --comment "MDNS [TCP]" --dport 5353 -j ACCEPT
# Kivulre is engedelyezett szolgaltatasok
-A externalinput -p tcp -m comment --comment "SSH engedelyezes" --dport 22 -j ACCEPT
-A externalinput -p udp -m comment --comment "DNS [UDP]" --dport 53 -j ACCEPT
-A externalinput -p tcp -m comment --comment "DNS [TCP]" --dport 53 -j ACCEPT
:INPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED -m comment --comment "Korabban mar vizsgalt kapcsolatok" -j ACCEPT
-A INPUT -i lo -m comment --comment "Belso kapcsolatok" -j ACCEPT
-A INPUT -m state ! --state ESTABLISHED -s 10.2.3.0/24 -m comment --comment "Belso halos cimrol" -j internalinput
-A INPUT -m state ! --state ESTABLISHED ! -s 10.2.3.0/24 -m comment --comment "Kulso halos cimrol" -j externalinput
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7
-A INPUT -m comment --comment "Es eldobunk" -j DROP
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -p tcp --tcp-flags SYN,RST SYN -o eth0 -j TCPMSS --clamp-mss-to-pmtu
-A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth1 -o eth0 -j ACCEPT

COMMIT
# Completed on Mon Nov 4 22:31:39 2013

Szerk.: Kerberos csak TCP-n bug javítva
Szerk 2.: A NetBIOS NS és NetBIOS Datagram szabályok is a 137-es portot engedélyezték, javítva
Szerk 3.: később írt ICMP bug itt is javítva

Egy kicsit részletesebben: megtartottuk a korábbi NAT-ot, de ez lényegtelen, most az INPUT lánc a lényeges. Két láncot (internalinput és externalinput) hoztam létre, a belső hálózatról érkező csomagokat az internalinput, míg a "mindenhonnan máshonnan" érkező csomagokra az externalinput lánc szabályai érvényesek; az internalinput garantáltan tartalmazza az externalinput-on engedélyezett szolgáltatásokat (a lánc első eleme alapján azokat is végignézzük). A külső címekre egyelőre csak az SSH, a DNS szolgáltatásokat tettem ki. Ez többek közt azt is jelenti, hogy kívülről az SSH-t nem fogjuk elérni csak kulccsal, így mielőtt kimegyünk a hálózatról, mindenki, aki kívülről eléri a gépet, másolja fel a kulcsait (ha még nincs SSH kulcsunk, akkor ssh-keygen, majd ssh-copy-id @adsrv01.example.org)

---------------

SSL Cert-ek I. felvonás

Bár van egy parancssori eszköz, amivel egy CA kezelhető lenne (openssl), aki látta már a konfig fájlját az vagy azt mondja, hogy tartsuk magunk távol tőle, vagy H. P. Lovecraft-nak hívják és teljes sorozatot írt róla (amiben egy távolról emberinek tűnő, de polip fejű, karmokkal és szárnyakkal rendelkező szörnynek írja le)

Egy grafikus felületet is futtató Linux-os gépre telepítsük fel az XCA vagy bármely hasonló Cert-kezelő alkalmazást és készítsünk egy gyökértanúsítványt:
* készítsünk egy új kulcsot (Private Keys fül New Key gombja), 4096 bit-es RSA, a neve legyen Root CA Key.
* A Certificates fülön készítsünk egy új tanúsítványt (New Certificate), használjuk a "[default] CA" sablont hozzá. A Subject fülön töltsük ki a kért elemeket, a Private key-nek válasszuk ki a korábban létrehozott kulcspárt.
* Az Extensions fül Basic constraints részén válasszuk típusnak a Certificate authority-t, Path length-nek állítsuk be egyet (nem tervezünk Sub-CA-kat készíteni)
* A Key Identifier-nél jelöljük be mindkét checkbox-ot
* Az érvényességnél adjunk meg pl. 10 évet
* CRL distribution point-nak adjuk meg a http://pki.example.org/ca.crl útvonalat (később hozzuk létre)
* A Key usage fülön válasszuk ki a Certificate Sign és CRL Sign opciókat

Miután leokéztuk, azonnal pirosan fogja jelölni, hogy a visszavonási lista lejárt, így azt exportáljuk ki (jobb klikk -> CA -> Generate CRL), ezután a Revocation lists fülön tudjuk kiexportálni fájlba (mentsük is el ca.clr néven, amikor már lesz webserverünk, bár még nem tudjuk hogy publikálni)

Egy pillanatra még lépjünk vissza a Certificates fülre és exportáljuk a Root CA-nk tanúsítványát fájlba PKCS#7 formátumban. Ezt a tanúsítványt terjesszük szét Group policy-val a Windows-os gépek között (Computer configuration - Windows Settings - Security Settings - Public Key Policies - Trusted Root Certification Authorities, jobb klikk Import).

Még mindig a Certificates fülön, PEM formátumban is exportáljuk a Root CA certjét (ca.pem).

Ha már itt vagyunk, csináljunk egy új cert-et. Ezúttal válasszuk a "[default] HTTPS Server" sablont.
* Subject
* Internal name: Radius
* commonName: adsrv01.example.org
* Generate a new key
* Extensions
* Adjuk ki mondjuk két évre
* Key Usage
* semmi ne legyen bejelölve, ekkor mindenre használható, mert a tanúsítványban nem szerepel a megfelelő rész. Nem feltétlenül kell, de a FreeRADIUS saját maga előállított cert-jében sem szerepel.
Exportáljuk ezt a cert-et is pem formátumban (server.pem), majd a Private Keys-nél a Radius kulcsát is, szintén PEM formátumban (server.key).

---------------

RADIUS
Ez alapján: http://deployingradius.com/documents/configuration/active_directory.html

A céges Wifihez jól jöhet, ha a dolgozók a standard felhasználói nevükkel tudnak authentikálni, úgyhogy rakjunk össze nekik egy ilyen rendszert. Először is szükségeünk lesz egy FreeRADIUS szerverre:

EXAMPLE\szamba4.ezek@adsrv01:~$ sudo apt-get install freeradius

Az alap konfigurációhoz képest csak minimálisan térünk el. Nyissuk meg a /etc/freeradius/modules/mschap fájlt, és a kikkomentezett ntlm_auth sor helyére/mellé írjuk be a

ntlm_auth = "/usr/bin/ntlm_auth --request-nt-key --username=%{mschap:User-Name:-None} --domain=%{%{mschap:NT-Domain}:-EXAMPLE} --challenge=%{mschap:Challenge:-00} --nt-response=%{mschap:NT-Response:-00}"

sort.

Ezután még minden egyes RADIUS kliens-hez (AP-k) fel kell vennünk egy klienst a /etc/freeradius/clients.conf fájlba, pl.:

client 10.2.3.5 {
secret = szuper-titkos-kulcs
shortname = router-1
nastype = other
}

Másoljuk fel a szerverre a korábban exportált kulcsot és tanúsítványokat:

user@masik_gep:~# scp server.{key,pem} szamba4.ezek@adsrv01:/home/EXAMPLE/szamba4.ezek/
user@masik_gep:~# scp ca.pem szamba4.ezek@adsrv01:/home/EXAMPLE/szamba4.ezek/

Majd tegyük be a megfelelő könyvtárba:

root@adsrv01:~# rm /etc/freeradius/certs/{ca.pem,server.key,server.pem}
root@adsrv01:~# mv /home/EXAMPLE/szamba4.ezek/{ca.pem,server.key,server.pem} /etc/freeradius/certs
root@adsrv01:~# chown root:freerad /etc/freeradius/certs/*.pem

Indítsuk újra a FreeRADIUS-t, adjuk hozzá a rules.v4-hez az új szabályunkat (-A internalinput -p tcp -m comment --comment "RADIUS" --dport 1812 -j ACCEPT) és indítsuk újra az iptables-persistent szolgáltatást. Ezután már beállíthatjuk az AP-n a RADIUS szerverünket.

--
Legközelebb folytatjuk, addigra valószínűleg ki kell lépnem a virtuális gépes mókából, elkezdett swap-et használni a gépem, és az nem jó.

---------------
---------------

Samba4 csak a belső (és loopback) interface-n

Ez egy gyors változtatás lesz: szerkesszük a /etc/samba/smb.conf fájlt és a [global] részbe illesszük be a következők direktívákat:

bind interfaces only = Yes
interfaces = lo eth1

Majd indítsuk újra a samba-t. Az újraindítás után (pár másodperccel) az nslookup adsrv01.example.org lekérdezésnek csak a belső címet kell visszaadnia. Ha a külső címünk is megmaradna, távolítsuk el:

root@adsrv01:~# kinit Administrator
root@adsrv01:~# samba-tool dns delete localhost example.org adsrv01 A 1.2.3.4

---------------

Squid

Folytassuk a Squid proxy elkészítésével. Telepítsük fel:

root@adsrv01:~# apt-get install squid3

Szükséges lesz egy felhasználóra az LDAP-ban illetve egy Kerberos Service Principal-ra, így készítsük el őket (illetve állítsuk be, hogy soha ne járjon le a jelszava):

root@adsrv01:~# samba-tool user add squid
Jegyezzük fel, hogy milyen jelszót állítottunk be, később szükségünk lesz rá!
root@adsrv01:~# samba-tool user setexpiry "--filter=(samaccountname=squid)" --noexpiry
root@adsrv01:~# samba-tool spn add HTTP/proxy.example.org squid
root@adsrv01:~# samba-tool domain exportkeytab /etc/squid3/PROXY.keytab --principal=squid
root@adsrv01:~# samba-tool domain exportkeytab /etc/squid3/PROXY.keytab --principal=HTTP/proxy.example.org

Ahogy látszik, külön hostnevet kapott a proxy, így később egyszerűbben tudjuk átvinni másik gépre, ha a terhelés megkövetelné. Vegyük is fel gyorsan a DNS-be:

root@adsrv01:~# kinit Administrator
root@adsrv01:~# samba-tool dns add localhost example.org proxy CNAME adsrv01.example.org
root@adsrv01:~# samba-tool dns add localhost 3.2.10.in-addr.arpa 1 PTR proxy.example.org
root@adsrv01:~# kdestroy

És ellenőrizzük a keytab-ot, majd állítsuk be a jogosultságait:

root@adsrv01:~# klist -k -t /etc/squid3/PROXY.keytab
root@adsrv01:~# chgrp proxy /etc/squid3/PROXY.keytab
root@adsrv01:~# chmod 440 /etc/squid3/PROXY.keytab

A /etc/squid3/ldappass.txt fájlba írjuk be a fentebb a squid user-hez megadott jelszót, majd biztosítsuk a fájl jogosultságokkal, hogy ne férjen hozzá akárki:

root@adsrv01:~# editor /etc/squid3/ldappass.txt
root@adsrv01:~# chgrp proxy /etc/squid3/ldappass.txt
root@adsrv01:~# chmod 440 /etc/squid3/ldappass.txt

Állítsuk be, hogy honnan olvassa a Keytab-ot. Ehhez szerkesszük a /etc/default/squid3 fájlt, tegyük bele a következőket:

KRB5_KTNAME=/etc/squid3/PROXY.keytab
export KRB5_KTNAME

Egy másik, Debian-t futtató gépen töltsük le a negotiate wrappert (unstable-ben levő Squid-ben már ott van, Wheezy-ben még nincs): http://sourceforge.net/projects/squidkerbauth/files/negotiate_wrapper/n… majd fordítsuk le.

user@masik_gep:~# tar -xvf negotiate_wrapper-1.0.1.tar.gz
user@masik_gep:~# cd negotiate_wrapper
user@masik_gep:~# ./configure
user@masik_gep:~# make

Az elkészült negotiate_wrapper fájlt másoljuk át a szerverre, majd:

root@adsrv01:~# mv negotiate_wrapper /usr/local/bin/negotiate_wrapper

Szerk.: Ha valahol elveszne ez a jog, adjuk meg a nagyvilágnak a futtatási jogot a fájlra (chmod o+x $(which negotiate_wrapper)).

Hozzunk létre egy megfelelő méretű (passz, függ attól, hány felhasználónk van/lesz, mik a netezési szokásai, mennyit akarunk ebből cache-lni stb.) partíciót a cache-nek.

root@adsrv01:~# lvcreate -L 1G -n squid vgadsrv01a
root@adsrv01:~# mkfs.ext3 /dev/vgadsrv01a/squid

Adjuk hozzá az fstab-hoz az új partíciót:

/dev/mapper/vgadsrv01a-squid /var/cache/squid ext3 noatime,defaults 0 2

Csatoljuk fel az új partíciót és tegyük írhatóvá a squid számára:

root@adsrv01:~# mkdir /var/cache/squid
root@adsrv01:~# mount -a
root@adsrv01:~# chown proxy:proxy /var/cache/squid

Szerkesszük a /etc/squid3/squid.conf -ot (biztosabb, ha lemásoljuk és újra létrehozzuk, mert a teljes dokumentációt betették ide)

http_port 3128

cache_dir ufs /var/cache/squid 768 16 256

auth_param negotiate program /usr/local/bin/negotiate_wrapper -d --ntlm /usr/bin/ntlm_auth --diagnostics --helper-protocol=squid-2.5-ntlmssp --domain=EXAMPLE.ORG --kerberos /usr/lib/squid3/squid_kerb_auth -d -s GSS_C_NO_NAME
auth_param negotiate children 10
auth_param negotiate keep_alive off

auth_param ntlm program /usr/bin/ntlm_auth --diagnostics --helper-protocol=squid-2.5-ntlmssp --domain=EXAMPLE.ORG
auth_param ntlm children 10
auth_param ntlm keep_alive off

auth_param basic program /usr/lib/squid3/squid_ldap_auth -R -b "dc=example,dc=org" -D squid@example.org -W /etc/squid3/ldappass.txt -f "sAMAccountName=%s" -h adsrv01.example.org
auth_param basic children 10
auth_param basic realm Internet Proxy
auth_param basic credentialsttl 1 minute

acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

acl whitelist url_regex "/etc/squid3/whitelist"
http_access allow whitelist

acl auth proxy_auth REQUIRED

http_access deny !auth
http_access allow auth
http_access deny all

Állítsuk le a Squid-et és hagyjuk, hogy létrehozza a cache mappáit:

root@adsrv01:~# service squid3 stop
root@adsrv01:~# squid3 -z

Szerk.: Az újraindítás a whitelist létrehozás utánra véve

Ezzel a Kerberos/NTLM/Plain-text Active Directory auth meg is van, a probléma az, hogy néhány kliens ezt nem fogja értékelni (Windows update, víruskergetők stb.). Éppen ezért van a whitelist acl, hozzuk létre számára a fájlt, ami soronként egy domaint tartalmaz, amelyet el lehet érni azonosítás nélkül is:

microsoft.com
windowsupdate.com
windowsupdate.website.com
windows.com
adobe.com
java.com
oracle.com

Így már el tudjuk indítani a Squid-et:

root@adsrv01:~# service squid3 start

Tiltsuk le az átjárón a HTTP(S) forgalmat és engedélyezzük a belső hálón a squid elérését. Előbbihez szúrjuk be valahova a

-A internalinput -p tcp -m comment --comment "Squid" --dport 3128 -j ACCEPT

szabályt, utóbbihoz a FORWARD lánc elfogadó (utolsó) szabálya elé pedig:

-A FORWARD -i eth1 -o eth0 -p tcp -m multiport --dports 80,443 -j REJECT --reject-with icmp-proto-unreachable

A kliens gépen állítsuk be proxynak az adsrv01.example.org-ot 3128-as porttal, majd ellenőrizzük, hogy elérjük-e a webet, és a /var/log/squid/access.log -ban megjelenik-e a felhasználónév. Ha mindent jól csináltunk, a Squid nem fog felhasználónevet bekérni.

---------------

Ennyi mára, holnap Apacheolunk, megcsináljuk a pki-t, a wpad-ot és még az összes többi rövidítést, ami eszembe jut, hogy hasznos.

---------------
---------------

A fenti Iptables szabályrendszert módosítottam, mert a Kerberos-t csak TCP-re tettem. Javítva.

---------------

Split DNS

Csúnya dolog, hogy per pill a fél világnak adunk infókat a belső hálónkról, úgyhogy ezt fejezzük abba :)

Hozzunk létre egy zóna fájlt, ami a publikus hosztjainkat tartalmazza (admin e-mailnek a hostmaster-t adtam meg, a belső DNS-ben is ez szerepel) és mentsük el a /etc/bind/db.example.org fájlba

$TTL 86400

@ IN SOA adsrv01.example.org. hostmaster. (
2013111701 ; serial number YYMMDDNN
28800 ; Refresh
7200 ; Retry
864000 ; Expire
86400 ; Min TTL
)

NS adsrv01.example.org.
MX 10 mail.example.org.

$ORIGIN example.org.
IN A 1.2.3.4
www IN A 1.2.3.4
adsrv01 IN A 1.2.3.4
mail IN A 1.2.3.4
pki IN A 1.2.3.4

Állítsuk a többi zóna fájlhoz hasonlóra a fájlt:

root@adsrv01:~# chown root:root /etc/bind/db.example.org
root@adsrv01:~# chmod chmod 644 /etc/bind/db.example.org

Majd nyissuk meg a /etc/bind/named.conf.local fájlt (ebben elvileg most csak egy include van) és cseréljük le a tartalmát erre:

acl internal {
10.2.3.0/24;
localhost;
};

view "internal-view" {
match-clients { internal; };
include "/var/lib/samba/private/named.conf";
allow-update { 10.2.3.0/24; };
};

view "external-view" {
match-clients { any; };
recursion no;
zone "example.org" IN {
type master;
file "/etc/bind/db.example.org";
allow-transfer { key TRANSFER; };
};
};

Ezután kommenteljünk ki minden sort a /etc/bind/named.conf.default-zones fájlban, majd indítsuk újra a bind-ot. Belső címekről továbbra is fel kell tudnunk oldani a belső címeket (pl. a desktop001.example.org-ot), kívülről ezekre NXDOMAIN-t kell kapnunk. (továbbá egy ipconfig /registerdns -re a kliens gépek felül kell, hogy írják a saját rekordjaikat)

Ellenőrizzük továbbá, hogy a külső címekről érkező kéréseknél ne oldjunk fel az example.org-on kívüli zónákból címeket (index.hu-ra NXDOMAIN-t kapunk). Split DNS letudva.

---------------
Apache

Telepítsünk Apache-ot, hogy a múltkor elkészült root certet és visszavonási listát valahol tudjuk publikálni (no meg a céges website-ot).

root@adsrv01:~# apt-get install apache2

A default site-unk legyen a céges oldal, úgyhogy szerkesszük ennek megfelelően a /etc/apache2/sites-available/000-default fájlt és vigyük fel a

ServerName example.org
ServerAlias www.example.org

sorokat, írjuk át a ServerAdmin-nál az e-mail címet és a DocumentRoot-ot üssük át mondjuk /var/www/default -ra.

Hozzuk létre az új document rootot:

root@adsrv01:~# mkdir /var/www/default

és tegyük be ide a céges publikus weboldalunk.

Adjuk hozzá az új szabályt a /etc/iptables/rules.v4 fájlhoz:

-A externalinput -p tcp -m comment --comment "HTTP" --dport 80 -j ACCEPT

--------
Apache - PKI

Hozzuk létre a pki virtualhost-ot: editor /etc/apache2/sites-available/pki

ServerAdmin webmaster@example.org
ServerName pki.example.org

DocumentRoot /var/www/pki

Options FollowSymLinks
AllowOverride None

Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all

ErrorLog ${APACHE_LOG_DIR}/error.log
LogLevel warn
CustomLog ${APACHE_LOG_DIR}/access.log combined

Hozzuk létre az új host document rootját (mkdir /var/www/pki), engedélyezzük az új site-ot (a2ensite pki) és indítsuk újra az Apache-ot. Másoljuk be a pki DocumentRoot-jába a múltkor exportált root cert-et és a visszavonási listát, ill. csináljunk egy rövid index.html fájlt, ahonnan linkeljük ezeket.

--------
Apache - WPAD

Hogy ne kelljen Group policy-ból / egyesével konfigulgatnunk a proxy beállításokat, használhatjuk a Web Proxy Auto Discovery-t. Ez gyakorlatilag annyit jelent, hogy a foo.bar.baz.com FQDN-ű gép egy HTTP kéréskor végigpásztázza a DNS, hogy létezik-e (sorrendben) wpad.bar.baz.com, wpad.baz.com és wpad.com (yup, vannak retardált böngészők :) ) host, ha igen, kapcsolódik hozzá és letölti a wpad.dat fájlt.

Csináljunk ilyen hostot!

root@adsrv01:~# kinit Administrator
root@adsrv01:~# samba-tool dns add adsrv01.example.org example.org wpad A 10.2.3.1
root@adsrv01:~# samba-tool dns add adsrv01.example.org 3.2.10.in-addr.arpa 1 PTR wpad.example.org
root@adsrv01:~# kdestroy

Hozzuk létre az Apache site-ot: /etc/apache2/sites-available/wpad

ServerAdmin webmaster@example.org
ServerName wpad.example.org

AddType application/x-ns-proxy-autoconfig .dat
AddType application/x-ns-proxy-autoconfig .pac

DocumentRoot /var/www/wpad

Options FollowSymLinks
AllowOverride None

Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all

ErrorLog ${APACHE_LOG_DIR}/error.log
LogLevel warn
CustomLog ${APACHE_LOG_DIR}/access.log combined

,
engedélyezzük az új oldalt (a2ensite wpad), hozzuk létre a DocumentRoot-ját majd indítsuk újra az apache-ot.

Hozzuk létre a /var/www/wpad/wpad.dat fájlt a következő tartalommal:

function FindProxyForURL(url,host)
{
if(isPlainHostName(host) || dnsDomainIs(host,".example.org")) {
return "DIRECT";
}
return "PROXY proxy.example.org:3128; DIRECT;";
}

Majd aliasoljuk a proxy.pac névre is

root@adsrv01:~# ln -s /var/www/wpad/wpad.dat /var/www/wpad/proxy.pac

Ezután ha a kliens böngészőkben beállítjuk, hogy automatikusan ismerjék fel a proxy beállításokat, meg kell találniuk a Squid-et.

Szerk.: Az AddType sorokat másoljuk át a default site-unkhoz is, ill. oda is linkeljük a wpad.dat-ot mindkét néven (wpad.dat, proxy.pac), mert továbbra is vannak kretén böngészők, amik annak ellenére, hogy egy specifikus nevezéktan alapján megkeresett szerverre (-> ismert hostnév) küldött HTTP/1.1 kérésben (-> kötelező Host: fejléc) kérik el, úgy tűnik a default site-ot találják el. Nem akarok ujjal mutogatni, de az IE 6 :)

--------
Szerk.: És naná, hogy 1) ma is elfelejtettem a Samba TLS beállításait és 2) a PKI rekordot felvinni a belső zónába.

Szóval: csináljunk egy biztonsági mentést az automatikusan generált CA-ról/cert-ről/kulcsról:

root@adsrv01:~# mkdir ~/samba-cert
root@adsrv01:~# cp /var/lib/samba/private/tls/{ca.pem,cert.pem,key.pem} ~/samba-cert

utána írjuk felül a korábban készített és a FreeRADIUS számára már exportált kulcsokkal:

root@adsrv01:~# cp /etc/freeradius/certs/ca.pem /var/lib/samba/private/tls/ca.pem
root@adsrv01:~# cp /etc/freeradius/certs/server.pem /var/lib/samba/private/tls/cert.pem
root@adsrv01:~# cp /etc/freeradius/certs/server.key /var/lib/samba/private/tls/key.pem

majd indítsuk újra a Samba-t!

Ezután a openssl s_client -showcerts -connect localhost:636 kimenetében a saját tanúsítványunkat kellene felfedeznünk.

Ami meg kimaradt:

root@adsrv01:~# kinit Administrator
root@adsrv01:~# samba-tool dns add adsrv01.example.org example.org pki A 10.2.3.1
root@adsrv01:~# samba-tool dns add adsrv01.example.org 3.2.10.in-addr.arpa 1 PTR pki.example.org
root@adsrv01:~# kdestroy

---------------
---------------

Rövid közbevetés: egy topic alapján teszteltem a GP beállításokat, egy gpupdate /force LÁTSZÓLAG sikeresen lefut, de a az event log-ba bekerül, hogy nem találja a DC-t (http://support.microsoft.com/kb/816045 <- ő az, amiért... pontosabban az, hogy a mostani tűzfal az ICMP forgalmat is eldobja, és bár a Win több szolgáltatást (LDAP, Krb stb.) gond nélkül elér, de a group policy-hoz az is kell neki. Hmm...)

A megoldás egy új szabály hozzáadása (belső hálón minden ICMP forgalmat engedünk):

-A internalinput -p icmp -m comment --comment "ICMP [internal]" -j ACCEPT

Ha már arra járunk, hasznos lehet a belső hálón a broadcast forgalmat is engedni:

-A INPUT -m comment --comment "Broadcast messages" -s 10.2.3.255 -j ACCEPT

(Szerk.: este tíz után nem kéne iptables-höz nyúlnom, sikerült egy olyan láncon, ahova csak a 10.2.3.1-re érkező csomagok jutnak el szűrni a 10.2.3.255-re...)

---------------
---------------

Ma csak szerkesztésként néhány talált hibát javítottam, ezek:
* Az enterprise samba tárolóiban megjelent a 4.1, az apt source-okat ehhez igazítottam (nap közben kipróbáltam, működik
vele minden)
* Egy későbbi kör szívás javítva a bind interfaces only rész előbbre vételével (hivatkozásával)
* < és > jelek javítva, azok eltűntek
* Egy hibás port (UDP/138 félig-meddig hiányzott) a tűzfal szabályok közt javítva
* Két squid bug javítva (egy fájl jogosultság és egy IE-kompatibilitás)
* SSH single-sign-on leírás kliensekhez

---------------

SSL tanúsítványok második kör

A korábbi SSL részt két helyen módosítottam (az XCA-ban szereplő internal name nem Radius, hanem adsrv01 ill. a kiszolgáló tanúsítvány tartalmazza a teljes tanúsítványláncot).

Viszont elég rosszul veszi ki magát, hogy a tanúsítvány infrastruktúránk alapjául szolgáló gépünk nem bízik a saját root certünkben, úgyhogy másoljuk [linkeljük, lásd a következő bekezésd] be a /usr/local/share/ca-certificates mappába a certünket .crt kiterjesztéssel és rootként futtassuk a

root@adsrv01#~> update-ca-certificates

parancsot.

Ha ezzel megvagyunk, akkor a

openssl s_client -CApath /etc/ssl/certs -showcerts -connect adsrv01.example.org:636

kimenetében az utolsó sorban Verify return code-nál nulla értéket kell kapnunk.

A másik probléma a korábbi tanúsítvány-használattal, hogy több helyen duplikáltuk a certeket/kulcsokat, ami nem szép. Úgyhogy módosítsuk :)

root@adsrv01#~> mv /etc/freeradius/certs/{server.key,server.pem,ca.pem} /etc/ssl/private
root@adsrv01#~> chmod 640 /etc/ssl/private/{server.key,server.pem,ca.pem}
root@adsrv01#~> chown root:freerad /etc/ssl/private/{server.key,server.pem,ca.pem}
root@adsrv01#~> ln -s /etc/ssl/private/{server.key,server.pem,ca.pem} /etc/freeradius/certs
<del>root@adsrv01#~> rm /var/lib/samba/private/tls/{key.pem,cert.pem,ca.pem}
root@adsrv01#~> ln -s /etc/ssl/private/server.key /var/lib/samba/private/tls/key.pem
root@adsrv01#~> ln -s /etc/ssl/private/server.pem /var/lib/samba/private/tls/cert.pem
root@adsrv01#~> ln -s /etc/ssl/private/ca.pem /var/lib/samba/private/tls/ca.pem</del>

Szerk.: Ezt csúnyán benéztem, a samba megköveteli, hogy 600-as móddal legyenek az SSL cuccai, illetve neki kifejezetten olyan cert kell, amely nem tartalmazza a teljes láncot.

Ezután indítsuk újra a freeradius-t és a sambát.

--------------------
Technikai megjegyzés: szerintem kezd nagyon átláthatatlan lenni az írás, holnap megpróbálom átszervezni kicsit, aztán visszatérünk a SASL-hez egy darabig és utána már tényleg csinálunk printert mielőtt levelezgetünk.

--------------------

Szerk.: Tegnap sikerült nulláznom a korábbi részeket, kugli cache-ből visszaállítva.