You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
I see that in 2023.4 there's a new radius provider, although I don't exactly understand some of the docs related to it here: https://goauthentik.io/docs/providers/radius/
For example. It is stated that "The RADIUS provider only supports the clear-text protocol:" I can only assume that by protocol it means authentication protocol. And if that is what that means then the only auth protocol which is clear-text is PAP. AFAIK all the others are encrypted (one way or another). So does that above sentence mean only PAP is supported?
The next sentence I don't really understand, is this one:
" However as all protocols besides Clear-text, EAP-MD5 and EAP-PWD require the password to be stored in the database in clear text, they are not supported."
So which one is not supported? Clear-text (there is no auth protocol named clear-text, maybe this should be PAP?), EAP-PWD - as the table suggests above - supports (at least in theory) the password being Salted SHA1, or unix-crypt-ed (that is theory, because in my experience only clear-text password is supported for the devices I tried) or EAP-MD5 which is the one that only supports password stored in clear-text. So that sentence should be clarified a bit.
Anyways... the usual way to handle this kind of nonsense of radius requiring password in cleartext is that there's a secondary pass/key that can be set by the user (and clearly stated that is not a usual password and stored in plaintext) which will only be used by radius authentication. That way the "real" password (which is used by authentik everywhere else) can still be hashed with whatever way it seems necessary, and radius could still be used with that key stored as cleartext.
Describe the solution you'd like
I'd like to have a way to define - for every user - a radius key (I would not call it a password, so users don't confuse it with one), which would only be used for authenticating to the radius server.
Users would be able to change this of course for themselves, it would be a cleartext entry, clearly stated that it is stored as cleartext, don't use anything that would be used for a password.
Maybe even put a button next to it, to autogenerate a simple, memorable key (eg. not too long X random words)
Describe alternatives you've considered
There's just no alternative to radius clear-text requirement nonsense for now, not until they start to think about passwords needing to be stored hashed everywhere, always.
Additional context
I'd really like to use authentik's radius server with eap-pwd auth.
The text was updated successfully, but these errors were encountered:
indeed what's referred to as clear-text in the docs is meant to be PAP. The reason nothing besides PAP is supported currently is that https://github.com/layeh/radius doesn't support any of the EAP-* protocols
I previously considered having an explicit clear text key for this use-case, however that would require a bunch of additional logic since we still want the Radius outpost to use the flow executor
Is your feature request related to a problem? Please describe.
I see that in 2023.4 there's a new radius provider, although I don't exactly understand some of the docs related to it here:
https://goauthentik.io/docs/providers/radius/
For example. It is stated that "The RADIUS provider only supports the clear-text protocol:" I can only assume that by protocol it means authentication protocol. And if that is what that means then the only auth protocol which is clear-text is PAP. AFAIK all the others are encrypted (one way or another). So does that above sentence mean only PAP is supported?
The next sentence I don't really understand, is this one:
" However as all protocols besides Clear-text, EAP-MD5 and EAP-PWD require the password to be stored in the database in clear text, they are not supported."
So which one is not supported? Clear-text (there is no auth protocol named clear-text, maybe this should be PAP?), EAP-PWD - as the table suggests above - supports (at least in theory) the password being Salted SHA1, or unix-crypt-ed (that is theory, because in my experience only clear-text password is supported for the devices I tried) or EAP-MD5 which is the one that only supports password stored in clear-text. So that sentence should be clarified a bit.
Anyways... the usual way to handle this kind of nonsense of radius requiring password in cleartext is that there's a secondary pass/key that can be set by the user (and clearly stated that is not a usual password and stored in plaintext) which will only be used by radius authentication. That way the "real" password (which is used by authentik everywhere else) can still be hashed with whatever way it seems necessary, and radius could still be used with that key stored as cleartext.
Describe the solution you'd like
I'd like to have a way to define - for every user - a radius key (I would not call it a password, so users don't confuse it with one), which would only be used for authenticating to the radius server.
Users would be able to change this of course for themselves, it would be a cleartext entry, clearly stated that it is stored as cleartext, don't use anything that would be used for a password.
Maybe even put a button next to it, to autogenerate a simple, memorable key (eg. not too long X random words)
Describe alternatives you've considered
There's just no alternative to radius clear-text requirement nonsense for now, not until they start to think about passwords needing to be stored hashed everywhere, always.
Additional context
I'd really like to use authentik's radius server with eap-pwd auth.
The text was updated successfully, but these errors were encountered: