Macs am Active Directory

One for all

Am SGS gibt es eine zentralisierte Account-Verwaltung. Unser Benutzerverzeichnis ist eine Active Directory Implementierung auf Basis von Samba 4 auf dem Betriebssystem von Synology. Hier bedienen sich verschiedenste Dienste, um Zugangskontrollen durchzuführen.

Etwa prüft unser WiFi-Controller an unserem Radius-Server, ob Zugangsrechte zum WLAN bestehen. Zukünftig möchte ich hier gruppenbasierte VLANs zuweisen, um unser WLAN zu segmentieren, denn einige Netzkomponenten kommen sonst anscheinend auch mal an ihre Grenzen.

Auch Chat- und Cloud-Speicher sowie unsere Homepage hängen an diesem Verzeichnis. Sogar unsere Kopierer (was bei häufigen Netzausfällen leider auch zu Frust führen kann). Und auch die Arbeitsplätze an unserer Schule. Über die zahlreichen Stolperstellen und mögliche Lösungen möchte ich hier etwas schreiben.

Die drei !!!

Die wichtigsten Grundideen dabei sind folgende:

1. Die Anmeldung soll über das Active Directory laufen.
2. Um die Netzlast durch unnötigen Traffic zu vermeiden soll nicht das gesamte User-Home über das Netz gemountet werden; stattdessen wird ein Netzverzeichnis gemountet und auf den Desktop des Benutzers verlinkt.
3. Sämtliche nötigen Einstellung und Eingriffe am lokalen System sollen über Konfigurationsprofile, die über dynamische Gruppen in unserem MDM ohne weiteres Zutun verteilt werden, geregelt werden.

Die Gründe für diese Eckpunkte sind klar: Alle Benutzer sollen für alle digitalen Dienste der Schule mit nur einer Kombination aus Benutzernamen und Passwort nutzen können. Die Entscheidung gegen ein netzbasiertes User-Homeverzeichnis stammt aus langen, leider sehr nervigen Erfahrungen etwa beim Surfen in zwei parallelen Förderkursen mit insgesamt ca. 32 aktiven Arbeitsplätzen: Browser wie Safari legen ihren Cache im User Home ab. Schon bei einem einzelnen Benutzer ist Caching im Netzwerk fragwürdig; bei 32 parallelen Sessions völlig sinnfrei.

Der Letzte der drei genannten Punkte ist mir dabei besonders wichtig. Es geht darum, sich nur einmal Gedanken über eine sinnvolle Konfiguration machen zu müssen, und diese dann ohne viel Zutun auf „blanke“ Rechner zu spielen. Die Einrichtung unserer 18 Macbooks zum Beispiel hat mich ca. 90 Minuten gekostet — inklusive Auspacken, Softwareverteilung, Einbindung ins Active Directory und Wegräumen der Kartons 😉

Der kleine feine Unterschied

Zunächst mal müssen die Rechner im Management identifiziert werden, die unsere Konfigurationsprofile und einige Bash-Scripte erhalten sollen. Dabei ist es natürlich ein Unterschied, ob die Rechner im Normalfall per LAN oder WLAN im Schulnetz hängen.

Abhängig vom Gerätetyp kann dann entschieden werden, wie die Active Directory Anbindung funktionieren soll. Hier gibt es einige Stolperstellen, die durch mehr oder weniger gute Script-Tricksereien umgangen werden können.

„Ärger gibt es immer“

Etwa kam es bei unseren Mac Minis regelmäßig zu Anmeldeproblemen, da parallel zur LAN Verbindung auch noch die WLAN Verbindung der Macs aktiv war. Dies lässt sich vom Benutzer wählen, und einige unserer Schüler haben sich aus Gewohnheit am Gäste-WLAN angemeldet. Da man hier am Captive Portal ohne Gast-Code nicht vorbeikommt und diese somit ohnehin im falschen Subnetz sind, kann unser Domaincontroller über diese Verbindung nicht gefunden werden, so dass keine Anmeldung möglich ist.

Um das in den Griff zu bekommen erhalten alle LAN-gebundenen Arbeitsplätze ein Script, mit dem das WLAN vollständig abgeschaltet wird:

networksetup -setairportpower en1 Off then
networksetup -setnetworkserviceenabled en1 Off

