UCS 4.3 Samba 4.7 - Probleme beim Authentizieren (war: Änderungen bei NTLM?)

UCS - Univention Corporate Server
,
#1

Hallo zusammen,

wir haben einen UCS als DC laufen, gegen den auch der Berichtsserver (SSRS) eines MS-SQL Servers authentiziert, der auf einem W2012-Server in der Domäne läuft.

Seit dem Update auf 4.3 ist nun ein Anmelden am Berichtsserver nicht mehr möglich. Es wird das Loginfenster gezeigt, nach Eingabe von Usernamen und Passwort verschwindet das Fenster, um nach ca. 2 Minuten völlig ungerührt wieder zu erscheinen. Die Authentizierung scheint nicht zu funktionieren.

Kann es sein, dass eine Authentizierung über NTLM nicht mehr möglich ist oder erst konfiguriert werden muss ?

Die Inbetriebnahme des SSRS unter 4.2 war völlig easy. Es funktionierte alles bis zum Update auf 4.3.

Jemand eine Idee ?

Danke & Gruß

Martin

No RDP connection to domain computers
MSSQL Server access fails to authenticate using kerberos after 4.3 upgrade
#2

Noch etwas:

Bei der Nutzung von Microsoft Remote Desktop vom Mac aus habe ich festgestellt, dass der Bildschirm nach dem Update auf UCS 4.3 deutlich länger (ca. 15 Sekunden) auf der Anzeige “Negotiating Credentials” verharrt, bevor es weitergeht. Das ging mit UCS 4.2 gefühlt viermal so schnell. Ich denke, das gehört zum obigen Problem.

Hat niemand eine Idee, wo man ansetzen könnte ?

Gruß - Martin

#3

Huhu,

was sagt denn die UCR-Variable samba/ntlm/auth bei Ihnen?

Gruß,
mosu

#4

Hallo ,

Bin von dem gleichen Problem betroffen.
Bei mir ist die Variable leer!

Peter

#5

Bei mir ist die Variable auch leer. In /etc/samba/smb.conf steht

ntlm auth       = yes

Testparm zeigt:

ntlm auth = ntlmv1-permitted

Das sieht ja eigentlich richtig aus.

Martin

#6

Hallo,

bei mir ist das auch bei 3 unterschiedlichen Installationen der Fall das das Login an den Windows Rechnern wesentlich länger dauert als vor dem Update auf 4.3

Ich habe festgestellt das die GRP Policies nicht mehr angewannt werden - scheint ein Access Problem zu (File Rechte, User SID ?) zu sein - konnte aber noch nicht tiefer testen - muss das am WE genauer analysieren

gibt es bei gpresult /h hier auch Fehler bei Ihnen ?

lg
Christian

#7

Hallo Christian,

Ich kann das bestätigen. Dauert bei mir auch länger.
Vor allem nach dem drücken von ctrl+alt+del kommt erst einmal ein schwarzer Schirm für mindestens 15 Sekunden.
Habe auch im Systemprotokoll einen roten Fehler. Ist er bei dir auch vorhanden? (Nach Neustart)
Allerdings werden bei mir die GPO’s gezogen. Keine Fehler in gpresult /h.
Ich überlege ernsthaft einen neuen Backup DC aufzusetzen und diesen dann hochzustufen.
Kann natürlich sein das die Probleme trotzdem noch da sind.

Peter

#8

I think i’m having the same issue… anyone was able to find a solution?

One related issue i detect i that i can’t access a shared folder via ipaddress only by server name…

Thanks

#9

Ich habe den Threadtitel geändert, denn ob das Ganze an NTLM hängt, vermag ich gar nicht zu sagen.

Kann uns jemand von den Experten sagen, welche Tests wir ggf. vornehmen können, um dem Problem auf die Spur zu kommen ?

Vorab danke in die Runde, ich schätze sehr, dass man sich die Zeit nimmt, Admins mit weniger Durchblick wie mir auf die Sprünge zu helfen - Martin

#10

Hallo,

Auf einem frisch installierten System tritt das Problem nicht auf.
Hier muss irgendetwas bei der Migration schief gelaufen sein.
Es wäre wirklich sehr hilfreich wenn sich ein Entwickler bitte mal zu dem Thema äußern könnte.

Vielen Dank
Peter

#11

@pixelpeter what is the value in the new install of samba/ntlm/auth

#12

@pixelpeter: Vielleicht einmal testparm aufrufen und die relevanten Teile (Global) posten. Dann könnten wir uns die Unterschiede ansehen.

Danke - Martin

#13

Hallo Martin,

Mache ich morgen gleich als erstes.
Noch ein Nachtrag:
Ich habe daraufhin einen neuen Backup DC aufgesetzt und diesen dann zum Master gemacht. Leider ohne Erfolg. Gleiches Problem.
Ich musste jetzt feststellen das innerhalb des AD auch die Zugriffe auf Shares nicht funktioniert.

