Falsche SambaSID bei neuem Benutzer nach Upgrade auf Samba 4

Hallo,

wir haben auf unseren UCS gemäß [wiki]Migration_from_Samba_3_to_Samba_4[/wiki] unter Berücksichtigung von [wiki]Best_Practice_Samba_4_Migration[/wiki] das Inplace-Upgrade von Samba3 auf Samba4 vorgenommen.

Nach dem Upgrade schien auch alles wie gewünscht zu funktionieren. Die Authentifizierung bestehender Benutzer per LDAP an externen Diensten (Wiki, Freigaben, etc.) klappte auch klaglos.

Nun haben wir aber folgendes Problem bei der Anlage neuer Benutzer:
Die sambaSID wird auf S-1-4- gesetzt anstelle S-1-5-21-<domain_id>-. Wenn diese manuell angepasst wird, wird diese auch synchronisiert und die Benutzer können sich dann an den externen Services anmelden.

Wir wären für jeden Hinweis, der zur Problemlösung beiträgt, dankbar.

Mit freundlichen Grüßen

Falk Koziol

Hallo,

bei der Inplace-Migration wird, zumindeśt nach Querlesen des Wiki-Artikels das SID-Mapping nicht angepasst.

Es wäre trotzdem zunächst mal sinnvoll, die entsprechenden UCR-Variablen zu prüfen (hier die Standardwerte von einer frischen Installation:

# ucr search --brief sid connector/s4/mapping/sid/sid_to_ucs: <empty> connector/s4/mapping/sid: true connector/s4/mapping/sid_to_s4: <empty> listener/module/wellknownsidnamemapping: <empty>

Viele Grüße,
Dirk Ahrnke

Hallo,

bitte entschuldigen Sie die späte Antwort. Die Mail-Benachrichtigung über ihren Post hat sich im Spam-Ordner versteckt.

So sieht das Ergebnis bei mir aus:

# ucr search --brief sid connector/s4/mapping/sid/sid_to_ucs: <empty> connector/s4/mapping/sid: true connector/s4/mapping/sid_to_s4: true listener/module/wellknownsidnamemapping: <empty>

Hallo,

ist nachvollziehbar, warum

connector/s4/mapping/sid_to_s4: true

gesetzt ist?

Das sieht für mich nach einer möglichen Quelle aus.
[bug]26055[/bug] hat ein paar Details zum Hintergrund…

Viele Grüße,
Dirk Ahrnke

Gab es hierzu eine Lösung? Wir stehen vor genau dem gleichen Problem, das User mit S-1-4 angelegt werden statt mit S-1-5-21…
Jeglicher neue User kann sich nicht an der Domäne anmelden, “alte” schon noch. Das Mapping ist wie gepostet gesetzt. Wir nutzen noch ein UCS 4.4-9.

Wir haben das verify-idmap-database/verify_idmap_database.pl · master · LINET Services / univention-tools · GitLab Skript drüberlaufen lassen, einen defekten Eintrag neu angelegt und gaaanz wichtig den Server selbst einmal neugestartet mit touch /forcefsck das er die Platte einmal druchcheckt.

Mastodon