Laufwerk M: mit einer Gruppenrichtlichtlinie ausblenden

Bei Terminal- und Citrixservern möchte man oft die lokalen Laufwerke bei Windows ausblenden. Ab besten kann man dies mit Hilfe einer Gruppenrichtlinie im Active Directory erledigen. Bei der normalen Gruppenrichtlinie gibt es allerdings nur die Möglichkeit die lokalen Laufwerken um A, B, C oder D auszublenden. Wenn man die Gruppenrichtlinie mit der folgenden ADM-Datei erweitert, kann man auch die bei Laufwerksbuchstaben M, N, O und X ausblenden, die häufig bei Citrixservern vorkommen.

Nähere Infos über ADM-Dateien sind bei www.gruppenrichtlinien.de, Microsoft oder www.MSExchangeFAQ.de zu finden.


;Einstellung zur Laufwerksunterdrückung

CLASS USER

CATEGORY !!WindowsComponents
    CATEGORY !!WindowsExplorer
	KEYNAME "Software\Microsoft\Windows\CurrentVersion\Policies\Explorer"

POLICY !!NoDrives 
            EXPLAIN !!NoDrives_Help
	    PART !!NoDrivesDropdown	DROPDOWNLIST NOSORT REQUIRED
		VALUENAME "NoDrives"
		ITEMLIST
		    NAME !!ABOnly           VALUE NUMERIC	3
		    NAME !!COnly            VALUE NUMERIC	4
		    NAME !!DOnly            VALUE NUMERIC 	8
		    NAME !!ABConly          VALUE NUMERIC 	7
		    NAME !!ABCDOnly         VALUE NUMERIC	15
                    NAME !!MOnly            VALUE Numeric       4096
                    NAME !!AMOnly           VALUE Numeric       4097
                    NAME !!NOnly            VALUE Numeric       8192
                    NAME !!ACDMNOnly        VALUE Numeric       12301
                    NAME !!CDMNOnly         VALUE Numeric       12300
                    NAME !!CDMNOOnly        VALUE Numeric       28684
                    NAME !!CDMNOXOnly       VALUE Numeric       8417292
		    NAME !!ALLDrives        VALUE NUMERIC	67108863 DEFAULT 
                         ; low 26 bits on (1 bit per drive)
		    NAME !!RestNoDrives     VALUE NUMERIC	0

		END ITEMLIST
	    END PART			
	END POLICY

        POLICY !!NoViewOnDrive
            EXPLAIN !!NoViewOnDrive_Help
	    PART !!NoDrivesDropdown	DROPDOWNLIST NOSORT REQUIRED
		VALUENAME "NoViewOnDrive"
		ITEMLIST
		    NAME !!ABOnly           VALUE NUMERIC	3
		    NAME !!COnly            VALUE NUMERIC	4
		    NAME !!DOnly            VALUE NUMERIC 	8
		    NAME !!ABConly          VALUE NUMERIC 	7
		    NAME !!ABCDOnly         VALUE NUMERIC	15
                    NAME !!MOnly            VALUE Numeric       4096
                    NAME !!AMOnly           VALUE Numeric       4097
                    NAME !!NOnly            VALUE Numeric       8192
                    NAME !!ACDMNOnly        VALUE Numeric       12301
                    NAME !!CDMNOnly         VALUE Numeric       12300
                    NAME !!CDMNOOnly        VALUE Numeric       28684
                    NAME !!CDMNOXOnly       VALUE Numeric       8417292
		    NAME !!ALLDrives        VALUE NUMERIC	67108863 DEFAULT 
                         ; low 26 bits on (1 bit per drive)
		    NAME !!RestNoDrives     VALUE NUMERIC	0

		END ITEMLIST
	    END PART			
	END POLICY

	End Category
End Category


[strings]

