Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!

vCenter Service startet nicht mehr

Alles zum Virtualisierungsmanagement und Servermanagement, was nicht direkt in ein festes Version-Schema paßt.

Moderatoren: irix, continuum, Dayworker

Member
Beiträge: 61
Registriert: 17.06.2006, 12:10

vCenter Service startet nicht mehr

Beitragvon brave_snoopy » 27.01.2014, 15:17

Hallo,

wir hatten heute ein erhebliches Problem mit unseren Domänencontrollern. Zum einen war für LDAPs ein falsches Zertifikat einer nicht mehr vorhanden Enterprise CA ausgestellt und zum anderen stand in der SSO Identitäts Quelle ein alter DC, welcher ersetzt wurde.

Nachdem ich das LDAPs Zertifikat auf beiden Domänencontrollern ersetzt habe (per ldp.exe kann ich mich auch vom vCenter Server aus per LDAPs Verbinden) habe ich mir die Identitätsquellen angesehen. Hier stand als primäre Quelle ein alter DC (von vor 3 Monaten drin)
Ich habe dann direkt in der SQL Datenbank die in der IMS Config Tabelle die Server angepasst und den ganzen Server neugestartet.

Der Single Sign On Service startet, aber das vCenter nicht.

Im vCenter Log (vpxd.log finde ich folgende Einträge):

Code: Alles auswählen

2014-01-27T10:59:06.401+01:00 [04628 warning 'Default'] Warning, existence of user "INTERN\benutzer" unknown, permission may not be effective until it is resolved.
2014-01-27T10:59:06.401+01:00 [04628 error 'Default'] The user account "INTERN\benutzer" could not be successfully resolved.  Check network connectivity to domain controllers and domain membership.  Users may not be able to log in until connectivity is restored.
2014-01-27T10:59:06.401+01:00 [04628 info '[SSO]'] [UserDirectorySso] GetUserInfo(INTERN\benutzer, false)


Und im SingleSignOn imsTrace. log finde ich folgendes:

Code: Alles auswählen

