Radius erweiterte RADIUS Konfiguration

[JudgeDredd]

Hallo Zusammen,

zur Zeit stehe ich vor einem Problem bzgl. des RADIUS-Servers aus dem offiziellen Synology-Paket.

Mein Vorhaben ist es, User/Clients mittels der Hunt-Groups zu Filtern.

Zunächst habe ich:

/volume1/@appstore/RadiusServer/etc/raddb/modules/preprocess
/volume1/@appstore/RadiusServer/etc/raddb/huntgroups

mit Permission 755 ausführbar gemacht.

In der Datei:
/volume1/@appstore/RadiusServer/etc/raddb/huntgroups

AccessPoint1 NAS-IP-Address == 10.1.1.1, NAS-Port-Id == 10
AccessPoint2 NAS-IP-Address == 10.1.1.2, NAS-Port-Id == 20

und in der Datei:
/usr/local/synoradius/rad_users

DEFAULT Huntgroup-Name == "AccessPoint1", Ldap-Group == "ld_allow_ap1", Auth-Type := eap
DEFAULT Huntgroup-Name == "AccessPoint2", Ldap-Group == "ld_allow_ap2", Auth-Type := eap
DEFAULT Auth-Type := Reject

diese Eintragungen gemacht.

Wenn sich nun ein User mittels 802.1x versucht am AccessPoint1 zu authentifizieren, erhalte ich im RADIUS Log:

Auth: Login incorrect: [BenutzerName/<via Auth-Type = Reject>] (from client AP001 port 10 cli ca2b6fc7def7)

Natürlich befindet sich der Benutzer in der Ldap-Gruppe "ld_allow_ap1". Sobald ich in "/usr/local/synoradius/rad_users" den Huntgroup Filter entferne und nur noch die Ldap-Group Abfrage setze, funktioniert die Anmeldung am AccessPoint einwandfrei.
Daher gehe ich davon aus, das irgendwo ein Fehler in den Huntgroups ist.
Hat schonmal Jemand das so, oder so ähnlich mit dem original Syno-RADIUS zum laufen bekommen und kann mir einen Tip geben ?
Leider hat mir die FreeRADIUS-Doku zu diesem Thema nicht weitergeholfen
Ich würde nur ungern auf des IPKG Paket ausweichen.

Gruß,
Andreas

 

[JudgeDredd]

Da ich mittlerweile mein Problem gelöst habe, hier kurz meine Vorgehensweise, auch wenn die RADIUS-Liebhabergemeinde doch sehr klein zu sein scheint

In der Datei "/usr/local/synoradius/rad_users" müssen noch zwei Zeilen eingefügt werden:

DEFAULT Huntgroup-Name != "AccessPoint1", Ldap-Group == "ld_allow_ap1", Auth-Type := Reject
DEFAULT Huntgroup-Name != "AccessPoint2", Ldap-Group == "ld_allow_ap2", Auth-Type := Reject
DEFAULT Ldap-Group == "ld_allow_ap1", Auth-Type := eap
DEFAULT Ldap-Group == "ld_allow_ap2", Auth-Type := eap
DEFAULT Auth-Type := Reject

Dadurch wird in den ersten beiden Zeilen geprüft, ob die richtige LDAP-Gruppe über den richtigen AccessPoint reinkommt und wenn nicht gleich abgewiesen.
In Zeile 3 & 4 wird der LDAP-Gruppe dann der Authentifizierungsmodus zugwiesen.

 

[Star TUX]

Hallo!

Ich gehöre auch zur RADIUS-Liebhabergemeinde

Auch wenn der Thread jetzt schon etwas älter ist, möchte ich hier kurz meine Erfahrungen einbringen. Ich habe eine ähnliche RADIUS-Konfiguration auf meiner DiskStation laufen, wobei ich die beiden Files, wie oben beschrieben, ausführbar gemacht und lediglich die Datei "/volume1/@appstore/RadiusServer/etc/raddb/huntgroups" verändert habe. Bei mir sieht das so aus:

ap1   NAS-IP-Address == 192.168.1.1
      Group == ap1_allowed

ap2   NAS-IP-Address == 192.168.2.1
      Group == ap2_allowed

An AccessPoint 1 dürfen sich nur Benutzer anmelden, die Mitglied der Gruppe "ap1_allowed" sind. An AP2 nur jene, die Mitglied der Gruppe "ap2_allowed" sind.

