User-Passwörter migrieren Samba 3 -> UCS 4/Samba 4

german

#1

Liebe Univention-Community,

erstmal hallo an alle! Ich prüfe derzeit eine mögliche Umstellung der Domäne unseres Instituts von Samba3/smbldap auf UCS 4 mit Samba 4. Wichtig wäre mir dabei eine möglichst automatisierte Migration der User inklusive bestehender Passwörter.

Die Migration der User sollte mit diesem Skript kein Problem sein. Für die Passwörter habe ich diese Anleitung gefunden, welche zwar für UCS 3 mit Samba 3 ist aber - zumindest teilweise - zu funktionieren scheint. Nur teilweise deswegen, weil nach den angegebenen Schritten zwar die Authentifizierung per Kerberos funktioniert (z.B. zum Web-Interface oder an Windows-Rechnern), nicht jedoch per LDAP (getestet mit ownCloud). Woran liegt das und wie kann ich es beheben? Eine “Notlösung” dafür ist, wenn der User im Web-Interface das Passwort ändert, dann funktioniert alles normal. Ich würde aber bevorzugen dass Passwörter nicht zwingend geändert werden müssen.

Noch ein interessantes Detail: Die Anleitung oben funktioniert NUR wenn VOR dem Ausführen der angegebenen Schritte der “userPassword”-Eintrag des Users auf “e0s1S0VZfQ==” (also “{K5KEY}”) gesetzt ist. Leuchtet mir auch nicht ein, warum das so ist, ist aber eher ein sekundäres Problem.

Vielen Dank schon mal für eure Hilfe!

  • David C.

Migration bestehender Kerberos Datenbank nach UCS
Passwort Import - Details?
#2

Moin,

sowohl das von Ihnen verlinkte Script als auch die Anleitung vergeben neue LDAP-Passwörter, übernehmen dann nachträglich die NT-Hashes und Kerberos-Einstellungen. Die Passwortinformationen für alle drei Systeme (POSIX/Linux, NT, Kerberos) werden nämlich im LDAP in getrennten Attributen verwaltet, u.a. weil die Hashingmechanismen andere sind und man natürlich keine Klartextpasswörter speichert. Daher klappt bei Ihnen auch die Anmeldung an manchen Diensten, nicht aber an allen, konkreter: nicht an denjenigen, die einen simple bind gegen das LDAP machen – und das sind, ganz grob gesprochen, alle, die nicht Windows-Authentifizierung oder von Univention stammen machen. Also Dinge wie Roundcube, Zarafa, Nicht-Univention-Linux-Clients etc.

Eine potenzielle Möglichkeit zur Übernahme besteht eventuell darin, selber ein Script zu schreiben, dass die gehashten Passwortattribute aus dem alten LDAP ausliest, eine LDIF-Datei erzeugt, die die im neuen LDAP entsprechend ändert. Diese Attribute dürfen allerdings nur dann gelesen werden, wenn man sich am LDAP mit einem entsprechend berechtigten User anmeldet; bei Nicht-UCS-LDAPs war das früher immer primär der User, der in der Konfiguration des LDAP-Servers mittels »rootdn« angegeben war. UCS-Seitig gibt’s hier den User cn=admin,dc=$basedn mit dem Passwort, das auf dem UCS-Domaincontroller Master in /etc/ldap.secrets steht.


#3

Tatsächlich, das hat funktioniert. Vielen Dank!

Ich war erst skeptisch, da der alte LDAP ein anderes Hashing-Verfahren (SSHA) nutzt als UCS (crypt). Aber trotzdem, wenn ich das gehashte “userPassword” vom alten LDAP ins neue übertrage, funktionieren auf Anhieb alle Authentifizierungsverfahren mit dem alten Passwort.

LG, David C


#4

Liebe Univention-Community,

