Keine LDAP-Auth mit OpenVPN nach Update auf 134

Post Reply
SecondLook
Posts: 1
Joined: July 10th, 2019, 3:46 pm

Keine LDAP-Auth mit OpenVPN nach Update auf 134

Post by SecondLook » July 10th, 2019, 4:09 pm

Hallo Zusammen,

ich habe nach folgenden Forum Eintrag mein OpenVPN mit LDAP-Auth eingerichtet:
viewtopic.php?f=52&t=16760&p=98799&hili ... dap#p98799

Nach Update auf auf Core134 funktioniert der Login nicht mehr. Core 131 hat noch funktioniert, dann direkt von 131 auf 134 geupdatet und jetzt bekomme ich folgende Meldungen bei OpenVPN:
LOG-File Verbindungsaufbau: (Adresse und Ähnliche Informationen entfernt)
-----------
Wed Jul 10 17:58:41 2019 OpenVPN 2.4.7 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 25 2019
Wed Jul 10 17:58:41 2019 Windows version 6.1 (Windows 7) 64bit
Wed Jul 10 17:58:41 2019 library versions: OpenSSL 1.1.0j 20 Nov 2018, LZO 2.10
Enter Management Password:
Wed Jul 10 17:58:41 2019 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Wed Jul 10 17:58:41 2019 Need hold release from management interface, waiting...
Wed Jul 10 17:58:41 2019 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Wed Jul 10 17:58:41 2019 MANAGEMENT: CMD 'state on'
Wed Jul 10 17:58:41 2019 MANAGEMENT: CMD 'log all on'
Wed Jul 10 17:58:41 2019 MANAGEMENT: CMD 'echo all on'
Wed Jul 10 17:58:41 2019 MANAGEMENT: CMD 'bytecount 5'
Wed Jul 10 17:58:41 2019 MANAGEMENT: CMD 'hold off'
Wed Jul 10 17:58:41 2019 MANAGEMENT: CMD 'hold release'
Wed Jul 10 17:58:44 2019 MANAGEMENT: CMD 'username "Auth" "Benutzer.Name"'
Wed Jul 10 17:58:44 2019 MANAGEMENT: CMD 'password [...]'
Wed Jul 10 17:58:44 2019 MANAGEMENT: CMD 'password [...]'
Wed Jul 10 17:58:44 2019 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Wed Jul 10 17:58:44 2019 MANAGEMENT: >STATE:1562774324,RESOLVE,,,,,,
Wed Jul 10 17:58:44 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]IPAdresse:1194
Wed Jul 10 17:58:44 2019 Socket Buffers: R=[8192->8192] S=[8192->8192]
Wed Jul 10 17:58:44 2019 UDP link local: (not bound)
Wed Jul 10 17:58:44 2019 UDP link remote: [AF_INET]IP-Adresse:1194
Wed Jul 10 17:58:44 2019 MANAGEMENT: >STATE:1562774324,WAIT,,,,,,
Wed Jul 10 17:58:44 2019 MANAGEMENT: >STATE:1562774324,AUTH,,,,,,
Wed Jul 10 17:58:44 2019 TLS: Initial packet from [AF_INET]IPAdresse:1194, sid=e725781b 570ead50
Wed Jul 10 17:58:44 2019 VERIFY OK: depth=1,
Wed Jul 10 17:58:44 2019 VERIFY KU OK
Wed Jul 10 17:58:44 2019 Validating certificate extended key usage
Wed Jul 10 17:58:44 2019 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Wed Jul 10 17:58:44 2019 VERIFY EKU OK
Wed Jul 10 17:58:44 2019 VERIFY X509NAME OK:
Wed Jul 10 17:58:44 2019 VERIFY OK: depth=0,
Wed Jul 10 17:58:45 2019 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-CHACHA20-POLY1305, 2048 bit RSA
Wed Jul 10 17:58:45 2019 [] Peer Connection Initiated with [AF_INET]ipadresse:1194
Wed Jul 10 17:58:46 2019 MANAGEMENT: >STATE:1562774326,GET_CONFIG,,,,,,
Wed Jul 10 17:58:46 2019 SENT CONTROL [DNSNAME]: 'PUSH_REQUEST' (status=1)
Wed Jul 10 17:58:46 2019 AUTH: Received control message: AUTH_FAILED
Wed Jul 10 17:58:46 2019 SIGUSR1[soft,auth-failure] received, process restarting
Wed Jul 10 17:58:46 2019 MANAGEMENT: >STATE:1562774326,RECONNECTING,auth-failure,,,,,
Wed Jul 10 17:58:46 2019 Restart pause, 5 second(s)
Wed Jul 10 17:58:51 2019 SIGTERM[hard,init_instance] received, process exiting
Wed Jul 10 17:58:51 2019 MANAGEMENT: >STATE:1562774331,EXITING,init_instance,,,,,
------------

Diese Problem gab es vor geraumer Zeit schon einmal, da war die basic_ldap_auth (wird für die Auth genutzt) fehlerhaft.
Die Datei liegt /usr/lib/squid/basic_ldap_auth. Allerdings bringt der Austausch gegen Datei aus Backup leider nichts.

Für mich schaut es so aus das Die Verbindung bis zur Firewall kommt, aber meinen User nicht bestätigt.
Die Dateien für die LDAP-Auth habe ich geprüft, nach Forumseintrag, hier schaut es für mich OK aus.
Leider bin ich hier aktuell mit meinen Latein am Ende, über Ideen würde ich mich freuen.

Edit: Habe mal den Verbindunsaufbau im Log mitverfolgt.
Hier erhalte ich folgenden meldung:
------------
Jul 11 07:14:20 EK-FW01 openvpnserver[21781]: IP-Adresse:53448 WARNING: Failed running command (--auth-user-pass-verify): external program exited with error status: 1
-------
Hier meine ovpnldapauth:

#!/bin/bash

BASE="dc=domainname,dc=local"
URI=ldap://DC.domainname.local
FILTER='sAMAccountName=%s'
RES=$(echo $username $password |
/usr/lib/squid/basic_ldap_auth -b "$BASE" -v 3 -D "CN=EK-FW01-LDAP,OU=SBSUsers,OU=Users,OU=MyBusiness,DC=domainname,DC=local" -w "sdfgsdfgsegrgssdfg" -f $FILTER -H $URI)
if [ "$RES" = "OK" ]; then
echo "0"
exit 0
else
echo "1"
exit 1
fi
--------------
Edit2:
.
---
Edit3: Edit2 entfernt da ich die Abfrage aus auf der Clientseite auskomentiert hatte. (War am Testen und warum auch immer war ich der Meinung dies raus zu nehmen)

Ich habe, da mir so langsam die Ideen ausgehen, auch mal die Komplette x509 Struktur neu erstellt.
Wenn hier jemand eine Idee oder einen Denkanstoß hat, würde ich mich freuen. Da dies eine schöne Lösung war, um User einfach aber sicher anzubinden.

Danke und Gruß

PS: Kann auch gerne in den VPN bereich verschoben werden, neu hier im Forum und einfach schnell runter getippt.... sorry.

Post Reply