WindowsComponents="Ohl_Windows-Komponenten"
WindowsExplorer="Windows Explorer"
NoDrives_Help="_Entfernt die Symbole für ausgewählte Laufwerke aus Arbeitsplatz, Windows Explorer und Netzwerkumgebung. Außerdem werden die Laufwerkbuchstaben, die die ausgewählten Laufwerke darstellen, im Standarddialog "Öffnen" nicht angezeigt.\n\nWenn Sie diese Richtlinien verwenden möchten, wählen Sie ein Laufwerk oder eine Kombination von Laufwerken aus der Dropdownliste. Deaktivieren Sie diese Richtlinie, oder wählen Sie die Option "Laufwerke nicht einschränken" aus der Dropdownliste, wenn alle Laufwerke angezeigt werden sollen.\n\nHinweis: Durch diese Richtlinie werden die Laufwerksymbole ausgeblendet. Benutzer können weiterhin anderweitig auf die Laufwerke zugreifen, indem sie z. B. einen Pfad zu dem Verzeichnis auf dem Laufwerk im Dialogfeld "Netzlaufwerk verbinden", im Dialogfeld "Ausführen" oder in der Eingabeaufforderung eingeben.\n\nAußerdem verhindert diese Richtlinie nicht, dass Benutzer das Datenträgerverwaltungs-Snap-In verwenden, um Laufwerkeigenschaften anzuzeigen oder zu ändern.\n\nWeitere Informationen finden Sie unter der Richtlinie "Zugriff auf Laufwerke vom Arbeitsplatz nicht zulassen"."
NoDrives="Diese angegebenen Datenträger im Fenster "Arbeitsplatz" ausblenden"
NoDrivesDropdown="Wählen Sie eine der folgenden Kombinationen"
NoViewOnDrive_Help="Verhindert, dass Benutzer in Arbeitsplatz auf den Inhalt ausgewählter Laufwerke zugreifen.\n\nDurch Aktivieren dieser Richtlinie, können Benutzer den Inhalt ausgewählter Laufwerke in Arbeitsplatz, Windows Explorer oder Netzwerkumgebung nicht einsehen. Außerdem können Benutzer nicht die Dialogfelder "Ausführen" oder "Netzlaufwerk verbinden" verwenden oder den Befehl "dir" ausführen, um Verzeichnisse auf diesen Laufwerken anzuzeigen.\n\nWählen Sie ein Laufwerk oder mehrere Laufwerke aus dem Listenfeld, um diese Richtlinie zu verwenden. Deaktivieren Sie diese Richtlinie, oder verwenden Sie die Option "Laufwerke nicht einschränken" aus dem Listenfeld, um diese Richtlinie zu deaktivieren.\n\nHinweis: Die Symbole, die die angegebenen Laufwerke darstellen, werden weiterhin in Arbeitsplatz angezeigt, aber wenn Benutzer versuchen, auf die Laufwerke zuzugreifen, wird eine Meldung angezeigt, die erläutert, dass dieser Vorgang aufgrund einer Richtlinie nicht gestattet ist.\n\nDiese Richtlinie verhindert nicht, dass Benutzer das Datenträgerverwaltungs-Snap-In verwenden, um Laufwerkeigenschaften zu ändern oder anzuzeigen.\n\nWeitere Informationen finden Sie unter der Richtlinie "Diese angegebenen Datenträger im Fenster Arbeitsplatz ausblenden"."
NoViewOnDrive="Zugriff auf Laufwerke vom Arbeitsplatz nicht zulassen"
ABOnly="Nur Laufwerke A und B beschränken"
COnly="Nur Laufwerk C beschränken"
DOnly="Nur Laufwerk D beschränken"
ABConly="Nur Laufwerke A, B und C beschränken"
ABCDOnly="Nur Laufwerke A, B, C und D beschränken"
ACDMNOnly="Nur Laufwerke A, C, D, M und N beschränken"
MOnly="Nur Laufwerk M beschränken"
AMOnly="Nur Laufwerke A und M beschränken"
NOnly="Nur Laufwerk N beschränken"
CDMNOnly="Nur Laufwerke C, D, M und N beschränken"
CDMNOOnly="Nur Laufwerke C, D, M, N und O beschränken"
CDMNOXOnly="Nur Laufwerke C, D, M, N, O und X beschränken"
ALLDrives="Alle Laufwerke einschränken"
RestNoDrives="Laufwerke nicht einschränken"

Samba 3.0 in ein Active Directory von Microsoft integrieren

