🪴 Quartz 4.0

Search

SearchSearch

Dokumentation

Dec 14, 2023, 16 min read

Arbeitsblatt 01

Einführung

Lernziele

  • Verwaltung eines integrierten ADDS mit Samba
  • Praktisches Fallbeispiel ist die Basis für eine realitätsnahe Konfiguration
  • Verständnis für LDAP als Teil eines Active Directory Service
  • Kenntnis wie Windows und Linux Rechner in einer Domain eingebunden werden
  • Berechtigungen definieren und in der Domain umsetzen unter Berücksichtigung der Windows/Linux Integrationsproblematik

Laborumgebung

Realm: SAM159.IET-GIBB.CH PW: Sml12345$ Gateway: 192.168.110.2 (OPNsense-Firewall) Search-Domain: sam159.iet-gibb.ch

  • vmLS1: DC/KDC, DNS, LDAP Server IP: 192.168.110.61
  • vmLS2: Member Server Linux IP: 192.168.110.62
  • vmLP1: Member Client Linux IP: 192.168.110.30
  • vmWP1: Member Client Windows IP: 192.168.110.10

Vorbereitung

Netzwerkkonfiguration

vmLS1: /etc/netplan/00-eth0.yaml:

network:
  ethernets:
    eth0:
      addresses:
      - 192.168.110.61/24 
      nameservers:
        addresses:
        - 192.168.110.2
        search:
        - sam159.iet-gibb.ch
      routes:
      - to: default
        via: 192.168.110.2
  version: 2

vmLS1:

sudo netplan apply --debug

vmLS1: /etc/hosts:

127.0.0.1       localhost.localdomain   localhost
127.0.1.1       vmLS1.sam159.iet-gibb.ch        vmLS1
192.168.110.61  vmLS1.sam159.iet-gibb.ch        vmLS1
# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

vmLS1: /etc/hostname:

vmLS1.sam159.iet-gibb.ch

SSH

vmLP1: SSH Key erstellen ssh-keygen SSH Key auf Server kopieren ssh-copy-id [-i <identity_file>] <server> SSH Verbindung starten ssh <server>

Samba Domain Controller

Installation

vmLS1:

sudo apt update
sudo apt dist-upgrade
sudo snap refresh
sudo apt install acl attr build-essential libacl1-dev libattr1-dev libblkid-dev libgnutls28-dev libreadline-dev python2-dev python2 python-dev-is-python3 python3-dnspython gdb pkg-config libpopt-dev libldap2-dev libbsd-dev attr krb5-user docbook-xsl libcups2-dev acl ntp ntpdate net-tools git winbind libpam0g-dev dnsutils lsof

Konfiguration

Domain provisionieren

vmLS1:

sudo mv /etc/samba/smb.conf /etc/samba/smb.conf.orig
sudo samba-tool domain provision
# Realm: SAM159.IET-GIBB.CH
# Domain: SAM159
# Server Role: dc
# DNS backend: SAMBA_INTERNAL
# DNS forwarder IP: 1.1.1.1
# Administrator password: Sml12345$

Resolver Dienst deaktivieren

vmLS1:

sudo systemctl disable systemd-resolved
sudo systemctl stop systemd-resolved
sudo rm /etc/resolv.conf

vmLS1: /etc/resolv.conf:

nameserver 192.168.110.61
search sam159.iet-gibb.ch

Samba Dienst aktivieren

vmLS1:

sudo systemctl unmask samba-ad-dc
sudo systemctl enable samba-ad-dc
sudo systemctl start samba-ad-dc
sudo reboot

vmLS1:

sudo systemctl status samba-ad-dc

Kerberos Konfiguration

vmLS1:

sudo rm /etc/krb5.conf

vmLS1: /etc/krb5.conf:

[libdefaults]
	default_realm = SAM159.IET-GIBB.CH
	fcc-mit-ticketflags = true
[realms]
	SAM159.IET-GIBB.CH = {
		kdc = vmLS1.sam159.iet-gibb.ch
		admin_server = vmLS1.sam159.iet-gibb.ch
	}
[domain_realm]
	.sam159.iet-gibb.ch = SAM159.IET-GIBB.CH
	sam159.iet-gibb.ch = SAM159.IET-GIBB.CH

Netzwerk testen

Aktuelle DNS-Server anzeigen

vmLS1:

