Probleme mit Cups-Login - Adminaccount funktioniert nicht
Guten Morgen an alle!
Seit ein paar Tagen habe ich das Problem das mein Adminlogin für Cups nichts mehr angenommen wird.
Jedesmal wenn ich versuch auf die Verwaltung im Webinterface zu gehen und die Passwortabfrage kommt passiert nach Eingabe nichts weiter als das ich die Logindaten neu eingeben muss. Aufgetaucht ist das Problem als ich wie üblich das Passwort, wie in der Richtlinie verlangt, geändert hatte. Auch ein ändern auf den ursprünglichen Wert hat nichts weiter gebracht. Zusätzlich funktionieren alle anderen Logins der Domain Admins ebenfalls nicht.
Die error_log sagt mir zu dem Fehler dieses:
Der Fehler ist an sich ganz klar zu erkennen. Es wird kein Username übergeben. Mein Problem hierbei ist das ich nichts aktuelles zu dem Fehler via Google gefunden habe. Da soll das Problem von einer veralteten Kerberosversion kommen die irgendwann 2011 aktuell war. Wie ich momentan vermute ist es die aktuellste Krb5-Version, wobei sich da aber das Problem stellt das ich diese nicht genau ermitteln kann.
Das System was ich hier einsetze ist ein Zentyalserver Communityedition in der Version 3.3.7 mit aktuellen Patches. Als Unterbau nutzt der Server Ubuntu 12.04 LTS. Derzeit bin ich mit meinem Latein am Ende und vielleicht kann mir hier jemand helfen.
Für alle Ideen, Vorschläge und Lösung möchte ich mich schon einmal im voraus bedanken.
Bis dann
liquid
@edit:
Nachdem ich das
rausgenommen habe geht die Verwaltung der Drucker wieder. Eine doch sehr unschöne Lösung, da nun jeder (wenn er das möchte) darauf zugreifen kann. War leider nötig, da mehrere Jobs abgebrochen werden mussten ... Murphys Law halt :/
Problem ist an sich immer noch vorhanden.
Seit ein paar Tagen habe ich das Problem das mein Adminlogin für Cups nichts mehr angenommen wird.
Jedesmal wenn ich versuch auf die Verwaltung im Webinterface zu gehen und die Passwortabfrage kommt passiert nach Eingabe nichts weiter als das ich die Logindaten neu eingeben muss. Aufgetaucht ist das Problem als ich wie üblich das Passwort, wie in der Richtlinie verlangt, geändert hatte. Auch ein ändern auf den ursprünglichen Wert hat nichts weiter gebracht. Zusätzlich funktionieren alle anderen Logins der Domain Admins ebenfalls nicht.
Die error_log sagt mir zu dem Fehler dieses:
D [31/Mar/2014:08:44:30 +0200] Connection from 192.168.2.10 now encrypted.
D [31/Mar/2014:08:44:30 +0200] cupsdReadClient: 16 GET /admin HTTP/1.1
D [31/Mar/2014:08:44:30 +0200] cupsdSetBusyState: newbusy="Active clients", busy="Not busy"
D [31/Mar/2014:08:44:30 +0200] cupsdAuthorize: Error accepting GSSAPI security context: An unsupported mechanism was requested, Unknown error
D [31/Mar/2014:08:44:30 +0200] cupsdIsAuthorized: username=""
D [31/Mar/2014:08:44:30 +0200] cupsdSendHeader: 16 WWW-Authenticate: Negotiate
D [31/Mar/2014:08:44:30 +0200] cupsdCloseClient: 16
D [31/Mar/2014:08:44:30 +0200] SSL shutdown successful!
D [31/Mar/2014:08:44:30 +0200] cupsdSetBusyState: newbusy="Not busy", busy="Active clients"
D [31/Mar/2014:08:44:30 +0200] cupsdReadClient: 16 WAITING Closing on EOF
D [31/Mar/2014:08:44:30 +0200] cupsdCloseClient: 16
D [31/Mar/2014:08:44:30 +0200] cupsdSetBusyState: newbusy="Not busy", busy="Not busy" Der Fehler ist an sich ganz klar zu erkennen. Es wird kein Username übergeben. Mein Problem hierbei ist das ich nichts aktuelles zu dem Fehler via Google gefunden habe. Da soll das Problem von einer veralteten Kerberosversion kommen die irgendwann 2011 aktuell war. Wie ich momentan vermute ist es die aktuellste Krb5-Version, wobei sich da aber das Problem stellt das ich diese nicht genau ermitteln kann.
Das System was ich hier einsetze ist ein Zentyalserver Communityedition in der Version 3.3.7 mit aktuellen Patches. Als Unterbau nutzt der Server Ubuntu 12.04 LTS. Derzeit bin ich mit meinem Latein am Ende und vielleicht kann mir hier jemand helfen.
Für alle Ideen, Vorschläge und Lösung möchte ich mich schon einmal im voraus bedanken.
Bis dann
liquid
@edit:
Nachdem ich das
Require group lpadminProblem ist an sich immer noch vorhanden.
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 234066
Url: https://administrator.de/forum/probleme-mit-cups-login-adminaccount-funktioniert-nicht-234066.html
Ausgedruckt am: 02.05.2025 um 06:05 Uhr
3 Kommentare
Neuester Kommentar
Hast du mit sudo nano /etc/cups/cupsd.conf mal die Konfig Datei überprüft in Zeile 17 ob dort Listen localhost:631 in Listen *:631 geändert wurde ?
Die Abschnitte <Location /...> bestimmen die Zugriffsrechte für die einzelnen Bereiche der Weboberfläche.
Du musst vor </Location> in den Zeilen 36, 42 und 50 jeweils eine Zeile mit dem Inhalt Allow @local setzen, um den Zugriff aus dem lokalen Netz zu erlauben. Wenn du Änderungen gemacht hast mit sudo /etc/init.d/cups restart CUPS neu starten.
Jetzt kann zwar jeder im lokalen Netzwerk zugreifen, wer Einstellungen verändern will, muss sich aber authentisieren (erkennbar an Zeile 47: Require user @system). Der Benutzer muss in der Gruppe der Drucker-Admins (lpadmin) sein. Das Kommando sudo usermod -a -G lpadmin willi fügt z.B. den User willi dieser Gruppe zu.
Bei Aufruf von //https://<IP-Adresse>:631 von einem Rechner im Netzwerk startet die CUPS Oberfläche. Als Usernamen gelten die die im Unix definiert sind.
Die Abschnitte <Location /...> bestimmen die Zugriffsrechte für die einzelnen Bereiche der Weboberfläche.
Du musst vor </Location> in den Zeilen 36, 42 und 50 jeweils eine Zeile mit dem Inhalt Allow @local setzen, um den Zugriff aus dem lokalen Netz zu erlauben. Wenn du Änderungen gemacht hast mit sudo /etc/init.d/cups restart CUPS neu starten.
Jetzt kann zwar jeder im lokalen Netzwerk zugreifen, wer Einstellungen verändern will, muss sich aber authentisieren (erkennbar an Zeile 47: Require user @system). Der Benutzer muss in der Gruppe der Drucker-Admins (lpadmin) sein. Das Kommando sudo usermod -a -G lpadmin willi fügt z.B. den User willi dieser Gruppe zu.
Bei Aufruf von //https://<IP-Adresse>:631 von einem Rechner im Netzwerk startet die CUPS Oberfläche. Als Usernamen gelten die die im Unix definiert sind.
Danke schon einmal für den Input aqui.
Deine Vorschläge habe ich erstmal soweit übernommen und der entsprechende Useraccount von meinem Domain Admin befand sich bereits in der Gruppe vom lpadmin. Problem dabei ist jetzt, das die Änderung so nichts gebracht haben. Problem bleibt bestehen. Daher habe ich auch erstmal die cupsd.conf von einem Backup zurückgespielt und nur das
auf
geändert.
Hier ist die cupsd.conf im Original:
Das ändern der letzten 3 Zeilen sollte man eigentlich nicht machen, da man sich wohl damit den kompletten Druckservice abschießt und der Zentyalserver dann aus den Templates wieder eine neue cupsd.conf erstellt. Vielleicht siehst du noch etwas in der cupsd.conf.
Deine Vorschläge habe ich erstmal soweit übernommen und der entsprechende Useraccount von meinem Domain Admin befand sich bereits in der Gruppe vom lpadmin. Problem dabei ist jetzt, das die Änderung so nichts gebracht haben. Problem bleibt bestehen. Daher habe ich auch erstmal die cupsd.conf von einem Backup zurückgespielt und nur das
Listen localhost:631Listen *:631Hier ist die cupsd.conf im Original:
LogLevel debug
SystemGroup lpadmin
Browsing Off
BrowseOrder allow,deny
BrowseAllow all
BrowseAddress @LOCAL
DefaultAuthType Negotiate
<Location />
Order allow,deny
Allow from all
</Location>
<Location /admin>
Encryption Required
Require group lpadmin
Order allow,deny
Allow from all
</Location>
<Location /admin/conf>
AuthType Basic
Require group lpadmin
Order allow,deny
Allow from all
</Location>
<Location /printers>
Order allow,deny
Allow from all
</Location>
<Location /jobs>
Order allow,deny
Allow from all
</Location>
<Policy default>
<Limit Send-Document Send-URI Hold-Job Release-Job Restart-Job Purge-Jobs Set-Job-Attributes Create-Job-Subscription Renew-Subscription Cancel-Subscription Get-Notifications Reprocess-Job Cancel-Current-Job Suspend-Current-Job Resume-Job CUPS-Move-Job>
Require user @OWNER
Require group lpadmin
Order deny,allow
Satisfy any
</Limit>
<Limit CUPS-Add-Modify-Printer CUPS-Delete-Printer CUPS-Add-Modify-Class CUPS-Delete-Class CUPS-Set-Default>
AuthType Basic
Require group lpadmin
Order deny,allow
Satisfy any
</Limit>
<Limit Pause-Printer Resume-Printer Enable-Printer Disable-Printer Pause-Printer-After-Current-Job Hold-New-Jobs Release-Held-New-Jobs Deactivate-Printer Activate-Printer Restart-Printer Shutdown-Printer Startup-Printer Promote-Job Schedule-Job-After CUPS-Accept-Jobs CUPS-Reject-Jobs>
AuthType Basic
Require group lpadmin
Order deny,allow
</Limit>
<Limit Cancel-Job CUPS-Authenticate-Job>
Require user @OWNER
Require group lpadmin
Order deny,allow
Satisfy any
</Limit>
<Limit All>
Order deny,allow
</Limit>
</Policy>
# Added by Zentyal, don't modify or add more Listen/SSLListen statements
Listen *:631
Listen /var/run/cups/cups.sock
SSLListen 192.168.2.100:631Das ändern der letzten 3 Zeilen sollte man eigentlich nicht machen, da man sich wohl damit den kompletten Druckservice abschießt und der Zentyalserver dann aus den Templates wieder eine neue cupsd.conf erstellt. Vielleicht siehst du noch etwas in der cupsd.conf.
Mit dem Update 3.4 des Servers hat sich das Problem im Luft aufgelöst. Da eine neue Version von Cups mit eingespielt wurde und eine neue Version von Ubuntu, wurden auch einige der conf-files neu angelegt. Damit hatte sich dann auch das Problem gelöst.
Danke Aqui für deinen Input
Danke Aqui für deinen Input