Schon seit längerem kann man einen Samba-Server in einen Active Directory von Microsoft integrieren. Dazu sind nur wenige Zeilen Konfiguration nötig. Allerdings wird für die Integration ein Kerberos 5 benötigt. Im folgenden eine kurze Beschreibung der nötigen Schritte für Debian Linux.

Bei Debian bekommt man alle benötigten Pakete, wenn man mit aptitude die dep-Files samba, winbind und heimdal-clients installiert. Die restlichen Pakete werden dabei durch die Abhängigkeiten automatisch installiert.

Als erstes muss Kerberos eingerichtet werden. Dazu muss die Konfigurationsdatei /etc/krb5.conf angepasst werden. Sie sollte hinterher in etwa wie folgt aussehen:

[libdefaults]
        default_realm = BUTTERNET.BIZ
        krb4_config = /etc/krb.conf
        krb4_realms = /etc/krb.realms
        kdc_timesync = 1
        ccache_type = 4
        forwardable = true
        proxiable = true

        v4_instance_resolve = false
        v4_name_convert = {
                host = {
                        rcmd = host
                        ftp = ftp
                }
                plain = {
                        something = something-else
                }
        }
        fcc-mit-ticketflags = true

[realms]
        BUTTERNET.BIZ = {
                kdc = server01.butternet.biz
                kdc = server02.butternet.biz                
                admin_server = server01.butternet.biz
        }

[domain_realm]

[login]
        krb4_convert = true
        krb4_get_tickets = false

Danach kann man mit kinit user und klist testen, ob man ein Ticket von dem Kerberos-Server (Windows Domain Controller) bekommen hat.

Nachdem Kerberos läuft muss Samba angepasst werden. Dazu müssen die globalen Parameter in der Konfigurationsdatei /etc/samba/smb.conf wie folgt angepasst werden:

# Global parameters
[global]
workgroup = BUTTERNET
netbios name = GARGOYLE
realm = BUTTERNET.BIZ
security = ADS
template shell = /bin/bash
idmap uid = 500-10000000
idmap gid = 500-10000000
winbind use default domain = Yes
winbind nested groups = Yes

Eine genaue Beschreibung der nötigen Parameter ist auf Webseite des Samba-Projektes zu finden.

Danach muss dem Linux-Server noch beigebracht werden winbind zu benutzen. Er soll ja nicht nur die lokalen User, Passworte und Gruppen kennen, sondern auch die des Active Directory. Dazu muss die Datei /etc/nsswitch.conf wie folgt angepaßt werden:

...
passwd: files winbind
shadow: files winbind
group:  files winbind
...
hosts:  files [dns] wins
...

Zum Schluss muss man mit dem Befehl net ads join -UAdministrator%passwort den Samba-Server der Windows Domäne beitreten lassen. Danach kann man mit dem Befehl net ads testjoin testen, ob der Server ein Mitglied der Domäne ist. Des weiteren sollte der Befehlt wbinfo -u alle Benutzer des AD anzeigen.

Nachdem die Konfiguration wie oben beschrieben getätigt ist, sollten Zugriffe von von Windows-Usern auf den Samba-Server möglich sein. Sie sollten z.B. auf die Freigabe testfreigabe zugreifen können, wenn in der Datei /etc/samba/smb.conf die folgende Freigabe konfiguriert wird:

[testfreigabe]
        comment = Testfreigabe
        inherit acls = Yes
        path = /home/irgendeinverzeichnis
        read only = No

Die Voraussetzung ist natürlich, dass es ein Verzeichnis /home/irgendeinverzeichnis gibt und der Benutzer die notwendigen Berechtigungen hat 😉

Squid 3.0 in ein Active Directory von Microsoft integrieren

Nach unendlich langer Zeit ist der bekannte und beliebte Proxy Squid in der Version 3.0 erschienen. Die Entwicklung hat fast acht Jahre gedauert. Ich hatte eigentlich auch schon nicht mehr daran geglaubt, dass es jemals eine Version 3.0 geben würde. Wie man den Release Notes entnehmen kann, hat sich einiges geändert. So wurde Squid jetzt in C++ statt C entwickelt und kann das Internet Content Adaptation Protocol (ICAP). Grund genug für mich, mir die neue Version mal etwas näher anzusehen und in der Praxis zu testen. Deshalb habe ich mich für einen Squid 3.0 entschieden, als ich einen kleineren Proxy für ca. 30 Benutzer benötigte.