Bei den Macbooks ist das natürlich so sinnvoll nicht. Daher wird hier verhindert, dass ein Benutzer ohne Admin-Rechte das WLAN ändern kann. Den Zugang zum Geräte-Wifi erhalten die Macbooks über ein Konfigurationsprofil:

/usr/libexec/airportd prefs RequireAdminIBSS=YES RequireAdminNetworkChange=YES RequireAdminPowerToggle=YES

Ein weiteres Problem: Unsere Benutzerprofile haben (leider) nicht den FQDN im Netzwerkpfad stehen, sondern nur einen lokalen Servernamen. Wenn die mDNS Antworten nicht oder nicht zügig genug zurückkamen verweigerte der Client die Anmeldung mit einer kryptischen Fehlermeldung („Die Anmeldung ist aufgrund eines Problems fehlgeschlagen“). Es ist zwar etwas quick-and-dirty, aber über das Setzen passender Hosteinträge lässt sich auch das umschiffen:

printf "127.0.0.1	localhost\n255.255.255.255	broadcasthost\n::1             localhost\n123.123.123.123	sgscloud.local	sgscloud    sgscloud.de\n" > /etc/hosts

Das Fehlen einer passenden Hostname-Auflösung umgehen wir in den Konfigurationsprofilen von Jamf übrigens dadurch, dass wir hier (vorerst) die feste IP des Domain Controllers hinterlegen.

In den AD Profilen setze ich zudem auf mobile Accounts. Das erlaubt 14 Tage lang bei vollständiger Trennung vom Netz immer noch die Anmeldung der letzten Benutzer.

Da hier lokal Homeverzeichnisse erstellt werden, kommen die Benutzer nicht ohne Weiteres an ihre Daten auf dem Server. Das ermöglicht aber das automatische authentifizierte Mounten des Home Ordners als Netzwerkfreigabe. Ein kleines Skript legt dann einen Link auf den Desktop:

loggedInUser=$(ls -l /dev/console | awk '{ print $3 }')
ln -s /Volumes/home /Users/$loggedInUser/Desktop/SGSCloud

Dadurch erhält der Benutzer Zugriff auf seine Dateien auf dem Fileserver, ohne dass lokale Apps ihre Einstellungen und Caches permanent über das Netz schicken müssen. Das ist besonders bei Laptops mit schwachem WiFi Signal hilfreich.

Der letzte Ärger, der mir sehr lange Kopfzerbrechen bereitet hat, hat folgendes Symptom: Geänderte AD Profile wurden nicht erfolgreich gepusht. Die – wie üblich kryptischen – Fehlermeldungen des MDM haben keinen Hinweis auf die Ursache gegeben. Nach einigem Hin- und Her konnte ich folgendes Feststellen: Bisweilen verweigert der AD Controller die Einbindung eines Clients mit geänderten Einstellungen, wenn dieser schon im AD eingebunden ist.

Hier muss also nach dem Ändern des AD Profils oder auch bei einer erneuten Einbindung eines „geplätteten“ Arbeitsplatzes der entsprechende Client erst vom AD Controller gelöst werden, damit er, beim Pushen des (aktualisierten) Konfigurationsprofils, wieder erfolgreich am AD angemeldet werden kann.

„Yeah, I can fly“

Mit den genannten Einstellungen haben einige Tests auf unseren 2014er Mac Minis und den 2020er Macbooks gezeigt, dass die Anmeldung tatsächlich sehr zügig von statten geht. Aktuell haben wir noch Mac OS Catalina im Einsatz, und die Anmeldung von kompletten Lerngruppen funktioniert endlich so zügig wie sie sollte. Auch die Arbeit am System klappt recht gut; hier werden allerdings in Kürze die über eine Spende des Fördervereins des Gymnasiums angeschafften SSDs noch für einen erheblichen Geschwindigkeitsboost sorgen, so dass diese nun 6 Jahre alten Rechner auch in den kommenden Jahren noch gut ihre Dienste verrichten werden.

In der Schule gibt es immer wieder mal Spenden, einmalige Fördermaßnahmen oder Investitionen. Was es nicht gibt sind dauerhafte Budgets für Administration und Support. Deswegen kann die Strategie nur lauten: Bei den Anschaffungen nicht sparen, wenn dadurch die Wartungs- und Administrationskosten gering gehalten werden können.