Moin,
welche UCS-Version ist im Einsatz? Wie haben Sie den Namen der zu joinenden Domäne angegeben – als NetBIOS-Namen (z.B. »LINET«) oder als FQDN (z.B. »bs.linet-services.de«)?
Sie sagten, es gebe keinen Slave-KDC mehr. Was meinen Sie damit? Gab es mal welche? Allgemein, was für UCS-Server (DC Master, Backup und Slave) haben Sie?
Gruß,
mosu
Moin,
UCS 4.1-0 errata100. Alle Paket-Updates eingespielt.
Bei dem Namen habe ich beides versucht: DOMAIN, domain, domain.de, DOMAIN.DE
Den Administrator mal mit vorgestelltem DOMAIN\ bzw. domain\ verwendet, mal ohne. In allen Fällen das Gleiche 
Hier nutze ich nur den Free-UCS, da war testhalber mal ein zweiter als BDC installiert, das hat mit dem Join aber nicht richtig geklappt- wohl ein bekanntes Problem der FREE-Version, habe das aber nicht weiterverfolgt und den BDC wieder rausgenommen. Der scheint auch in keiner Konfig mehr aufzutauchen. Da aber der Kerberos Fehler wohl mit Replikation zu tun hat, habe ich das erwähnt.
Grüße
Christian
Moin,
können Sie bitte mal die Ausgabe der folgenden Befehle posten:
[ul][li]»ldbsearch --debug-stderr -H [ldaps://$(ucr](ldaps://$(ucr) get ldap/master) -UAdministrator« (hiervon nur die erste paar Zeilen; es geht mir darum, ob zwischen der Passwortabfrage und dem ersten Eintrag irgendwelche merkwürdigen Fehlermeldungen erscheinen)[/li]
[li]»smbclient -L $(ucr get ldap/master) --machine-pass«[/li][/ul]
Gruß,
mosu
Hallo,
definitiv das richtige Passwort eingegeben!
Hatte es via Web-UI auch noch einmal neu gesetzt. Dennoch angeblich immer das falsche:
root@ucs:~# ldbsearch --debug-stderr -H ldaps://$(ucr get ldap/master) -UAdministrator
Password for [KNEBB\Administrator]:
Password for [KNEBB\Administrator]:
Password for [KNEBB\Administrator]:
Wrong username or password: kinit for Administrator@KNEBB.DE failed (Preauthentication failed)
SPNEGO(gssapi_krb5) creating NEG_TOKEN_INIT failed: NT_STATUS_LOGON_FAILURE
Failed to bind - LDAP error 49 LDAP_INVALID_CREDENTIALS - <SASL:[GSS-SPNEGO]: NT_STATUS_LOGON_FAILURE> <>
Failed to connect to 'ldaps://ucs.knebb.de' with backend 'ldaps': (null)
Failed to connect to ldaps://ucs.knebb.de - (null)Und:
root@ucs:~# smbclient -L $(ucr get ldap/master) --machine-pass
Domain=[KNEBB] OS=[Windows 6.1] Server=[Samba 4.3.3-Debian]
Sharename Type Comment
--------- ---- -------
netlogon Disk Domain logon service
sysvol Disk
print$ Disk Printer Drivers
musik Disk
video Disk
ftp Disk
bilder Disk
epson Printer
IPC$ IPC IPC Service (Univention Corporate Server)
Domain=[KNEBB] OS=[Windows 6.1] Server=[Samba 4.3.3-Debian]
Server Comment
--------- -------
LENA
UCS Univention Corporate Server
Workgroup Master
--------- -------
UCS
KNEBB UCSSie scheinen ziemlich eindeutig ein tiefergehendes Problem mit Kerberos zu haben. Probieren Sie bitte mal ein »kinit Administrator«, wobei ich fest davon ausgehe, dass auch das nicht funktioniert. Prüfen Sie auch mal, ob Sie für andere User Tokens bekommen, ganz einfach mit »kinit Username« gefolgt von »klist«.
Haben Sie Rejects des S4-Connectors (»univention-s4connector-list-rejected«)? Falls ja, diese unbedingt beseitigen; siehe dazu diesen Support-DB-Eintrag.
Eventuell ist von Ihrem alten gejointen Computer auch noch etwas vorhanden. Bitte prüfen Sie das mit »univention-ldapsearch« für den OpenLDAP-Teil und »univention-s4search« für den Samba-4-Teil.
Zeigen Sie auch bitte mal den Inhalt der Datei »/etc/krb5.conf«.
Hallo,
das erste geht einwandfrei:
root@ucs:~# kinit Administrator
Administrator@KNEBB.DE's Password:
root@ucs:~# klist
Credentials cache: FILE:/tmp/krb5cc_0
Principal: Administrator@KNEBB.DE
Issued Expires Principal
Feb 10 16:11:45 2016 Feb 11 02:11:42 2016 krbtgt/KNEBB.DE@KNEBB.DE
root@ucs:~#Rejcts des S4-Connectors finde ich KEINE:root@ucs:/var/log/univention# grep -i reject connector-s4.log
Aber es besteht wohl ein Problem mit dem sync:
[code]
root@ucs:/var/log/univention# univention-ldapsearch -b “uid=administrator,cn=users,dc=knebb,dc=de”
dn: uid=Administrator,cn=users,dc=knebb,dc=de
uid: Administrator
krb5PrincipalName: Administrator@KNEBB.DE
uidNumber: 2002
sambaAcctFlags: [U ]
krb5MaxLife: 86400
cn: Administrator
[…][/code]
s4 zeigt aber Probleme und läßt sich nicht syncen:
root@ucs:/var/log/univention# univention-s4search -b "uid=administrator,cn=users,dc=knebb,dc=de"
Failed to bind - LDAP error 49 LDAP_INVALID_CREDENTIALS - <SASL:[GSS-SPNEGO]: NT_STATUS_LOGON_FAILURE> <>
Failed to connect to 'ldaps://ucs.knebb.de' with backend 'ldaps': (null)
Failed to connect to ldaps://ucs.knebb.de - (null)
root@ucs:/var/log/univention# /usr/share/univention-s4-connector/resync_object_from_ucs.py --filter uid=Administrator
resync triggered for uid=Administrator,cn=users,dc=knebb,dc=de
root@ucs:/var/log/univention# univention-s4search -b "uid=administrator,cn=users,dc=knebb,dc=de"
Failed to bind - LDAP error 49 LDAP_INVALID_CREDENTIALS - <SASL:[GSS-SPNEGO]: NT_STATUS_LOGON_FAILURE> <>
Failed to connect to 'ldaps://ucs.knebb.de' with backend 'ldaps': (null)
Failed to connect to ldaps://ucs.knebb.de - (null)Sorry, mit ldapsearch kenne ich mich zu wenig aus, nach was sollte ich da suchen?
Grüeß
Christian Völker
Zu den Rejects des Connectors: bitte führen Sie einmal den Befehl »univention-s4connector-list-rejected« aus. Dessen Ausgabe ich maßgeblich für Rejects, nicht die Suche im Log.
Zu ldapsearch: relativ einfach ein »univention-ldapsearch | grep HostnameDesAltenServers«. Ich vermute aber weiterhin, dass Sie ein Problem mit der Synchronisation vom LDAP zu Samba 4 haben.
[quote=“Moritz Bunkus”]Zu den Rejects des Connectors: bitte führen Sie einmal den Befehl »univention-s4connector-list-rejected« aus. Dessen Ausgabe ich maßgeblich für Rejects, nicht die Suche im Log.
Zu ldapsearch: relativ einfach ein »univention-ldapsearch | grep HostnameDesAltenServers«.
[/quote]
Da kommt viel- vor allem, weil ich den Hostnamen nicht mehr weiß! Das war zum Testen, hat nicht funktioniert, also wieder weg damit und bei Single-Betrieb geblieben.
Und es scheint immer noch keine Rejects zu geben (wie stoppe ich den connector? Ist das nötig?):[code]
root@ucs:/var/log/univention# univention-s4connector-list-rejected
UCS rejected
S4 rejected
There may be no rejected DNs if the connector is in progress, to be
sure stop the connector before running this script.
last synced USN: 13511
[/code]
Hallo,
keiner eine Idee, wie das gelöst werden kann?
Auf unserem Produktivsystemen hatten wir wohl so etwas ähnliches schon- allerdings haben wir da für alle System Supportverträge.
Ist das vielleicht ein bekanntes Problem? Dann sollte es doch auch eine bekannte Lösung geben.
Aktuell komme ich als “normaler” Benutzer auch nicht mehr auf die Freigaben drauf- hier sagt er auch immer “falsches Passwort”
Moin,
ich habe momentan keine Idee, wie das weiter zu debuggen ist. Diverse Suchen in der Support-Datenbank, im Bugzilla und allgemein via Google haben auch keine guten Anhaltspunkte ergeben – sprich es handelt sich wohl nicht um ein häufig vorkommendes Problem.
Ich hatte Univention um einen Tipp gebeten, leider da noch keine Antwort; vielleicht kommt da noch etwas.
Was Sie ins Auge fassen können, ist den Samba-4-Teil neu zu provisionieren. Dabei wird das Samba-4-LDAP komplett weggeworfen und aus den Informationen im OpenLDAP neu erstellt. Die Prozedur ist in diesem Support-Datenbank-Artikel beschrieben. Auf jeden Fall sollten Sie vorher ein Backup der Maschine erstellen.
Gruß,
mosu
Hallo,
ich würde vielleicht nochmal folgendes versuchen :
Zuerst mit dem Win7-Client die Domäne verlassen.
Anschliessend den kompletten Eintrag des Win7-Client-Rechner aus dem LDAP löschen.
Anschliessend mit dem Win7-Client neu in die Domäne joinen.
Das als DNS-Server der Ad eingetragen ist, gehe ich mal von aus.
Beim Joinen in die AD müssen ja Benutzer und Passwort vom AD-Admin angegeben werden.
Wenn das klappen sollte, dann kann man ja erstmal davon ausgehen, das Benutzernamen und PW korrekt übertragen und verifiziert werden können.
Gruß,
Oliver
[quote=“O. Bertgen”]Hallo,
ich würde vielleicht nochmal folgendes versuchen :
Zuerst mit dem Win7-Client die Domäne verlassen.[/quote]
Habe ich ja getan. Weil es Probleme mit der Profilübernahme gab. Wollte den Client dann neu reinbringen.
Habe ich jetzt auch mal gemacht und prompt gibt es eine andere Fehlermeldung bei dem Versuch, die domäne zu joinen:
[quote]"Fehler beim Ändern des DNS-Namens für die primäre Domäne dieses Computers in “”. Name “knebb.de” wird beibehalten.
Fehler:
Anmeldung fehlgeschlagen: unbekannter Benutzername oder flasches Passwort[/quote]
Also wie gehabt: Passwort angeblich falsch.
Muß wohl das Samba neu aufsetzen
Tritt dieser fehler denn auch auf,
wenn sie mit einem anderen Win7-Client joinen ?
Das Problem ist nicht das Joinen, das Problem ist, dass die Kerberos-Anmeldung an Samba 4 bei ihm generell nicht mehr funtkioniert. Siehe hier: nicht einmal ein »univention-s4search« funktioniert mehr, was das lokale Computerkonto (als das des DCs selber) zur Anmeldung am Samba-4-LDAP nutzt.
Da bringt’s jetzt nichts, mit Windows-Clients irgend etwas zu versuchen, bis nicht zumindest ein »univention-s4search« wieder läuft.
Hallo!
[quote=“O. Bertgen”]Tritt dieser fehler denn auch auf,
wenn sie mit einem anderen Win7-Client joinen ?[/quote]
Ich möchte die anderen Rechner jetzt nicht aus der Domäne herausnehmen, da mir die Gefahr zu groß ist, dass sie nicht mehr reinkommen!
Aber ich gehe mal aufgrund der weiter oben bereits durchgeführten Analysen mal davon aus, dass es sich nicht um ein Client- sondern Serverproblem handelt.
Danke, sehe ich auch so.
/Christian
Huhu,
bevor Sie Samba 4 neu provisionieren, würden mich noch interessieren, was bei den folgenden Befehlen herauskommt (bitte genau in dieser Reihenfolge ausführen):
[ol][li]ucr search --brief version/version version/patchlevel server/role[/li]
[li]kdestroy; kinit -t /var/lib/samba/private/dns.keytab “dns-$(hostname)”; klist[/li]
[li]univention-check-join-status || univention-run-join-scripts[/li]
[li]kdestroy; kinit -t /var/lib/samba/private/dns.keytab “dns-$(hostname)”; klist[/li]
[li]ldbsearch -H /var/lib/samba/private/secrets.ldb sAMAccountName=“dns-$(hostname)” msDS-KeyVersionNumber saltPrincipal[/li]
[li]ldbsearch -H ldapi:///var/lib/samba/private/ldap_priv/ldapi sAMAccountName=“dns-$(hostname)” msDS-KeyVersionNumber[/li][/ol]
Gruß,
mosu
Hi,
jau, bitteschön:
root@ucs:~# ucr search --brief version/version version/patchlevel server/role
server/role: domaincontroller_master
version/patchlevel: 0
version/version: 4.1
root@ucs:~# kdestroy; kinit -t /var/lib/samba/private/dns.keytab "dns-$(hostname)"; klist
Credentials cache: FILE:/tmp/krb5cc_0
Principal: dns-ucs@KNEBB.DE
Issued Expires Principal
Feb 11 15:22:25 2016 Feb 12 01:22:25 2016 krbtgt/KNEBB.DE@KNEBB.DE
root@ucs:~# univention-check-join-status || univention-run-join-scripts
Joined successfully
root@ucs:~# kdestroy; kinit -t /var/lib/samba/private/dns.keytab "dns-$(hostname)"; klist
Credentials cache: FILE:/tmp/krb5cc_0
Principal: dns-ucs@KNEBB.DE
Issued Expires Principal
Feb 11 15:22:53 2016 Feb 12 01:22:53 2016 krbtgt/KNEBB.DE@KNEBB.DE
root@ucs:~# ldbsearch -H /var/lib/samba/private/secrets.ldb sAMAccountName="dns-$(hostname)" msDS-KeyVersionNumber saltPrincipal
# record 1
dn: samAccountName=dns-ucs,CN=Principals
msDS-KeyVersionNumber: 1
saltPrincipal: dns-ucs@KNEBB.DE
# returned 1 records
# 1 entries
# 0 referrals
root@ucs:~# ldbsearch -H ldapi:///var/lib/samba/private/ldap_priv/ldapi sAMAccountName="dns-$(hostname)" msDS-KeyVersionNumber
# record 1
dn: CN=dns-ucs,CN=Users,DC=knebb,DC=de
msDS-KeyVersionNumber: 1
# Referral
ref: ldap://knebb.de/CN=Configuration,DC=knebb,DC=de
# Referral
ref: ldap://knebb.de/DC=DomainDnsZones,DC=knebb,DC=de
# Referral
ref: ldap://knebb.de/DC=ForestDnsZones,DC=knebb,DC=de
# returned 4 records
# 1 entries
# 3 referrals
root@ucs:~#Danke für die Mühen- obiges sagt mir aber nicht viel…
Hey,
sieht alles normal aus. Leider. Gibt damit nämlich keine neuen Erkenntnisse über die Natur des Problems. Damit halte ich das Neuprovisionieren doch für das Erfolgversprechendste.
Gruß,
mosu
Yohoo!
Ok, habe also “Neuprovisioniert”, wie in dem hier vorher verlinkten Wiki-Artikel beschrieben.
Hat problemlos geklappt und es funktioniert wieder alles wie vorher.
Danke für die Hilfe!
/Christian
Sehr schön! & gern geschehen.