Bis kürzlich hat das wunderbar funktioniert, seit dem letzten Update des offiziellen RADIUS-Paketes leider nicht mehr. Es scheint so als würden die huntgroups völlig ignoriert werden. Hat jemand ähnliche Erfahrungen gemacht? Hast du das Update gemacht und funktioniert es bei Dir noch, JudgeDredd?

EDIT: Funktioniert auch mit der neuesten Version (1.1-0072)!

Gruß,
Patrick

 

[JudgeDredd]

Hi Star TUX,

also nur mit Änderungen in der ".../etc/raddb/huntgroups" hat es bei mir noch nie funktioniert.

In der ".../etc/raddb/eap.conf" habe ich noch den Request durch den Tunnel aktivieren müssen:

"copy_request_to_tunnel" und "use_tunneled_reply"
auf " = yes" gesetzt.

Und in der ".../etc/raddb/users" habe ich dann stehen:

DEFAULT Ldap-Group == "LDAP_Alpha, Huntgroup-Name = Alpha, Auth-Type := EAP
DEFAULT Auth-Type := Reject

Ausserdem habe ich noch die Datei ".../etc/raddb/modules/preprocess" mit chmod 755 ausführbar gemacht.

Da für mich aber bei DSM 4.2 leider Schluss ist, verwende ich die RADIUS Version 1.0-0029

Falls Du schon etwas "weiter" bist, ist meine Anpassung evtl. nicht mehr 100% richtig.

Gruß,
Andreas

 

[Star TUX]

Hallo Andreas,

ich habe nun alles noch einmal konfiguriert und es läuft wieder einwandfrei mit der neusten Version. Beim Update gehen alle "manuellen" Konfigurationen verloren.

Zu meiner Konfiguration: Bei mir funktioniert das alleinig durch Anpassung von ".../etc/raddb/huntgroups", allerdings verwende ich keine LDAP-Gruppen, sondern die lokalen auf der DS.

Danke für Deine Tipps!

Grüße,
Patrick

 

[JudgeDredd]

Beim Update gehen alle "manuellen" Konfigurationen verloren

Ach, ich dachte das hättest Du nach dem Update bereits gecheckt
Da hätten wir das ganze auch abkürzen können, das die Anpassungen verloren gehen ist mir bekannt.

Hauptsache es rennt alles wieder ...

 

[Star TUX]

Hauptsache es rennt alles wieder ...

So ist es

 

[onkelandy]

Hilfe!

Hallo ihr zwei "Einsamen"!

Ich versuche verzweifelt, die Synology-Sache mit wechselseitigen Zertifikaten zum Laufen zu bringen.. es will einfach nicht. Radius Server an sich mit automatischem Anbieten des Zertifikats funktioniert, aber sobald ich mittels Apple Configuration die Profile für die Clients mit Client-Zertifikaten hergestellt und installiert habe, bekomme ich an meinen Apple Geräten ein "fehlgeschlagen". Das Log vom Radius Server zeigt an:

Auth	2014-12-04 01:00:55	Login incorrect (TLS Alert read:warning:close notify): [onkelandy/<via Auth-Type = EAP>] (from client TPLink port 0 cli 1xx-xx-xx)
Error	2014-12-04 01:00:55	SSL: SSL_read failed in a system call (-1), TLS session fails.
Error	2014-12-04 01:00:55	rlm_eap: SSL error error:140940E5:lib(20):func(148):reason(229)
Error	2014-12-04 01:00:55	TLS_accept: failed in SSLv3 read client certificate A
Error	2014-12-04 01:00:55	TLS Alert read:warning:close notify

Hab schon alles nach diesem Fehler gegoogelt, aber keine Lösung gefunden
Ich möchte die lokalen Nutzer der Synology nutzen, kein LDAP. Ohne Client Zertifikat funktioniert alles einwandfrei.
Meine eap.conf sollte eigtl. auch passen (PASSWORT = tatsächliche Pwd):

               eap {
                default_eap_type = ttls
                #default_eap_type = mschapv2
                timer_expire     = 60
                ignore_unknown_eap_types = no
                cisco_accounting_username_bug = no
                max_sessions = 4096

                md5 {
                }

                leap {
                }

                gtc {
                        auth_type = PAP
                }

                tls {
                        certdir = /volume1/homes/onkelandy/openvpn/keys
                        cadir = /volume1/homes/onkelandy/openvpn/keys

                        private_key_password = PASSWORT
                        private_key_file = ${certdir}/server.key
                        certificate_file = ${certdir}/server.crt

                        CA_file = ${certdir}/ca.crt

                        dh_file = ${certdir}/dh1024.pem
                        random_file = /volume1/@appstore/RadiusServer/etc/raddb/certs/random
                     CA_path = ${certdir}
                        cipher_list = "DEFAULT"
                        make_cert_command = "${certdir}/bootstrap"
                        verify {
                        }
                }

                ttls {
                        default_eap_type = md5
                        copy_request_to_tunnel = yes
                        use_tunneled_reply = yes
                        virtual_server = "inner-tunnel"
                }

                peap {
                        default_eap_type = md5
                        copy_request_to_tunnel = yes
                        use_tunneled_reply = yes
                        virtual_server = "inner-tunnel"
                }

                mschapv2 {
                }
        }

