On Nov 14, 2024, at 12:25 PM, Rodrigo Antunes via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:

Hi, I'd like to authenticate a PC using it's machine account and the mschap module, without calling ntlm_auth, is this possible?

If you mean with libwbclient instead of ntlmauth then yes, host auths do indeed work through that route. However they still use the NTLM method under the hood, so that method must still be allowed by the directory server. No major RADIUS supplicants available on commodity client machines support newer methods than NTLM. If you are unfamiliar with libwbclient, see the "winbind_username" and "winbind_domain" configuration options. If you also want to use host auths from a Linux client joined to an SMB domain, then there is a lot of magic involved to fish the most recent host password out of the SMB daemon... host passwords are rotated over time. Probably this is not what you are trying to do but just in case someone else googles this mailing list thread: export DOMAIN=<your AD domain name> NTLM=$(sudo tdbdump -k SECRETS/MACHINE_PASSWORD/$DOMAIN /var/lib/samba/private/secrets.tdb | perl -e 'use Digest::MD4 qw(md4 md4_hex md4_base64); use Encode qw(decode encode); my $a = <>; $a =~ s/\n$//; $a =~ s/\\00$//; my @a; while ($a =~ s/((?:\\[89A-F].)|(?:.))//) { if (length($1) == 1) { push(@a, $1) } else { my $bs = $1; $bs =~ s/\\/0x/; push (@a, chr(hex("$bs"))) } }; my $blob = join("",@a); print md4_hex(encode("UTF16-LE",decode("UTF-8", $blob)))') ...and then put "hash:$NTLM" in the password setting for your wpa_supplicant/eapol_test config file. Don't blame the samba folks for the above, they are just faithfully emulating MS AD, even down to the warts and blisters.

On 14/11/2024 18:40, Dave Funk wrote:

On Thu, 14 Nov 2024, Alan DeKok wrote:

...

On Nov 14, 2024, at 12:25 PM, Rodrigo Antunes via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:

...

Hi, I'd like to authenticate a PC using it's machine account and the mschap module, without calling ntlm_auth, is this possible?

If using ntlm_auth is so issuous that it needs to be avoided another approach would be to use eap-tls with the PC's SSL certificate that was issued by the domain (assuming your AD domain has a CA).

This. It's faster, more secure, and a lot simpler to set up. -- Matthew

On Nov 18, 2024, at 8:26 AM, Rodrigo Antunes via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:

The only thing I have found are the nt hashes but I think I can't check them in users file.

You can add them to the "users" file: bob NT-Password := 0xabcdef ... Alan DeKok.

On 18/11/2024 14:48, Rodrigo Antunes via Freeradius-Users wrote:

I will also try to explain better what I want to achieve, maybe someone have another solution:

I have a windows machine that is in kiosk mode, it is not domain joined and has no local users. I need this machine to authenticate against radius automatically, without the user provide credentials.

The alternatives i tried:

mac auth - don't work because windows client always try mschap kiosk user - don't work because kios mode don't has password machine user - the one I'm trying

Install a certificate on it and use EAP-TLS, as I suggested the other day. If it's not domain joined then you'll need to install the certificate yourself, but other than that the process is basically the same. -- Matthew

On Nov 18, 2024, at 9:48 AM, Rodrigo Antunes via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:

The hashes are nt-challenge and nt-response, I think they aren't the same as the nt-password.

It would help to say that. It's not productive to give information in bits and pieces.

Does someone know how to obtain the machine account password or nt-password from a windows machine account?

Google. Alan DeKok.

Does someone know how to obtain the machine account password or nt-password from a windows machine account

You can not do MSCHAPv2 auth with computer context in modern Windows 11 OS, as virtualization-based security and credential guard prohibits access of RRAS(?) to this data. You should disable this internal protection first. Also note that not all directories have such concept as "computer account password", ex, FreeIPA or RedHat IDM don't. Just drop the idea of using computer account passwords and use certificates (EAP-TLS or PEAP-TLS). Leave password authentication to unmanaged devices like personal laptops and smartphones. Create a new user account for those devices each time you need to setup a device. On 2024-11-18 17:48, Rodrigo Antunes via Freeradius-Users wrote:

Does someone know how to obtain the machine account password or nt-password from a windows machine account

On Nov 19, 2024, at 6:55 AM, Alexey D. Filimonov <alexey@filimonic.net> wrote:

Addition: Set up AD Certification Services to issue certificates to domain-joined computer. Configure AD CS to publish CRLs to HTTP instead of LDAP. Create a certificate template with special EKUs: 1.3.6.1.5.5.7.3.14 (EAPoL) and 1.3.6.1.5.5.7.3.2 (Client auth). Use EAPoL EKU in WLAN Group policy to configure certificate selection for EAP-TLS. Configure automatic enroll of those certificates to "domain computers" group.

