Created attachment 2395 [details] Korrigiert die Zeitstempelkonvertierung von Unix nach AD Aufgetreten mit der Version 4.1.11-1.145.201003022002. Wenn ein Benutzer ein Ablaufdatum hat kann dieser nicht synchronisiert werden. Bei der Umwandlung des Zeitstempels gibt es einen Traceback: sync failed, saved as rejected Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/univention/connector/__init__.py", line 568, in __sync_file_from_ucs if ((old_dn and not self.sync_from_ucs(key, object, premapped_ucs_dn, unicode(old_dn,'utf8'))) File "/usr/lib/python2.4/site-packages/univention/connector/ad/__init__.py", line 1799, in sync_from_ucs f(self, property_type, object) File "/usr/lib/python2.4/site-packages/univention/connector/ad/__init__.py", line 70, in disable_user_from_ucs return connector.disable_user_from_ucs(key, object) File "/usr/lib/python2.4/site-packages/univention/connector/ad/__init__.py", line 1463, in disable_user_from_ucs if ldap_object_ad.has_key('accountExpires') and ldap_object_ad['accountExpires'][0] != unix2ad_time(ucs_admin_object['userex piry']): File "/usr/lib/python2.4/site-packages/univention/connector/ad/__init__.py", line 124, in unix2ad_time return long(time.mktime(time.gmtime(time.mktime(time.strptime(l,"%d.%m.%y"))+90000)))*10000000+d # 90000s are one day and on e hour File "/usr/lib/python2.4/_strptime.py", line 293, in strptime raise ValueError("time data did not match format: data=%s fmt=%s" % ValueError: time data did not match format: data=2010-02-21 fmt=%d.%m.%y Mit dem angehängten Üatch funktioniert es zumindest im write-Mode wieder. Die Funktion ad2unix_time für die Gegenrichtung müsste noch angepasst werden.
Erneut aufgetreten: 2010091010022636
fixed in 2.4-1
Windows 2000 mit UCS 2.4-1 Master: UCS-seitig wird einem Benutzer testuser ein Ablaufdatum auf den 24.12.2010 gesetzt. Es wird laufend gesynced und AD-seitig erhalte ich dauerhaft neue Werte für das Ablaufdatum - beginnend im Dezember 2010 - wenige Minuten später September 2011 - tendenz steigend. Folgender Traceback währenddessen in der connector-tracebacks.log: sync failed, saved as rejected /var/lib/univention-connector/ad/1290590691.792528 Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/univention/connector/__init__.py", line 712, in poll_ucs sync_successfull = self.__sync_file_from_ucs(filename) File "/usr/lib/python2.4/site-packages/univention/connector/__init__.py", line 472, in __sync_file_from_ucs dn,new,old,old_dn=cPickle.load(f) EOFError reopen
root@master:/var/log/univention# ldapsearch -xLLL uid=testuser dn: uid=testuser,cn=users,dc=univention,dc=ad uid: testuser krb5PrincipalName: testuser@UNIVENTION.QA objectClass: top objectClass: person objectClass: univentionPWHistory objectClass: posixAccount objectClass: shadowAccount objectClass: univentionMail objectClass: univentionKolabInetOrgPerson objectClass: kolabInetOrgPerson objectClass: sambaSamAccount objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: krb5Principal objectClass: krb5KDCEntry uidNumber: 2013 sambaAcctFlags: [U ] krb5MaxLife: 86400 cn: name krb5MaxRenew: 604800 kolabHomeServer: master.univention.ad loginShell: /bin/bash kolabVacationResendInterval: 7 displayName: name sambaSID: S-1-5-21-4288138871-3321426892-2926664130-5026 gecos: name sn: name homeDirectory: /home/testuser gidNumber: 5001 sambaPrimaryGroupSID: S-1-5-21-4288138871-3321426892-2926664130-513 shadowLastChange: 14937 shadowExpire: 15443 sambaKickoffTime: 1334192400 krb5ValidEnd: 20120412000000Z root@master:/var/log/univention# univention-adsearch cn=testuser # # univention-adsearch # filter: cn=testuser # DN: CN=testuser,CN=Users,DC=windows,DC=ad primaryGroupID: 513 logonCount: 0 cn: testuser countryCode: 0 objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user userPrincipalName: testuser@windows.ad instanceType: 4 distinguishedName: CN=testuser,CN=Users,DC=windows,DC=ad sAMAccountType: 805306368 objectSid: S-1-5-21-1275210071-1060284298-839522115-1109 whenCreated: 20101124072304.0Z uSNCreated: 3261 badPasswordTime: 0 pwdLastSet: 129350569847628352 sAMAccountName: testuser objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=windows,DC=ad objectGUID: ['\xee\xd5\x86\xe8\x93[\x04G\xaf\x8c\xa1\x97\xaa\x08\x07]'] whenChanged: 20101124073110.0Z badPwdCount: 0 accountExpires: 129801420000000000 name: testuser codePage: 0 userAccountControl: 544 lastLogon: 0 uSNChanged: 3788 sn: name lastLogoff: 0 # # results: 1 # "accountExpires" wird hierbei laufend hochgezählt.
Created attachment 2849 [details] end of connector.log
Die Änderungen werden auch laufend AD-UCS zurückgesynced.
Das genannte Problem konnte auf einer Umgebung mit einem Windows 2008 R2 Server nicht nachgestellt werden. Ebenso scheint es diese Probleme in Windows 2003 Umgebungen auch nicht zu geben.
Das UCS System scheint nicht die richtige Zeitzone zu haben: root@master:~# rdate time.fu-berlin.de Thu Nov 25 09:58:14 GMT+1 2010 root@master:~# date Do 25. Nov 09:58:18 GMT+1 2010 root@master:~# date -R Thu, 25 Nov 2010 09:58:20 -0100 root@master:~# date -u Do 25. Nov 10:59:18 UTC 2010 root@master:~# Es ist aktuell 11:59 Uhr.
(In reply to comment #8) > Das UCS System scheint nicht die richtige Zeitzone zu haben: > > root@master:~# rdate time.fu-berlin.de > Thu Nov 25 09:58:14 GMT+1 2010 > root@master:~# date > Do 25. Nov 09:58:18 GMT+1 2010 > root@master:~# date -R > Thu, 25 Nov 2010 09:58:20 -0100 > root@master:~# date -u > Do 25. Nov 10:59:18 UTC 2010 > root@master:~# > > Es ist aktuell 11:59 Uhr. Mit korrekt gesetzter Zeitzone auf UCS-Seite funktioniert die Replikation der Ablaufzeit problemlos Changelogeintrag hierzu ist vorhanden, andere Windows Server Versionen wurden bereits erfolgreich getestet - verified!
UCS 2.4-1 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte der Bug dupliziert werden: "Clone This Bug".