0
winbind versus krb5
Wie kann ich Cups dazu bringen, dass es sich mit den jeweiligen AD Credentials am Windows Printserver authentifziert und nicht mit einem vorgegebenen Username:Passwort
Hallo,
Ich arbeite seit einiger Zeit an der Umsetzung einer Art Linux-"Terminalserver" in einer Windows Domäne.
Weitgehend ist auch alles umgesetzt, doch seitdem ich versuche Cups einzurichten, steigt meine Verwirrung ins Unermessliche.
Doch immer schön der Reihe nach.
Was ich habe:
- Windows 2003 Domäne im gemischten Modus
- 3x Debian Lenny auf dem neuesten Stand; jeder Server ist Memberserver der Domäne
- 1 Lenny ist der Masterserver, auf dem mit xr load balancing zur Verfügung gestellt wird.
- 2 Lennys sind die Backends von xr, auf denen x2go läuft (es könnte aber ohne großen Aufwand auch VNC, rdp, freenx, oder sonstiges bereitverwendet )
- Auf dem Masterserver werden per NFSv4 die Homeverzeichnisse zur Verfügung gestellt.
- Die Anmeldung mit AD Credentials funktioniert einwandfrei. Der Masterserver leitet die Verbindung weiter auf einen Backendserver. Bei der Erstanmeldung wird automatisch aus /etc/skel ein Homeverzeichnis generiert.
- Desktop Environment ist lxde
Was noch fehlt:
- Cups soll so konfiguriert werden, dass Druckaufträge auf den Windows Printserver (Win 2003) weitergeleitet werden.
- Da es sehr viele User sind, sollten gleich die AD Credentials verwendet werden, um sich gegenüber dem WinPrintserver zu authentifizieren. Ein fest vorgegebener Druckaccount kann nicht verwendet werden, da sonst die einzelnen Jobs nicht
mehr den Usern zuzuordnen sind.
Was mich verwirrt:
- Ich weiß nicht, wie die korrekte AD Gruppenbezeichnung in der cups.conf ist. Muss ich mit Winbind seperator + @he+"Domain Users", oder @"HE+Domain Users", oder @he+Domain Users, oder gar "@HE+Domain Users" verwenden.
Ich kann also gar nicht sagen, ob es nicht an sowas scheitert.
- Die größe Konfusion ergibt sich aber in Zusammenhang mit DefaultAuthType Negotiate. Prinzipiell wird cups dadurch ja kerberisiert. Das bedeutet, er sollte auf die AD Credentials zugreifen können. Wenn ich das einstelle, dann kann ich allerdings keine Drucker mehr hinzufügen, bzw. löschen, obwohl ich einen AD User in der cupsd.conf dafür berechtigt habe.
Bei genauerer Betrachtung ist mir dann aufgefallen, dass ich bei der Anmeldung am Backend zwar die AD Credentials verwenden kann und die Anmeldung auch einwandfrei funktioniert, ich aber kein Kerberos Ticket bekomme.
klist zeigt mir einen leeren Ticketcache. Ich kann mir mit kinit zwar ein Ticket holen, aber anscheinend wird das für nichts verwendet.
Auch wenn ich auf der Konsole mit root arbeite, dann kann ich mir mit getent passwd sämtliche User anzeigen lassen. Und den Account root gibt es in der AD nicht.
Wie ist das dann, wenn 10 Leute auf dem Server arbeiten? Kriegt dann jeder ein Ticket, brauchen sie das überhaupt und warum kann root die Domäne abfragen?
- krb5 versus winbind
In der PAM Konfiguration steht bei mir derzeit alles auf winbind. Allerdings steht in manchen Anleitungen winbind und in anderen krb5. Wenn ich alles auf krb5 umstelle, dann kann ich gleich die Rescue CD rausholen, um überhaupt wieder aufs System zu kommen.
Ich vermute allerdings, dass cups auf krb5 angewiesen ist (kerberisiertes Cups). Nur wie soll das ohne Ticket funktionieren?
Wie kann überhaupt winbind ohne Ticket funktionieren?
Je mehr ich darüber nachdenke, desto unklarer wird mir, warum die Anmeldung mit AD Credentials überhaupt funktioniert. Oder hat das was mit der 2003 Domäne im gemischten Modus zu tun?
Aber auch wenn ich das nie verstehe, die Hauptfrage ist, wie ich Cups dazu bringen kann, dass es die AD Credentials des druckenden Users nimmt und sich damit gegen den Windows Printserver für diesen Job zu authentifizieren (SSO). Am Schluß will ich die Windows Printqueue öffnen und den Job dann eindeutig anhand der AD User ID zuordnen können.
Geht das überhaupt unter Linux? Auf einem Mac scheint das ja zu funktionieren.
Unten stehen die wesentlichen Konfigdateien.
Jede Hilfe ist mehr als willkommen und ich will mich gleich im Voraus dafür bedanken.
Hallo,
Ich arbeite seit einiger Zeit an der Umsetzung einer Art Linux-"Terminalserver" in einer Windows Domäne.
Weitgehend ist auch alles umgesetzt, doch seitdem ich versuche Cups einzurichten, steigt meine Verwirrung ins Unermessliche.
Doch immer schön der Reihe nach.
Was ich habe:
- Windows 2003 Domäne im gemischten Modus
- 3x Debian Lenny auf dem neuesten Stand; jeder Server ist Memberserver der Domäne
- 1 Lenny ist der Masterserver, auf dem mit xr load balancing zur Verfügung gestellt wird.
- 2 Lennys sind die Backends von xr, auf denen x2go läuft (es könnte aber ohne großen Aufwand auch VNC, rdp, freenx, oder sonstiges bereitverwendet )
- Auf dem Masterserver werden per NFSv4 die Homeverzeichnisse zur Verfügung gestellt.
- Die Anmeldung mit AD Credentials funktioniert einwandfrei. Der Masterserver leitet die Verbindung weiter auf einen Backendserver. Bei der Erstanmeldung wird automatisch aus /etc/skel ein Homeverzeichnis generiert.
- Desktop Environment ist lxde
Was noch fehlt:
- Cups soll so konfiguriert werden, dass Druckaufträge auf den Windows Printserver (Win 2003) weitergeleitet werden.
- Da es sehr viele User sind, sollten gleich die AD Credentials verwendet werden, um sich gegenüber dem WinPrintserver zu authentifizieren. Ein fest vorgegebener Druckaccount kann nicht verwendet werden, da sonst die einzelnen Jobs nicht
mehr den Usern zuzuordnen sind.
Was mich verwirrt:
- Ich weiß nicht, wie die korrekte AD Gruppenbezeichnung in der cups.conf ist. Muss ich mit Winbind seperator + @he+"Domain Users", oder @"HE+Domain Users", oder @he+Domain Users, oder gar "@HE+Domain Users" verwenden.
Ich kann also gar nicht sagen, ob es nicht an sowas scheitert.
- Die größe Konfusion ergibt sich aber in Zusammenhang mit DefaultAuthType Negotiate. Prinzipiell wird cups dadurch ja kerberisiert. Das bedeutet, er sollte auf die AD Credentials zugreifen können. Wenn ich das einstelle, dann kann ich allerdings keine Drucker mehr hinzufügen, bzw. löschen, obwohl ich einen AD User in der cupsd.conf dafür berechtigt habe.
Bei genauerer Betrachtung ist mir dann aufgefallen, dass ich bei der Anmeldung am Backend zwar die AD Credentials verwenden kann und die Anmeldung auch einwandfrei funktioniert, ich aber kein Kerberos Ticket bekomme.
klist zeigt mir einen leeren Ticketcache. Ich kann mir mit kinit zwar ein Ticket holen, aber anscheinend wird das für nichts verwendet.
Auch wenn ich auf der Konsole mit root arbeite, dann kann ich mir mit getent passwd sämtliche User anzeigen lassen. Und den Account root gibt es in der AD nicht.
Wie ist das dann, wenn 10 Leute auf dem Server arbeiten? Kriegt dann jeder ein Ticket, brauchen sie das überhaupt und warum kann root die Domäne abfragen?
- krb5 versus winbind
In der PAM Konfiguration steht bei mir derzeit alles auf winbind. Allerdings steht in manchen Anleitungen winbind und in anderen krb5. Wenn ich alles auf krb5 umstelle, dann kann ich gleich die Rescue CD rausholen, um überhaupt wieder aufs System zu kommen.
Ich vermute allerdings, dass cups auf krb5 angewiesen ist (kerberisiertes Cups). Nur wie soll das ohne Ticket funktionieren?
Wie kann überhaupt winbind ohne Ticket funktionieren?
Je mehr ich darüber nachdenke, desto unklarer wird mir, warum die Anmeldung mit AD Credentials überhaupt funktioniert. Oder hat das was mit der 2003 Domäne im gemischten Modus zu tun?
Aber auch wenn ich das nie verstehe, die Hauptfrage ist, wie ich Cups dazu bringen kann, dass es die AD Credentials des druckenden Users nimmt und sich damit gegen den Windows Printserver für diesen Job zu authentifizieren (SSO). Am Schluß will ich die Windows Printqueue öffnen und den Job dann eindeutig anhand der AD User ID zuordnen können.
Geht das überhaupt unter Linux? Auf einem Mac scheint das ja zu funktionieren.
Unten stehen die wesentlichen Konfigdateien.
Jede Hilfe ist mehr als willkommen und ich will mich gleich im Voraus dafür bedanken.
# /etc/cups/cupsd.conf (815 ist ein AD User)
LogLevel info
# Administrator user group...
SystemGroup lpadmin "domain users"
# Only listen for connections from the local machine.
Listen localhost:631
Listen /var/run/cups/cups.sock
# Show shared printers on the local network.
Browsing On
BrowseOrder allow,deny
BrowseAllow all
# Default authentication type, when authentication is required...
DefaultAuthType Negotiate
# Restrict access to the server...
<Location />
Order allow,deny
</Location>
# Restrict access to the admin pages...
<Location /admin>
Order allow,deny
</Location>
# Restrict access to configuration files...
<Location /admin/conf>
AuthType Default
Require user @SYSTEM @"domain users"
Order allow,deny
</Location>
# Set the default printer/job policies...
<Policy default>
# Job-related operations must be done by the owner or an administrator...
<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 @SYSTEM
Order deny,allow
</Limit>
# All administration operations require an administrator to authenticate...
<Limit CUPS-Add-Modify-Printer CUPS-Delete-Printer CUPS-Add-Modify-Class CUPS-Delete-Class CUPS-Set-Default>
AuthType Default
Require user @SYSTEM 815
Order deny,allow
</Limit>
# All printer operations require a printer operator to authenticate...
<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 Default
Require user @SYSTEM 815
Order deny,allow
</Limit>
# Only the owner or an administrator can cancel or authenticate a job...
<Limit Cancel-Job CUPS-Authenticate-Job>
Require user @OWNER @SYSTEM
Order deny,allow
</Limit>
<Limit All>
Order deny,allow
</Limit>
</Policy>#/etc/krb5.conf
[libdefaults]
default_realm = EH.INT
# The following krb5.conf variables are only for MIT Kerberos.
krb4_config = /etc/krb.conf
krb4_realms = /etc/krb.realms
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true
[realms]
EH.INT = {
kdc = seh0131.eh.int
admin_server = seh0131.eh.int
}
[domain_realm]
.eh.int = EH.INT
[login]
krb4_convert = true
krb4_get_tickets = false
[appdefaults]
pam = {
ticket_lifetime = 1d
renew_lifetime = 1d
forwardable = true
proxiable = false
retain_after_close = false
minimum_uid = 0
debug = false
}#/etc/samba/smb.conf
[global]
workgroup = EH
realm = EH.INT
netbios name = x2gomember2
security = ADS
idmap uid = 10000-20000
idmap gid = 10000-20000
template sehll = /bin/bash
winbind use default domain = yes
password server = 172.16.1.31
printing = cups
cups options = raw
winbind refresh tickets = yes
printing = cups
printcap = cups
cups options = raw
winbind enum users = yes
winbind enum groups = yes#/etc/nsswitch.conf
passwd: compat winbind
group: compat winbind
shadow: compat
hosts: files dns
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis#/etc/pam.d/common-account
account sufficient pam_winbind.so
account required pam_unix.so#/etc/pam.d/common-auth
auth sufficient pam_winbind.so
auth required pam_unix.so nullok_secure use_first_pass#/etc/pam.d/common-session
session required pam_mkhomedir.so skel=/etc/skel/ umask=0022
session sufficient pam_winbind.so
session required pam_unix.so#/etc/pam.d/common-password
password required pam_unix.so nullok obscure md5
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 118474
Url: https://administrator.de/contentid/118474
Ausgedruckt am: 26.11.2024 um 10:11 Uhr
