This is how the freeradius log should look during the authorization phase: (0) rest: EXPAND http://127.0.0.1:8000 (0) rest: --> http://127.0.0.1:8000 (0) rest: EXPAND /api/v1/authorize/ (0) rest: --> /api/v1/authorize/ (0) rest: Sending HTTP POST to "http://127.0.0.1:8000/api/v1/authorize/"; (0) rest: EXPAND {"username": "%{User-Name}", "password": "%{User-Password}" } (0) rest: --> {"username": "admin", "password": "admin"}
I am not sure regarding post-auth right now, keep in mind django-freeradius doesn't store the password in case of successful authentications for security reasons. F. On Saturday, November 17, 2018 at 8:28:29 PM UTC+1, Marty Plummer wrote: > > So is that authorize section the entire thing? as in, comment out/delete > the defaults and > replace it with that? > > I don't think that's a bug per se, or maybe it is, but when I manually > curl that json up with > a filled password attribute it 'works', but the User-Password attribute > always expands to > '' in the wild. > > On Saturday, November 17, 2018 at 1:19:11 PM UTC-6, Federico Capoano wrote: >> >> The current django-freeradius docs show a full authorize section in the >> sample configuration: >> >> https://django-freeradius.readthedocs.io/en/latest/general/freeradius.html#configure-the-site >> >> At the end of the page the docs also state: >> >> *Customizing your configuration* >> You can further customize your freeradius configuration and exploit the >> many features of freeradius but you will need to test how your >> configuration plays with django-freeradius. >> >> This means that if you follow the instructions exactly as in the examples >> it will work, if you don't then it may work or it may not work depending on >> many factors because as 2stacks mentioned, freeradius is a complex beast. >> If you think this is not clear it doesn't cost anything to make it more >> explicit and I will do so, although I wouldn't consider it as a bug in the >> software. >> The 500 internal server error you mentioned instead sounds like a bug but >> I'd need to see the stack trace to confirm that, but I guess it will simply >> go away if you configure the sections exactly as shown in the docs. >> >> Federico >> >> >> On Saturday, November 17, 2018 at 1:22:21 PM UTC+1, Marty Plummer wrote: >>> >>> Well therein lies the problem. This is a freeradius config problem that >>> arises from a lack of >>> documentation on the part of django-freeradius. Nowhere in the docs does >>> it say you should >>> disable eap, and the only explicit mention of pap is a link to the >>> rlm_pap documentation for >>> a list of supported password formats. >>> >>> For the record this is a brand new radius setup, btw, so I don't have to >>> depend on radcheck >>> stuff. >>> >>> On Friday, November 16, 2018 at 8:49:39 PM UTC-6, 2stacks wrote: >>>> >>>> Thats just Freeradius. Nothing to do with django-freeradius directly. >>>> The first is a very broad topic and the later was designed to work with a >>>> REST api specifically. You definitely have a Freeradius config problem. >>>> Try to follow the guidance in the link I sent. If you want to >>>> authenticate >>>> against users created in django you only need to enable REST in the >>>> authorize section of your Freeradius config. Try commenting out all the >>>> things you dont need. >>>> >>>> Dont get discouraged. Freeradius is a complex subject in and of itself. >>>> >>>> Heres a bit more info as to how SQL and PAP relate to authentication in >>>> django-freeradius. >>>> >>>> >>>> https://django-freeradius.readthedocs.io/en/latest/general/freeradius.html#using-radius-checks-for-authorization-information >>>> >>>> On Fri, Nov 16, 2018, 8:45 PM Marty Plummer <[email protected] >>>> wrote: >>>> >>>>> Well considering there is pretty much no mention of pap in the linked >>>>> page I don't see how I'm supposed to know that. Also setting >>>>> sites-enabled/default >>>>> to use auth-type pap throws me a 500 internal server error and >>>>> apparently >>>>> sends back some html instead of json. >>>>> >>>>> rlm_rest (rest): Reserved connection (0) >>>>> (0) rest: Expanding URI components >>>>> (0) rest: EXPAND http://web:8000 >>>>> (0) rest: --> http://web:8000 >>>>> (0) rest: EXPAND /api/v1/authorize/ >>>>> (0) rest: --> /api/v1/authorize/ >>>>> (0) rest: Sending HTTP POST to "http://web:8000/api/v1/authorize/"; >>>>> (0) rest: EXPAND { "username": "%{User-Name}", "password": >>>>> "%{User-Password}" } >>>>> (0) rest: --> { "username": "testuser", "password": "" } >>>>> (0) rest: Processing response header >>>>> (0) rest: Status : 500 (Internal Server Error) >>>>> (0) rest: Type : html (text/html) >>>>> (0) rest: ERROR: Type "html" is not a valid web API data markup format >>>>> (0) rest: ERROR: <h1>Server Error (500)</h1> >>>>> (0) rest: ERROR: Server returned no data >>>>> rlm_rest (rest): Released connection (0) >>>>> Need 5 more connections to reach 10 spares >>>>> rlm_rest (rest): Opening additional connection (5), 1 of 27 pending >>>>> slots used >>>>> rlm_rest (rest): Connecting to "http://web:8000"; >>>>> (0) [rest] = fail >>>>> (0) } # authorize = fail >>>>> (0) Using Post-Auth-Type Reject >>>>> (0) # Executing group from file /opt/etc/raddb/sites-enabled/default >>>>> (0) Post-Auth-Type REJECT { >>>>> (0) update control { >>>>> (0) &REST-HTTP-Header += "Authorization: Bearer >>>>> 2dda94d1-5d38-49e0-803c-f89369a782dd" >>>>> (0) } # update control = noop >>>>> rlm_rest (rest): Reserved connection (1) >>>>> >>>>> >>>>> >>>>> On Friday, November 16, 2018 at 5:05:47 PM UTC-6, 2stacks wrote: >>>>>> >>>>>> If I remember correctly authenticating against rest happens in the >>>>>> authorize section and for sql auth-type should be PAP. Looks like >>>>>> your auth-type is set to eap. Make sure you read all of >>>>>> >>>>>> https://django-freeradius.readthedocs.io/en/latest/general/freeradius.html#configuring-freeradius-3. >>>>>> >>>>>> >>>>>> >>>>>> Found Auth-Type = eap >>>>>> On Fri, Nov 16, 2018 at 4:33 PM Marty Plummer <[email protected]> >>>>>> wrote: >>>>>> > >>>>>> > git clone https://bitbucket.org/hanetzer/radius.git >>>>>> > cd radius && docker-compose up --build >>>>>> > >>>>>> > You'll need a .env file, looks like this: >>>>>> > >>>>>> > DATABASE_URL=db://postgres:changeme@db/postgres // not yet >>>>>> configurable >>>>>> > DJANGO_DEBUG=false // DEBUG = False in settings.py >>>>>> > DJANGO_FREERADIUS_API_TOKEN=bigsecrettoken >>>>>> > DJANGO_MANAGEPY_COLLECTSTATIC=off >>>>>> > DJANGO_MANAGEPY_MAKEMIGRATIONS=on >>>>>> > DJANGO_MANAGEPY_MIGRATE=on >>>>>> > DJANGO_SETTINGS_MODULE=radius.settings >>>>>> > POSTGRES_DB=postgres // not yet configurable >>>>>> > POSTGRES_PASSWORD=changeme // not yet configurable >>>>>> > POSTGRES_USER=postgres //not yet configurable >>>>>> > SECRET_KEY=normaldjangosecretkey >>>>>> > FREERADIUS_SECRET=testing123 >>>>>> > >>>>>> > -- >>>>>> > You received this message because you are subscribed to the Google >>>>>> Groups "OpenWISP" group. >>>>>> > To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> > For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "OpenWISP" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> -- You received this message because you are subscribed to the Google Groups "OpenWISP" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