sudo systemctl start systemd-resolved
sudo systemctl status systemd-resolved
sudo resolvectl status
# DNS Server werden angezeigt
 
sudo systemctl stop systemd-resolved
sudo reboot

Offene Ports anzeigen

vmLS1:

netstat -tlpn

Interner DNS-Service aktualisieren

vmLS1:

sudo samba_dnsupdate --verbose

Wichtige DNS-Einträge testen

vmLS1:

host -t SRV _kerberos._tcp.sam159.iet-gibb.chhost -t SRV _gc._tcp.sam159.iet-gibb.chhost -t SRV _ldap._tcp.sam159.iet-gibb.chhost -t A vmls1.sam159.iet-gibb.ch

Reverse-Lookup-Zone einrichten

Reverse-Lookup-Zone erstellen

vmLS1:

samba-tool dns zonecreate vmLS1 110.168.192.in-addr.arpa -U administrator --password SmL12345$

PTR-Record für vmls1 eintragen

vmLS1:

samba-tool dns add 192.168.110.61 110.168.192.in-addr.arpa 61 PTR vmls1.sam159.iet-gibb.ch -U administrator --password SmL12345$

A- und PTR-Records eintragen

A-Record für vmls2 eintragen

vmLS1:

samba-tool dns add vmLS1.sam159.iet-gibb.ch sam159.iet-gibb.ch vmLS2 A 192.168.110.62 -U administrator --password SmL12345$

A-Record für vmlp1 eintragen

vmLS1:

samba-tool dns add vmLS1.sam159.iet-gibb.ch sam159.iet-gibb.ch vmLP1 A 192.168.110.30 -U administrator --password SmL12345$

Pointer-Record in Reverse-Zone für vmlp1 eintragen

vmLS1:

samba-tool dns add vmLS1.sam159.iet-gibb.ch 110.168.192.in-addr.arpa 30 PTR vmlp1.sam159.iet-gibb.ch -U administrator --password SmL12345$

Pointer-Record in Reverse-Zone für vmls2 eintragen

vmLS1:

samba-tool dns add vmLS1.sam159.iet-gibb.ch 110.168.192.in-addr.arpa 62 PTR vmls2.sam159.iet-gibb.ch -U administrator --password SmL12345$

Testen der Verbindung

vmLS1:

ping vmLP1 -c 3
ping vmLS2 -c 3
ping vmLS1 -c 3
dig -x 192.168.110.61
dig -x 192.168.110.62
dig -x 192.168.110.30
smbclient -L localhost -U administrator --password SmL12345$

Aufgaben

4.1) Portnummern:

  • 445: SMB (Server Message Block)
  • 389: LDAP (Lightweight Directory Access Protocol)
  • 636: LDAPS (Lightweight Directory Access Protocol over TLS/SSL)
  • 88: KDC (Kerberos key distribution center)
  • 53: DNS (Domain Name Service)

4.2) Ticket für administrator lösen: vmLS1:

kinit administrator@sam159.iet-gibb.ch

4.3) Verbindung testen mit Kerberos Ticket Der folgende Befehl benutzt das gelöste Kerberos Ticket für die Authentifizierung.

vmLS1:

smbclient -N --use - kerberos = required -L vmLS1

4.4) Credential Cache Der Credential Cache enthält das gelöste TGT und ein cifs Ticket.

vmLS1:

klist

4.5) Verbindungsaufbau zu localhost Der Verbindungsaufbau mit der Kerberos Authentifizierung funktioniert nur, wenn es einen entsprechenden Service Principal gibt.

vmLS1:

smbclient -N --use-kerberos=required -L vmLS1

4.6) Passwortrichtlinien setzen

vmLS1:

samba-tool domain passwordsettings set --complexity=off
samba-tool domain passwordsettings set --history-length=24
samba-tool domain passwordsettings set --min-pwd-age=1
samba-tool domain passwordsettings set --max-pwd-age=90
samba-tool domain passwordsettings set --min-pwd-length=8
samba-tool user setexpiry Administrator --noexpiry

4.7) Adding an A record:

vmLS1:

samba-tool dns add dc1.samdom.example.com samdom.example.com demo A 192.168.0.55 -U administrator

Adding a PTR record to the 192.168.0.0/24 reverse zone:

vmLS1:

samba-tool dns add dc1.samdom.example.com 0.168.192.in-addr.arpa 55 PTR demo.samdom.example.com -U administrator

