Administrator Passwort zurücksetzen

Hallo,

wie kann das Passwort des Administrators über die Konsole zurückgesetzt werden (UCS3)?
Nach der letzten Änderung des Passworts (wegen Ablauf), ist nun keine Anmeldung als Administrator mehr möglich.

Die Authentisierung schlug fehl. Bitte melden Sie sich erneut an.

Wird ein offensichtlich falsches (beliebiges) Passwort angegeben, erfolgt keine Fehlermeldung sondern eine Endlosschleife -> evtl. liegt also auch ein anderes Problem vor.
Anmeldung an CIFS-Shares funktioniert augenscheinlich noch.

Die Anmeldung als “root” am Webfrontend funktioniert ebenfalls, allerdings ist darüber kein Zugriff auf die Benutzerverwaltung möglich.
Scheinbar beschränken sich die Probleme auf den Administrator-User.

Folgende Fehler tauchen in den Logfiles auf:

connector-s4.log

12.02.2012 11:34:17,928 LDAP (PROCESS): sync from ucs: Resync rejected file: /var/lib/univention-connector/s4/1325180038.416787 12.02.2012 11:34:17,934 LDAP (WARNING): sync failed, saved as rejected /var/lib/univention-connector/s4/1325180038.416787 12.02.2012 11:34:17,935 LDAP (WARNING): Traceback (most recent call last): File "/usr/lib/pymodules/python2.6/univention/s4connector/__init__.py", line 724, in resync_rejected_ucs if self.__sync_file_from_ucs(filename, append_error=' rejected'): File "/usr/lib/pymodules/python2.6/univention/s4connector/__init__.py", line 556, in __sync_file_from_ucs if self._ignore_object(key, new_object): File "/usr/lib/pymodules/python2.6/univention/s4connector/__init__.py", line 1333, in _ignore_object for subtree in self.property[key].ignore_subtree: KeyError: None

management-console-server.log

12.02.12 11:12:08.083  AUTH        ( ERROR   ) : PAM: authentication error: ('Authentifizierungstoken ist nicht mehr g?ltig; neues erforderlich', 12)
UNIVENTION_DEBUG_BEGIN  : uldap.__open host=ucs3.xxx.local port=7389 base=dc=xxx,dc=local
UNIVENTION_DEBUG_END    : uldap.__open host=ucs3.xxx.local port=7389 base=dc=xxx,dc=local
UNIVENTION_DEBUG_BEGIN  : uldap.searchDn filter=(&(uid=root)(objectClass=posixAccount)) base= scope=sub unique=0 required=0
UNIVENTION_DEBUG_END    : uldap.searchDn filter=(&(uid=root)(objectClass=posixAccount)) base= scope=sub unique=0 required=0
UNIVENTION_DEBUG_BEGIN  : uldap.searchDn filter=(&(objectClass=person)(uid=root)) base= scope=sub unique=1 required=0
UNIVENTION_DEBUG_END    : uldap.searchDn filter=(&(objectClass=person)(uid=root)) base= scope=sub unique=1 required=0
UNIVENTION_DEBUG_BEGIN  : uldap.__open host=ucs3.xxx.local port=7389 base=dc=xxx,dc=local
UNIVENTION_DEBUG_END    : uldap.__open host=ucs3.xxx.local port=7389 base=dc=xxx,dc=local
UNIVENTION_DEBUG_BEGIN  : uldap.searchDn filter=(&(uid=root)(objectClass=posixAccount)) base= scope=sub unique=0 required=0
UNIVENTION_DEBUG_END    : uldap.searchDn filter=(&(uid=root)(objectClass=posixAccount)) base= scope=sub unique=0 required=0
UNIVENTION_DEBUG_BEGIN  : uldap.searchDn filter=(&(objectClass=person)(uid=root)) base= scope=sub unique=1 required=0
UNIVENTION_DEBUG_END    : uldap.searchDn filter=(&(objectClass=person)(uid=root)) base= scope=sub unique=1 required=0
12.02.12 11:22:12.799  SSL         ( WARN    ) : SSL error: (-1, 'Unexpected EOF'). Probably the socket was closed by the client.
12.02.12 11:30:49.244  MAIN        ( WARN    ) : Socket died (module=ucr)
12.02.12 11:30:49.244  MAIN        ( WARN    ) : Module process ucr died (pid: 3896, exit status: -1, signal: -1)
12.02.12 11:30:49.244  MAIN        ( WARN    ) : Cleaning up requests
12.02.12 11:30:49.244  MAIN        ( WARN    ) : Remove inactivity timer
12.02.12 11:30:54.111  SSL         ( WARN    ) : SSL error: (-1, 'Unexpected EOF'). Probably the socket was closed by the client.
12.02.12 11:33:12.548  AUTH        ( ERROR   ) : PAM: authentication error: ('Authentifizierungstoken ist nicht mehr g?ltig; neues erforderlich', 12)
12.02.12 11:34:12.396  AUTH        ( ERROR   ) : PAM: authentication error: ('Fehler bei Authentifizierung', 7)
12.02.12 11:40:22.981  MAIN        ( WARN    ) : Socket died (module=ucr)
12.02.12 11:40:22.981  MAIN        ( WARN    ) : Module process ucr died (pid: 4180, exit status: -1, signal: -1)
12.02.12 11:40:22.981  MAIN        ( WARN    ) : Cleaning up requests
12.02.12 11:40:22.981  MAIN        ( WARN    ) : Remove inactivity timer
12.02.12 11:40:27.845  SSL         ( WARN    ) : SSL error: (-1, 'Unexpected EOF'). Probably the socket was closed by the client.

