No ENC-TS found

german

#1

Hallo,

mir ist eben aufgefallen, daß ein User kein Kerberos-Tiket kriegt.

kinit: krb5_get_init_creds: No ENC-TS found

Wie kriegt man das wieder repariert ohne den Benutzer neu anzulegen?

Grüße


#2

So wie ich das verstehe scheint das Problem, daß er behauptet das Paßwort sei abgelaufen, damit zusammenzuhängen. Nur wenn es geändert wurde kommt die Frage nach einem neuen Paßwort trotzdem wieder beim nächsten login.


#3

Hallo,

ein erster Ansatz wäre, im LDAP nachzusehen, ob krb5*-Attribute mit gesetztem End-Datum vorhanden sind.

Viele Grüße,
Dirk Ahrnke


#4

Hallo, Bei dem fraglichen User gibt es keinen derartigen Eintrag.


#5

Hallo,

in http://www.mentby.com/Group/samba-technical/samba3upgrade-migration-results-issues-questions.html am Ende des Threads hat jemand das Phänomen mit unterschiedlichen kinit-Versionen auf unterschiedliche Plattformen nachgestellt.


#6

Danke aber das hilft irgendwie nicht weiter. Mir ist immer noch nicht klar, wieso der auf das schmale Brett kommt das Paßwort wäre abgelaufen.

Hier läuft übrigens noch kein Samba 4. Den Teil hab ich mir noch für später aufgehoben


#7

Der von mir erwähnte Thread handelt zwar grundsätzlich von einem Upgrade auf Samba4, kommt aber im letzten Post zur Erkenntnis, dass es eher mit dem Heimdal kinit selbst zu tun hat.
Es gibt eine ähnliche Verhaltensbeschreibung in [bug]30840[/bug], allerdings im Moment ohne weitere Erkenntnisse.
In unserer eigenen Umgebung konnte ich das erstmal insofern nachvollziehen, dass - bei gesetztem “pwdChangeNextLogin=1” - auf dem Master (hier Samba 4) immer Verhalten Nr. 1 (Password incorrect) aus dem Bug zu sehen ist. Auf einem Member-Server sehe ich Verhalten Nr. 2 (No ENC-TS found). Das Kennwort ist aber geändert und wird bei einem erneuten kinit akzeptiert.


#8

Stimmt mein Fehler, da haben Sie recht. Verhalten Nr. 2 tritt bei mir übrigens auch auf dem SDC auf


#9

Der Workaround aus dem Bugzilla bewirkt leider nur, daß die Paßwortänderung nicht funktioniert.


#10

Hallo,

was genau funktioniert dann nicht bzw. welche Fehlermeldung gibt es? Gibt es Meldungen dazu in der Logdatei des KDC (/var/log/heimdal-kdc.log)?
Ist tatsächlich nur ein Benutzer betroffen oder tritt das Verhalten bei mehreren auf? Können Sie das auch mit neu angelegten Benutzern reproduzieren?

Seit wann tritt das Verhalten auf (UCS Updates in der Zeit)?

Mit freundlichen Grüßen
Janis Meybohm


#11

Hallo,

der User wird beim Login jedesmal mit Paßwortwechsel genervt, der sich natürlich durch Enter umgehen läßt. Er bekommt daher aber kein Ticket. Die Logs sagen:

[quote]2013-07-25T10:49:41 AS-REQ krbtgt/TOP2.TOP1@TOP2.TOP1
2013-07-25T10:49:41 Client sent patypes: encrypted-timestamp, 149
2013-07-25T10:49:41 Looking for PKINIT pa-data – user@TOP2.TOP1
2013-07-25T10:49:41 Looking for ENC-TS pa-data – user@TOP2.TOP1
2013-07-25T10:49:41 ENC-TS Pre-authentication succeeded – user@TOP2.TOP1 using aes256-cts-hmac-sha1-96
2013-07-25T10:49:41 Client’s key has expired at 2012-09-11T18:15:08 – user@TOP2.TOP1
[/quote]

Irgendwie bildet er sich ein das Paßwort wäre abgelaufen. Im LDAp stand ja aber nichts derartiges. Und alle Paßwortwechsel über LightDM, UMC, kpasswd und Windows ändern nichts. Selbst die Paßwortrichtlinie hab ich geändert.

Ob das mit einem neuen User auch auftrittt hab ich noch nicht ausprobiert, werde ich aber in den nächsten Tagen machen.


#12

Hallo,

wäre es möglich dass Sie einmal das komplette LDAP-Objekt eines entsprechenden Benutzers posten?
Seit wann tritt das Verhalten auf (UCS Updates in der Zeit) und welche UCS Version setzen Sie derzeit ein?

