vCenter Service startet nicht mehr

[brave_snoopy]

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?

[irix]

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

[brave_snoopy]

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

[Dayworker]

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?

[bla!zilla]

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.

[Dayworker]

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?

[bla!zilla]

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

[brave_snoopy]

@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.

[bla!zilla]

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

[brave_snoopy]

Leider geht auch der webclient nicht