Datevconnect einrichten

[#1]

Hallo liebe Leute,

entschuldigt falls die Frage etwas dumm klingt aber wie kommuniziere ich mit dem Datevconnect wenn ich es mal an meiner Installation eingerichtet habe?

Gibts da eine .dll? Welches Format müssen meine Anfragen haben oder muss ich die Schnittstelle direkt per https ansprechen? Ich hab im Developer Forum dazu nichts gefunden.

Viele Grüße

Tobias

[#2 · Accepted solution]

Hallo,

die Schnittstelle muss wie der der Dokumentation via http/https angesprochen werden.

Alle Feinheiten finden Sie im Developer Portal zu dem jeweiligem Programm welches Sie ansprechen möchten.

Grüße

[#3]

Danke für den Hinweis, ich habs jetzt auch gefunden 🙂
Schönes Wochenende wünsch ich Ihnen

[#4]

Guten Morgen zusammen,

ich versuche aktuell, DATEVconnect Rechnungswesen aus unserem Kanzleinetz anzusprechen und stoße dabei auf ein Authentifizierungsproblem.

DATEVconnect läuft auf einem Arbeitsplatzrechner, auf dem auch die DATEV-Programme installiert sind (ich hatte es zunächst auf dem Fileserver, dort sind aber die Programm nicht installiert). Direkt auf diesem Rechner funktioniert der Aufruf problemlos, z. B.:

https://localhost:58452/datev/api/accounting/v1/clients

Auch mit meinem eigenen Windows-/DATEV-Benutzer werden die Mandanten korrekt geliefert. Benutzerzuordnung und DATEV-Rechte scheinen daher zu passen.

Rufe ich dieselbe Schnittstelle jedoch von einem anderen Domänen-PC über

https://RECHNERNAME:58452/datev/api/accounting/v1/clients

auf, erhalte ich immer HTTP 401 – Unauthorized.

Das DATEVconnect-Zertifikat ist auf dem aufrufenden PC als vertrauenswürdig eingerichtet, sodass TLS/HTTPS funktioniert. Der Server bietet Negotiate, NTLM und Basic zur Authentifizierung an.

Beim Remote-Aufruf wird laut Ereignisanzeige auf dem DATEVconnect-Rechner tatsächlich eine Kerberos-Anmeldung versucht, diese endet aber mit Ereignis 4625 / Status 0xC000006D. Direkt auf dem DATEVconnect-Rechner funktioniert derselbe Benutzer hingegen.

Die Domänenverbindung des DATEVconnect-Rechners ist laut Test-ComputerSecureChannel und nltest in Ordnung.

Hat jemand DATEVconnect in einer vergleichbaren Konstellation erfolgreich von einem anderen Arbeitsplatz im selben AD-Netz angesprochen? Gibt es hierfür eine besondere DATEVconnect-Einstellung bzw. etwas bei der Windows-Authentifizierung zu beachten?

Ich freue mich über jeden Hinweis, der das Problem etwas eingrenzen kann.

Viele Grüße,

Thorsten Müller

[#5]

Moin zusammen!

Ich ergänze meine Frage noch einmal: spricht irgendetwas dagegen, DATEVconnect im Netz auf mehreren (oder allen) Clients laufen zu lassen?

Das Authorisierungsproblem (Fehler 401) konnte ich leider noch nicht lösen.

Viele Grüße,

Thorsten Müller

[#6]

Hallo,

für mich ist die Info das wichtigste. "Ereignis 4625 / Status 0xC000006D". Es fehlt noch der Substatus.

Ich durfte vor einiger Zeit dies mal für einen Kunden ausarbeiten, kann es jetzt wiederverwenden. Vielleicht hilft es.

Protokollname: Security

Quelle:        Microsoft-Windows-Security-Auditing

Ereignis-ID:   4625

Schlüsselwörter: Überwachung gescheitert

Antragsteller:
Sicherheits-ID: Netzwerkdienst
Kontoname: _systemname_$
Kontodomäne: _domänenname_
Anmelde-ID: 0x3E4

Anmeldetyp: 3

Konto, für das die Anmeldung fehlgeschlagen ist:
Sicherheits-ID: NULL SID
Kontoname: _username_
Kontodomäne: _systemname_

Fehlerinformationen:
Fehlerursache: Unbekannter Benutzername oder ungültiges Kennwort.
Status: 0xC000006D (Beispiel)
Unterstatus:: 0xC000006A (Beispiel)

Prozessinformationen:
Aufrufprozess-ID: 0x_hexwert_
Aufrufprozessname: C:\Program Files (x86)\DATEV\SYSTEM\Datev.Framework.RemoteServiceModel.GenericService2010.exe

Das kann wie folgt gelesen werden:

Eine über das Netzwerk (Anmeldetyp 3) erfolgte Anfrage,

an einen unter Netzwerkdienst laufenden Prozess C:\Program Files (x86)\DATEV\SYSTEM\Datev.Framework.RemoteServiceModel.GenericService2010.exe

auf dem System _systemname_$ / : _domänenname_

wurde die Anmeldung des Benutzers _username_ wegen Unbekannter Benutzername oder ungültiges Kennwort. abgelehnt.

Das ist eine Restanfrage wahrscheinlich mit Basic Authentifizierung (Benutzername und Kennwort wird der Anfrage mitgegebene) an den DATEVconnect Dienst der unter dem User Netzwerkdienst ausgeführt wird.

Folgende Status/Unterstatus Infos habe ich gefunden:

Status\Sub-Status-Code	Beschreibung
0XC000005E	Zurzeit sind keine Anmeldeserver verfügbar, um die Anmeldeanforderung zu bedienen.
0xc0000064	Benutzeranmeldung mit falsch geschriebenem oder fehlerhaftem Benutzerkonto
0xC000006A	Benutzeranmeldung mit falsch geschriebenem oder fehlerhaftem Kennwort
0XC000006D	Dies liegt entweder an einem fehlerhaften Benutzernamen oder an Authentifizierungsinformationen.
0XC000006E	Unbekannter Benutzername oder fehlerhaftes Kennwort.
0xC000006F	Benutzeranmeldung außerhalb autorisierter Stunden
0xC0000070	Benutzeranmeldung von nicht autorisierten Workstations
0xC0000071	Benutzeranmeldung mit abgelaufenem Kennwort
0xC0000072	Vom Administrator deaktivierte Benutzeranmeldung für das Konto
0XC00000DC	Gibt an, dass sich der SAM-Server im falschen Zustand befand, um den gewünschten Vorgang auszuführen.
0XC0000133	Uhren zwischen DC und anderen Computern zu weit außerhalb der Synchronisierung
0XC000015B	Dem Benutzer wurde der angeforderte Anmeldetyp (aka Logon right) auf diesem Computer nicht gewährt.
0XC000018C	Die Anmeldeanforderung ist fehlgeschlagen, da die Vertrauensstellung zwischen der primären Domäne und der vertrauenswürdigen Domäne fehlgeschlagen ist.
0XC0000192	Es wurde versucht, sich anzumelden, aber der Netlogon -Dienst wurde nicht gestartet.
0xC0000193	Benutzeranmeldung mit abgelaufenem Konto
0XC0000224	Der Benutzer muss bei der nächsten Anmeldung das Kennwort ändern.
0XC0000225	Offenbar ein Fehler in Windows und kein Risiko
0xC0000234	Benutzeranmeldung mit gesperrtem Konto
0XC00002EE	Fehlergrund: während der Anmeldung ist ein Fehler aufgetreten.
0XC0000413	Anmeldefehler: der Computer, an dem Sie sich anmelden, ist durch eine Authentifizierungs Firewall geschützt. Das angegebene Konto darf sich beim Computer nicht authentifizieren.
0x0	Status OK.

Das muss weiter analysiert werden, wieso der User hier abgelehnt wird.

[#7]

Guten Morgen @Michael_Crome!

Ganz lieben Dank für das ausführliche Feedback!

Bei mir lautet der Unterstatus leider 0x0 ("OK"), daher ergibt sich daraus kein genauerer Hinweis. Auffällig ist außerdem, dass im Ereignis ausdrücklich

Anmeldeprozess: Kerberos und
Authentifizierungspaket: Kerberos steht.

Derselbe Benutzer funktioniert direkt auf dem DATEVconnect-Rechner problemlos. Dort liefert curl --negotiate HTTP 200. Vom anderen Domänen-PC liefert derselbe Aufruf HTTP 401 und erzeugt das 4625-Ereignis.

Nach einem Remote-Aufruf liegt auf dem Client ein Kerberos-Ticket HTTP/Client @ Domain.LOCAL vor. Beim erfolgreichen lokalen Aufruf auf MRD-CD entsteht dagegen kein entsprechendes HTTP-Kerberos-Ticket.

Könnte es daher sein, dass DATEVconnect lokal auf NTLM zurückfällt und der Kerberos-Zugriff von einem anderen Rechner aus an der Konfiguration des Dienstes bzw. der SPN-/Windows-Authentifizierung scheitert?

Freundliche Grüße,

Thorsten Müller

[#8]

Hallo,

dass lokal NTLM verwendet wird, glaube ich nicht. Aber dass lokal andere Wege genommen werden bestimmt.

DATEVconnect kann mit WindowsAuth und BasicAuth sich authentifizieren.

Man kann BasicAuth erzwingen, wenn man die Abfrage in einem InPrivat Browser Fenster ausführt. Um weiter Fehlerquellen auszuschließen würde ich erst mal mit der einfachsten abfrage testen.

https://<servername>:58452/datev/api/diagnostics/v1/echo/

Das lokal am DATEVconnect PC in einem InPrivat Browser.

Dann noch mal am Client, an dem es nicht geht, in einem InPrivat Browser.

Was ich tatsächlich auch in Erwägung ziehen würde, ist die beiden Systeme aus der Domäne entfernen und wieder aufnehmen. Nicht dass doch eine Problem vorliegt.

Sie haben geschrieben dass der DATEVconnect Dienst am Server mal gelaufen ist. Gibt es den Dienst noch, wenn ja kann man  den obigen TestRequest auch mal gegen diesen Dienst laufen lassen.

Dann noch, ich gehe davon aus dass der DATEVconnect Test (enthalten im Testtool dstest) keine Fehler aufzeigt.

... mehr fällt mir gerade nicht ein. 

[#9]

Hier funktioniert es (per PowerShell) bei deaktiviertem NTLM.

$Headers = @{
    "Accept" = "application/json"
}
$response = Invoke-RestMethod -UseBasicParsing `
    -UseDefaultCredentials `
    -Headers $Headers `
    -ContentType "application/json" `
    -Uri "https://smf122fs01:58452/datev/api/diagnostics/v1/echo/" `
    -Method Get

$response

Test war von einem Terminalserver auf die DATEVconnect API auf dem Fileserver.

[#10]

Hallo @janm!

Danke für die Hinweis, führt aber leider bei mir zu demselben Fehler:

Invoke-RestMethod : Der Remoteserver hat einen Fehler zurückgegeben: (401) Nicht autorisiert.

Die letzte Antwort von @Michael_Crome (danke dafür!!) muss ich mir noch in Ruhe anschauen, das schaffe jetzt im laufenden Betrieb nicht.

Viele Grüße,

Thorsten Müller

[#11]

Dieser Powershell-Befehl aus einer RDS-Sitzung klappt hier. Wir hatten mit einem Benutzer Probleme, die gelöst wurden. Versuche dies mal und teile die Meldung mit. Evtl. hilft dann unserer Lösung.

$uri = "https://localhost:58452/datev/api/accounting/v1/clients"

try {
    $response = Invoke-WebRequest `
        -Uri $uri `
        -UseDefaultCredentials `
        -UseBasicParsing `
        -TimeoutSec 15

    Write-Host "DATEVconnect-Anmeldung erfolgreich." -ForegroundColor Green
    Write-Host "HTTP-Status: $($response.StatusCode)"
}
catch {
    $response = $_.Exception.Response

    if ($response) {
        Write-Host "HTTP-Status: $([int]$response.StatusCode)"
        Write-Host "Statusbeschreibung: $($response.StatusDescription)"
    }
    else {
        Write-Host $_.Exception.Message -ForegroundColor Red
    }
}

[#12]

Die Lösung hier war, dass der Benutzer, bei dem die Anmeldung an DATEV-Connect mit dem obigen Befehl nicht funktionierte, in der DATEV-Benutzerverwaltung nicht in einer bestimmten DATEV-Gruppe (Alle Freigaben) war.

Nachdem der Benutzer der Gruppe hinzugefügt wurde, klappt es.

[#13]

Hallo @oliverstippe!

Gerade getestet, liefert aber auch

HTTP-Status: 401
Statusbeschreibung: Unauthorized

localhost habe ich durch den Clientnamen ersetzt, auf dem DATEVconnect läuft.

Die anderen Vorschläge muss ich noch testen. Worst case würde ich einfach auf den Clients DATEVconnect installieren, auch wenn es so nicht gedacht ist.

Viele Grüße,

Thorsten Müller

[#14]

---

@thorstenmüller  schrieb:

Moin zusammen!

Ich ergänze meine Frage noch einmal: spricht irgendetwas dagegen, DATEVconnect im Netz auf mehreren (oder allen) Clients laufen zu lassen?

Das Authorisierungsproblem (Fehler 401) konnte ich leider noch nicht lösen.

Viele Grüße,

Thorsten Müller

---

Du musst connect nicht auf allen Servern installieren, das läuft ja im Netzwerk, da reicht einer.