Mit freundlichen Grüßen
Janis Meybohm


#13

Hallo, genau sagen läßt sich das nicht, da der Benutzeraccount, bei dem mir das erstmals aufgefallen ist, vor dem Upgrade nur unter Windows benutzt wurde, wo es keine Probleme gibt. Aber da es auch bei anderen Accounts auftritt, die auch unter Linux benutzt wurden, nehme ich an, daß das Problem seit dem Upgrade auftritt. Die momentane Version ist UCS3.1-1 errata151

Hier sind die zensierten Auszüge:

Bei dem gehts:

[code]# extended LDIF

LDAPv3

base <dc=top2,dc=top1> (default) with scope subtree

filter: uid=userGeht

requesting: ALL

userGeht, users, top2.top1

dn: uid=userGeht,cn=users,dc=top2,dc=top1
cn:: U3RlZmFuIFN0w6RnbGljaA==
krb5PrincipalName: userGeht@TOP2.TOP1
uidNumber: 2008
krb5MaxLife: 86400
uid: userGeht
krb5MaxRenew: 604800
kolabHomeServer: dcmaster.top2.top1
loginShell: /bin/bash
krb5KDCFlags: 126
displayName:: U3RlZmFuIFN0w6RnbGljaA==
mailPrimaryAddress: userGeht@top2.top1
sambaSID: S-1-5-21-3054788567-1665514781-1078244825-5016
gecos:
sn:: U3TDpGdsaWNo
homeDirectory: /home/userGeht
givenName:
gidNumber: 5001
sambaPrimaryGroupSID: S-1-5-21-3054788567-1665514781-1078244825-513
mail: userGeht@top2.top1
mail: userGeht@extern.de
street:
homePhone:
homePostalAddress:
l:
telephoneNumber:
mailGlobalSpamFolder: 0
mobile: 015253112636
univentionBirthday: 1988-10-27
postalCode: 79295
automountInformation: -rw dcmaster.top2.top1:/home/userGeht
univentionPolicyReference: cn=userGeht,cn=pwhistory,cn=users,cn=policies,dc=top2
,dc=top1
univentionPolicyReference: cn=userGeht_uv0,cn=thinclient,cn=policies,dc=top2,dc=
top1
mailAlternativeAddress: userGeht@extern.de
kolabForwardUCE: FALSE
univentionKolabDeliveryToFolderActive: FALSE
univentionKolabDisableSieve: FALSE
univentionKolabForwardActive: FALSE
kolabForwardKeepCopy: FALSE
sambaAcctFlags: [U ]
sambaBadPasswordCount: 0
krb5KeyVersionNumber: 3
krb5Key::
krb5Key::
krb5Key::
krb5Key::
krb5Key::
krb5Key::
pwhistory:
userPassword::
shadowMax: 200
sambaNTPassword:
sambaLMPassword:
sambaPasswordHistory: 4
univentionFetchmailProtocol: IMAP
univentionCreateRevokeCertificate: 1
univentionRenewCertificate: 0
userCertificate;binary::
sambaPwdCanChange: 1361794586
sambaPwdMustChange: 1379074602
krb5PasswordEnd: 20130913000000Z
sambaPwdLastSet: 1361794602
shadowLastChange: 15761
objectClass: top
objectClass: person
objectClass: univentionPWHistory
objectClass: posixAccount
objectClass: shadowAccount
objectClass: univentionMail
objectClass: univentionKolabInetOrgPerson
objectClass: kolabInetOrgPerson
objectClass: sambaSamAccount
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: simpleSecurityObject
objectClass: uidObject
objectClass: krb5Principal
objectClass: krb5KDCEntry
objectClass: pkiUser
objectClass: univentionPerson
objectClass: automount
objectClass: univentionPolicyReference
objectClass: univentionManageCertificates
objectClass: univentionFetchmail
objectClass: univentionObject
univentionObjectType: users/user
univentionMailHomeServer: dcmaster.top2.top1
univentionFetchmailAddress:
univentionFetchmailUseSSL: 1
univentionFetchmailServer:
sambaMungedDial:

search result

search: 3
result: 0 Success

numResponses: 2

numEntries: 1[/code]

Bei dem nicht:

[code]# extended LDIF

LDAPv3

base <dc=top2,dc=top1> (default) with scope subtree

filter: uid=userGethtNicht

requesting: ALL

userGethtNicht, users, top2.top1

