Win7 Join klappt nicht

UCS - Univention Corporate Server
#1

Hallo,

irgendwie weiß ich nicht mehr weiter. Den Artikel zu Problemen eines Win7 Client Join habe ich gelesen, Uhrzeit stimmt, DNS-Einträge stimmen und es ist auch bei “host -al| grep SRV” kein Hostname dabei, der nicht ovrhanden ist. Alles nur der einzige UCS Server hier.

Ich kann einen Win7 Client nicht Joinen, der Client sagt immer: “Unbekannter Benutzer oder falsches Passwort”. Allerdings habe ich das Passwort GANZ SICHER richtig eingegeben.

Im samba.log steht:

[2016/02/09 22:50:26.490379,  1, pid=28071] ../source4/auth/gensec/gensec_gssapi.c:619(gensec_gssapi_update)
  GSS server Update(krb5)(1) Update failed:  Miscellaneous failure (see text): Decrypt integrity check failed
[2016/02/09 22:50:26.490469,  1, pid=28071] ../auth/gensec/spnego.c:523(gensec_spnego_parse_negTokenInit)
  SPNEGO(gssapi_krb5) NEG_TOKEN_INIT failed: NT_STATUS_LOGON_FAILURE
[2016/02/09 22:50:26.895218,  1, pid=28079] ../source4/auth/gensec/gensec_gssapi.c:619(gensec_gssapi_update)
  GSS server Update(krb5)(1) Update failed:  Miscellaneous failure (see text): Decrypt integrity check failed
[2016/02/09 22:50:26.895279,  1, pid=28079] ../auth/gensec/spnego.c:523(gensec_spnego_parse_negTokenInit)
  SPNEGO(gssapi_krb5) NEG_TOKEN_INIT failed: NT_STATUS_LOGON_FAILURE
[2016/02/09 22:50:39.426222,  1, pid=28105] ../source4/auth/gensec/gensec_gssapi.c:619(gensec_gssapi_update)
  GSS server Update(krb5)(1) Update failed:  Miscellaneous failure (see text): Decrypt integrity check failed
[2016/02/09 22:50:39.426280,  1, pid=28105] ../auth/gensec/spnego.c:523(gensec_spnego_parse_negTokenInit)
  SPNEGO(gssapi_krb5) NEG_TOKEN_INIT failed: NT_STATUS_LOGON_FAILURE
[2016/02/09 22:50:39.822986,  1, pid=28108] ../source4/auth/gensec/gensec_gssapi.c:619(gensec_gssapi_update)
  GSS server Update(krb5)(1) Update failed:  Miscellaneous failure (see text): Decrypt integrity check failed
[2016/02/09 22:50:39.823040,  1, pid=28108] ../auth/gensec/spnego.c:523(gensec_spnego_parse_negTokenInit)
  SPNEGO(gssapi_krb5) NEG_TOKEN_INIT failed: NT_STATUS_LOGON_FAILURE

Decrypt integrity check failed sagt lt. Kerberos aus, dass es ein falsches Passwort ist. Lt. Kerberos Doc (cmf.nrl.navy.mil/krb/kerbero … ml#badpass) kann es im Zusammenhang mit einem Slave KDC sein. Es gibt aber keinen (mehr!).

Jemand eine Idee, wie das zu lösen ist?

Danke!

#2

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

#3

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 :frowning:

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

#4

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

#5

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                UCS
#6

Sie 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«.

#7

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”

extended LDIF

LDAPv3

base <uid=administrator,cn=users,dc=knebb,dc=de> with scope subtree

filter: (objectclass=*)

requesting: ALL

Administrator, users, knebb.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

#8

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.

#9

[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]

#10

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” :frowning:

#11

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

#12

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

#13

[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 :frowning:

#14

Tritt dieser fehler denn auch auf,
wenn sie mit einem anderen Win7-Client joinen ?

Nach Takeover: Keine Replizierung von DC Master
#15

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.

#16

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

#17

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

#18

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…

#19

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

#20

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

Mastodon