Wie man sieht, habe ich die Zertifikate alle für OpenVPN angelegt, was ja nach dem gleichen Schema läuft. Möchte so auch die gleichen certs und keys nutzen, ich hoffe, das ist kein grober Denkfehler von mir. Mit OpenVPN funktioniert die Kommunikation einwandfrei - kann von allen Geräten aus eine sichere Verbindung aufbauen. Firewall hab ich kurzfristig in der Synology deaktiviert, an der liegt's also auch nicht.

Das Profil habe ich mir wie folgt angelegt: client. crt + client.key in ein p12 File umgewandelt mittels openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt -certfile CACert.crt.

Dieses Zertifikat dann als "Identitiy Certificate" definiert, das ca.crt hingegen als "normales" trusted Zertifikat. Kann gerne noch weitere Infos geben, aber vielleicht habt ihr ja auch so schon eine Idee? File- und Directory-Permissions habe ich im Übrigen soweit auf 0644 angepasst, sodass das auch klappen sollte. Kann aber durchaus sein, dass es doch in Rechteproblem ist..?

10000 Dank für eure Hilfe!

 

[JudgeDredd]

Hallo onkelandy und willkommen im Forum,

tja, leider kann ich zu der Cert-Authentifizierung nicht besonders viel beitragen, weil ich sie einfach nicht nutze. Was aber helfen würde, ist, wenn Du mal das debug-Log einschaltest. Dann würde man mehr Infos haben als Deine paar Zeilen.
Dazu musst Du in der Datei:
/volume1/@appstore/RadiusServer/syno_bin/RadiusServer.sh

in der Funktion StartRAD()
in der Zeile "var/pack.....sbin/radiusd

Am Ende ein "-X >/root/rad_debug.log" anhängen.

Danach startest Du den RADIUS neu mit:
/volume1/@appstore/RadiusServer/syno_bin/RadiusServer.sh restart

Da er das Log nun in eine Datei umleitet, beendet der Prozess nicht und Du kannst mit einer zweiten Session Dir die Log-Datei unter "/root/rad_debug.log" ansehen.

Evtl. findest Du dort ja ein paar Infos, wo der Schuh drückt. Zumindest mir hat es immer bei der Fehlersuche geholfen.

Gruß,
Andreas

 

[onkelandy]

Heho Judge!

Danke für die nette und rasche Hilfe, allerdings muss ich massiv vor deiner Lösung warnen! Wenn man hier im Startup Script herum fummelt und das NAS neu startet, hängt sich das Ding auf. Es heißt dann "Starting Services" und man kann gar nichts mehr machen

Ich habe jetzt aber einfach manuell das Service gestoppt und mit dem unten angeführten Befehl den Debug Mode gestartet. So hat es auch funktioniert und ich konnte ein paar Infos bekommen. Wenngleich ich nicht genau weiß, was ich jetzt eigtl. alles gemacht habe, um zum Erfolg zu kommen.

Sonderbar jedenfalls: wenn ich auf einem Device 2 verschiedene WLAN IDs konfigurieren möchte und die Profile dazu im Apple Configurator erstelle und hochlade, dann funktioniert immer nur die jeweils andere SSID. Daher habe ich jetzt ein Profil erstellt, bei dem eine fiktive SSID eingetragen ist. Und siehe da - nach Umstellen des Modus auf EAS-TLS funktioniert nun alles, juhu!

Serverseitig habe ich crt und key File gegen ein pem File ausgetauscht, in dem sowohl crt als auch key gespeichert sind. Und das ca.crt hab ich auch in ein pem konvertiert. Ob das nötig war, weiß ich nicht.

Vielleicht kann ich so ja auch wem anderen helfen, der hier drüber stolpern sollte.