ich melde mich nochmal, da ich mich beim letzten Post ein wenig zu früh gefreut habe. Weitere Tests haben gezeigt, dass meine damalige Lösung leider doch nicht funktioniert hat, bzw. nur manchmal. Und ich konnte lange Zeit nicht wirklich erkennen, was ausschlaggebend dafür war, dass es funktioniert. Offensichtlich hatte ich die Logik hinter der Passwortverwaltung noch ganz und gar nicht verstanden.

Inzwischen allerdings habe ich es schon sehr viel besser verstanden und eine sehr gute Lösung gefunden.

Die Grundlage dieser Lösung ist wieder die schon erwähnte Anleitung. Diese ist ja eigentlich für UCS 3. Ich nahm an, dass das kein Problem sein sollte und aufgrund der teilweisen Erfolge schien das auch zu stimmen. Es ist jedoch ein Problem, nämlich folgendes: Das Skript /usr/share/univention-heimdal/kerberos_now welches in der Anleitung vorkommt, erstellt Kerberos-Keys für die User. Jedoch nur für jene, deren LDAP-Eintrag weder die objectClass “krb5Principal” noch die objectClass “krb5KDCEntry” haben, welche also noch keine Kerberos-Attribute besitzen (eigentlich eh logisch). Und da ja in UCS 4 Kerberos fest integriert ist, hat natürlich jeder neu angelegte User die Kerberos-Einträge. Die naheliegende Lösung war also, vor dem Ausführen des Skripts alle Kerberos-Attribute zu löschen.

Damit funktioniert der Userimport inklusive Passwörter problemlos. Hier nochmal die Schritte zusammengefasst:

  1. User mit dem bereits erwähnten Skript importieren.
  2. Alle Kerberos-Attribute und Objektklassen des LDAP-Eintrags des neuen Users entfernen
  3. Das Attribut “userPassword” des LDAP-Eintrags auf “{K5KEY}” setzen.
  4. Das Attribut “sambaNTPassword” auf den Wert aus dem alten LDAP setzen.
  5. Das Skript /usr/share/univention-heimdal/kerberos_now ausführen.

Danach ist der User mit dem alten Passwort angelegt und alle Authentifizierungsmöglichkeiten funktionieren.

LG, David C.


#5

Hallo,
ein paar Fragen/ Ergänzungen von mir…

[quote=“davidc”]

  1. User mit dem bereits erwähnten Skript importieren.[/quote]
    Ich gehe davon aus, dass ein “normaler” Import via CSV-Dateien via WebGUI hier das Gleiche tut, richtig?

Das sind bei UCS 4 konkret die folgenden, oder?

krb5PrincipalName krb5MaxLife krb5Key (mehrfach) krb5MaxRenew krb5KeyVersionNumber krb5KDCFlags
Dummerweise gehören die User aber zu “objectClass: krb5Principal” und “objectClass: krb5KDCEntry”. Da verbietet mir ldapmodify das Löschen der diesbezüglichen Attribute. Ich muß also zuerst diesen Eintrag der objectClass loswerden. Bloss: WIE?
Aktuell kann ich einzelne Attribute wie folgt löschen. Zuerst die Kommandozeile:

 ldapmodify  -D "cn=admin,$(ucr get ldap/base)" -w "$(cat /etc/ldap.secret)" <mod

Und dann die Datei “mod”:

[code]dn: uid=testte,cn=users,dc=evs-nb,dc=de
changetype: modify
delete: krb5KDCFlags

delete: krb5KeyVersionNumber[/code]

Wie kann ich jetzt die objectClass loswerden? Beispiele aus dem Netz haben mir nicht wirklich geholfen…
Und nein, das will ich nicht via WebGUI machen, da es für ca. 500 Benutzer sein soll!

Und wenn wir schon dabei sind, wie mache ich die nächsten Schritte?