Peter

#14

@mschlee
Ich habe ein diff von testparm -v gemacht.
Bis auf die Domainspezifischen Parameter wie Realm usw.
Ist es 100% identisch.

@codedmind
the value samba/ntlm/auth is Empty.

Bin kurz davor das AD neu aufzusetzen.

Was mich ehrlich etwas stört ist die Tatsache das doch etliche User mit diesen Problemen vorhanden sind und es keinerlei Reaktion von den Entwicklern gibt. Auch wenn es keine zahlenden User sind, wäre wenigstens eine Reaktion nicht ganz so verkehrt.
Da es ja kein Enterpriserepository gibt gehe ich davon aus das Enterprisekunden auch betroffen sein müssen.
Mein System ist schon mal von 4.1 auf .4.2 hochgezogen worden.
Ist das bei Euch auch so gewesen.

Peter

#15

My version is from 4.0… then 4.1, 4.2 and, and now 4.3

#16

Ich bin seit 4.1-0 dabei und habe das PostgreSQL Update gemacht.

#17

Still ruht der See - :neutral_face:

#18

Was mir auffällt das es mir nicht gelingt den Loglevel von Samba zu erhöhen.
Man kann zwar debug level als Systemvariable ändern, das wird auch in die smb.conf übernommen, testparm kennt aber kein “debug level”, nur “log level”.
Händisch diese Variable auf 5 zu setzen zieht nicht. testparms gibt weiterhin log level = 2 aus.

Peter

#19

Huhu,

testparm zeigt den Wert in der Tat nicht an. Das ist aber kein Problem, denn es funktioniert mit der Variable samba/debug/level sehr wohl. Die Option debug level in der smb.conf wird als Synonym für log level genommen.

Eine Änderung wird erst nach Neustart des Samba-Daemons aktiv.

Bei einem laufenden Samba-Daemon kann man übrigens on-the-fly das Loglevel abfragen und verändern.

Hier ein komplettes Beispiel:

# Anfangs ist Loglevel normal auf 1:
[0 root@master ~] ucr get samba/debug/level
1
[0 root@master ~] smbcontrol smbd debuglevel
PID 10569: all:1 tdb:1 printdrivers:1 lanman:1 smb:1 rpc_parse:1 rpc_srv:1 rpc_cli:1 passdb:1 sam:1 auth:1 winbind:1 vfs:1 idmap:1 quota:1 acls:1 locking:1 msdfs:1 dmapi:1 registry:1 scavenger:1 dns:1 ldb:1 tevent:1 auth_audit:1 auth_json_audit:1 kerberos:1 drs_repl:1

# Dauerhaft auf 5 hochsetzen:
[0 root@master ~] ucr set samba/debug/level=5
Setting samba/debug/level
Module: kopano-cfg
Multifile: /etc/samba/smb.conf
[0 root@master ~] systemctl restart samba-ad-dc.service

# Sicherstellen, dass das auch gegriffen hat:
[0 root@master ~] smbcontrol smbd debuglevel
PID 10777: all:5 tdb:5 printdrivers:5 lanman:5 smb:5 rpc_parse:5 rpc_srv:5 rpc_cli:5 passdb:5 sam:5 auth:5 winbind:5 vfs:5 idmap:5 quota:5 acls:5 locking:5 msdfs:5 dmapi:5 registry:5 scavenger:5 dns:5 ldb:5 tevent:5 auth_audit:5 auth_json_audit:5 kerberos:5 drs_repl:5

# On-the-fly für den laufenden Daemon auf 3 heruntersetzen:
[1 root@master ~] smbcontrol smbd debug 3
[0 root@master ~] smbcontrol smbd debuglevel
PID 10777: all:3 tdb:3 printdrivers:3 lanman:3 smb:3 rpc_parse:3 rpc_srv:3 rpc_cli:3 passdb:3 sam:3 auth:3 winbind:3 vfs:3 idmap:3 quota:3 acls:3 locking:3 msdfs:3 dmapi:3 registry:3 scavenger:3 dns:3 ldb:3 tevent:3 auth_audit:3 auth_json_audit:3 kerberos:3 drs_repl:3

# Ist nach einem Restart wieder auf konfiguriertem Wert von oben:
[0 root@master ~] systemctl restart samba-ad-dc.service
[0 root@master ~] smbcontrol smbd debuglevel
PID 10986: all:5 tdb:5 printdrivers:5 lanman:5 smb:5 rpc_parse:5 rpc_srv:5 rpc_cli:5 passdb:5 sam:5 auth:5 winbind:5 vfs:5 idmap:5 quota:5 acls:5 locking:5 msdfs:5 dmapi:5 registry:5 scavenger:5 dns:5 ldb:5 tevent:5 auth_audit:5 auth_json_audit:5 kerberos:5 drs_repl:5

Gruß
mosu

#20

Hallo Moritz,

Danke, funktioniert.

Peter

Mastodon