auth.log

Feb 12 11:32:37 ucs3 nscd: nss_ldap: reconnecting to LDAP server...
Feb 12 11:32:37 ucs3 nscd: nss_ldap: reconnected to LDAP server ldap://ucs3.xxx.local:7389 after 1 attempt
Feb 12 11:33:12 ucs3 python2.6: nss_ldap: reconnecting to LDAP server...
Feb 12 11:33:12 ucs3 python2.6: nss_ldap: reconnected to LDAP server ldap://ucs3.xxx.local:7389 after 1 attempt
Feb 12 11:33:12 ucs3 python2.6: pam_unix(univention-management-console:account): expired password for user Administrator (password aged)
Feb 12 11:33:12 ucs3 python2.6: pam_unix(univention-management-console:account): conversation failed
Feb 12 11:33:17 ucs3 python2.6: pam_unix(univention-management-console:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=  user=Administrator
Feb 12 11:34:01 ucs3 CRON[5045]: pam_unix(cron:session): session opened for user root by (uid=0)
Feb 12 11:34:10 ucs3 python2.6: pam_krb5(univention-management-console:auth): authentication failure; logname=Administrator uid=0 euid=0 tty= ruser= rhost=

Dem Eintrag
Feb 12 11:33:12 ucs3 python2.6: pam_unix(univention-management-console:account): expired password for user Administrator (password aged)
entnehme ich, dass das Passwort abgelaufen ist - eine entsprechende Meldung hatte ich bereits auf einem Linux-Client beim Versuch, der Domäne beizutreten.

Daraufhin habe ich mich eingeloggt, und die Einstellung für Passwort-Ablauf sowie die Passwort-Historie deaktiviert und anschließend das Passwort neu gesetzt (gleiches wie vorher).
Offenbar resultieren hieraus die aktuellen Probleme. Mit einem Reset des Passworts sollte es also wieder zu richten sein.

Ein su bestätigt den Verdacht:


root@ucs3:~# su - Administrator
Sie müssen Ihr Passwort sofort ändern (Passwortablauf).
su: Authentifizierungstoken ist nicht mehr gültig; neues erforderlich
(Ignoriert)

Mit passwd - Administrator ließ sich das Passwort zurücksetzen:

root@ucs3:~# passwd Administrator Current Kerberos password: Passwort: Passwort nicht geändert Geben Sie das neue Passwort erneut ein: LDAP password information changed for Administrator passwd: Passwort erfolgreich geändert root@ucs3:~#

Allerdings hat der Vorgang relativ lange gedauert…

Ein ähnliches Problem gab es bereits unter 2.4:
https://forge.univention.org/bugzilla/show_bug.cgi?id=20239

Bitte nochmal Feedback, ob das Vorgehen soweit korrekt ist?

Hallo,

das Vorgehen ist soweit in Ordnung. Einfacher wäre es vermutlich beim nächsten mal über den UDM-Client:

udm users/user modify --dn uid=Administrator,cn=users,<ldap-basis> --set password=<passwort>

Mit freundlichen Grüßen,
Tim Petersen

Problem tritt jeden Tag erneut auf - offensichtlich lässt sich die History und der Passwort-Ablauf nicht dauerhaft zurücksetzen.

Mit

udm users/user modify --dn uid=Administrator,dc=xxx,dc=local --set password=xxxxxx

war es mir leider nicht möglich, dass Passwort zurückzusetzen, Account wird scheinbar nicht gefunden:

E: object not found

Ein Workaround war wie folgt erfolgreich:

  • Zurücksetzen des Kennworts über
passwd Administrator
  • Einloggen im Frontend
  • Bearbeiten der Kennwortrichtlinie, “Passwort-Ablaufintervall” von “0” auf beliebigen Wert hochsetzen
  • Unter “Konto” Haken bei “Passwort bei der nächsten Anmeldung ändern” entfernen

Im Anschluss kann (wenn gewünscht) “Passwort-Ablaufintervall” wieder auf “0” gesetzt werden.
Ob das Passwort dennoch im vorher gesetzten Zeitraum ausläuft, kann ich noch nicht sagen, das Datum wird nach wie vor als Ablaufdatum angezeigt.

Get auch über udm, hatte nur cn=users vergessen:

udm users/user modify --dn="uid=Administrator,cn=users,dc=xxx,dc=local" --set password=xxxxx

Hallo,

[quote=“harke”]Problem tritt jeden Tag erneut auf - offensichtlich lässt sich die History und der Passwort-Ablauf nicht dauerhaft zurücksetzen.
[/quote]

Ist dieses Verhalten noch akut?
Sollte dies der Fall sein, würde ich Sie bitten uns einmal die Ausgabe des folgenden Befehls per Mail an feedback@univention.de zukommen zu lassen. Sie können die entsprechend sensiblen Bereiche selbstverständlich auch entfernen und uns die Ausgabe hier anhängen.

udm users/user list --filter uid=Administrator

Mit freundlichen Grüßen,
TIm Petersen

Das Problem besteht nach wie vor - täglich kann ich das Kennwort per

udm users/user modify --dn="uid=Administrator,cn=users,dc=xxx,dc=local" --set password=xxx[/code]

zurücksetzen. Das Ablaufdatum bleibt dennoch stets der jeweilige Tag, wie heute, der 21/02/2012:

[code]root@ucs3:~# udm users/user list --filter uid=Administrator
uid=Administrator
DN: uid=Administrator,cn=users,dc=xxx,dc=local
ARG: None
  homedrive: None
  CtxKeyboardLayout: None
  disabled: none
  postcode: None
  CtxWFProfilePath: None
  CtxRASDialin: None
  title: None
  mailAlternativeAddress: None
  organisation: None
  CtxMaxIdleTime: None
  lastname: Administrator
  employeeNumber: None
  password: {crypt}XXXXXXXXX
  passwordexpiry: 2012-02-21
  sambaRID: 500
  profilepath: None
  mobileTelephoneNumber: None
  sambahome: /home/Administrator
  CtxWFHomeDirDrive: None
  CtxCallback: None
  street: None
  CtxShadow: 00000000
  e-mail: None
  CtxWorkDirectory: None
  CtxNWLogonServer: None
  CtxMaxConnectionTime: None
  homePostalAddress: None
  groups: cn=Domain Admins,cn=groups,dc=xxx,dc=local
  groups: cn=Domain Users,cn=groups,dc=xxx,dc=local
  groups: cn=DC Backup Hosts,cn=groups,dc=xxx,dc=local
  groups: cn=Schema Admins,cn=groups,dc=xxx,dc=local
  groups: cn=Group Policy Creator Owners,cn=groups,dc=xxx,dc=local
  overridePWHistory: None
  pwdChangeNextLogin: 1
  secretary: None
  primaryGroup: cn=Domain Admins,cn=groups,dc=xxx,dc=local
  CtxInitialProgram: None
  scriptpath: None
  sambaPrivileges: None
  city: None
  CtxStartprogramClient: 0
  pagerTelephoneNumber: None
  userexpiry: None
  sambaUserWorkstations: None
  username: Administrator
  departmentNumber: None
  shell: /bin/bash
  CtxMinEncryptionLevel: None
  CtxCallbackNumber: None
  mailHomeServer: None
  CtxCfgFlags1: None
  phone: None
  gidNumber: 5000
  sambaLogonHours: None
  CtxBrokenSession: 0000
  locked: none
  CtxReconnectSession: 0000
  roomNumber: None
  homeShare: None
  gecos: Administrator
  CtxCfgClientPrinters: 0
  jpegPhoto: None
  uidNumber: 2002
  employeeType: None
  homeSharePath: None
  CtxCfgPresent: None
  CtxWFHomeDir: None
  unixhome: /home/Administrator
  homeTelephoneNumber: None
  description: None
  firstname: None
  birthday: None
  overridePWLength: None
  CtxMaxDisconnectionTime: None
  CtxCfgDefaultClientPrinters: 0
  displayName: Administrator
  mailPrimaryAddress: None
  CtxCfgClientDrivers: 0
  CtxCfgTSLogon: 1

Wenn ich den Passwort-Ablaufintervall > 0 setze, wird die Einstellung entsprechend übernommen. Nur mit “0” erreiche ich leider nicht, dass das Passwort niemals abläuft.
Bei einem anderen User (kein Admin) greift die Einstellung auf “0”, es wird dann kein Ablaufdatum angezeigt:

root@ucs3:~# udm users/user list --filter uid=username
uid=username
DN: uid=username,cn=users,dc=xxx,dc=local
ARG: None
  homedrive: None
  CtxKeyboardLayout: None
  disabled: none
  postcode: None
  CtxWFProfilePath: None
  CtxRASDialin: E
  title: None
  mailAlternativeAddress: None
  organisation: None
  CtxMaxIdleTime: None
  lastname: Nachname
  employeeNumber: None
  password: {crypt}xxx
  passwordexpiry: None
  sambaRID: 1114
  profilepath: None
  mobileTelephoneNumber: None
  sambahome: /home/username
  CtxWFHomeDirDrive: None
  CtxCallback: None
  street: None
  CtxShadow: 00000000
  e-mail: username.Nachname@mailserver.xx
  CtxWorkDirectory: None
  CtxNWLogonServer: None
  CtxMaxConnectionTime: None
  homePostalAddress: None
  groups: cn=Domain Users,cn=groups,dc=xxx,dc=local
  overridePWHistory: None
  pwdChangeNextLogin: None
  secretary: None
  primaryGroup: cn=Domain Users,cn=groups,dc=xxx,dc=local
  CtxInitialProgram: None
  scriptpath: None
  sambaPrivileges: None
  city: None
  CtxStartprogramClient: 0
  pagerTelephoneNumber: None
  userexpiry: None
  sambaUserWorkstations: None
  username: username
  departmentNumber: None
  shell: /bin/bash
  CtxMinEncryptionLevel: None
  CtxCallbackNumber: None
  mailHomeServer: ucs3.xxx.local
  CtxCfgFlags1: 00000100
  phone: None
  gidNumber: 5001
  sambaLogonHours: None
  CtxBrokenSession: None
  locked: none
  CtxReconnectSession: None
  roomNumber: None
  homeShare: None
  gecos: username Nachname
  CtxCfgClientPrinters: 0
  jpegPhoto: None
  uidNumber: 2008
  employeeType: None
  homeSharePath: None
  CtxCfgPresent: 551e0bb0
  CtxWFHomeDir: None
  unixhome: /home/username
  homeTelephoneNumber: None
  description: None
  firstname: username
  birthday: 1977-01-11
  overridePWLength: None
  CtxMaxDisconnectionTime: None
  CtxCfgDefaultClientPrinters: 0
  displayName: username Nachname
  mailPrimaryAddress: username.Nachname@mailserver.xx
  CtxCfgClientDrivers: 0
  CtxCfgTSLogon: 0

Hallo,

mit dem Wert “0” für das Passwort-Ablaufintervall an einer Passwort-Richtlinie erreichen Sie das Verhalten, dass das Passwort-Ablaufdatum stets auf den aktuellen Tag gesetzt wird (Intervall = 0).
Sollten Sie hier wünschen, dass das Passwort des Administrators niemals abläuft, sollten Sie eine Passwort-Richtlinie für den Administrator erstellen, welche für das Passwort-Ablaufintervall keinen Wert gesetzt hat.

Nach dem Anpassen bzw. Erstellen dieser Richtlinie, müsste das Passwort für den Administrator einmalig neu gesetzt werden (selbstverständlich können Sie hier Passwort-Historie ignorieren verwenden und das gleiche Passwort setzen). Im Anschluss sollte das Feld Passwort-Ablaufdatum leer und das Passwort persistent sein.

Mit freundlichen Grüßen,
Tim Petersen

Hallo zusammen,

im Moment habe ich die Version 4.0-2 errata205 neu aufgesetzt und habe das Problem, dass ich mich ebenfalls nicht
via Administrator am Nagios anmelden kann trotz der hier beschriebenen Methode.

Ideen ?

Danke !

Hallo,

ein generelles Problem ist da nicht bekannt - evt. helfen die folgenden Topics?


Viele Grüße,
Tim Petersen

Mastodon