Automount Windows-Freigaben auf Ubuntu 18.04 mithilfe eines Kerberos-Tickets

833
Nicolas

Ich habe jetzt seit ein paar Tagen damit zu kämpfen. Ich versuche, eine Ubuntu 18.04-Workstation in ein Netzwerk zu integrieren, das hauptsächlich aus Windows besteht. Die Authentifizierung erfolgt über Active Directory auf einem Server, auf dem Windows Server 2012 ausgeführt wird. Ich konnte der Domäne ohne allzu viele Probleme beitreten. Als nächstes möchte ich automatisch eine Windows-Freigabe für den Linux-Benutzer bereitstellen. Ich habe es funktioniert, indem ich diese Zeile zu /etc/auto.master hinzugefügt habe:

/mnt/cifs /etc/auto.cifs --timeout=60 --ghost 

und dies in /etc/auto.cifs:

NameOfTheShare -fstype=cifs,uid=$UID,gid=100,username=&,credentials=$HOME/.smbcredentials ://ServerName/NameOfTheShare 

Nun, ich bin nicht zufrieden mit der Idee, Benutzerpasswörter in Klartext in einer Datei zu haben. Außerdem habe ich irgendwo gelesen, dass es möglich war, mit dem Kerberos-Ticket eine CIFS-Freigabe bereitzustellen. Also habe ich versucht, dies in auto.cifs zu setzen:

NameOfTheShare -fstype=cifs,sec=krb5,username=&,domain=mydomain.local,multiuser,cruid=$ ://ServerName/NameOfTheShare 

(Dies ist eine Datei, die unter CentOS 7 problemlos funktioniert).

Da es nicht funktionierte, entschied ich mich, Spuren von Automount-Fehlern zu suchen. Anscheinend ist die einzige Möglichkeit, dies zu erreichen, den Autofs-Dienst zu stoppen und im Vordergrund mit der ausführlichen Option "Automount" auszuführen:

$ sudo service autofs stop $ sudo automount -f -v 

Nun, wenn ich cdin /mnt/cifs/NameOfTheSharewird der Anteil erwartungsgemäß montiert (so kann ich nichts debuggen!)

Wenn ich automount töte, die Freigabe manuell freigebe und autofs.service erneut starte, kommt das anfängliche Problem zurück: /mnt/cifs/NameOfTheShareKann nicht gemountet werden.

Was ist der Unterschied zwischen der Ausführung des autofs-Dienstes und dem manuellen Starten von automount, was erklären kann, dass die erste Methode fehlschlägt, wenn die zweite erfolgreich ist?

Zusatzfrage: Gibt es nicht irgendwo ein Fehlerprotokoll des autofs-Dienstes? Ich konnte keine finden. Selbst journalctl liefert keine wertvollen Informationen.

Bearbeiten:

Hier ist die Ausgabe von klist:

Ticket cache: FILE:/tmp/krb5cc_1072801131_l33ZzG Default principal: MyLogin@MYDOMAIN.LOCAL  Valid starting Expires Service principal 31/08/2018 15:11:10 01/09/2018 01:11:10 krbtgt/MYDOMAIN.LOCAL@MYDOMAIN.LOCAL renew until 01/09/2018 15:11:10 

Edit 2:

Ich habe mehr Informationen zum Automount-Fehler gefunden. Syslog zeigt diese Nachricht:

No credentials cache found (filename: /tmp/krb5cc_1072801131_igAxKm) 

Doch klistjetzt gibt mir:

Ticket cache: FILE:/tmp/krb5cc_1072801131_zgYtQf 

Es sieht so aus, als würde automount nach dem falschen Dateinamen der Anmeldeinformationen suchen. Das Problem ist, ich habe keine Ahnung, wie ich das beheben kann.

2
Enthält Ihre auto.cifs-Datei den wörtlichen Text `uid = $ UID`,` cruid = $ `usw. oder enthält sie tatsächliche Zahlen als Wert? grawity vor 6 Jahren 0
@grawity Ja, es enthält den wörtlichen Text `uid = $ UID` und` cruid = $ `. Nicolas vor 6 Jahren 0
Welchen Kerberos-Cache-Typ für Berechtigungsnachweise verwenden Sie gemäß "klist"? (DATEI, DIR, KEYRING usw.)? grawity vor 6 Jahren 0
@ grawity: Ich habe meine Frage bearbeitet, um sie zu beantworten Nicolas vor 6 Jahren 0

0 Antworten auf die Frage