dn: uid=userGethtNicht,cn=users,dc=top2,dc=top1
cn:: RG9yaXMgU3TDpGdsaWNo
krb5PrincipalName: userGethtNicht@TOP2.TOP1
uidNumber: 2010
krb5MaxLife: 86400
uid: userGethtNicht
krb5MaxRenew: 604800
kolabHomeServer: dcmaster.top2.top1
loginShell: /bin/bash
displayName::
mailPrimaryAddress: userGethtNicht@top2.top1
sambaSID:
gecos:
sn::
homeDirectory: /home/userGethtNicht
givenName:
gidNumber: 5001
sambaPrimaryGroupSID: S-1-5-21-3054788567-1665514781-1078244825-513
l:
univentionBirthday:
mobile:
street:
postalCode: 79295
automountInformation: -rw dcmaster.top2.top1:/home/userGethtNicht
telephoneNumber:
sambaPwdCanChange: 1310298837
sambaBadPasswordCount: 0
homePhone:
homePostalAddress:
sambaPwdMustChange: 1347380108
jpegPhoto::
univentionFetchmailAddress:
univentionFetchmailProtocol: IMAP
objectClass: top
objectClass: person
objectClass: univentionPWHistory
objectClass: posixAccount
objectClass: shadowAccount
objectClass: univentionMail
objectClass: univentionKolabInetOrgPerson
objectClass: kolabInetOrgPerson
objectClass: sambaSamAccount
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: simpleSecurityObject
objectClass: uidObject
objectClass: krb5Principal
objectClass: krb5KDCEntry
objectClass: pkiUser
objectClass: univentionPerson
objectClass: automount
objectClass: univentionFetchmail
objectClass: univentionObject
univentionObjectType: users/user
univentionMailHomeServer: dcmaster.top2.top1
pwhistory:
sambaAcctFlags: [U ]
shadowLastChange: 15876
univentionFetchmailUseSSL: 1
mail: userGethtNicht@top2.top1
mail:
mail: userGethtNicht@extern.de
mailAlternativeAddress: userGethtNicht@extern.de
univentionFetchmailServer:
userPassword::
sambaNTPassword:
sambaLMPassword:
sambaPasswordHistory:
E0BD6D3B
krb5Key::
krb5Key::
krb5Key::
krb5Key::
krb5Key::
krb5Key::
krb5Key::
krb5KDCFlags: 126
krb5KeyVersionNumber: 26
sambaPwdLastSet: 1374583703
sambaMungedDial:

search result

search: 3
result: 0 Success

numResponses: 2

numEntries: 1[/code]

EDIT: Bei einem neuangelegten User tritt das nicht auf.


#14

Hallo,

ein Problem wird auf jeden Fall sein dass bei Ihren Benutzern das Attribut sambaPwdMustChange noch gesetzt ist. Mit dem Update auf UCS 3.0 sollte dieses Attribut in der Nachbereitung durch einmaliges Ausführen des Scripts /usr/share/univention-directory-manager-tools/remove_sambapwdmustchange entfernt werden.
Ich würde Sie bitten zu prüfen ob das Verhalten auch nach dem Ausführen des Scripts (mit remove als Parameter) noch auftritt. Außerdem Prüfen Sie bitte die Release-Notes der eingespielten Updates auf weitere Punkte zur Vor-/Nachbereitung der Updates die evtl. noch nicht durchgeführt wurden.

Mit freundlichen Grüßen
Janis Meybohm


#15

Vielen Dank, das war die Lösung. Eigentlich hab ich beim Upgrade alle Schritte durchgeführt bis auf die Aktualisierung von PostgresSQL, weil nach einem Test die pkdb nicht mehr funktionierte. Aber ich werde das noch mal überprüfen.


#16

[quote=“Release Notes 3.0-2”]Ab UCS 3.0-1 wird das Attribut sambaPwdMustChange in den Univention Directory Manager-
Modulen nicht mehr gesetzt. Weiterhin bestehende Attribute sollten durch Aufruf des Skripts
/usr/share/univention-directory-manager-tools/remove_sambapwdlastset
entfernt
werden.
[/quote]

Ein Skript mit diesem Namen gibts hier nicht. Da ist wohl das von Ihnen genannte gemeint. So ist es wohl auch geklärt wieso es das Attribut noch gab: Es gab wohl ein command not found und ich hab vergessen das weiter zu verfolgen.


#17

Hallo,

unter UCS 3.0-2 existiert das Script mit dem Namen, zu UCS 3.1 wurde es jedoch umbenannt da der Name irreführend ist:[quote=“Release Notes 3.1”]The script remove_sambapwdlastset has been renamed to remove_sambapwdmustchange
([bug]27838[/bug]).[/quote]

Mit freundlichen Grüßen
Janis Meybohm