Aufgabenstellung
Es wird ein HTTP-Proxy für ca. 30 Benutzer benötigt. Die Benutzer sollen sich für Internetzugriffe authentifizieren und teilweise nur zugriff auf bestimmte Internetseiten bekommen. Die Anmeldenamen und Passwörter dafür sind in einem Active Directory hinterlegt. Bei jedem Zugriff soll der Squid also bei einem Windows Domain Controller nachfragen, ob der Benutzer existiert und ob er Internetseiten sehen darf.

HTTP-Proxy

Installation
Als Server habe ich einen IBM HS21 Blade mit einer 2 GHz Xeon Dual Core CPU, 1 GB Hauptspeicher und einem Debian Linux 4.0 (64 Bit) verwendet. Er hatte bereits einige andere Aufgaben, die ihn aber kaum auslasteten.
Bei Squid habe ich die PRE5-Version verwendet. Diese kann man bei Debian 4.0 mit dem Befehlt aptitude install squid3 installieren. Das STABLE2-Paket gibt es nur für den „testing-Zweig“ von Debian und es ist wegen einigen Abhängigkeiten nicht so einfach zu installieren. Alle aktuellen Debian-Pakete von Squid 3.0 sind unter http://packages.debian.org/squid3 zu finden.

Konfiguration der Authentifizierung
Um die Anmeldenamen und Passwörter abzufragen, habe ich im Active Directory einen Benutzer SquidAuth und die Gruppe InternetZugang angelegt. Der Benutzer sollte aus Sicherheitsgründen keine vollen Admin-Rechte bekommen. Für das abfragen der Gruppenmitgliedschaft reicht es, wenn er Mitglied in der Gruppe RAS- IAS-Server ist. Falls man die Mitgliedschaften von Gruppen nicht braucht und nur den Benutzernamen und das Passwort gegen den Windows Domain Controller Authentifizieren möchte, reichen sogar normale Benutzerrechte!
Danach habe ich die Konfigurationsdatei des Squid (/etc/squid3/squid.conf) entsprechend erweitert. Wenn der befragte Windows Domain Controller ein Global Catalog Server ist, sollte der Port 3268 anstelle von Port 389 (wie eigentlich bei LDAP üblich) verwendet werden.
Falls sich ein Windows Domain Controller (der auch Global Catalog Server ist) mit der IP-Adresse 192.168.140.11 für die Domäne DOMAIN.local verantwortlich fühlt und das LAN den IP-Bereich 192.168.140.0/24 hat, könnte die Erweiterung etwa wie folgt aussehen:


# Authentifizierung an Active Directory
auth_param basic program /usr/lib/squid3/squid_ldap_auth -R -b "dc=DOMAIN,dc=local" -D "cn=SquidAuth,cn=Users,dc=DOMAIN,dc=local" -w "password" -f sAMAccountName=%s -h 192.168.140.11:3268
auth_param basic children 5
auth_param basic realm "Proxy Authentifizierung. Bitte geben Sie Ihren Benutzername und Ihr Passwort ein!"
auth_param credentialsttl 2 hours

external_acl_type InetGroup %LOGIN /usr/lib/squid3/squid_ldap_group -R -b "dc=DOMAIN,dc=local" -D "cn=SquidAuth,cn=Users,dc=DOMAIN,dc=local" -w "password" -f "(&(objectclass=person)(sAMAccountName=%v) (memberof=cn=%a,cn=Users,dc=DOMAIN,dc=local))" -h 192.168.140.11:3268

acl localnet proxy_auth REQUIRED
acl InetAccess external InetGroup InternetZugang
http_access allow InetAccess

Danach fragt Squid beim Aufruf einer Webseite nach einem Benutzernamen und Passwort. Des weiteren erhalten nur noch die Mitglieder der Gruppe InternetZugang Internetzugriff.

Fazit
Der Squid läuft jetzt seit 14 Tagen ohne Probleme. Bis jetzt habe ich keine Probleme mit Webseiten festgestellt. Sogar das Microsoft Windows Update läuft jetzt. Bei den alten Versionen von Squid funktionierte es meist nicht richtig.