4.8) Deleting an A record:

vmLS1:

samba-tool dns delete dc1.samdom.example.com samdom.example.com demo A 192.168.0.55 -U administrator`

4.9) Samba Flexible Single Master Operations

vmLS1:

sudo samba-tool fsmo show

Der Befehl zeigt die FSMO-Rollen der REALM an. Der Befehl zeigt normalerweise Informationen zu den folgenden FSMO-Rollen an:

  1. Schema Master: Zeigt den Server an, auf dem der Schema-Master-Rolle liegt. Der Schema-Master ist für die Aktualisierung und Pflege des Active Directory-Schemas verantwortlich.
  2. Domain Naming Master: Zeigt den Server an, auf dem der Domain Naming Master liegt. Der Domain Naming Master ist für die Hinzufügung und Entfernung von Domänen in der Gesamtstruktur verantwortlich.
  3. RID Pool Manager: Zeigt den Server an, auf dem der RID Pool Manager liegt. Der RID Pool Manager ist für die Generierung von RIDs (Relative Identifiers) in einer Domäne verantwortlich.
  4. PDC Emulator: Zeigt den Server an, auf dem der PDC Emulator liegt. Der PDC Emulator ist für die Behandlung von Legacy-Anforderungen von Windows NT 4.0-Betriebssystemen, die in der Domäne vorhanden sein können, sowie für die Synchronisierung von Passwortänderungen verantwortlich.
  5. Infrastructure Master: Zeigt den Server an, auf dem der Infrastructure Master liegt. Der Infrastructure Master ist für die Synchronisierung von Sicherheitsprinzipalnamen (Security Principal Names, SPNs) zwischen Domänencontrollern in verschiedenen Domänen verantwortlich.

Arbeitsblatt 02

Aufgaben

User, Gruppen und DNS mit RSAT Tools verwalten

DNS Server setzen

vmWP1:

Set-DnsClientServerAddress -InterfaceAlias "eth0" -ServerAddresses ("192.168.110.61")

Domain Join

vmWP1:

Add-Computer -DomainName sam159.iet-gibb.ch
# Administrator / SmL12345$

Installation RSAT Tools

vmWP1:

Get-WindowsCapability -Online | Where-Object {$_.Name -like 'Rsat*'} | Add-WindowsCapability -Online

Neuen User im LDAP anlegen und TGT lösen

Neuen Benutzer anlegen

Via GUI von RSAT Tools (Username = luca)

Benutzer in Gruppe Domain Admins hinzufügen

Via Gui von RSAT Tools

DistinguishedName herausfinden

Via Gui von RSAT Tools (Attribut-Editor)

TGT lösen

Search domain zuerst konfigurieren (siehe unten) vmLP1:

sudo apt install krb5-user
 
kinit luca

Verbindung testen

vmLP1:

smbclient -L vmls1

SID herausfinden

Via GUI von RSAT Tools (Attribut-Editor -> objectSID)

Active Directory mit ldapsearch abfragen

Search domain konfigurieren

vmLP1:

sudo nmcli con mod eth0 ipv4.dns-search "sam159.iet-gibb.ch"
sudo nmcli networking off
sudo nmcli networking on

Ldap-utils installieren

vmLP1:

sudo apt update
sudo apt install ldap-utils

Require Strong Auth deaktivieren

vmLS1: /etc/samba/smb.conf

# Folgende Zeile unter GLOBAL hinzufügen
ldap server require strong auth = no

# Samba neustarten 
sudo systemctl restart samba-ad-dc.service

Ldap query

Der nachfolgende Command gibt den zuvor erstellten User aus. '(cn=*)' würde alle Objekte im Realm ausgeben.

vmLP1:

ldapsearch -x -LLL -H ldap://vmls1.sam159.iet-gibb.ch -b dc=sam159,dc=iet-gibb,dc=ch -D CN=administrator,CN=Users,DC=sam159,DC=iet-gibb,DC=ch -w Sml12345$ '(cn=luca)'

Fileserver in der Domäne

Bisher existiert nur ein Domaincontroller. Auf diesem sollten keine Daten gespeichert werden. Dazu sollte immer ein Fileserver verwendet werden. Dies, weil nur Fileserver ein einheitliches ID-Mapping (UIDs und GIDs) garantieren kann. Microsoft rät davon ab, Daten auf einem Domaincontroller zu speichern.

ID Mapping

Windows und Linux nutzen verschiedene Arten von der ID-Zuweisung. SIDs, welche im AD gespeichert sind, müssen auf GIDs und UIDs umgewandelt werden. Dazu gibt es den Dienst Winbind, welcher dafür zuständig ist. Es gibt verschiedene Arten, wie der Vorgang gemacht wird. Eine davon ist die RID-Methode. Die Definition, welche Methode bei unserem Fallbespiel verwendet wird, steht im smb.conf File. Bei der RID-Methode wird eine RID für das Mapping verwendet. Eine solche ID wird jedes Mal beim Anlegen eines solchen Nutzers automatisch vergeben. Dadurch gelingt es auch ein einheitliches Mapping für Linux-Benutzer zu erstellen.

SID

Security Identifier kurz SID sind Security Principals in einer Domäne. Ein solcher Principal erhält mittels dieser ID eine eindeutige Kennung. Eine SID besteht aus 2 Teilen:

  • Domänenerkennung
  • Objekterkennung (RID) Mittels der SID eines Objektes, kann man in einer AD-Domäne den Zugriff auf Ressourcen gewähren oder verweigern. Die beiden SIDs aus der Aufgabe von Vorher sind folgende:
  • S-1-5-21-2314224508-1894359441-3930816415-500
  • S-1-5-21-2314224508-1894359441-3930816415-512

Winbind übersetzt SID in GID und UID. Die Art wird in smb.conf definiert und wir verwenden die rid-Methode. Eine SID besteht mehreren Teilen:

  • S - Kennzeichen für SID
  • 1 - Revisionsebene
  • 5 - Identifizierungsautorität
  • 21-3770624505-2901393275-1935834510 - Domäne/Computer
  • 500/512 - Relativer Identifier (RID)
SIDZuordnung
S-1-5-<Domäne>-500Administrator-Benutzerkonto
S-1-5-<Domäne>-501Gast-Benutzerkonto
S-1-5-<Domäne>-502KRBTGT-Servicekonto
S-1-5-<Domäne>-512Domain Admins
S-1-5-<Domäne>-513Domain User Group
S-1-5-<Domäne>-514Domain Guest Group
S-1-5-<Domäne>-515Domain Computer Group
S-1-5-<Domäne>-516Domain Controller Group
S-1-5-<Domäne>-519Organisations-Admins
S-1-5-<Domäne>-520Richtlinien-Ersteller-Besitzer Gruppe
S-1-5-32-544Administratoren-Gruppe
S-1-5-32-545Benutzer-Gruppe

SIDs finden

Unter Windows muss man im Server Manager auf Tools -> Active Directory Benutzer und Computer zuerst auf Ansicht drücken. Dort wählt man erweiterte Features. Anschliessend wählt man mit rechtsklick den Nutzer aus und drückt auf Eigenschaften. Unter Attribut-Editor findet man beim Herunterscrollen unter objectsid die SID.

Die angegebene Nummer entspricht aber nicht der ganzen SID. Der RID ist nicht angegeben. Dieser findet man etwas weiter unten bei primary Group ID.

Arbeitsblatt 03

Netzwerkkonfiguration

vmLS2: /etc/netplan/00-eth0.yaml:

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      addresses:
      - 192.168.110.62/24 
      dhcp4: false
      nameservers:
        addresses:
        - 192.168.110.61
        search:
        - sam159.iet-gibb.ch
      routes:
      - to: default
        via: 192.168.110.2

vmLS2:

sudo netplan apply --debug

Samba installieren

vmLS2:

sudo apt update
sudo apt install samba samba-common-bin smbclient heimdal-clients libpam-heimdal
sudo apt install libnss-winbind libpam-winbind

Folgende Realm-Konfiguration hinzufügen: vmLS2: /etc/krb5.conf

[realms]
	SAM159.IET-GIBB.CH = {
		kdc = vmls1.sam159.iet-gibb.ch
		admin_server = vmls1.sam159.iet-gibb.ch
		default_domian = sam159.iet-gibb.ch
	}

Grundkonfiguration des Fileservers

vmLS2: /etc/samba/smb.conf:

[global]	
	workgroup = sam159	
	realm = SAM159.IET-GIBB.CH	
	security = ADS	
	winbind enum users = yes	
	winbind enum groups = yes	
	winbind use default domain = yes	
	winbind refresh tickets = yes	
	template shell = /bin/bash	
	idmap config * : range = 10000 - 19999	
	idmap config SAM159 : backend = rid	idmap 
	config SAM159 : range = 1000000 - 1999999	
	inherit acls = yes	
	store dos attributes = yes	
	client ipc signing = auto	
	vfs objects = acl_xattr

vmLS2:

sudo reboot

vmLS2 als Mitglied zur Domäne hinzufügen

vmLS2:

sudo net ads join -U administrator

Der DNS-Fehler entsteht, da VMLS2 bereits in der Domäne eingetragen ist.

Wbinfo

Zur Überprüfung können wir mittels wbinfo testen, ob die Nutzer und Gruppen übernommen wurden

vmLS2:

sudo winbindd
wbinfo -u # listet Benutzer
wbinfo -g # listet Gruppen
wbinfo --name-to-sid=administrator # SID von domain admin
wbinfo --domain-info=SAM159 # domain info
wbinfo --dc-info=SAM159 # dc info

Damit man Rechte im Dateisystem Rechte vergeben kann, muss man die Datei /etc/nsswitch.conf bearbeiten

vmLS2: /etc/nsswitch.conf:

passwd:         compat systemd winbind
group:          compat systemd winbind
shadow:         compat winbind
gshadow:        files

hosts:          files dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

Gemappte User und Gruppen anzeigen

vmLS2:

getent passwd
getent group

Bei den Ausgaben, sind sowohl die lokalen als auch die Nutzer und gruppen der Domäne enthalten. Die IDs sind so von den AD-Nutzer und Gruppen festgelegt, wie es im vorherigen Schritt in der smb.conf Datei definiert wurde.

Aufgaben

Aufgabe 1

Die Nutzer und Gruppen sind nun auf vmLS2 aktiviert. Jedoch kann man sich noch nicht mit einem User anmelden. Su -l luca und su -l administrator funktionieren nicht.

Dies funktioniert noch nicht, weil für die Benutzer kein Homeverzeichnis eingerichtet ist. Mit dem Befehl id luca sieht man die ID des Nutzers. Ebenfalls ist ersichtlich, dass es ein Domain Nutzer ist. Dies, weil die ID dem in der smb.conf festgelegten Konzept entspricht.

Aufgabe 2

vmLS2:

wbinfo --name-to-sid luca
# S-1-5-21-1487683448-2288546232-1082645044-1104 SID_USER (1)
wbinfo --name-to-sid "domain users"
# S-1-5-21-1487683448-2288546232-1082645044-513 SID_DOM_GROUP (2)
wbinfo --group-info "domain users"
# domain users:x:10000:
wbinfo -i luca
# luca:*:10003:10000::/home/SAM159/luca:/bin/bash

Die Endung 1104 wird mit Prefix 100 als uid übernommen. Die Endung 513 wird mit Prefix 1000 als gid übernommen.

Der Zusammenhang zwischen der ID und der SID ist wie folgt. Es wird eine ID definiert. Bei User 1113 und bei der Gruppe 1112. Dies ist der Relativ Identifier (RID) Diese RID wird im Linux hinter 100 gestellt. Daraus geben sich die IDs 1001112 und 1001113. Bei der SID wird diese Nummer hinter die Domäne gestellt. Es dient hier als RID.

Arbeitsblatt 04

Grund

Es gibt verschiedenen Gründe, weshalb ein Fieserer über die Registry verwaltet werden sollte und nicht über die Datei smb.conf. Jeder Client, der sich mit dem Fileserver verbindet, startet einen smbd-Prozess. Dabei liest er die Konfiguration des Servers. Jedes Mal, wenn eine Änderung an der Konfiguration vorgenommen wird, muss di Konfiguration über das ganze netz verteilt werden. Beim Administrieren über die Registry werden nur die angepassten Einstellungen verteilt. Bei der smb.conf Datei handelt es sich um eine ASCII-textdatei, was zur Folge hat, dass nur ein Administrator an dem Fileserver arbeiten kann. Bei der Registry ist es eine Datenbank, auf welche mehrere Administratoren gleichzeitig zugreifen können. Um die Konfigurationsdatei zu bearbeiten, muss man sich immer mit ssh auf den Server verbinden. Mit der Registry braucht es diesen Schritt nicht. Es kann direkt aus der Registry gearbeitet werden und sogar neue Freigaben erstellt werden.

Was ist die Registry

Die Registry Datenbank wird von Samba dazu benutzt, Informationen abzulegen. Bei der Kommunikation mit den Clients wird die Datenbank benötigt. Windows Clients suchen nämlich nach gewissen Parametern immer zuerst in der Registry. Die Registry ist as Baumstruktur gegliedert und hat darin verschiedene Schlüssel mit Unterschlüssel. Ein solcher kann mit einem oder mehreren Werten belegt sein. Diese Werte gibt es in verschiedenen Datentypen. (String, Binaries, Interger). Bei der Konfiguration sind die String-Typen REG_SZ und REG_MULTI_SZ von Interesse. Die Registry ist in unterschiedliche Hives aufgeteilt. Der relevante Hiev für Samba ist der HKEY_LOCAL_MACHINE (HKLM).

Zugriff auf die Registry

vmLS2:

sudo net registry enumerate HKLM
 
sudo net registry enumerate HKLM\\software
 
sudo net registry enumerate HKLM\\software\\samba

Remote-Zugriff auf die Datenbank

Die Datenbank ist als Datei unter /var/lib/samba/registry.tdb abgespeichert. Dort hat nur der User Root Zugriff und kein anderer. Auf die Datenbank kann aber über das Netzwerk zugegriffen werden. Dies geschieht mit rpc.

vmLS1:

sudo net rpc registry enumerate HKLM\\software\\samba\\ -U administrator -I 192.168.110.10

Der ganze Remote Zugriff funktioniert auch via Kerberos.

vmLP1:

kinit administrator
net rpc registry enumerate HKLM\\software\\samba\\ -k -S vmls2.sam159.iet-gibb.ch

Es ist auch möglich via Windows auf die Registry zuzugreifen. Dazu muss man sich als Administrator auf der vmWP1 anmelden. Anschliessend muss man den Registrierungseditor (regedit) öffnen.

Inhalt der smb.conf in die Registry verschieben

Zur Verschiebung der smb.conf Datei in die Registry der untenstehende Befehl. Anschliessend kann man sich die importierte Konfiguration anzeigen lassen:

vmLS2:

sudo net conf import /etc/samba/smb.conf
sudo net conf list

Aufgaben

Aufgabe 1

Um sich die Registry durch die regedit Brille anzuschauen, verbindet man sich wieder mit der Registry, wie im vorherigen Schritt beschrieben. Anschliessend öffnet man den Pfad: HKEY_LOCAL_MASCHINE -> SOFTWARE -> Samba -> smbconf -> global Nun sind die Parameter von der Konfigurationsdatei ersichtlich.

Aufgabe 2

Die Samba Konfiguration soll so angepasst werden, dass die Settings in Zukunft nur aus der Registry geladen werden sollen.

vmLS2:

sudo cp /etc/samba/smb.conf /etc/samba/smb.conf.master

vmLS2: /etc/samba/smb.conf

[global]
	config backend = registry

Aufgabe 3

Damit man prüfen kann, ob die User die Konfiguration aus der Registry lesen, kann man den Befehl testparm nutzen. Dieser simuliert einen Zugriff auf den Fileserver. Bei der Ausgabe ist ein Parameter von grosser Bedeutung. Wenn in der Zeile lp_load_ex: als Wert changing to Config backend registry steht, war der Switch von der Konfiguration auf die Registry erfolgreich.

Arbeitsblatt 05

Um einen Share zu erstellen, braucht es zuerst einen Ordner. Dieser wird wie folgt angelegt:

vmLS2:

sudo mkdir -p /daten/reg-share

Anschliessend muss man diesen in die Registry importieren. Dazu braucht es wieder den net conf Befehl.

vmLS2:

sudo net conf addshare reg-share /daten/reg-share writeable=y guest_ok=n "Share in der Registry"

Wie oben gesehen, können beim Erstellen des Shares nur die Parameter writeable, guest_ok und die Beschreibung angegeben werden. Weitere Angaben, können jedoch später eingetragen werden. Nun kann man überprüfen, ob der Share erstellt wurde und in die Registry übernommen wurde. Mit dem untenstehenden Befehl sollte in der Ausgabe der Share erscheinen und die entsprechenden Parameter aufgelistet sein.

vmLS2:

sudo net registry export hklm\\software\\samba /dev/stdout

Natürlich kann man auch von einer anderen Maschine prüfen, ob der Share erstellt wurde. Dazu kann man auf der Maschine vmLP1 den untenstehenden Befehl nutzen. Dieser zeigt alle Informationen zum Share an:

vmLP1:

kinit administrator 
 
sudo net rpc registry enumerate HKLM\\software\\samba\\smbconf\\reg-share -k -S vmls2.sam159.iet-gibb.ch

Zugriff auf Share aus der Registry

Um sich den Share anzuzeigen, kann man sich mittels smbclient eine auflistung aller Shares machen.

vmLP1:

smbclient -L vmls2
smbclient -L vmls2 -k

Wenn man nun versucht eine Verbindung zum Share herzustellen, funktioniert dies einwandfrei. Im Falle, dass man aber einen Ordner erstellen möchte, funktioniert dies nicht, da man keine Berechtigungen hat.

Freigabe der Homeverzeichnisse

Damit ein User Files in seinem Heimverzeichnis ablegen kann, muss man nun eine entsprechende Freigabe erstellen. Dazu wird unter Samba 4 immer das Verzeichnis /home/DomainName als Heimverzeichnis verwendet. Den Share erstellt man mit folgenden Schritten:

vmLS2:

sudo mkdir /home/SAM159 
sudo chmod 755 /home/SAM159/ 
sudo chgrp 'SAM159\Domain Admins' /home/SAM159/ 
sudo chown 'SAM159\administrator' /home/SAM159/ 
sudo net conf addshare users /home/SAM159 writeable=y guest_ok=n "Home-Dirs" 
sudo net conf setparm users "browsable" "no" 
sudo net conf setparm users "create mask" "700" 
sudo net conf setparm users "directory mask" "700"

Damit wurde nun ein Share namens User erstellt, welcher von den Domain Admins und dem Administrator verwaltet werden. Der Share stammt vom Verzeichnis /home/SAM159. Den Share mit den Parametern kann man sich wie folgt anschauen:

vmLS2:

sudo net rpc registry enumerate HKLM\\software\\samba\\smbconf\\users -k -S vmls2

Aufgaben

Aufgabe 1

Aufgabe 1 wurde bereits einige Schritte vorhin gelöst, da dies mitten im Prozess geschehen musste.

Aufgabe 2

Um einem bestehenden Nutzer via RSAT ein Heimatverzeichnis zuzuordnen, muss man in den Server Manager gehen. Unter Active Directory Benutzer und Gruppen, wählt man den entsprechenden Nutzer aus. In diesem Fall wird der Nutzer Samuel verwendet. Man macht einen Rechtsklick auf den Nutzer und wählt anschliessend Eigenschaften. Dann muss man den Reiter Profil auswählen. Dort trägt man bei Basis Ordner ein, welcher Laufwerksbuchstabe verwendet werden soll und welcher Share.

  • Laufwerksbuchstabe: H
  • Share: \\192.168.110.11\users\%username%

Aufgabe 3

Die Berechtigungen für das erstellte Verzeichnis sind wie folgt:

  • Benutzer Admin: RWX
  • Benutzer Luca: RWX
  • Gruppe Domain User: ---
  • Other: --- Die Berechtigungen kann man auf dem Fileserver anschauen:

vmLS2:

sudo ll /home/SAM159/

Zu sehen ist, dass noch ein Pluszeichen (+) hinter den Berechtigungen stehen. Dies steht dafür, das es eine ACL gibt, welche angezogen ist. Damit man diese ACL anschauen kann, muss man zuerst das Paket acl herunterladen. Anschliessend kann man mittels des untenstehenden Befehls die Berechtigungen anschauen.

vmLS2:

sudo apt install acl
sudo getfacl /home/SAM159/luca

Aufgabe 4

Prüfen, ob es funktioniert hat, kann man, indem man sich mit dem Benutzer anmeldet und im Explorer schaut, ob das Verzeichnis da ist.

Aufgabe 5

Die Berechtigungen kann man wie in der Aufgabe 3 mittels getfacl anschauen. Man kann aber auch unter Windows anschauen, wie die Berechtigungen gesetzt sind. Man sieht, dass der User Luca alle benötigten Rechte hat, sowie dies die Administratoren Gruppe hat.

Graph View

Backlinks