3. Das Attribut "userPassword" des LDAP-Eintrags auf "{K5KEY}" setzen. 4. Das Attribut "sambaNTPassword" auf den Wert aus dem alten LDAP setzen.
Wie lautet der Eintrag in der “mod” Datei? “modify:”?

5. Das Skript /usr/share/univention-heimdal/kerberos_now ausführen.

Das kriege ich gerade noch so hin :wink:

Danke!

Christian


#6

Hallo an alle,

hier jetzt die detaillierte Lösung für den Import von Benutzern mit vorhandenen Passwörtern (aus einem anderen LDAP o.ä.). Die bisherigen Postings hier brachten den grundsätzlichen Weg, ich habe einen Tag gebraucht, um alles im Detail hinzufummeln ;D

Das erschien mir reichlich umständlich, zumal unsere Nutzer noch keine wichtigen Informationen im bisherigen LDAP gespeichert hatten. Ich habe also über Shell Skripte und slapcat (bei gestopptem LDAP) die benötigten Informationen (Vorname, Nachname,Benutzername,Email,Passwort) ausgelesen und in eine CSV Datei gepackt. Die sieht so aus:

Jeannette,Meyer,meyer,j.meyer@domain.de,FD57B41217F811A9403ADC37E9FAE6

Das Skript dazu schreibe ich jetzt hier nicht hin, das hängt ja davon ab, was in dem alten LDAP alles gespeichert ist und wie. Das sollte man schon mit einigen Tools (grep, cut, sed, awk) problemlos hinktregen.
Danach über das Web-GUI des UCS die Benutzer via CSV importieren (geht das nur bei UCS@school?).

Das war das Schwierige. Die Attribute zu löschen war ok, allerdings hatte ich große Problem, die beiden Kerberos Objektklassen zu löschen. Bis ich auf den Trichter kam, dass ich den Eintrag einfach modifizieren kann und halt nur noch die objectClass aufführe, die eben nicht Kerberos relevant sind. Und die Syntax der LDIF Dateien für ldapmodify ist nun wirklich nicht besonders gut dokumentiert. Wie auch immer, hier ist die LDIF-Datei:[code]changetype: modify
replace: objectClass
objectClass: top
objectClass: person
objectClass: univentionPWHistory
objectClass: posixAccount
objectClass: shadowAccount
objectClass: univentionMail
objectClass: sambaSamAccount
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: univentionObject

delete: krb5Key

delete: krb5MaxLife

delete: krb5PrincipalName

delete: krb5MaxRenew

delete: krb5KeyVersionNumber

delete: krb5KDCFlags

replace: userPassword
userPassword: {K5KEY}

replace: sambaNTPassword[/code]

[quote]3. Das Attribut “userPassword” des LDAP-Eintrags auf “{K5KEY}” setzen.
4. Das Attribut “sambaNTPassword” auf den Wert aus dem alten LDAP setzen.[/quote]
Das ist mit den letzten Zeilen des obigen LDIFs auch erledigt.
Jetzt fehlt nur noch der letzte Schritt und anschließend alles so zusammenbringen, dass es automatisiert funktioniert.

Alles zusammenpacken:
Skript, das die CSV-Dateien ausliest (importuserpwd.sh):[code]
#!/bin/bash

Aufrufparameter die CSV-Datei! (ist $1)

rm -rf ucs_mod.ldif

for i in cat $1; do # liest zeilenweise ein
# liest das gehashte Passwort und den Benutzernamen aus
PWD=echo $i| cut -d "," -f 5
USR=echo $i| cut -d "," -f 3
# schreibt die jeweilige Zeile, damit ldapmodify weiss, welchen Benutzer es bearbeiten soll
echo “dn: uid=$USR,cn=users,dc=evs-nb,dc=de” >> ucs_mod.ldif
# ergänzt den Benutzereintrag um die auszuführenden Befehle
cat mod >> ucs_mod.ldif
# schreibt zum Schluß noch das gehashte Passwort in den Eintrag- wichtig sind die Leerzeilen hier!
echo "sambaNTPassword: $PWD

