RE: Re: Re: Re: Configure Freeradius Server on a Synology NAS to Authenticate Cisco RV340 Users
Hi Fajar, Just to be clear: the user accounts and groups already exist in Synology's local database. My goal is to return the users' group as a Class attribute in the authentication reply to the RADIUS client (Cisco VPN router). Here's what I did (working config files are located in /usr/local/synoradius/): 1. Created /usr/local/synoradius/groups file with the following content: update reply { Class := "%{Group}" } 2. Updated the post-auth statement of /usr/local/synoradius/rad_site_def_local file as follows: post-auth { exec $INCLUDE /usr/local/synoradius/groups Post-Auth-Type REJECT { attr_filter.access_reject } 3. Restarted the server and tested. No go. The client log reads "charon: Localdb:authorization failed as group is NULL". Below is the server log: Type Date & Time Event 2019-09-04 18:59:06 Info Ready to process requests 2019-09-04 18:59:06 Debug (0) Cleaning up request packet ID 166 with timestamp +36671 2019-09-04 18:59:01 Debug Waking up in 4.9 seconds. 2019-09-04 18:59:01 Debug (0) Finished request 2019-09-04 18:59:01 Debug (0) Class := 0x 2019-09-04 18:59:01 Debug (0) Sent Access-Accept Id 166 from 192.168.1.101:1812 to 192.168.1.100:57745 length 0 2019-09-04 18:59:01 Auth (0) Login OK: [username] (from client RV340 port 11121) 2019-09-04 18:59:01 Debug (0) } # post-auth = noop 2019-09-04 18:59:01 Debug (0) } # update reply = noop 2019-09-04 18:59:01 Debug (0) Class := 0x 2019-09-04 18:59:01 Debug (0) --> 2019-09-04 18:59:01 Debug (0) EXPAND %{Group} 2019-09-04 18:59:01 Debug (0) update reply { 2019-09-04 18:59:01 Debug (0) [exec] = noop 2019-09-04 18:59:01 Debug (0) modsingle[post-auth]: returned from exec (rlm_exec) 2019-09-04 18:59:01 Debug (0) modsingle[post-auth]: calling exec (rlm_exec) 2019-09-04 18:59:01 Debug (0) post-auth { 2019-09-04 18:59:01 Debug (0) # Executing section post-auth from file /usr/local/synoradius/rad_site_def_local 2019-09-04 18:59:01 Debug (0) } # Auth-Type PAP = ok 2019-09-04 18:59:01 Debug (0) [pap] = ok 2019-09-04 18:59:01 Debug (0) modsingle[authenticate]: returned from pap (rlm_pap) 2019-09-04 18:59:01 Debug (0) pap: User authenticated successfully 2019-09-04 18:59:01 Debug (0) pap: Comparing with "known good" Crypt-Password "$6$LFU97T6ajw2Q/a$zilaUncUFrH.XW9n4gN.kMq2osfBhcd2.D6UVa286NmOizyjxKZzpw2deyU4twmvfSgcXbfC2ABJiLM0iLVxz." 2019-09-04 18:59:01 Debug (0) pap: Login attempt with password "password" (8) 2019-09-04 18:59:01 Debug (0) modsingle[authenticate]: calling pap (rlm_pap) 2019-09-04 18:59:01 Debug (0) Auth-Type PAP { 2019-09-04 18:59:01 Debug (0) # Executing group from file /usr/local/synoradius/rad_site_def_local 2019-09-04 18:59:01 Debug (0) Found Auth-Type = PAP 2019-09-04 18:59:01 Debug (0) } # authorize = updated 2019-09-04 18:59:01 Debug (0) [pap] = updated 2019-09-04 18:59:01 Debug (0) modsingle[authorize]: returned from pap (rlm_pap) 2019-09-04 18:59:01 Debug (0) pap: Normalizing NT-Password from hex encoding, 32 bytes -> 16 bytes 2019-09-04 18:59:01 Debug (0) pap: Normalizing LM-Password from base64 encoding, 32 bytes -> 24 bytes 2019-09-04 18:59:01 Debug (0) modsingle[authorize]: calling pap (rlm_pap) 2019-09-04 18:59:01 Debug (0) [logintime] = noop 2019-09-04 18:59:01 Debug (0) modsingle[authorize]: returned from logintime (rlm_logintime) 2019-09-04 18:59:01 Debug (0) modsingle[authorize]: calling logintime (rlm_logintime) 2019-09-04 18:59:01 Debug (0) [expiration] = noop 2019-09-04 18:59:01 Debug (0) modsingle[authorize]: returned from expiration (rlm_expiration) 2019-09-04 18:59:01 Debug (0) modsingle[authorize]: calling expiration (rlm_expiration) 2019-09-04 18:59:01 Debug (0) [smbpasswd] = ok 2019-09-04 18:59:01 Debug (0) modsingle[authorize]: returned from smbpasswd (rlm_passwd) 2019-09-04 18:59:01 Debug (0) smbpasswd: Added SMB-Account-CTRL-TEXT: '[U ]' to config 2019-09-04 18:59:01 Debug (0) smbpasswd: Added NT-Password: '54BC4927BD320C776E53E1B38F92496B' to config 2019-09-04 18:59:01 Debug (0) smbpasswd: Added LM-Password: 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' to config 2019-09-04 18:59:01 Debug (0) modsingle[authorize]: calling smbpasswd (rlm_passwd) 2019-09-04 18:59:01 Debug (0) [unix] = updated 2019-09-04 18:59:01 Debug (0) modsingle[authorize]: returned from unix (rlm_unix) 2019-09-04 18:59:01 Debug (0) modsingle[authorize]: calling unix (rlm_unix) 2019-09-04 18:59:01 Debug (0) [files] = noop 2019-09-04 18:59:01 Debug (0) modsingle[authorize]: returned from files (rlm_files) 2019-09-04 18:59:01 Debug (0) modsingle[authorize]: calling files (rlm_files) 2019-09-04 18:59:01 Debug (0) [eap] = noop 2019-09-04 18:59:01 Debug (0) modsingle[authorize]: returned from eap (rlm_eap) 2019-09-04 18:59:01 Debug (0) eap: No EAP-Message, not doing EAP 2019-09-04 18:59:01 Debug (0) modsingle[authorize]: calling eap (rlm_eap) 2019-09-04 18:59:01 Debug (0) [synorad] = noop 2019-09-04 18:59:01 Debug (0) modsingle[authorize]: returned from synorad (rlm_synorad) 2019-09-04 18:59:01 Debug synorad: block list[(null)] 2019-09-04 18:59:01 Debug synorad: block list[(null)] 2019-09-04 18:59:01 Debug synorad: Full name[username] 2019-09-04 18:59:01 Debug (0) modsingle[authorize]: calling synorad (rlm_synorad) 2019-09-04 18:59:01 Debug (0) [suffix] = noop 2019-09-04 18:59:01 Debug (0) modsingle[authorize]: returned from suffix (rlm_realm) 2019-09-04 18:59:01 Debug (0) suffix: No such realm "NULL" 2019-09-04 18:59:01 Debug (0) suffix: No '@' in User-Name = "username", looking up realm NULL 2019-09-04 18:59:01 Debug (0) suffix: Checking for suffix after "@" 2019-09-04 18:59:01 Debug (0) modsingle[authorize]: calling suffix (rlm_realm) 2019-09-04 18:59:01 Debug (0) [digest] = noop 2019-09-04 18:59:01 Debug (0) modsingle[authorize]: returned from digest (rlm_digest) 2019-09-04 18:59:01 Debug (0) modsingle[authorize]: calling digest (rlm_digest) 2019-09-04 18:59:01 Debug (0) [mschap] = noop 2019-09-04 18:59:01 Debug (0) modsingle[authorize]: returned from mschap (rlm_mschap) 2019-09-04 18:59:01 Debug (0) modsingle[authorize]: calling mschap (rlm_mschap) 2019-09-04 18:59:01 Debug (0) [chap] = noop 2019-09-04 18:59:01 Debug (0) modsingle[authorize]: returned from chap (rlm_chap) 2019-09-04 18:59:01 Debug (0) modsingle[authorize]: calling chap (rlm_chap) 2019-09-04 18:59:01 Debug (0) [preprocess] = ok 2019-09-04 18:59:01 Debug (0) modsingle[authorize]: returned from preprocess (rlm_preprocess) 2019-09-04 18:59:01 Debug (0) modsingle[authorize]: calling preprocess (rlm_preprocess) 2019-09-04 18:59:01 Debug (0) authorize { 2019-09-04 18:59:01 Debug (0) # Executing section authorize from file /usr/local/synoradius/rad_site_def_local 2019-09-04 18:59:01 Debug (0) session-state: No State attribute 2019-09-04 18:59:01 Debug (0) Service-Type = Authenticate-Only 2019-09-04 18:59:01 Debug (0) NAS-Port-Type = Virtual 2019-09-04 18:59:01 Debug (0) NAS-Port = 11121 2019-09-04 18:59:01 Debug (0) NAS-Identifier = "3rdparty" 2019-09-04 18:59:01 Debug (0) NAS-IP-Address = 192.168.1.100 2019-09-04 18:59:01 Debug (0) User-Password = "password" 2019-09-04 18:59:01 Debug (0) User-Name = "username" 2019-09-04 18:59:01 Debug (0) Received Access-Request Id 166 from 192.168.1.100:57745 to 192.168.1.101:1812 length 85 What am I missing or doing wrong? Thank you, vl -----Original Message----- From: Freeradius-Users [mailto:freeradius-users-bounces+vladlevin=geo-logic.com@lists.freeradius.org] On Behalf Of Fajar A. Nugraha Sent: Wednesday, September 04, 2019 2:41 AM To: FreeRadius users mailing list Subject: ++++SPAM++++ Re: Re: Re: Configure Freeradius Server on a Synology NAS to Authenticate Cisco RV340 Users On Wed, Sep 4, 2019 at 3:02 PM Levin, Vladimir <vladlevin@geo-logic.com> wrote:
Is that correct?[] Yes, that is absolutely correct.
You should use quoting when replying message, to make your replies easier to read. e.g: https://en.wikipedia.org/wiki/Posting_style#Quoted_line_prefix
- you have no problem with potentially breaking (or voiding warranty) your synlogy nas[] I don't have a problem with that. - you have access to command line[] I do. - you are familiar with configuring software directly via command line[] To a certain degree. - you can read (and implement) the docs[] I guess that remains to be seen.
As for "send radius attribute", if it were a normal freeradius installation with mysql backend, and the attribute is specific to each user, you probably need to add entries to radreply table, e.g. https://wiki.freeradius.org/guide/SQL-HOWTO#populating-sql
You can try to follow the example then. Looking at https://github.com/FreeRADIUS/freeradius-server/blob/master/share/dictionary... , the attribute name should be just what you wrote earlier: 'Class'. Try adding it (or find the way to add it using synology gui) to radreply table for your test user. -- Fajar - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Thu, Sep 5, 2019 at 9:43 AM Levin, Vladimir <vladlevin@geo-logic.com> wrote:
Hi Fajar,
Just to be clear: the user accounts and groups already exist in Synology's local database.
Does freeradius get the same information from that database?
My goal is to return the users' group as a Class attribute in the authentication reply to the RADIUS client (Cisco VPN router). Here's what I did (working config files are located in /usr/local/synoradius/): 1. Created /usr/local/synoradius/groups file with the following content: update reply { Class := "%{Group}" }
Have you determined that %{Group} actually contain the correct group?
The client log reads "charon: Localdb:authorization failed as group is NULL".
Below is the server log: Type Date & Time Event 2019-09-04 18:59:06 Info Ready to process requests 2019-09-04 18:59:06 Debug (0) Cleaning up request packet ID 166 with timestamp +36671 2019-09-04 18:59:01 Debug Waking up in 4.9 seconds. 2019-09-04 18:59:01 Debug (0) Finished request 2019-09-04 18:59:01 Debug (0) Class := 0x
Looking at this, it seems that %{Group} is expanded to null. Where did synology define the group? If it's part of unix group, then reading http://freeradius.1045715.n5.nabble.com/Reply-with-group-attribute-tp2781054... , it does not store group membership in 'Group' attribute. You might be able to use something like https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/raddb/mods-avail... , but it might or might not work depending on what's in your /etc/group. If your user/group are stored in sql, then it's another different story. You might be able to get group membership using a custom SQL query. In any case, you can see what attributes you can use (for update reply) in debug mode using debug_all: https://serverfault.com/a/845161 -- Fajar
participants (2)
-
Fajar A. Nugraha -
Levin, Vladimir