Postfix nach gültigen Emailadressen auf einem Exchangeserver fragen lassen

Häufig wird zwischen Internet und dem internen Mailserver ein Linux mit Postfix eingesetzt, um unerwünschte Viren und SPAM nicht in das Firmennetzwerk gelangen zu lassen.

Postfix Mailproxy

Oft wird dabei eingestellt, dass alle Emails für die interne Domäne angenommen und an den internen Emailserver weiter geleitet werden, da Postfix die gültigen Emailadressen des internen Emailservers nicht kennt. Daraus ergeben sich jedoch zwei Probleme:

  1. Es werden auch Viren und SPAM für ungültige Emailadressen angenommen und untersucht, was unnötige Resourcen verbraucht.
  2. Es werden unnötige Unzustellbarkeitsbenachrichtigungen erzeugt, welche die Warteschlange im Mailserver verstopfen. Hinzu kommt, dass diese bei Viren und SPAM oft an falsche Emailadressen gehen. Dadurch werden zum Teil mehrere Zustellversuche unternommen, wodurch die Warteschlange wiederum noch mehr verstopft.

Um diese Probleme zu umgehen muss Postfix in der Lage sein, Emails an ungültige Emailadressen gar nicht erst anzunehmen. Dazu muss es jedoch die Möglichkeit haben, die Gültigkeit einer Emailadresse zu erfragen. Da Exchange ab der Version 2000 die dazu nötigen Informationen im Active Directory speichert, kann dies mit einer LDAP-Anfrage an einen Windows Domänen Controller geschehen. Ab Postfix 2.1 kann dies mit wenigen Zeilen Konfiguration und der Option relay_recipient_maps eingestellt werden. In der Firewall sollten vorher allerdings LDAP-Anfragen von Postfix an mindestens einen internen Windows Domänen Controller erlaubt werden. Dazu müssen Verbindungen des Postfix auf den TCP-Port 389 des Windows Domänen Controllers erlaubt werden.

Mit der Option relay_recipient_maps kann Postfix dazu gebracht werden nur Emails für gültige Emailadressen der eigenen Domäne weiterzuleiten. Bei unbekannten Emailadressen verweigert Postfix die Annahme einer Email mit der Meldung: Recipient address rejected: User unknown in relay recipient table. Diese existierenden Emailadressen können dabei auch über LDAP abgefragt werden, wenn Postfix mit LDAP-Unterstützung installiert ist (bei Debian muss dazu das Paket postfix-ldap installiert sein). Dazu muss man lediglich die folgende Zeile in die Datei /etc/postfix/main.cf einfügen.


relay_recipient_maps = ldap:/etc/postfix/ldap_relay_recipient_maps.cf

Danach muss die Datei /etc/postfix/ldap_relay_recipient_maps.cf mit den Einstellungen für die LDAP-Abfrage angelegt werden. Für die Abfrage der Emailadressen von den Windows Domän Controllern ad-01 und ad-02 der Domäne example.com als Benutzer postfix sollte sie wie folgt aussehen.


server_host = ad-01.example.com
              ad-02.example.com
search_base = dc=example, dc=com
version = 3

bind_dn = CN=postfix,CN=Users,DC=example,DC=com
bind_pw = password

query_filter = (proxyAddresses=smtp:%s)
result_attribute = mail

Die Voraussetzung ist natürlich, dass es einen Benutzer postfix unterhalb Users in der Domäne example.com gibt. Dieser muss jedoch keine Administrationsrechte haben. Es reicht ein normaler Benutzer.

Ob die Konfiguration in der Datei ldap_relay_recipient_maps.cf funktioniert, kann man als root mit dem folgendem Befehl testen.

/usr/sbin/postmap -q "postmaster@example.com" ldap:/etc/postfix/ldap_relay_recipient_maps.cf

Sofern es die Emailadresse postmaster@example.com gibt, sollte diese als Ausgabe erscheinen. Wenn es keine Ausgabe gibt, existiert diese nicht.

Weiter Infos zu dem Thema sind unter den folgenden Links zu finden: