PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Auth. per users-File und ldap



a-tobias
27.06.2014, 14:23
Erstmal Hallo an das ganze Forum,
mein Heimserver soll durch die neue DS414 Box ersetzt werden.
Dazu benötige ich aber einen Radiusserver , der alle Benutzer (liegen im LDAP), authorisiert. Z.B. für den WLAN Access Point. <- Das funktioniert auch soweit wunderbar.

Jetzt benötige ich aber zusätzlich noch die auth. mittels users-File (mod files), da mein Switch für einige Netzwerkkomponenten dynamisch vlans verteilt.

Mein Problem ist, dass ich es nicht schaffe, dass der FreeRadius server die mac adressen der geräte (also dessen "usernamen") nicht im ldap nachschlägt. Ich habe in den configs rad_site_def_ldap und rad_site_inn_ldap zum testen sogra einmal alle module auskommentiert. Trotzdem versucht er es im ldap.
Habe fast das gefühl, dass ein zusätzliche script einkompiliert wurde ?!?!

Wenn ich zum Testen den user im ldap anlege (mac adresse), dann funktioniert alles und er +bermittelt auch die infos aus der users Datei (vlan etc.).

Da man die ldap user aber nicht aus der gruppe users@domain heraus nehmen kann und sich jeder theoretisch dann mit den mac adressen einloggen könnte (da das passort ja das gleiche wie der name ist - in diesem fall), ist das keine Option.

Vielleicht hat jemand eine Idee !

Gruß Tobi

P.S.
habe bereits folgendes in den files(rad_site_def_ldap und rad_site_inn_ldap) versucht :

authorize {
...
ldap {
fail = 1
}
if(fail) {
files
}
...
}

authenticate {
...
Auth-Type LDAP {
redundant {
ldap
eap / pap / files
}
}
...
}

Offensichtlich funktioniert meine Konfiguration. Wenn ich einen Benutzernamen aus dem ldap wähle, aber ein falsches passwort eingebe, so schaut er in dem users file nach.
Scheinbar wird das script "synouser --get <name>" ausgeführt , noch bevor die ldap configs zum tragen kommen.

profhastings
19.03.2015, 22:31
Hallo,

ich habe nur das halbe Problem, denn ich möchte ausschließlich Nutzer über die users Datei authorisieren, kriege das bisher jedoch nicht hin, weil laut Log ebenfalls synouser dazwischen funkt. Ich würde mich sehr freuen, wenn Ihr mir helfen könnt!

Mein System:


Synology DS209+
DSM 4.2-3252
Synology Radius Server package v1.0-0029 (based on FreeRadius v2.1.10)

Hier meine bisherigen Ergebnisse und Einstellungen:

Ort der Haupt-Konfigurationsdatei:

/volume1/@appstore/RadiusServer/etc/raddb/radiusd.conf
Dateien für die wichtigsten Einstellungen:

/usr/local/synoradius/rad_site_inn_local (or .../rad_site_inn_ldap etc.)
/usr/local/synoradius/rad_site_def_local (or .../rad_site_def_ldap etc.)
referenziert durch diese Dateien:

/var/packages/RadiusServer/target/etc/raddb/sites-enabled/inner-tunnel
/var/packages/RadiusServer/target/etc/raddb/sites-enabled/default
wiederum referenziert durch diese Dateien:

/usr/local/synoradius/rad_site_inn
/usr/local/synoradius/rad_site_def

Ort der users Datei:

/volume1/@appstore/RadiusServer/etc/raddb/users
die wiederum auf die folgende Datei verlinkt:

/usr/local/synoradius/rad_users

Folgende Zeile habe ich zum Testen in letzterer Datei hinzugefügt:

dummyuser Cleartext-Password := "dummypassword"

Dann habe ich /usr/local/synoradius/rad_site_inn_local wie folgt modifiziert:

server inner-tunnel {
listen {
ipaddr = 127.0.0.1
$INCLUDE /usr/local/synoradius/rad_port_inner
type = auth
}

authorize {
chap
mschap
# unix
suffix
# ntdomain
update control {
Proxy-To-Realm := LOCAL
}
eap {
ok = return
}
files
# smbpasswd
# ldap
expiration
logintime
pap
}

authenticate {
Auth-Type PAP {
pap
}
Auth-Type CHAP {
chap
}
Auth-Type MS-CHAP {
mschap
}
unix
# Auth-Type LDAP {
# ldap
# }
eap
}

session {
radutmp
}

post-auth {
# ldap
Post-Auth-Type REJECT {
attr_filter.access_reject
}
}

pre-proxy {
}

post-proxy {
eap
}

} # inner-tunnel server block

und /usr/local/synoradius/rad_site_def_local entsprechend:

authorize {
preprocess
chap
mschap
digest
suffix
# ntdomain
eap {
ok = return
}
unix
files
smbpasswd
expiration
logintime
pap
}

authenticate {
Auth-Type PAP {
pap
}
Auth-Type CHAP {
chap
}
Auth-Type MS-CHAP {
mschap
}
digest
unix
eap
}

preacct {
preprocess
acct_unique
suffix
# ntdomain
files
}

accounting {
detail
unix
radutmp
exec
attr_filter.accounting_response
}

session {
radutmp
}

post-auth {
exec
Post-Auth-Type REJECT {
attr_filter.access_reject
}
}

pre-proxy {
}

post-proxy {
eap
}

Aber immer, wenn ich obigen dummyuser über einen passend eingerichteten WLAN-Access-Point einloggen will, wirft freeradius folgende Fehler im Log aus:

SYNOUserGet failed (input name [dummyuser], full name [dummyuser])
Es sieht wie gesagt so aus, als ob freeradius noch immer das User Management von Synology verwendet. Wie lässt sich das verhindern, so dass statt dessen die Benutzer aus der users Datei (bzw. /usr/local/synoradius/rad_users verwendet wird?

Hier noch eine bequeme Methode, mit der freeradius die Konfigurationsdateien neu einliest.

xargs kill -HUP < /var/packages/RadiusServer/target/var/run/radiusd/radiusd.pid
Und zu guter Letzt, um freeradius im Debug Modus zu starten (natürlich erst, nachdem das Paket zuvor im Paketzentrum gestoppt wurde):

/volume1/@appstore/RadiusServer/sbin/radiusd -X