Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?
Forum>Netzwerke>AD-Anmeldung scheitert mit neuen macOS Versionen

AD-Anmeldung scheitert mit neuen macOS Versionen

Jan-Henrik12.07.2111:45
Hallo,
unsere Macs sind alle ins Active Directory eingebunden. Dabei wird ganz normal das Programm "Verzeichnisdienste" benutzt. Bei der Bindung wurde in den Optionen der mobile Account ausgestellt und auch der Benutzerordner wird *nicht* auf dem Startvolume angelegt, es wird der UNC-Pfad von AD verwendet, um den Benutzerpfad abzuleiten. Das Ergebnis:
Die Benutzer (Studenten) können sich an jeden beliebigen Mac setzen, denn bei der Anmeldung werden nur die AD-Server befragt und der Benutzer landet in seinem persönlichen Heimatverzeichnis mit all seinen persönlichen Einstellungen. Er benutzt zwar die Programme des Macs, aber es werden von ihm keine Daten auf dem Mac gespeichert. Die liegen alle in seinem HomeDirectory auf dem AD-Server.
Das hat viele Jahre gut funktioniert, über viele macOS Versionen hinweg, bis macOS 10.13 (High Sierra).
Mit neueren macOS Versionen (10.14, 10.15, 11.x) scheitert diese Methode.
Nach Eingabe von Benutzername und Passwort dreht sich nur noch der Ball, eine vollständige Anmeldung erfolgt niemals. Aus dieser "Nummer" kommt man nur noch mit einem harten Neustart heraus.
Wenn man sich lokal am Mac anmeldet und dann manuell sein AD-Heimatverzeichnis kontrolliert, kann man erkennen, dass ein Zugriff erfolgt ist, denn in der Library wurden Einstellungen vorgenommen. Aber das scheint immer wieder im Kreis zu laufen, der Finder kommt niemals zum Ende, das HomeDirectory erscheint niemals.

Die AD-Admins zucken nur mit der Schulter. Eine Google-Abfrage hat diesbezüglich bisher wenig ergeben, ausser einigen wenigen "MeToo" Mitteilungen gab es keinen Lösungsansatz. Ein Anruf beim Business-Support von Apple führte ebenfalls ins Nirwana ("wir unterstützen nur OpenDirectory").
Downgrade ist keine Option, neuere iMacs erfordern 10.14 oder neuer, die ganz neuen M1-Maschinen laufen nur mit BigSur (11.x).

Kennt jemand das Problem und womöglich einen Lösungsansatz?
+2

Kommentare

Schibulski12.07.2112:58
Ich würde dir gerne weiterhelfen mit einer Lösung, kann dir aber nur den Hinweis geben, dass sich unsere Macs auch alle gegen das AD authentifizieren, manche mit mobilen Accounts, manche nicht. Bei uns kommt alles von 10.14 bis 11.0 zum Einsatz. Aktuell mit einer AD auf einem Windows Server 2019. Vor kurzem war es noch ein Server 2012 R2 Domaincontroller. Alles ohne Probleme.
Es scheint also kein generelles Problem mit neueren MAcOS Versionen zu sein. Ich vermute hier sind eure AD-Admins gefragt.
+2
Jan-Henrik12.07.2115:20
Es freut mich dass es kein generelles Problem ist. Es gibt also noch Hoffnung. Aber in welche Richtung sollte die Problemsuche losgehen? Unsere AD-Admins sind immer sehr mürrisch, wenn es um Apple-Probleme geht. Man muss ihnen immer den Weg weisen.
0
caMpi
caMpi12.07.2115:45
Welche Windowsversion läuft auf den Domain Controllern? Auf welchem Functional-Level ist euer AD?
Gleiche Fragen gelten für den/die Fileserver, auf denen das Benutzerverzeichnis abgelegt werden soll. Wie wird das Benutzerverzeichnis definiert? Im Benutzer-Objekt selbst? Sind alle User betroffen, oder neue oder nur bestehende?
0
Zikade
Zikade13.07.2108:51
Was sagen denn die Logs?
Schibulski
Ich würde dir gerne weiterhelfen mit einer Lösung, kann dir aber nur den Hinweis geben, dass sich unsere Macs auch alle gegen das AD authentifizieren, manche mit mobilen Accounts, manche nicht
Wenn ich das richtig verstanden habe geht es hier aber um einen reinen Netzwerk Benutzer, dessen Heimatverzeichnis in den dunklen Untiefen von AD versteckt ist. Also nicht um den mobilen Account (den ich endlich überall entferne genau wie die Bindung an AD, Juchhe. Aber das tut nichts zur Sache ) oder einen lokalen Account. Oder liege ich da falsch?
0
Jan-Henrik13.07.2109:33
Unsere AD-Admins sagen: Die Domänenfunktionsebene ist 2012 R2.

Es geht um reine Netzwerkbenutzer und die Fehlfunktion betrifft alle, also alte und neue Benutzer. Sie können sich unter Windows 10 anmelden und auf den Macs bis Mac OS X 10.13. Dabei wird auf das gleiche Heimatverzeichnis zugegriffen, welches im Benutzerobjekt definiert ist. Man kann das im Verzeichniseditor wunderbar sehen.

