CentOS OpenLDAP pwdReset Attribute
Current Setup: CentOS Steam 8 FreeRADIUS 3.0.20 OpenLDAP 2.5.5 Issue: FreeRADIUS ignores pwdReset attribute, because it only needs the initial OpenLDAP bind to be successful. Description: If there are any users on the list with the above config, how do you get around the issue of password resets, specifically having the pwdReset attribute set? Our users primarily use RADIUS for network device authentication, but then we also have a few web apps that only work with LDAP. So, we pointed FreeRADIUS at OpenLDAP, and use LDAP's password policy to adhere to company security policies. Seems like this would be a common config, and everything generally works great. The only main issue is when it comes time to reset a user's password. We have the pwdMustChange option set to TRUE, and when an admin resets a user's password (from out lockout or forgotten) the pwdReset attribute shows up as expected and is set to TRUE. Since FreeRADIUS only cares about a simple BIND to OpenLDAP, the end user can continue to use the given (temp) password, because the initial BIND works as expected. FreeRADIUS doesn't care about the pwdReset attribute, so just lets the user login to the network device. In the documentation, right above the "Auth-Type LDAP" section, I noticed the lines "We do NOT recommend using this". So I'm curious what is the recommended best practice for situations that require both LDAP and RADIUS authentication for their various apps and devices? Thank you for your time, -V
On Oct 25, 2021, at 1:41 PM, Th1am1dMonozoicK4runa via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
Issue: FreeRADIUS ignores pwdReset attribute, because it only needs the initial OpenLDAP bind to be successful.
FreeRADIUS treats LDAP as a database, and doesn't try to use / validate the entire user object.
Description: If there are any users on the list with the above config, how do you get around the issue of password resets, specifically having the pwdReset attribute set? Our users primarily use RADIUS for network device authentication, but then we also have a few web apps that only work with LDAP. So, we pointed FreeRADIUS at OpenLDAP, and use LDAP's password policy to adhere to company security policies. Seems like this would be a common config, and everything generally works great. The only main issue is when it comes time to reset a user's password. We have the pwdMustChange option set to TRUE, and when an admin resets a user's password (from out lockout or forgotten) the pwdReset attribute shows up as expected and is set to TRUE. Since FreeRADIUS only cares about a simple BIND to OpenLDAP, the end user can continue to use the given (temp) password, because the initial BIND works as expected. FreeRADIUS doesn't care about the pwdReset attribute, so just lets the user login to the network device.
You can always run an LDAP query manually via "unlang" to check the status of the pwdReset field.
In the documentation, right above the "Auth-Type LDAP" section, I noticed the lines "We do NOT recommend using this". So I'm curious what is the recommended best practice for situations that require both LDAP and RADIUS authentication for their various apps and devices?
The recommendation against using "Auth-Type = LDAP" is that it only works for clear-text passwords. If the user tries CHAP / MS-CHAP / EAP, then "Auth-Type = LDAP" simply won't work. If all of your authentication is via clear-text passwords, then it should be fine. Note also that there's no standard for doing password changes via RADIUS. So the only thing you'll get by setting / checking pwdReset is that users won't be able to login via RADIUS. Alan DeKok.
On Monday, October 25th, 2021 at 5:09 PM, Alan DeKok <aland@deployingradius.com> wrote:
You can always run an LDAP query manually via "unlang" to check the status of the pwdReset field.
Thank you for the tip, I was leaning that way, but was curious what the recommended method would be.
The recommendation against using "Auth-Type = LDAP" is that it only works for clear-text passwords. If the user tries CHAP / MS-CHAP / EAP, then "Auth-Type = LDAP" simply won't work.
And there's no way around this for users that have to have both LDAP and RADIUS, correct? Even though there are articles floating around out there about setting CHAP with LDAP: https://www.wogri.com/networking/freeradius-chap/
Note also that there's no standard for doing password changes via RADIUS. So the only thing you'll get by setting / checking pwdReset is that users won't be able to login via RADIUS.
Overall, we're just trying to implement the most secure/best practice setup to allow the LDAP users and RADIUS users to utilize the same company driven password policy. Looked like the only way to accomplish that, was to have RADIUS use LDAP as a password database. Thanks for your time!
On Oct 26, 2021, at 8:43 AM, Th1am1dMonozoicK4runa via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
The recommendation against using "Auth-Type = LDAP" is that it only works for clear-text passwords. If the user tries CHAP / MS-CHAP / EAP, then "Auth-Type = LDAP" simply won't work.
And there's no way around this for users that have to have both LDAP and RADIUS, correct? Even though there are articles floating around out there about setting CHAP with LDAP: https://www.wogri.com/networking/freeradius-chap/
It works because LDAP contains the users clear-text password. And the server doesn't do "Auth-Type = LDAP" when there's a CHAP request. TBH, if the password is in LDAP in clear-text, there's no point in doing "Auth-Type = LDAP". Just use LDAP as a database. It stores passwords, and FreeRADIUS authenticates users. It's simpler, faster, and better. i.e. that article is little more than an explanation as to why the default configuration works, and why the default configuration is designed that way. And, it adds complexity where it's not needed. This is why I keep saying "most third-party documentation sites are wrong". It's not that the recommendations in article don't work, they do. It's that it's entirely unnecessary. To get CHAP, MS-CHAP, PAP, etc. working with LDAP, just: * enable and configure the LDAP module * put clear-text passwords into the normal fields in LDAP That's it. There's no need to go through long third-party articles which do extra (and useless) work.
Note also that there's no standard for doing password changes via RADIUS. So the only thing you'll get by setting / checking pwdReset is that users won't be able to login via RADIUS.
Overall, we're just trying to implement the most secure/best practice setup to allow the LDAP users and RADIUS users to utilize the same company driven password policy. Looked like the only way to accomplish that, was to have RADIUS use LDAP as a password database.
Which is generally what you want to do. RADIUS is for authentication and network access. LDAP is for storing information about users. You really *don't* want different databases. Generally you also put users into different groups into LDAP, and then use RADIUS to enforce group checks. For example: if (user is trying to log into a switch console) { if (user is NOT network admin LDAP group) { reject } check passwords, etc. ... } Alan DeKok.
On Tuesday, October 26th, 2021 at 8:56 AM, Alan DeKok <aland@deployingradius.com> wrote:
You can always run an LDAP query manually via "unlang" to check the status of the pwdReset field.
For any future reader out there, as Alan suggested, this works perfectly fine. Hopefully it will help someone else: sudo vim /etc/raddb/dictionary ATTRIBUTE Password-Reset 3000 string sudo vim /etc/raddb/mods-available/ldap update{ control:Password-Reset += 'pwdReset' } sudo vim /etc/raddb/sites-available/default post-auth { if (control:Password-Reset == "TRUE") { update reply { &Reply-Message := "Your password has been reset. You must change your password." } reject } } Thanks!
On 10/26/21 17:35, Th1am1dMonozoicK4runa via Freeradius-Users wrote:
For any future reader out there, as Alan suggested, this works perfectly fine. Hopefully it will help someone else: > sudo vim /etc/raddb/dictionary ATTRIBUTE Password-Reset 3000 string
sudo vim /etc/raddb/mods-available/ldap update{ control:Password-Reset += 'pwdReset' }
sudo vim /etc/raddb/sites-available/default post-auth { if (control:Password-Reset == "TRUE") { update reply { &Reply-Message := "Your password has been reset. You must change your password." } reject } }
IMHO it's unlikely that this message will ever be presented to the end user. So personally I'd just adjust the filter for searching users and add (!(pwdReset=TRUE)) YMMV. Ciao, Michael.
W dniu 26.10.2021 o 14:43, Th1am1dMonozoicK4runa via Freeradius-Users pisze:
On Monday, October 25th, 2021 at 5:09 PM, Alan DeKok <aland@deployingradius.com> wrote:
You can always run an LDAP query manually via "unlang" to check the status of the pwdReset field.
Thank you for the tip, I was leaning that way, but was curious what the recommended method would be.
The recommendation against using "Auth-Type = LDAP" is that it only works for clear-text passwords. If the user tries CHAP / MS-CHAP / EAP, then "Auth-Type = LDAP" simply won't work.
And there's no way around this for users that have to have both LDAP and RADIUS, correct? Even though there are articles floating around out there about setting CHAP with LDAP: https://www.wogri.com/networking/freeradius-chap/
For better GDPR compliance and security I'd like to recommend using NT-Password for authentication (sambaNTPassword in LDAP). These passwords stored as NThashes are fully compliant with MSCHAP authentication, but you have to store them in LDAP (or even database), so you have to store and chage both: SHA hashed userPassword and NT hashed sambaNTPassword for each user. The drawback is that such a solution requires 3rd party password updating tool for LDAP.
Note also that there's no standard for doing password changes via RADIUS. So the only thing you'll get by setting / checking pwdReset is that users won't be able to login via RADIUS.
Overall, we're just trying to implement the most secure/best practice setup to allow the LDAP users and RADIUS users to utilize the same company driven password policy. Looked like the only way to accomplish that, was to have RADIUS use LDAP as a password database.
Thanks for your time!
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Marek Zarychta
On Oct 26, 2021, at 12:51 PM, Marek Zarychta <zarychtam@plan-b.pwste.edu.pl> wrote:adius-chap/
For better GDPR compliance and security I'd like to recommend using NT-Password for authentication (sambaNTPassword in LDAP).
All 8-character NT hashes can be cracked fairly quickly: https://www.theregister.com/2019/02/14/password_length/
These passwords stored as NThashes are fully compliant with MSCHAP authentication, but you have to store them in LDAP (or even database), so you have to store and chage both: SHA hashed userPassword and NT hashed sambaNTPassword for each user. The drawback is that such a solution requires 3rd party password updating tool for LDAP.
My choice would be (in order) * use whatever is mandated by your DB, because you don't have a choice e.g. NT hashes for Active Directory * some crypt'd / salted format. Whatever it is doesn't matter, so long as it's relatively recent * clear-text passwords If you're not using AD, then NT hashes are *slightly* better than clear-text passwords. But any additional security is little more than an illusion. If someone gets access to the password DB, then NT hashes are entirely equivalent to clear-text passwords. Anyone with $ to spare can crack the passwords pretty quickly. Alan DeKok.
W dniu 26.10.2021 o 19:09, Alan DeKok pisze:
On Oct 26, 2021, at 12:51 PM, Marek Zarychta <zarychtam@plan-b.pwste.edu.pl> wrote:adius-chap/
For better GDPR compliance and security I'd like to recommend using NT-Password for authentication (sambaNTPassword in LDAP).
All 8-character NT hashes can be cracked fairly quickly:
Indeed, it can be easily cracked, but NT-Password is stored as 32-character long MD4 hash and at least needs some effort to be cracked. I never recommended using eight-character Windows NTLM passwords and wonder if they will work for MSCHAP auth.
These passwords stored as NThashes are fully compliant with MSCHAP authentication, but you have to store them in LDAP (or even database), so you have to store and chage both: SHA hashed userPassword and NT hashed sambaNTPassword for each user. The drawback is that such a solution requires 3rd party password updating tool for LDAP.
My choice would be (in order)
* use whatever is mandated by your DB, because you don't have a choice e.g. NT hashes for Active Directory
* some crypt'd / salted format. Whatever it is doesn't matter, so long as it's relatively recent
* clear-text passwords
If you're not using AD, then NT hashes are *slightly* better than clear-text passwords. But any additional security is little more than an illusion. If someone gets access to the password DB, then NT hashes are entirely equivalent to clear-text passwords. Anyone with $ to spare can crack the passwords pretty quickly.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Marek Zarychta
On Oct 26, 2021, at 1:42 PM, Marek Zarychta <zarychtam@plan-b.pwste.edu.pl> wrote:
Indeed, it can be easily cracked, but NT-Password is stored as 32-character long MD4 hash and at least needs some effort to be cracked.
The issue isn't the length of the hash. The issue is the length of the input. *All* passwords of length 8 can be cracked in a short amount of time, if you have the MD4 hash of the password. That time is days for someone who's bored, and has a GPU to spare. It's maybe minutes for someone who has $$ to spend on hardware. If the are additional requirements on the contents of the password, then this time goes down substantially. Each additional requirement of things like "MUST include one uppercase letter" will reduce the time required by 50%. Requirements like "MUST include a special character" or "MUST include a number" will reduce the time required by 80% or more. Those kind of limitations are security theatre, and make things worse. :( They change the time required to crack NT hash from minutes (for someone with $$) to seconds. The main reason to use NT hashes is because you're using Active Directory, and AD doesn't really use anything else. Everyone else should really switch to crypt'd passwords.
I never recommended using eight-character Windows NTLM passwords and wonder if they will work for MSCHAP auth.
LM hashes won't work for MS-CHAP. Alan DeKok.
W dniu 26.10.2021 o 21:05, Alan DeKok pisze:
On Oct 26, 2021, at 1:42 PM, Marek Zarychta <zarychtam@plan-b.pwste.edu.pl> wrote:
Indeed, it can be easily cracked, but NT-Password is stored as 32-character long MD4 hash and at least needs some effort to be cracked.
The issue isn't the length of the hash. The issue is the length of the input.> > *All* passwords of length 8 can be cracked in a short amount of time, if you have the MD4 hash of the password. That time is days for someone who's bored, and has a GPU to spare. It's maybe minutes for someone who has $$ to spend on hardware.
If the are additional requirements on the contents of the password, then this time goes down substantially.
Each additional requirement of things like "MUST include one uppercase letter" will reduce the time required by 50%. Requirements like "MUST include a special character" or "MUST include a number" will reduce the time required by 80% or more.
Those kind of limitations are security theatre, and make things worse. :( They change the time required to crack NT hash from minutes (for someone with $$) to seconds.
Thank you for the comprehensive explanation, but I still believe that MD4 hash is more GDPR conformant than Cleartext-Password ;)
The main reason to use NT hashes is because you're using Active Directory, and AD doesn't really use anything else. Everyone else should really switch to crypt'd passwords.
But can anything besides NTPassword or Cleartext-Password work for MSCHAP authentication?
I never recommended using eight-character Windows NTLM passwords and wonder if they will work for MSCHAP auth.
LM hashes won't work for MS-CHAP.
I am sorry, I have not carefully read this article and at a glance confused NTLM with LM. -- Marek Zarychta
On 10/26/21 21:28, Marek Zarychta wrote:
but I still believe that MD4 hash is more GDPR conformant than Cleartext-Password ;)
Basically the NT-Password-Hash is used as a shared secret in a challenge-response protocol. The hashing is just used as a key derivation function. => So you have to protect it just like a clear-text password. Ciao, Michael.
On Oct 26, 2021, at 3:28 PM, Marek Zarychta <zarychtam@plan-b.pwste.edu.pl> wrote:
Thank you for the comprehensive explanation, but I still believe that MD4 hash is more GDPR conformant than Cleartext-Password ;)
Only because it's *slightly* better than clear-text passwords, and because the political / legal rules have little relation to the reality of computer security.
But can anything besides NTPassword or Cleartext-Password work for MSCHAP authentication?
No. We're stuck with decisions made in the late 1980s. Alan DeKok.
participants (4)
-
Alan DeKok -
Marek Zarychta -
Michael Ströder -
Th1am1dMonozoicK4runa