2014-01-27 15:15:45,402, [castle-exec-5], (PrincipalAccessSQL.java:1683), trace.com.rsa.ims.admin.dal.sql.PrincipalAccessSQL, DEBUG, SKVCENTER.intern.net,,,,SELECT IMS_PRINCIPAL.ID,IMS_PRINCIPAL.CERT_DN,IMS_PRINCIPAL.EMAIL,IMS_PRINCIPAL.FIRST_NAME,IMS_PRINCIPAL.MIDDLE_NAME,IMS_PRINCIPAL.LAST_NAME,IMS_PRINCIPAL.LOGINUID,IMS_PRINCIPAL.PASSWORD,IMS_PRINCIPAL.PRINCIPAL_IS_DESCRIPTION, IMS_PRINCIPAL_DATA.ID,IMS_PRINCIPAL_DATA.ROW_VERSION,IMS_PRINCIPAL_DATA.LAST_UPDATED_BY,IMS_PRINCIPAL_DATA.LAST_UPDATED_ON,IMS_PRINCIPAL_DATA.IDENTITY_SRC_ID,IMS_PRINCIPAL_DATA.IDENTITY_SRC_KEY,IMS_PRINCIPAL_DATA.OWNER_ID,IMS_PRINCIPAL_DATA.START_DATE,IMS_PRINCIPAL_DATA.EXPIRATION_DATE,IMS_PRINCIPAL_DATA.REGISTRATION_FLAG,IMS_PRINCIPAL_DATA.LOGINUID,IMS_PRINCIPAL_DATA.LOGIN_DATE,IMS_PRINCIPAL_DATA.ENABLE_FLAG,IMS_PRINCIPAL_DATA.IMPERSONATABLE_FLAG,IMS_PRINCIPAL_DATA.IMPERSONATOR_FLAG,IMS_PRINCIPAL_DATA.FAIL_PASSWORD_COUNT,IMS_PRINCIPAL_DATA.FAIL_PASSWORD_DATE,IMS_PRINCIPAL_DATA.FAIL_EMERGENCY_COUNT,IMS_PRINCIPAL_DATA.FAIL_EMERGENCY_DATE,IMS_PRINCIPAL_DATA.CHANGE_PASSWORD_FLAG,IMS_PRINCIPAL_DATA.CHANGE_PASSWORD_DATE,IMS_PRINCIPAL_DATA.LOCKOUT_FLAG,IMS_PRINCIPAL_DATA.EXPIRE_LOCKOUT_DATE,IMS_PRINCIPAL_DATA.EMERGENCY_LOCKOUT_FLAG,IMS_PRINCIPAL_DATA.EXPIRE_EMERGENCY_LOCKOUT_DATE,IMS_PRINCIPAL_DATA.NOTES,IMS_PRINCIPAL_DATA.AUTHENTICATOR_BIT_FLAGS,IMS_PRINCIPAL_DATA.ADMINISTRATOR_FLAG,IMS_PRINCIPAL_DATA.EXUID,IMS_PRINCIPAL_DATA.SECURITY_QUES_ANSWERS,IMS_PRINCIPAL_DATA.SECURITY_QUES_REQUIRED_AUTHN,IMS_PRINCIPAL_DATA.SECURITY_QUES_REQUIRED_REG,IMS_PRINCIPAL_DATA.SECURITY_QUES_LANGUAGE,IMS_PRINCIPAL_DATA.SECURITY_QUES_COUNTRY,IMS_PRINCIPAL_DATA.SECURITY_QUES_VARIANT,IMS_PRINCIPAL_DATA.SECURITY_QUES_RESET,IMS_PRINCIPAL_DATA.FIRST_RBA_AUTH_DATE,IMS_PRINCIPAL_DATA.LAST_USED_SECONDARY_AUTH FROM IMS_PRINCIPAL, (SELECT IMS_PRINCIPAL_DATA.ID,IMS_PRINCIPAL_DATA.ROW_VERSION,IMS_PRINCIPAL_DATA.LAST_UPDATED_BY,IMS_PRINCIPAL_DATA.LAST_UPDATED_ON,IMS_PRINCIPAL_DATA.IDENTITY_SRC_ID,IMS_PRINCIPAL_DATA.IDENTITY_SRC_KEY,IMS_PRINCIPAL_DATA.OWNER_ID,IMS_PRINCIPAL_DATA.START_DATE,IMS_PRINCIPAL_DATA.EXPIRATION_DATE,IMS_PRINCIPAL_DATA.REGISTRATION_FLAG,IMS_PRINCIPAL_DATA.LOGINUID,IMS_PRINCIPAL_LOGIN_DATE.LOGIN_DATE,IMS_PRINCIPAL_DATA.ENABLE_FLAG,IMS_PRINCIPAL_DATA.IMPERSONATABLE_FLAG,IMS_PRINCIPAL_DATA.IMPERSONATOR_FLAG,IMS_PRINCIPAL_DATA.FAIL_PASSWORD_COUNT,IMS_PRINCIPAL_DATA.FAIL_PASSWORD_DATE,IMS_PRINCIPAL_DATA.FAIL_EMERGENCY_COUNT,IMS_PRINCIPAL_DATA.FAIL_EMERGENCY_DATE,IMS_PRINCIPAL_DATA.CHANGE_PASSWORD_FLAG,IMS_PRINCIPAL_DATA.CHANGE_PASSWORD_DATE,IMS_PRINCIPAL_DATA.LOCKOUT_FLAG,IMS_PRINCIPAL_DATA.EXPIRE_LOCKOUT_DATE,IMS_PRINCIPAL_DATA.EMERGENCY_LOCKOUT_FLAG,IMS_PRINCIPAL_DATA.EXPIRE_EMERGENCY_LOCKOUT_DATE,IMS_PRINCIPAL_DATA.NOTES,IMS_PRINCIPAL_DATA.AUTHENTICATOR_BIT_FLAGS,IMS_PRINCIPAL_DATA.ADMINISTRATOR_FLAG,IMS_PRINCIPAL_DATA.EXUID,IMS_PRINCIPAL_DATA.SECURITY_QUES_ANSWERS,IMS_PRINCIPAL_DATA.SECURITY_QUES_REQUIRED_AUTHN,IMS_PRINCIPAL_DATA.SECURITY_QUES_REQUIRED_REG,IMS_PRINCIPAL_DATA.SECURITY_QUES_LANGUAGE,IMS_PRINCIPAL_DATA.SECURITY_QUES_COUNTRY,IMS_PRINCIPAL_DATA.SECURITY_QUES_VARIANT,IMS_PRINCIPAL_DATA.SECURITY_QUES_RESET,IMS_PRINCIPAL_DATA.FIRST_RBA_AUTH_DATE,IMS_PRINCIPAL_DATA.LAST_USED_SECONDARY_AUTH FROM IMS_PRINCIPAL_DATA WITH (NOLOCK) inner join IMS_PRINCIPAL_LOGIN_DATE on (IMS_PRINCIPAL_DATA.ID = IMS_PRINCIPAL_LOGIN_DATE.PRINCIPAL_ID) ) IMS_PRINCIPAL_DATA  WHERE UPPER(IMS_PRINCIPAL.LOGINUID) = UPPER(IMS_PRINCIPAL_DATA.LOGINUID) AND IMS_PRINCIPAL_DATA.IDENTITY_SRC_ID = '000000000000000000001000d0011000' AND  UPPER(IMS_PRINCIPAL.LOGINUID) = UPPER(?)   ORDER BY UPPER(IMS_PRINCIPAL.LOGINUID)
2014-01-27 15:15:45,414, [castle-exec-5], (IMSUtilImpl.java:249), trace.com.rsa.riat.utils.IMSUtil, DEBUG, SKVCENTER.intern.net,,,,Could not find user intern\skvcenter-svc in domain null
2014-01-27 15:15:45,415, [castle-exec-5], (SecurityTokenServiceImpl.java:107), trace.com.rsa.riat.sts.impl.SecurityTokenServiceImpl, ERROR, SKVCENTER.intern.net,,,,Error while trying to generate RequestSecurityTokenResponse
com.rsa.riat.ws.security.trust.authn.AuthnPluginException: Authentication Failed



