OPSI mag nicht authentifizieren

german
opsi

#1

Hallo, hallo!

Heute wollte ich mal OPSI auf unserem UCS einrichten, um unseren Prä-UCS-Server so langsam zu entlasten. Jetzt kann ich mich aber nicht mit dem OPSI-Configed authentifizieren. Gruppenzugehörigkeit zu opsiadmin und opsifileadmins ist gegeben. Melde ich mich an, läuft folgendes im Log auf:

Aug 23 16:07:02 kappa python[32480]: pam_krb5(opsi-auth:auth): user maal authenticated as maal@WIKIMEDIA.DE
Aug 23 16:07:02 kappa unix_chkpwd[5815]: could not obtain user info (maal)
Aug 23 16:07:02 kappa slapd[26705]: conn=3913 fd=22 ACCEPT from IP=172.16.66.4:33362 (IP=0.0.0.0:7389)
Aug 23 16:07:02 kappa slapd[26705]: conn=3913 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Aug 23 16:07:02 kappa slapd[26705]: conn=3913 op=0 STARTTLS
Aug 23 16:07:02 kappa slapd[26705]: conn=3913 op=0 RESULT oid= err=0 text=
Aug 23 16:07:02 kappa slapd[26705]: conn=3913 fd=22 TLS established tls_ssf=256 ssf=256
Aug 23 16:07:02 kappa slapd[26705]: conn=3913 op=1 BIND dn="" method=128
Aug 23 16:07:02 kappa slapd[26705]: conn=3913 op=1 RESULT tag=97 err=0 text=
Aug 23 16:07:02 kappa slapd[26705]: conn=3913 op=2 SRCH base="dc=wikimedia,dc=de" scope=2 deref=0 filter="(uid=maal)"
Aug 23 16:07:02 kappa slapd[26705]: OVER: rs->sr_err != LDAP_SUCCESS on "dc=wikimedia,dc=de" ERR: 0x32
Aug 23 16:07:02 kappa slapd[26705]: conn=3913 op=2 SEARCH RESULT tag=101 err=50 nentries=0 text=
Aug 23 16:07:02 kappa python[32480]: pam_ldap: ldap_search_s Insufficient access
Aug 23 16:07:02 kappa slapd[26705]: conn=3913 op=3 UNBIND
Aug 23 16:07:02 kappa slapd[26705]: conn=3913 fd=22 closed
Aug 23 16:07:04 kappa slapd[26705]: conn=1920 op=868 SRCH base="cn=wikimedia.de,cn=dhcp,dc=wikimedia,dc=de" scope=2 deref=0 filter="(&(|(objectClass=dhcpHost)(objectClass=univentionDhcpHost))(dhcpHWAddress=ethernet 52:54:00:56:14:9b))"
Aug 23 16:07:04 kappa slapd[26705]: conn=1920 op=868 SEARCH RESULT tag=101 err=0 nentries=0 text=

Interessant ist die Zeile mit dem Bind. OPSI scheint zwar PAM zu benutzen, aber /etc/pam.d/opsi-auth scheint irgendetwas anders zu machen, obwohl dort nichts Auffälliges zu sehen ist …

Log bei Loginversuch mit opsi-cofiged:

Aug 23 16:52:26 kappa python: pam_krb5(opsi-auth:auth): user maal authenticated as maal@WIKIMEDIA.DE
Aug 23 16:52:26 kappa unix_chkpwd[11660]: could not obtain user info (maal)

Log bei Login mit ssh:

Aug 23 16:52:55 kappa sshd[11694]: Accepted publickey for maal from 172.16.66.209 port 47554 ssh2: RSA d0:52:12:5d:39:84:4d:e1:68:13:7d:45:ca:9b:64:4e
Aug 23 16:52:55 kappa sshd[11694]: pam_unix(sshd:session): session opened for user maal by (uid=0)

Log bei Login über UCS-Webinterface:

Aug 23 16:57:44 kappa python2.7: nss_ldap: reconnecting to LDAP server...
Aug 23 16:57:44 kappa python2.7: nss_ldap: reconnected to LDAP server ldap://kappa.wikimedia.de:7389 after 1 attempt
Aug 23 16:57:44 kappa python2.7: pam_unix(univention-management-console:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=  user=maal
Aug 23 16:57:44 kappa python2.7: pam_krb5(univention-management-console:auth): user maal authenticated as maal@WIKIMEDIA.DE

Log von opsiconfd, Loglevel 7

[7] [Aug 23 16:52:25] Now using log-file '/var/log/opsi/opsiconfd/172.16.66.209.log' for object 0x7fcbc6b57b90 (Logger.py|489)
[6] [Aug 23 16:52:25] Failed to read opsi modules file '/etc/opsi/modules': [Errno 2] No such file or directory: u'/etc/opsi/modules' (Backend.py|444)
[6] [Aug 23 16:52:25] Worker <opsiconfd.workers.WorkerOpsiconfdJsonRpc instance at 0x7fcbc6b57b90> started processing (Worker.py|250)
[5] [Aug 23 16:52:25] Application 'opsi config editor 4.0.7.6.34' on client '172.16.66.209' did not send cookie (workers.py|185)
[7] [Aug 23 16:52:25] Trying to get username and password from Authorization header (workers.py|105)
[7] [Aug 23 16:52:25] Authorization header found (type: basic) (workers.py|109)
[5] [Aug 23 16:52:25] New session created (session.py|77)
[7] [Aug 23 16:52:25] Trying to get username and password from Authorization header (workers.py|105)
[7] [Aug 23 16:52:25] Authorization header found (type: basic) (workers.py|109)
[5] [Aug 23 16:52:25] Authorization request from maal@172.16.66.209 (application: opsi config editor 4.0.7.6.34) (workers.py|217)
[6] [Aug 23 16:52:25] Connection from admin network (workers.py|259)
[7] [Aug 23 16:52:25] Trying to authenticate by operating system... (BackendManager.py|595)
[7] [Aug 23 16:52:25] PAM conversation: query 'login:', type 2 (BackendManager.py|727)
[7] [Aug 23 16:52:25] PAM conversation: query 'Password: ', type 1 (BackendManager.py|727)
[6] [Aug 23 16:52:26] Traceback: (Logger.py|798)
[6] [Aug 23 16:52:26]   File "/usr/lib/python2.7/dist-packages/opsiconfd/workers.py", line 269, in _authenticate
    forceGroups=forceGroups
 (Logger.py|798)
[6] [Aug 23 16:52:26]   File "/usr/lib/python2.7/dist-packages/OPSI/Backend/BackendManager.py", line 600, in __init__
    raise BackendAuthenticationError(forceUnicode(e))
 (Logger.py|798)
[6] [Aug 23 16:52:26]      ==>>> Backend authentication error: Backend authentication error: PAM authentication failed for user 'maal': ('Authentication failure', 7) (workers.py|290)
[7] [Aug 23 16:52:26] Freeing session <OpsiconfdSession(<opsiconfd.session.OpsiconfdSessionHandler object at 0x7fcbbc05f450>, name=u'OPSISID', sessionMaxInactiveInterval=120> (Worker.py|318)
[6] [Aug 23 16:52:26] Session timer <_Timer(Thread-4, stopped 140513008875264)> canceled (Session.py|128)
[5] [Aug 23 16:52:26] Session '3LqspShmXzLhApAe885IlGMmNQNoqXuA' from ip '172.16.66.209', application 'opsi config editor 4.0.7.6.34' deleted (Session.py|234)
[7] [Aug 23 16:52:26] Freeing session <OpsiconfdSession(<opsiconfd.session.OpsiconfdSessionHandler object at 0x7fcbbc05f450>, name=u'OPSISID', sessionMaxInactiveInterval=120> (Worker.py|318)
[7] [Aug 23 16:52:26] <opsiconfd.workers.WorkerOpsiconfdJsonRpc instance at 0x7fcbc6b57b90>._setCookie (Worker.py|434)
[2] [Aug 23 16:52:26] Traceback: (Logger.py|798)
[2] [Aug 23 16:52:26]   File "/usr/lib/python2.7/dist-packages/OPSI/Service/Worker.py", line 291, in _errback
    failure.raiseException()
 (Logger.py|798)
[2] [Aug 23 16:52:26]   File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 577, in _runCallbacks
    current.result = callback(current.result, *args, **kw)
 (Logger.py|798)
[2] [Aug 23 16:52:26]   File "/usr/lib/python2.7/dist-packages/opsiconfd/workers.py", line 293, in _authenticate
    raise OpsiAuthenticationError(u"Forbidden: %s" % error)
 (Logger.py|798)
[2] [Aug 23 16:52:26]      ==>>> Opsi authentication error: Forbidden: Backend authentication error: Backend authentication error: PAM authentication failed for user 'maal': ('Authentication failure', 7) (Worker.py|293)

Irgendwelche Ratschläge?

Besten Gruß aus Berlin-Kreuzberg
Masin Al-Dujaili


#2

Weil es so lustig ist: Ich habe meine Recherche im OPSI-Forum nochmal ausgebreitet. Da kann mir anscheinend auch niemand helfen, aber mittlerweile kann ich sagen, dass es sich wohl um ein Rechteproblem handelt. Führe ich opsiconfd als root aus, kann ich mich anmelden. Ein strace zeigt, dass sich beim Zugriff auf /etc/libnss-ldap.conf der Ausführungspfad gegenüber einer Ausführung als opsiconfd unterschiedlich entwickelt. Die Berechtigungen der Datei sehen aber normal aus (0440, messagebus:root).

Ich würde ja sagen, mit einer einfachen Mitgliedschaft des Kontos opsiconfd in irgendeiner Gruppe ist es da nicht getan.


#3

Hallo,

Das ist ja … spannend. Ich könnte mal auf einem Referenzsystem nachschauen, wie sich das da verhält. Ich vermute mal, das UCS System ist eine UCS Master? Wurde opsi über das App Center oder händisch über die Repositories des openSuse Build Service installiert? Und die UCS und opsi Versionen wären auch noch gut zu wissen :slight_smile:

Beste Grüße,
Michael Grandjean


#4

Ist der Nutzer opsiconfd in der lokalen Gruppe shadow? Poste mal die Ausgabe von

id opsiconfd

#5

UCS-Master, ja.

Die Installation erfolgte

  1. aus dem Appcenter und funktionierte nicht (hier beschriebenes Problem),
  2. dann via univention-install opsi4ucs auf der Kommandozeile, was auch nicht klappte (opsi4ucsappcenter konnte nicht installiert werden, weil es opsi4ucs benötigt, was aber nicht installiert war (Problem mit dem Skript, was ich hier irgendwo erwähnt habe)),
  3. wieder aus dem Appcenter via univention-appcenter install opsi, weil: was soll’s? Wenn ich schon eine dysfunktionale Installation habe, dann die aus dem Appcenter. Ernsthaft: Ich wollte sichergehen, dass die Installation sauber durchläuft und hoffte, dass es dann funktioniert. Aber auch hier gab es Probleme mit dem Installationsskript, weil in /var/univention/join-status noch “opsi4ucs v44 successful” drinsteht, obwohl die App deinstalliert war.
root@kappa:~# lsb_release -a
No LSB modules are available.
Distributor ID:	Univention
Description:	Univention Corporate Server 4.2-3 errata313 (Lesum)
Release:	4.2-3 errata313
Codename:	Lesum
root@kappa:~# dpkg -l | grep opsi
rc  opsi-atftpd                                         0.7.dfsg-9                                     amd64        advanced TFTP server - opsi version with pcre, fifo and max-blksize patches
ii  opsi-configed                                       4.0.7.6.34-2                                   all          OPSI config editor
ii  opsi-linux-bootimage                                20180713-1                                     all          opsi bootimage for netboot tasks.
ii  opsi-tftpd-hpa                                      5.2.8-47                                       amd64        HPA's tftp server
ii  opsi-utils                                          4.1.1.17-2                                     all          utilites for working with opsi.
ii  opsi-windows-support                                4.1.1-5                                        all          Install utilities useful for deploying Windows with opsi.
ii  opsi4ucs                                            4.1.1.5-1                                      all          opsi software deployment for ucs
ii  opsi4ucsappcenter                                   4.1.1.8                                        all          Installing opsi through the UCS App Center.
ii  opsiconfd                                           4.1.1.10-4                                     all          opsi configuration service
ii  opsipxeconfd                                        4.1.1.8-2                                      all          opsi pxe configuration daemon
ii  python-opsi                                         4.1.1.29-1                                     all          opsi python library

Es kann natürlich sein, dass es ein Problem darstellt, dass der UCS seit Inbetriebnahme gewachsen ist. IIRC hatten wir ihn als 4.1 installiert, würde dafür aber jetzt nicht meine Hand ins Feuer legen.

root@kappa:~# id opsiconfd
uid=2244(opsiconfd) gid=5114(opsifileadmins) Gruppen=5114(opsifileadmins),42(shadow),5115(opsiadmin)

#6

Aus irgendeinem Grund waren Dateien in /etc/pam.d/ verändert. Dank Damrose’s Antwort konnte ich mittels ucr commit /etc/pam.d/*die Dateien neu generieren. Damit funktioniert die Authentifizierung dann.