The scriptsand configuration files in raddb/certs will automatically add those EKUs.

Also it looks like easier to setup Microsoft NPS as RADIUS if most of your clients are Windows. As you need EAP-TLS for computers and PEAP-MSCHAPv2 for unmanaged devices. PEAP is quite difficult to setup and manage with FreeRADIUS, IMO.

Why? a) check that username / password authentication works as per docs in sites-enabled/inner-tunnel b) add certs to EAP c) PEAP works. The hardest part about it is reading the documentation. Alan DeKok.

On Nov 19, 2024, at 7:52 AM, Alexey D. Filimonov <alexey@filimonic.net> wrote:

...

The scriptsand configuration files in raddb/certs will automatically add those EKUs.

But this requires manual certificate installation if use raddb/certs. From other side, there is AD-integrated CA from MS where computers can securely issue and update their certificates automatically.

Yeah, that's what I thought. The issue isn't FreeRADIUS, the issue is configuring the clients. While that's a hard problem, it's a problem caused by Microsoft. Which means that it's misleading to say that *FreeRADIUS* is hard to configure.

...

Why?

Now switching half of the computer park from Windows to Linux, from AD to FreeIPA and from NPS to FreeRADIUS. So this is my personal mention based on my personal experience. Comparing NPS to FreeRADIUS - in NPS everything about inner tunnels is hidden, checks against AD is done transparently to admin, nice UI, good documentation. NPS is less customizable, limited to only things that are supported by MS and requires CALs for each client device or employee. FreeRADIUS 3.x is poorly documented (in comparsion to MS NPS) and requires different entry threshold.

I've been saying this for 20+ years: IF YOU THINK THE DOCUMENTATION IS NOT GOOD ENOUGH, THEN SUBMIT PATCHES TO ADD MORE DOCUMENTATION. But that doesn't work. My experience is that for every 999 people complaining about how bad the documentation is, perhaps one person will actually contribute anything. In fact, the people who complain the most tend to have religious objections to contributing anything. But they also have a sense of entitlement which demands that they complain about something they got for free. So forgive me if I'm not sympathetic to your argument. Complaining and not contributing doesn't make me inclined to work hard to keep you happy. Rather the reverse, I'm fact. On top of all of that, Microsoft has literally billions of dollars to spend on software development. Which is a *little* bit more than we have. So this kind of comparison is, at best, facetious. Perhaps more truthfully dishonest. You're comparing free software which depends on community contributions to paid software written by dozens of people with full-time jobs. Even with all of that, the only thing that NPS does better than FreeRADIUS is the simple / trivial use-case. If you can click a GUI, you can configure NPS. And, because Microsoft owns the entire ecosystem, it can integrate NPS configuration with Active Directory, and with the clients.

For 99%-Windows enterprise company, NPS+ADCS allows to use less and cheaper IT staff to run, so I'd prefer NPS+ADCS for Windows-Only computer park with my current experience.

That's nice. So why are you here? Do you expect that people will be happy when you dump on FreeRADIUS, without contributing anything? Alan DeKok.

On Nov 19, 2024, at 8:47 AM, Alexey D. Filimonov <alexey@filimonic.net> wrote:

The problem is people who use FreeRADIUS and who develop FreeRADIUS are different people. Without deep-diving to code, you can not create documentation.

Not true. There's plenty of opportunity to write "how to" examples. Or, many people on this list are getting paid to do FreeRADIUS installs and support. Yet the number of those willing to contribute, or pay the core team to do work is pretty much zero.

For example, calling ldap.authorize inside authenticate section - who knew it is possible this way...

https://www.freeradius.org/documentation/freeradius-server/3.2.7/unlang/keyw... It's documented. <sigh> So the documentation is terrible, but pretty much every time people say this, the things they want documentation for are already documented.

Because I'm switching to FreeRADUIS and trying to get into it. About contributing - I'm currently making an article about a way of providing EAP-TLS Wi-Fi and EAPoL for Puppet\FreeIPA\DogTag\FreeRADIUS\Linux enterprise environment to make it possible to join together all parts of this quest. I could not find any guide for that.

That's good.

Please don't swear on me, I just notified Rodrigo that for existing windows enterprise environment there is a ready-to-use book and solution. FreeRADIUS does not have one. If I ever switch my Windows clients from NPS to FreeRADIUS, I will make an article about it.

BTW, FreeRADIUS should have something like open wiki for that.

There is a wiki. We made it read-only because the only changes in the last 5-10 years were spammers. Alan DeKok.