4
VMWare vCenter Orchestrator - Probleme bei DB-Konfiguration
Ich versuche gerade den VMWare vCenter Orchestrator zu konfigurieren und komme bei der Datenbankkonfiguration nicht weiter.
Hallo zusammen,
ich habe das folgende Problem. Ich kann bei der Konfiguration des VMWare vCenter Orchestrators keine Verbindung zur SQL 2008 DB aufbauen. Diese befindet sich auf einem separaten System, jedoch in der gleichen Domäne und sogar im gleichen Netz.
Meine derzeitige Konfiguration wie folgt aus.
Ich kann nur sagen, die Angaben stimmen. Habs unzählige Male probiert, erhalte aber immer die folgende Fehlermeldung.
Cannot connect to jdbc:jtds:sqlserver://lab-srv001:1433/VCO;domain=lab.intra;instance=lab_srv001_b. Connection error was: Anmeldefehler. Die Anmeldung stammt aus einer nicht vertrauenswürdigen Domäne und kann mit der Windows-Authentifizierung nicht verwendet werden.
Es erscheint immer die gleiche Fehlermeldung, unabhängig davon was für einen Benutzeraccount ich verwende. Selbst bei einem Domain-Admin erscheint der gleiche Fehler. Die Verbindung funktioniert zudem mit dem SQL Management Studio problemlos. Nur der Orchestrator scheint hier Probleme zu haben. Auf dem SQL Server erscheinen bei den Login versuchen jeweils die folgenden Meldungen.
Login failed. The login is from an untrusted domain and cannot be used with Windows authentication. [CLIENT: 192.168.1.12]
SSPI handshake failed with error code 0x8009030c while establishing a connection with integrated security; the connection has been closed. [CLIENT: 192.168.1.12]
Hab bereits nach einer Lösung gegoogelt. Für die Fehlermeldungen gibts zwar viele Treffer, mir hat aber nichts wirklich weitergeholfen.
Ich hab schon daran gedacht, dass der Orchestrator evtl. den falschen Treiber für den Verbindungsaufbau benutzt, hatte diesbezüglich bereits bei der Installation des vCenter Servers Probleme. Habe aber keine Möglichkeit gefunden den zu verwendenden Treiber mitzugeben.
Ich hoffe jemand kann mir helfen, ich schlag mich jetzt schon den ganzen Nachmittag damit rum. Vielen Dank.
ich habe das folgende Problem. Ich kann bei der Konfiguration des VMWare vCenter Orchestrators keine Verbindung zur SQL 2008 DB aufbauen. Diese befindet sich auf einem separaten System, jedoch in der gleichen Domäne und sogar im gleichen Netz.
Meine derzeitige Konfiguration wie folgt aus.
Ich kann nur sagen, die Angaben stimmen. Habs unzählige Male probiert, erhalte aber immer die folgende Fehlermeldung.
Cannot connect to jdbc:jtds:sqlserver://lab-srv001:1433/VCO;domain=lab.intra;instance=lab_srv001_b. Connection error was: Anmeldefehler. Die Anmeldung stammt aus einer nicht vertrauenswürdigen Domäne und kann mit der Windows-Authentifizierung nicht verwendet werden.
Es erscheint immer die gleiche Fehlermeldung, unabhängig davon was für einen Benutzeraccount ich verwende. Selbst bei einem Domain-Admin erscheint der gleiche Fehler. Die Verbindung funktioniert zudem mit dem SQL Management Studio problemlos. Nur der Orchestrator scheint hier Probleme zu haben. Auf dem SQL Server erscheinen bei den Login versuchen jeweils die folgenden Meldungen.
Login failed. The login is from an untrusted domain and cannot be used with Windows authentication. [CLIENT: 192.168.1.12]
SSPI handshake failed with error code 0x8009030c while establishing a connection with integrated security; the connection has been closed. [CLIENT: 192.168.1.12]
Hab bereits nach einer Lösung gegoogelt. Für die Fehlermeldungen gibts zwar viele Treffer, mir hat aber nichts wirklich weitergeholfen.
Ich hab schon daran gedacht, dass der Orchestrator evtl. den falschen Treiber für den Verbindungsaufbau benutzt, hatte diesbezüglich bereits bei der Installation des vCenter Servers Probleme. Habe aber keine Möglichkeit gefunden den zu verwendenden Treiber mitzugeben.
Ich hoffe jemand kann mir helfen, ich schlag mich jetzt schon den ganzen Nachmittag damit rum. Vielen Dank.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 160467
Url: https://administrator.de/contentid/160467
Printed on: April 19, 2024 at 00:04 o'clock
4 Comments
Latest comment
Hallo,
solltest du nicht unten den Haken bei "Windows Authentication Mode" setzen ?
Dein Username hat ein "\" drin, d.h. das ist ein Windows-User und kein reiner Datenbank-User ...
MfG
solltest du nicht unten den Haken bei "Windows Authentication Mode" setzen ?
Dein Username hat ein "\" drin, d.h. das ist ein Windows-User und kein reiner Datenbank-User ...
MfG
Moin,
ich würde dann noch checken, ob der User auch Rechte auf dem SQL hat ... ohne das geht es nämlich auch nicht
Gruß
24
ich würde dann noch checken, ob der User auch Rechte auf dem SQL hat ... ohne das geht es nämlich auch nicht
Gruß
24
Bei dem Haken bei "Windows Authentication Mode" war ich mir auch nicht sicher. Ich hab beides ausprobiert und beides ging nicht. Ich denke aber es ist schon richtig, dass der Haken nicht gesetzt ist. Wie ich das verstanden habe, ist der Haken dazu da um NTLM Authentifizierung zu forcieren. Die Authentifizierung sollte doch aber eigentlich über Kerberos erfolgen.
Der User ist tatsächlich ein Windows User. Soweit ich weiss, unterschiedet der Orchestrator anhand der angegebenen Domäne zwischen Windows- und SQL-Authentifizierung. D.h. wenn keine Domäne angegeben wird, nimmt der Orchestrator an, dass es sich um einen SQL User handelt und ansonsten geht er von Windows-Authentifizierung aus.
Der Benutzer hat zudem db_owner Rechte auf der Datenbank. Das sollte daher kein Problem sein. Wie gesagt, habe ich auch versucht mit einem Domain-Admin eine Verbindung zur DB herzustellen. Dieser hat lokale Admin-Rechte auf dem SQL- und dem Orchestrator-Server auch auf den Datenbanken. Ich glaube daher nicht, dass es sich um ein Berechtigungsproblem handelt. Datenbankseitig ist die Authentifizierung natürlich auf Mixed-Mode gestellt, d.h. Windows- und SQL-Authentifizierung. Ausserdem funktioniert die Anmeldung an der DB ja mit dem SQL Management Studio. Wenn es sich um ein Berechtigungsproblem handeln würde, dürfte ja auch das nicht funktionieren.
mfg
Der User ist tatsächlich ein Windows User. Soweit ich weiss, unterschiedet der Orchestrator anhand der angegebenen Domäne zwischen Windows- und SQL-Authentifizierung. D.h. wenn keine Domäne angegeben wird, nimmt der Orchestrator an, dass es sich um einen SQL User handelt und ansonsten geht er von Windows-Authentifizierung aus.
Der Benutzer hat zudem db_owner Rechte auf der Datenbank. Das sollte daher kein Problem sein. Wie gesagt, habe ich auch versucht mit einem Domain-Admin eine Verbindung zur DB herzustellen. Dieser hat lokale Admin-Rechte auf dem SQL- und dem Orchestrator-Server auch auf den Datenbanken. Ich glaube daher nicht, dass es sich um ein Berechtigungsproblem handelt. Datenbankseitig ist die Authentifizierung natürlich auf Mixed-Mode gestellt, d.h. Windows- und SQL-Authentifizierung. Ausserdem funktioniert die Anmeldung an der DB ja mit dem SQL Management Studio. Wenn es sich um ein Berechtigungsproblem handeln würde, dürfte ja auch das nicht funktionieren.
mfg
Ich hab im Security Log die folgende Meldung gefunden. Hilft das vielleicht jemandem weiter? Beim googeln bin ich auf Hinweise gestossen, wonach der Fehler evtl. mit der Authentifizierung zusammenhängen könnte. Sprich: Client nutzt NTLM aber Server verlangt NTLMv2 oder sowas. Ich hab jetzt mal die Verschlüsselung beidseitig deaktiviert und den "LAN Manager authentication level" auf "Send LM & NTLM - use NTLMv2 session security if negotiated" gestellt (Local Security policies). Hat aber leider auch nichts gebracht. Vielleicht könnt ihr mit der Meldung ja was anfangen.
An account failed to log on.
Subject:
Security ID: NULL SID
Account Name: -
Account Domain: -
Logon ID: 0x0
Logon Type: 3
Account For Which Logon Failed:
Security ID: NULL SID
Account Name: lab\labsrv-vCO
Account Domain: LAB.INTRA
Failure Information:
Failure Reason: Unknown user name or bad password.
Status: 0xc000006d
Sub Status: 0xc0000064
Process Information:
Caller Process ID: 0x0
Caller Process Name: -
Network Information:
Workstation Name:
Source Network Address: -
Source Port: -
Detailed Authentication Information:
Logon Process: NtLmSsp
Authentication Package: NTLM
Transited Services: -
Package Name (NTLM only): -
Key Length: 0
This event is generated when a logon request fails. It is generated on the computer where access was attempted.
The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.
The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).
The Process Information fields indicate which account and process on the system requested the logon.
The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.
The authentication information fields provide detailed information about this specific logon request.
- Transited services indicate which intermediate services have participated in this logon request.
- Package name indicates which sub-protocol was used among the NTLM protocols.
- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.
An account failed to log on.
Subject:
Security ID: NULL SID
Account Name: -
Account Domain: -
Logon ID: 0x0
Logon Type: 3
Account For Which Logon Failed:
Security ID: NULL SID
Account Name: lab\labsrv-vCO
Account Domain: LAB.INTRA
Failure Information:
Failure Reason: Unknown user name or bad password.
Status: 0xc000006d
Sub Status: 0xc0000064
Process Information:
Caller Process ID: 0x0
Caller Process Name: -
Network Information:
Workstation Name:
Source Network Address: -
Source Port: -
Detailed Authentication Information:
Logon Process: NtLmSsp
Authentication Package: NTLM
Transited Services: -
Package Name (NTLM only): -
Key Length: 0
This event is generated when a logon request fails. It is generated on the computer where access was attempted.
The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.
The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).
The Process Information fields indicate which account and process on the system requested the logon.
The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.
The authentication information fields provide detailed information about this specific logon request.
- Transited services indicate which intermediate services have participated in this logon request.
- Package name indicates which sub-protocol was used among the NTLM protocols.
- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.