Für Windows steht dort für den Testbenutzer "troester":
SMBHome:
\\fh-h.de\HsH\HomeFolder\Stud\troester
Für Mac:
HomeDirectory
<home_dir><url>smb://fh-h.de/HsH/HomeFolder/Stud/troester</url><path>/</path></home_dir>
und NFSHomeDirectory
/home/troester

Das sieht für mich richtig aus und funktioniert unter den älteren OS Versionen ja auch. Aber letztendlich habe ich keinen tieferen Zugriff aufs AD. Die AD-Admins sind da sehr restriktiv.
Einblick in ein Log auf dem Mac bekommt man nicht, weil er sich ja nicht anmeldet und nur den rotierenden Ball zeigt.
0
Jan-Henrik13.07.2109:39
Habe gerade noch diese ergänzende Info bekommen:

PS C:\Windows\system32> Get-SmbServerConfiguration

AnnounceComment :
AnnounceServer : False
AsynchronousCredits : 512
AuditSmb1Access : False
AutoDisconnectTimeout : 15
AutoShareServer : True
AutoShareWorkstation : True
CachedOpenLimit : 10
DurableHandleV2TimeoutInSeconds : 180
EnableAuthenticateUserSharing : False
EnableDownlevelTimewarp : False
EnableForcedLogoff : True
EnableLeasing : True
EnableMultiChannel : True
EnableOplocks : True
EnableSecuritySignature : False
EnableSMB1Protocol : True
EnableSMB2Protocol : True
EnableStrictNameChecking : True
EncryptData : False
IrpStackSize : 15
KeepAliveTime : 2
MaxChannelPerSession : 32
MaxMpxCount : 50
MaxSessionPerConnection : 16384
MaxThreadsPerQueue : 20
MaxWorkItems : 1
NullSessionPipes :
NullSessionShares :
OplockBreakWait : 35
PendingClientTimeoutInSeconds : 120
RejectUnencryptedAccess : True
RequireSecuritySignature : False
ServerHidden : True
Smb2CreditsMax : 8192
Smb2CreditsMin : 512
SmbServerNameHardeningLevel : 0
TreatHostAsStableStorage : False
ValidateAliasNotCircular : True
ValidateShareScope : True
ValidateShareScopeNotAliased : True
ValidateTargetName : True

PS C:\Windows\system32> (Get-WmiObject -class Win32_OperatingSystem).Caption
Microsoft Windows Server 2016 Datacenter
0
sunni13.07.2110:17
Verstehe ich es richtig, dass sich der HomeFolder des Users nur auf dem Server und nicht lokal befindet?
0
Jan-Henrik13.07.2110:22
Genau so ist es.
Das hat den Vorteil, dass sich die Benutzer an jeden beliebigen Rechner setzen können, immer ihre persönliche Umgebung bekommen und keine Daten auf den Rechnern hinterlassen.
0
sunni13.07.2110:29
Ich denke du kannst dich von diesem Vorhaben verabschieden. Die Technologie ist alt und unzuverlässig. Wie du geschrieben hast, funktioniert es seit ein paar Systemversionen nicht mehr zuverlässig.
Ich habe bis 2018 mit mobilen Accounts mit Sync gearbeitet. Nachdem das auch nicht mehr zuverlässig lief, sind wir nach und nach von diesem Sync abgerückt und haben dem Anwender lediglich seinen HomeFolder auf dem Schreibtisch anzeigen lassen.

Ich schlage vor, du prüft die Einführung eines MDM, zB. Jamf Pro oder Jamf Now. Damit kannst du den AD-Server per Konfigurations Profil setzen und damit auch sagen, dass ein lokaler HomeFolder angelegt wird. Dem HomeFolder kann man auch ein Ablaufdatum mitgeben, zB. Löschen nach 14 Tagen.
0
Jan-Henrik13.07.2110:53
Warum soll ich mich von einer Technologie verabschieden, die an anderer Stelle funktioniert?
"Schibulski" hat ganz oben bestätigt, dass es geht. Leider meldet er sich nicht mehr dazu. Wir haben es hier nicht mit einer Handvoll von Benutzern zu tun, sondern mit mehreren Hundert, die durch mehrere Gebäude vagabundieren (Hochschule). Und die sollen jetzt ihre persönlichen Daten auf zig Rechnern verstreuen?
Nach meinen Informationen wird die AD-Anmeldung mit HomeDir-Mount in amerikanischen Hochschulen nach wie vor praktiziert. Nur habe ich da keinen Kontakt und der Support von Apple-Deutschland gibt sich ahnungslos.

Unter Windows ist es völlig normal so zu arbeiten.

Mobile Accounts haben wir niemals genutzt, weil hier niemand seinen eigenen persönlichen Rechner benutzt. Bestimmte Software-Produkte sind einfach zu teuer, um sie jedem nach Hause zu geben.
Mobile Accounts gelten auch schon eine Weile als "deprecated" und werden unter Big Sur nicht mehr unterstützt. Dieser Angelegenheit weine ich keine Träne nach.

Ein MDM ist grundsätzlich keine schlechte Sache, aber nach meiner Meinung für diesen Fall einfach Overkill und würde die Arbeitsweise der Benutzer grundlegend ändern.

Ich suche einfach nach Hinweisen, wo ich den Hebel ansetzen kann, um den Bremsklotz im AD finden zu können.
+1
sunni13.07.2110:56
Jan-Henrik
Ich suche einfach nach Hinweisen, wo ich den Hebel ansetzen kann, um den Bremsklotz im AD finden zu können.

Das ist ja genau der Punkt. Es ist nicht die AD. Es ist macOS.
-2
logo13.07.2111:16
Kann es sein, dass es an der SMB Version liegt? Ganz vage Vermutung...

Da steht nur SMBv2. Ich weiß, dass es mit den neuen macOS-Versionen Probleme mit SMB gibt (vgl. Fritz!Boxen). Und du hast da ein altes Windows Server 2012 R2.
Falls es das sein könnte, gibt es hier eine Möglichkeit die SMB-Versionen zu beeinflussen.
0
Jan-Henrik13.07.2112:04
@sunni: Wenn es denn so sein sollte, wo steht das? Ich habe bisher keine Veröffentlichung gefunden, in der bestätigt wird, dass die AD-Anmeldung mit HomeDir Mount nicht mehr unterstützt wird.
0
caMpi
caMpi13.07.2112:21
Ich war mal faul und habe nicht alles in diesem Link von Apple durchgelesen, aber deine Admins sollten das tun (https://support.apple.com/de-de/guide/directory-utility/diru39a25fa2/6.0/mac/11.0)
Das sind die Voraussetzungen für den AD-Join.
Functional Level ist schonmal erfüllt.
Der Fileserver läuft anscheinend unter Win 2016, somit kann er SMBv3. Das wird nicht explizit ausgewiesen.
Ihr solltet SMB1 abschalten, Emotet lässt grüßen. Es gibt keinen Grund, im Jahr 2021 SMB1 aktiviert zu lassen.
Ihr könntet für einen Testuser den Pfad zu den Homedirs auf einen frischen Win2019-Server (oder noch besser ein SMB-Share eines NAS) lenken, um SMB & Co. auszuschließen.
+1
caMpi
caMpi13.07.2112:49
Jan-Henrik
Wir haben es hier nicht mit einer Handvoll von Benutzern zu tun, sondern mit mehreren Hundert, …
An welcher Hochschule muss ich anheuern, damit ich mich als AD-Admin in so einer Situation raushalten darf?
In welcher Position bist du? Mac-Admin?
Jan-Henrik
Ein MDM ist grundsätzlich keine schlechte Sache, aber nach meiner Meinung für diesen Fall einfach Overkill und würde die Arbeitsweise der Benutzer grundlegend ändern.
Da sprechen wir uns in 1-2 Jahren nochmal. Der Trend, egal ob macOS, iOS und je nach Anwendungsfall auch Windows, geht nämlich genau dahin.
+1
Jan-Henrik13.07.2113:17
Danke caMpi. Du hast mit dem Link gezeigt, dass diese Art der Anmeldung von Apple nach wie vor unterstützt wird und nicht veraltet oder unzuverlässig ist.

Zur Situation: Der Leiter der zentralen IT an dieser Institution ist bekennender Mac-Hasser. "Wir unterstützen ausschliesslich Windows-Systeme, weil unsere Personaldecke für alles andere zu dünn ist." Anwender anderer Systeme sind somit auf sich selbst gestellt. Wenn also ein Mac-Anwender einen Fehler berichtet, kann das schon mal gar nicht sein. In 9 von 10 Fällen stellt sich zwar heraus, dass es das Problem tatsächlich gibt und es von grundsätzlicher Natur ist. Aber das sind immer Einzelfälle.
Ich betreue nur die Macs einer kleinen Untereinheit.
0
Zikade
Zikade13.07.2114:56
Jan-Henrik
Der Leiter der zentralen IT an dieser Institution ist bekennender Mac-Hasser. "Wir unterstützen ausschliesslich Windows-Systeme, weil unsere Personaldecke für alles andere zu dünn ist."
Huh, auf der Leiter fehlen ein paar Stufen. Solche Leute kenne ich auch.

Eine Möglichkeit ist die Macs auf SMB2 zu zwingen mit einem Eintrag in /etc/nsmb.conf:
[default]
signing_required=no
protocol_vers_map=2

Was die Logs angeht: wenn du dich über Screen Sharing mit einem lokalen Admin-Account anmeldest und dann mit einem Netzwerkbenutzer anmeldest, solltest du die logs einsehen können.
+1
Zikade
Zikade13.07.2115:27
Eins hatte ich vergessen - wenn du auf den Macs mit Mojave oder Catalina zufällig die Security Updates 2021-003 Catalina und 2021-004 Mojave installiert hast - die Dinger ruinieren derzeit die Anmeldung über Kerberos. Einen Workaround — ohne Gewähr — findest du hier:
+1

Kommentieren

Sie müssen sich einloggen, um sich an einer Diskussion beteiligen zu können.