">> ucs_mod.ldif
done

führt ldapmodify mit dem Befehlen aus der gerade erstellten Datei aus

ldapmodify -D “cn=admin,$(ucr get ldap/base)” -w “$(cat /etc/ldap.secret)” <ucs_mod.ldif

zu guter Letzt wird hierdurch allen Benutzern wieder der (umständlich entfernte) Kerberos-Krams dazugepackt.

/usr/share/univention-heimdal/kerberos_now[/code]
Die Datei “mod” ist die obige LDIF-Datei.

Insgesamt eine ganz schöne Fummelei, aber es hat sich gelohnt- jetzt kann ich das System umstellen um meine Nutzer merken das nicht einmal :wink:
Das ist ja fast schon Zauberei- den Teppich unter den Füßen wegziehen und gleichzeitig einen neuen drunter packen, ohne dass sie es merken ;D

Grüße

Christian


#7

Hi,

dummerweise kann man CSV Dateien nur bei UCS@school importieren. Das haben wir zwar lizensiert, nutzen es aber nicht. Also mußte ich die Benutzer über Kommandozeile hinzufügen.
Über das ürsprüngliche Script ist mir das nicht gelungen, da ich keine Ahnung von Python habe.

Habe dann über diesen Thread herausgefunden, dass es auch ohne Python geht.

Dazu habe ich jetzt in Ergänzung zu obigem noch für den 1. Punkt ein Shell Skript gebastelt, das ich gleich hier noch anfüge. Jetzt sind meine Nutzer angelegt und alle sind (hoffentlich !) glücklich:

#!/bin/bash
# Filename create_users.sh
# $1 = csv Datei zum Einlesen
# Vorname,Name,Benutzername,Emailadresse,Passwort

BASEDN="dc=domain,dc=de"
POS="cn=users,$BASEDN"
USRUID=2999
for i in `cat $1|sort  -t "," -k3`; do
        PWD=`echo $i| cut -d "," -f 5`
        USR=`echo $i| cut -d "," -f 3`
        VNAME=`echo $i| cut -d "," -f 1`
        NNAME=`echo $i| cut -d "," -f 2`
        EMAIL=`echo $i| cut -d "," -f 4`
        USRUID=$[$USRUID+1]
#echo "Attempt to  create USR $USR with USRUID $USRUID"
univention-directory-manager users/user create --position $POS \
  --set username="$USR" \
  --set primaryGroup="cn=GRUPPENNAME,cn=groups,dc=domain,dc=de"\
  --set uidNumber=$USRUID \
  --set password="BEISPIEL"\
  --set firstname="$VNAME" --set lastname="$NNAME"\
  --set overridePWHistory=1 --set overridePWLength=1\
  --set unixhome="/home/$USR"\
  --set e-mail="$EMAIL" \
  --set sambahome="\\\\pdc\\home\\$USR"\
  --set homedrive="U:"\
  --set scriptpath="LOGON.CMD"\
  --set street="A-Straße 6"\
  --set postcode="12345"\
  --set city="Beiuns"\
  --set profilepath="\\\\pdc\\home\\$USR\\.profil"


done
./importuserpwd.sh $1

#8

Hi Christian,

Dein Lösung geht natürlich auch, aber einfacher ist folgende LDIF:

dn: uid=<uid>cn=users,dc=ai,dc=wu,dc=ac,dc=at
changetype: modify
delete: krb5KDCFlags
-
delete: krb5MaxRenew
-
delete: krb5KeyVersionNumber
-
delete: krb5PrincipalName
-
delete: krb5Key
-
delete: krb5MaxLife
-
delete: objectClass
objectClass: krb5Principal
-
delete: objectClass
objectClass: krb5KDCEntry

Ich war auch ziemlich begeistert, als es schlussendlich tatsächlich geklappt hat :smiley:

LG, David