Jemand eine Idee?

King of the Hill
Beiträge: 12450
Registriert: 02.08.2008, 15:06
Wohnort: Hannover/Wuerzburg
Kontaktdaten:

Beitragvon irix » 27.01.2014, 15:27

Hmm.....das "INTERN" als NETBIOS tut ja nur wenn Wins funktioniert und somit wuerde ich es erstmal mit intern.local oder wie immer die Domäne heist probieren. Des weiteren mal die Uhrzeiten auf den Systemen kontrollieren.

Als Hammermethode SSO von 5.1 auf 5.5 bringen. Es ist supportet SSO auf 5.5 und den anderen Krempel auf 5.1 zuhaben.

Gruss
Joerg

Member
Beiträge: 61
Registriert: 17.06.2006, 12:10

Beitragvon brave_snoopy » 27.01.2014, 15:40

Interessant ist aber, das es ja die ganze Zeit funktioniert hat.

Mh SSO auf 5.5. bringen ist jetzt eigentlich nicht so die beste Idee die ich vorhatte ;)

King of the Hill
Beiträge: 13253
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 27.01.2014, 16:08

Zum einen war für LDAPs ein falsches Zertifikat einer nicht mehr vorhanden Enterprise CA ausgestellt und zum anderen stand in der SSO Identitäts Quelle ein alter DC, welcher ersetzt wurde.
Dir kommt sowas nicht seltsam vor?
Wenn es damit bisher lief und auf einmal ein bereits vor Monaten entfernter DC noch gelistet wird, würde ich mir das Win-Ereignislog vornehmen und dort die letzten Einträge ansehen.
Kann es sein, daß irgendwer ein Backup eingespielt oder einen alten DC wieder hinzugefügt hat?

Guru
Beiträge: 2082
Registriert: 21.10.2006, 08:24

Beitragvon bla!zilla » 27.01.2014, 16:15

Das mit dem toten DC in der SSO Quelle ist bekannt. Da stehen per Default zwei DCs drin (wenn >= 2 vorhanden sind...). Die beiden werden aber nicht angepasst, wenn einer entfernt wird. Deswegen passt man das nach der Installation per Hand an und setzt statt dem Servernamen den Domänennamen rein. Dann wird jedes Mal per DNS ein DC ermittelt.

King of the Hill
Beiträge: 13253
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 27.01.2014, 16:18

Ist der "tote DC in der SSO-Quelle" beim vCenter 5.5 gelöst oder tritt es dort aufgrund der SSO-Änderungen überhaupt nicht auf?

Guru
Beiträge: 2082
Registriert: 21.10.2006, 08:24

Beitragvon bla!zilla » 27.01.2014, 16:24

Ich habe noch keine 5.5er Installation gesehen, bei der ein DC entfernt wurde. Müsste man testen.

Member
Beiträge: 61
Registriert: 17.06.2006, 12:10

Beitragvon brave_snoopy » 27.01.2014, 16:35

@bla!zilla: du meinst die Anpassung in der krb5.conf Datei?

Was genau soll dort wie rein? Und Was ist mit den Einstellungen in der RSA SQL Datenbank.

Guru
Beiträge: 2082
Registriert: 21.10.2006, 08:24

Beitragvon bla!zilla » 27.01.2014, 16:44

Neee. Web Client > als SSO Admin User anmelden und Identitätsquelle anpassen.

Member
Beiträge: 61
Registriert: 17.06.2006, 12:10

Beitragvon brave_snoopy » 27.01.2014, 20:36

Leider geht auch der webclient nicht


Zurück zu „vCenter / VMware VirtualCenter“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast