problems getting ntlm_auth working.
Hai, Im new here, so please be nice if i missed a thing. Im having problem to get my ntlm_auth working with freeradius. My Setup: Debian Buster Samba 4.10.7 ( running winbind only ) My winbind auth works fine, server is domain joined. Squid is also configured on this server which also uses winbind and kerberos for authentication. SSH uses kerberos authentication, and im using nfsv4 kerberizes automounted homedirs for the users. This all works fine. Now im adding freeradius. So i hope with a little bit of help, someone can point to me what i did wrong. Im following the site http://deployingradius.com Steps 1-4 all done and all working. Only i use my own certificates here. This is the running samba config : [global] # Auth-Only setup with winbind. ( no Shares ) workgroup = NTDOM security = ADS realm = MY.REALM.TLD netbios name = HOSTNAME preferred master = no domain master = no host msdfs = no dns proxy = yes interfaces = eth0 lo bind interfaces only = yes log level = 1 #Add and Update TLS Key tls enabled = yes tls keyfile = /etc/ssl/private/my.key.pem tls certfile = /etc/ssl/certs/my.cert.pem tls cafile = /etc/ssl/certs/my-ca.cert.pem ## map id's outside to domain to tdb files. idmap config *: backend = tdb idmap config *: range = 2000-9999 ## map ids from the domain and (*) the range may not overlap ! idmap config NTDOM : backend = ad idmap config NTDOM : schema_mode = rfc2307 idmap config NTDOM : range = 10000-3999999 #4.6+ ( get primary group from AD ) idmap config NTDOM : unix_nss_info = yes #4.6+ ( get primary group from unix primary group ) idmap config NTDOM : unix_primary_group = yes kerberos method = secrets and keytab dedicated keytab file = /etc/krb5.keytab # renew the kerberos ticket winbind refresh tickets = yes # We strip the domain (NTDOM\username) to username winbind use default domain = yes # use: getent passwd username to check. # enabled slows down you samba. winbind enum users = no winbind enum groups = no # enable offline logins # Not on a VPN server. #winbind offline logon = no # check depth of nested groups, ! slows down you samba, if to much groups depth # Not needed on the VPN server. #winbind expand groups = 4 # Added for freeradius ntlm auth = mschapv2-and-ntlmv2-only # user Administrator workaround, without it you are unable to set privileges username map = /etc/samba/samba_usermapping # disable usershares creating usershare path = # Disable printing completely load printers = no printing = bsd printcap name = /dev/null disable spoolss = yes # For ACL support on member servers with shares vfs objects = acl_xattr map acl inherit = Yes store dos attributes = Yes ######## SHARE DEFINITIONS ################ I've proceded to : http://deployingradius.com/documents/configuration/active_directory.html I've edited : /etc/freeradius/3.0/users and tested it. radtest user password localhost 0 testing123 This all works with : DEFAULT Auth-Type = ntlm_auth enabled. Im now at : Configuring FreeRADIUS to use ntlm_auth for MS-CHAP Now i remove DEFAULT Auth-Type = ntlm_auth from /etc/freeradius/3.0/users I edited : /etc/freeradius/3.0/mods-available/mschap As suggested on the site, but that did not work. I used: ntlm_auth = "/usr/bin/ntlm_auth --request-nt-key --allow-mschapv2 \ --username=%{mschap:User-Name:-None} \ --domain=%{%{mschap:NT-Domain}:-NTDOM} \ --challenge=%{mschap:Challenge:-00} \ --nt-response=%{mschap:NT-Response:-00}" Tried with and without the --mschapv2 and/or the --domain=%{%{mschap:NT-Domain}:-NTDOM}. That did not work when testing with : radtest -t mschap bob hello localhost 0 testing123 Or with radtest -t mschap username password localhost 0 testing123 Where this username and password is 10000000000% sure correct. ;-) I also noticed these : # winbind_username = "%{mschap:User-Name}" # winbind_domain = "%{mschap:NT-Domain}" # and i checked that lbwbclient is installed. libwbclient0:amd64 2:4.10.7-0.1~deb10 But also did not work. Note, # An alternative to using ntlm_auth is to connect to the # winbind daemon directly for authentication. This option # is likely to be faster and may be useful on busy systems, # but is less well tested. This is one i like but first i need the basic ntlm_auth working. Or kerberos auth, i have not added the radius/SPN yet to the keytab file. When i now run radtest username ... .. This is the output. What im a doing wrong, or what did i miss. radtest -t mschap username password localhost 0 testing123 Ready to process requests (0) Received Access-Request Id 126 from 127.0.0.1:60982 to 127.0.0.1:1812 length 131 (0) User-Name = "username" (0) NAS-IP-Address = 192.168.xxx.xxx (0) NAS-Port = 10 (0) Message-Authenticator = 0x18e47fd9598eba89c40254557077f7ff (0) MS-CHAP-Challenge = 0x08243010dec6eb38 (0) MS-CHAP-Response = 0x0001000000000000000000000000000000000000000000000000e386418de8527edff1949800324f8f34d4716529e6176b1c (0) # Executing section authorize from file /etc/freeradius/3.0/sites-enabled/default (0) authorize { (0) policy filter_username { (0) if (&User-Name) { (0) if (&User-Name) -> TRUE (0) if (&User-Name) { (0) if (&User-Name =~ / /) { (0) if (&User-Name =~ / /) -> FALSE (0) if (&User-Name =~ /@[^@]*@/ ) { (0) if (&User-Name =~ /@[^@]*@/ ) -> FALSE (0) if (&User-Name =~ /\.\./ ) { (0) if (&User-Name =~ /\.\./ ) -> FALSE (0) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/)) { (0) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/)) -> FALSE (0) if (&User-Name =~ /\.$/) { (0) if (&User-Name =~ /\.$/) -> FALSE (0) if (&User-Name =~ /@\./) { (0) if (&User-Name =~ /@\./) -> FALSE (0) } # if (&User-Name) = notfound (0) } # policy filter_username = notfound (0) [preprocess] = ok (0) [chap] = noop (0) mschap: Found MS-CHAP attributes. Setting 'Auth-Type = mschap' (0) [mschap] = ok (0) [digest] = noop (0) suffix: Checking for suffix after "@" (0) suffix: No '@' in User-Name = "username", looking up realm NULL (0) suffix: No such realm "NULL" (0) [suffix] = noop (0) eap: No EAP-Message, not doing EAP (0) [eap] = noop (0) [files] = noop (0) [expiration] = noop (0) [logintime] = noop (0) pap: WARNING: No "known good" password found for the user. Not setting Auth-Type (0) pap: WARNING: Authentication will fail unless a "known good" password is available (0) [pap] = noop (0) } # authorize = ok (0) Found Auth-Type = mschap (0) # Executing group from file /etc/freeradius/3.0/sites-enabled/default (0) authenticate { (0) mschap: Client is using MS-CHAPv1 with NT-Password (0) mschap: Executing: /usr/bin/ntlm_auth --request-nt-key --allow-mschapv2 --username=%{mschap:User-Name:-None} --domain=%{%{mschap:NT-Domain}:-NTDOM} --challenge=%{mschap:Challenge:-00} --nt-response=%{mschap:NT-Response:-00}: (0) mschap: EXPAND --username=%{mschap:User-Name:-None} (0) mschap: --> --username=username (0) mschap: ERROR: No NT-Domain was found in the User-Name (0) mschap: EXPAND --domain=%{%{mschap:NT-Domain}:-NTDOM} (0) mschap: --> --domain=NTDOM (0) mschap: mschap1: 08 (0) mschap: EXPAND --challenge=%{mschap:Challenge:-00} (0) mschap: --> --challenge=08243010dec6eb38 (0) mschap: EXPAND --nt-response=%{mschap:NT-Response:-00} (0) mschap: --> --nt-response=e386418de8527edff1949800324f8f34d4716529e6176b1c (0) mschap: ERROR: Program returned code (1) and output 'The attempted logon is invalid. This is either due to a bad username or authentication information. (0xc000006d)' (0) mschap: External script failed (0) mschap: ERROR: External script says: The attempted logon is invalid. This is either due to a bad username or authentication information. (0xc000006d) (0) mschap: ERROR: MS-CHAP2-Response is incorrect (0) [mschap] = reject (0) } # authenticate = reject (0) Failed to authenticate the user (0) Using Post-Auth-Type Reject (0) # Executing group from file /etc/freeradius/3.0/sites-enabled/default (0) Post-Auth-Type REJECT { (0) attr_filter.access_reject: EXPAND %{User-Name} (0) attr_filter.access_reject: --> username (0) attr_filter.access_reject: Matched entry DEFAULT at line 11 (0) [attr_filter.access_reject] = updated (0) [eap] = noop (0) policy remove_reply_message_if_eap { (0) if (&reply:EAP-Message && &reply:Reply-Message) { (0) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE (0) else { (0) [noop] = noop (0) } # else = noop (0) } # policy remove_reply_message_if_eap = noop (0) } # Post-Auth-Type REJECT = updated (0) Delaying response for 1.000000 seconds Waking up in 0.2 seconds. Waking up in 0.7 seconds. (0) Sending delayed response (0) Sent Access-Reject Id 126 from 127.0.0.1:1812 to 127.0.0.1:60982 length 61 (0) MS-CHAP-Error = "\000E=691 R=1 C=0b9be1dfc950ab3e V=2" Waking up in 3.9 seconds. (0) Cleaning up request packet ID 126 with timestamp +4 Ready to process requests If anyone has some suggestions what i did wrong or what did i miss, i would be greatfull. Im lost.. Greetz, Louis
On Aug 29, 2019, at 9:00 AM, L.P.H. van Belle via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
Samba 4.10.7 ( running winbind only ) My winbind auth works fine, server is domain joined.
That's good.
Im following the site http://deployingradius.com Steps 1-4 all done and all working. Only i use my own certificates here.
This is the running samba config :
We don't need to see the Samba config.
I've proceded to : http://deployingradius.com/documents/configuration/active_directory.html I've edited : /etc/freeradius/3.0/users and tested it. radtest user password localhost 0 testing123 This all works with : DEFAULT Auth-Type = ntlm_auth enabled.
That's good.
Im now at : Configuring FreeRADIUS to use ntlm_auth for MS-CHAP
Now i remove DEFAULT Auth-Type = ntlm_auth from /etc/freeradius/3.0/users
I edited : /etc/freeradius/3.0/mods-available/mschap As suggested on the site, but that did not work.
See the messages below.
(0) mschap: Executing: /usr/bin/ntlm_auth --request-nt-key --allow-mschapv2 --username=%{mschap:User-Name:-None} --domain=%{%{mschap:NT-Domain}:-NTDOM} --challenge=%{mschap:Challenge:-00} --nt-response=%{mschap:NT-Response:-00}: (0) mschap: EXPAND --username=%{mschap:User-Name:-None} (0) mschap: --> --username=username (0) mschap: ERROR: No NT-Domain was found in the User-Name (0) mschap: EXPAND --domain=%{%{mschap:NT-Domain}:-NTDOM} (0) mschap: --> --domain=NTDOM (0) mschap: mschap1: 08 (0) mschap: EXPAND --challenge=%{mschap:Challenge:-00} (0) mschap: --> --challenge=08243010dec6eb38 (0) mschap: EXPAND --nt-response=%{mschap:NT-Response:-00} (0) mschap: --> --nt-response=e386418de8527edff1949800324f8f34d4716529e6176b1c (0) mschap: ERROR: Program returned code (1) and output 'The attempted logon is invalid. This is either due to a bad username or authentication information. (0xc000006d)'
That's pretty clear. Samba is rejecting the request. Maybe Samba is still refusing to allow ntlm_auth. There isn't much you can do to FreeRADIUS to fix this issue. Use the debug output above to run the "ntlm_auth" program from the command line yourself. Samba shouldn't care about repeated authentication attempts which use the same MS-CHAP magic hex strings. Keep running ntlm_auth with the MS-CHAP strings, and poking Samba until ntlm_auth succeeds. At that point, FreeRADIUS will work, too. Alan DeKok.
Hai Alan, Thank you for you quick reply. I was already waiting for this responce of you. As i said.. Winbind auth/samba works.. I can do any test from CLI all work. ntlm_auth --request-nt-key --domain=NTDOM --username=username --password='somepass' NT_STATUS_OK: The operation completed successfully. (0x0) ntlm_auth --mschap --request-nt-key --domain=NTDOM --username=username --password='somepass' NT_STATUS_OK: The operation completed successfully. (0x0) wbinfo -a username%'somepass' plaintext password authentication succeeded challenge/response password authentication succeeded I reported so much because i already notice more of these responces of you.. And im really sure my base setup is correct.
(0) mschap: ERROR: Program returned code (1) and output 'The attempted logon is invalid. This is either due to a bad username or authentication information. (0xc000006d)'
That's pretty clear. Samba is rejecting the request. Maybe Samba is still refusing to allow ntlm_auth.
No it is not, see above.
There isn't much you can do to FreeRADIUS to fix this issue. Use the debug output above to run the "ntlm_auth" program from the command line yourself. Samba shouldn't care about repeated authentication attempts which use the same MS-CHAP magic hex strings.
Keep running ntlm_auth with the MS-CHAP strings, and poking Samba until ntlm_auth succeeds. At that point, FreeRADIUS will work, too.
As shown, it does not. This is why im mailing to the list, yes, i know you get lots of these "failures" But im also a samba dev and i support the samba list and i know my samba setup works as it should. If my squid proxy uses ntlm_auth it works fine. So why not in freeradius.. We are missing something here really. So please, have a better look, or tell me more where to look. Greetz, Louis
On Aug 29, 2019, at 9:36 AM, L.P.H. van Belle via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
Hai Alan,
Thank you for you quick reply. I was already waiting for this responce of you. As i said.. Winbind auth/samba works.. I can do any test from CLI all work.
ntlm_auth --request-nt-key --domain=NTDOM --username=username --password='somepass' NT_STATUS_OK: The operation completed successfully. (0x0) ntlm_auth --mschap --request-nt-key --domain=NTDOM --username=username --password='somepass' NT_STATUS_OK: The operation completed successfully. (0x0)
So you're not reading my message. I did read yours. I am aware that *password* authentication works. My point was that MS-CHAP authentication is not the same as password authentication. You should *test the thing going wrong*. Testing something else is not helpful.
(0) mschap: ERROR: Program returned code (1) and output 'The attempted logon is invalid. This is either due to a bad username or authentication information. (0xc000006d)'
That's pretty clear. Samba is rejecting the request. Maybe Samba is still refusing to allow ntlm_auth.
No it is not, see above.
Yes, it is. This isn't rocket science. When ntlm_auth returns FAIL, it means that ntlm_auth is returning FAIL. No amount of denial will change that fact. Other tests you run on the command line are irrelevant. Something is different between the command-line tests, and when ntlm_auth is run from FreeRADIUS. Find out what that difference is, and fix it. That is your ONLY way to fix the problem.
Keep running ntlm_auth with the MS-CHAP strings, and poking Samba until ntlm_auth succeeds. At that point, FreeRADIUS will work, too.
As shown, it does not.
So did you run the tests with the MS-CHAP strings as I suggested? Likely not, otherwise you would have said so. My prediction is that it won't work. Which is why I suggested doing it.
This is why im mailing to the list, yes, i know you get lots of these "failures" But im also a samba dev and i support the samba list and i know my samba setup works as it should.
Then why is ntlm_auth returning "fail" to FreeRADIUS? Hint: we didn't write ntlm_auth, and we don't know how it works.
If my squid proxy uses ntlm_auth it works fine.
Probably because it's using passwords for authentication, and not mschap.
So why not in freeradius.. We are missing something here really.
You're missing my suggestion to run ntlm_auth with ms-chap strings. This reply of "but I tested it with passwords and it works" is just not helpful. The server prints out those MS-CHAP strings *precisely so that you can test them*.
So please, have a better look, or tell me more where to look.
"Have a better look"? That's rude. Especially when you're ignoring my suggestions. This shouldn't be difficult. FreeRADIUS is simply executing another program, using normal system APIs. If that program fails, then the problem isn't FreeRADIUS. The possible problems are: a) the program is run under a different UID, and therefore can't access the resources it needs when run under a different UID b) the parameters passed to the program are different in the situations when it works, and when it doesn't work There really isn't a lot else. There is no magical cross-process memory corruption where ntlm_auth works fine from the command-line, but *exactly the same* command fails when run under FreeRADIUS Test it from the command line *using exactly the same parameters as used by FreeRADIUS*. If it works, then the issue is likely UID related. If it doesn't work, then you should apologize for asking me to "take a better look" instead of following instructions. And then fix something *unrelated to FreeRADIUS* to get ntlm_auth with MS-CHAP to work. FreeRADIUS is using *exactly* the same code to run ntlm_auth on millions of other systems. We can believe that FreeRADIUS is magically broken on your system when running an external program. OR we can believe that there is a local permissions / configuration issue which is preventing ntlm_auth from working. Alan DeKok.
On Aug 29, 2019, at 9:56 AM, Alan DeKok <aland@deployingradius.com> wrote:
The possible problems are:
a) the program is run under a different UID, and therefore can't access the resources it needs when run under a different UID
b) the parameters passed to the program are different in the situations when it works, and when it doesn't work
The only *other* choice is that the client is doing MS-CHAP calculations wrong. FreeRADIUS just packages that up and sends it to ntlm_auth. So if the calculations are wrong, then ntlm_auth will return "fail", even when ntlm_auth and samba are configured correctly. That can be tested by doing a test without ntlm_auth, and a locally configured password. If that works, then the client is fine. And, the problem isn't FreeRADIUS. Because FreeRADIUS can authenticate users just fine. Alan DeKok.
Hai Alan, Offcourse if id read everyting you where saying. And it's all working now. If you can change one thing to the site's howto then you will never get these questions again. .. Yes i know it is on the site already but, i would suggest you change this part. 'This configuration needs to be set on all participating Samba member(s) and (Samba4) AD-DC server(s).' So what did i miss.. Yes, forgot to add to the AD-DC's smb.conf ntlm auth = mschapv2-and-ntlmv2-only After setting that, then "it just works" .. ;-) Pretty stupid of me.. I wont argue that.. Just twoo more questions. 1) We can authenticate 3 ways. username username@REALM NTDOM\username If running freeradius on AD-DC. where : winbind use default domain = yes is not working on AD-DC. See output of wbinfo -u You can login with : username or NTDOM\username. test : radtest -t mschap 'NTDOM\username' 'password' localhost 0 testing123 test : radtest -t mschap 'username' 'password' localhost 0 testing123 If running freeradius on AD-Member where : winbind use default domain = yes is working. See output of wbinfo -u You can login with : username or username@REALM test : radtest -t mschap 'username' 'password' localhost 0 testing123 test : radtest -t mschap 'username@REALM' 'password' localhost 0 testing123 What is the best way to handle all 3 types? Im really new with freeradius, im trying to understand the configs, but thats not done in a sec. 2) Do note on the REALM. I notice, and maybe you can verify this. If realm is set as : [libdefaults] default_realm = internal.domain.tld Trying to login with : username@INTERNAL.DOMAIN.TLD does not work. You must match CAPS/non-caps in REALM, dorrect? Or can we handle this in the config? But thank you for your responces so far. Greetz, Louis
-----Oorspronkelijk bericht----- Van: Freeradius-Users [mailto:freeradius-users-bounces+belle=bazuin.nl@lists.freerad ius.org] Namens Alan DeKok Verzonden: donderdag 29 augustus 2019 16:31 Aan: FreeRadius users mailing list Onderwerp: Re: problems getting ntlm_auth working.
On Aug 29, 2019, at 9:56 AM, Alan DeKok <aland@deployingradius.com> wrote:
The possible problems are:
a) the program is run under a different UID, and therefore can't access the resources it needs when run under a different UID Yes, i have checked that. Ive added freerad to winbind_priv group.
b) the parameters passed to the program are different in
the situations when it works, and when it doesn't work
The only *other* choice is that the client is doing MS-CHAP calculations wrong. FreeRADIUS just packages that up and sends it to ntlm_auth. So if the calculations are wrong, then ntlm_auth will return "fail", even when ntlm_auth and samba are configured correctly.
That can be tested by doing a test without ntlm_auth, and a locally configured password. If that works, then the client is fine. And, the problem isn't FreeRADIUS. Because FreeRADIUS can authenticate users just fine.
You where complety right here.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Aug 30, 2019, at 7:55 AM, L.P.H. van Belle via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
Offcourse if id read everyting you where saying. And it's all working now.
Good to hear.
If you can change one thing to the site's howto then you will never get these questions again. .. Yes i know it is on the site already but, i would suggest you change this part.
'This configuration needs to be set on all participating Samba member(s) and (Samba4) AD-DC server(s).'
Done.
So what did i miss.. Yes, forgot to add to the AD-DC's smb.conf ntlm auth = mschapv2-and-ntlmv2-only
After setting that, then "it just works" .. ;-) Pretty stupid of me.. I wont argue that..
Complex systems are complex, and are difficult to get right. Admitting mistakes is even harder. :) My evident frustration in many posts is really due to giving advice, and then (essentially) getting told to go F myself.
Just twoo more questions. 1) We can authenticate 3 ways. username username@REALM NTDOM\username
From the point of view of FreeRADIUS, they're all identical. Some string is being used as the User-Name. That same string is being used in the MS-CHAP calculations. However, a possibly *different* string is being used to look up users in a database. That's why we make a clear distinction between User-Name (what the user entered), and Stripped-User-Name (what we use for database lookups as the users identity). We *can't* mangle User-Name, because it breaks things like MS-CHAP. We also can't use User-Name for DB lookups, because it contains things like domain names, which generally aren't in the DB.
If running freeradius on AD-DC. where : winbind use default domain = yes is not working on AD-DC. See output of wbinfo -u
Not attached...
You can login with : username or NTDOM\username. test : radtest -t mschap 'NTDOM\username' 'password' localhost 0 testing123 test : radtest -t mschap 'username' 'password' localhost 0 testing123
If running freeradius on AD-Member where : winbind use default domain = yes is working. See output of wbinfo -u
You can login with : username or username@REALM test : radtest -t mschap 'username' 'password' localhost 0 testing123 test : radtest -t mschap 'username@REALM' 'password' localhost 0 testing123
Why do some things work and others don't? Maybe the wrong things are getting passed from FreeRADIUS to ntlm_auth. But maybe not. Again, the command-lines are printed out so that you can use them to test without running a full RADIUS stack. But winbind doesn't work, that's a Samba / AD thing. There are magical things there which I don't understand. It's been 15 years since I was tangentially involved in Samba4 development.
What is the best way to handle all 3 types? Im really new with freeradius, im trying to understand the configs, but thats not done in a sec.
Generally speaking, punt on the problem. Hand those strings to something else, and let it do the work. Or, use a database that returns the "known good" password to FreeRADIUS, and let FreeRADIUS do the work. While FreeRADIUS is complex, it isn't *stupid*. You can make it do pretty much anything you want. And the debug output shows you exactly what it's doing, and why. Contrast that to "helpful" commercial tools. Often the best error they produce is "failed". <sigh> It's like they have a pathological hatred for their customers, and a deep-seated terror of giving the customer any useful information.
2) Do note on the REALM. I notice, and maybe you can verify this.
If realm is set as : [libdefaults] default_realm = internal.domain.tld
Trying to login with : username@INTERNAL.DOMAIN.TLD does not work. You must match CAPS/non-caps in REALM, dorrect?
That's really a Samba thing, and I have absolutely no clue about it. I would *hope* that it's not case sensitive.
Or can we handle this in the config?
Maybe. It's possible in FreeRADIUS to lowercase the domain, and pass that to ntlm_auth. The issue is that the MS-CHAP calculations are done using the name *as entered by the user*. So if Samba doesn't get passed that *exact string*, then it's impossible to do the same MS-CHAP calculations, and it's impossible to authenticate the user.
But thank you for your responces so far.
You're welcome. It's what I do. Alan DeKok.
Hai Alan,
-----Oorspronkelijk bericht----- Van: Alan DeKok [mailto:aland@deployingradius.com] Verzonden: vrijdag 30 augustus 2019 14:22 Aan: FreeRadius users mailing list CC: L.P.H. van Belle Onderwerp: Re: problems getting ntlm_auth working.
On Aug 30, 2019, at 7:55 AM, L.P.H. van Belle via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
Offcourse if id read everyting you where saying. And it's all working now.
Good to hear.
If you can change one thing to the site's howto then you will never get these questions again. .. Yes i know it is on the site already but, i would suggest you change this part.
'This configuration needs to be set on all participating Samba member(s) and (Samba4) AD-DC server(s).'
Done.
Great, i hope this helps you also in reducing "unneeded" questions. I googled around a there are a lot of people that where missing that part. Me included.
So what did i miss.. Yes, forgot to add to the AD-DC's smb.conf ntlm auth = mschapv2-and-ntlmv2-only
After setting that, then "it just works" .. ;-) Pretty stupid of me.. I wont argue that..
Complex systems are complex, and are difficult to get right. Admitting mistakes is even harder. :)
Well, we are all human, we are not robots.. Humans are allowed to make misstakes.. Robots not. It just all about how we handle them.
My evident frustration in many posts is really due to giving advice, and then (essentially) getting told to go F myself.
Well, if i make it look like that or feal like that, then, please accept my deepst apolegies. I know/understand your frustration totaly, we get these sometimes also on the samba list.
Just twoo more questions. 1) We can authenticate 3 ways. username username@REALM NTDOM\username
From the point of view of FreeRADIUS, they're all identical. Some string is being used as the User-Name. That same string is being used in the MS-CHAP calculations.
However, a possibly *different* string is being used to look up users in a database.
That's why we make a clear distinction between User-Name (what the user entered), and Stripped-User-Name (what we use for database lookups as the users identity).
We *can't* mangle User-Name, because it breaks things like MS-CHAP. We also can't use User-Name for DB lookups, because it contains things like domain names, which generally aren't in the DB.
O, so i played a bit around with the settings and resulting now in. username username@REALM username@realm NTDOM\username All work fine now.
If running freeradius on AD-DC. where : winbind use default domain = yes is not working on AD-DC. See output of wbinfo -u
Not attached... ( * NTDOM\username )
You can login with : username or NTDOM\username. test : radtest -t mschap 'NTDOM\username' 'password' localhost 0 testing123 test : radtest -t mschap 'username' 'password' localhost 0 testing123
If running freeradius on AD-Member where : winbind use default domain = yes is working. See output of wbinfo -u (* username )
You can login with : username or username@REALM test : radtest -t mschap 'username' 'password' localhost 0 testing123 test : radtest -t mschap 'username@REALM' 'password' localhost 0 testing123
Why do some things work and others don't? Maybe the wrong things are getting passed from FreeRADIUS to ntlm_auth. But maybe not. Again, the command-lines are printed out so that you can use them to test without running a full RADIUS stack.
But winbind doesn't work, that's a Samba / AD thing. There are magical things there which I don't understand.
Your not alone here.. Im not a coder..
It's been 15 years since I was tangentially involved in Samba4 development. So why not join again, its still a great bunch of people there.
What is the best way to handle all 3 types? Im really new with freeradius, im trying to understand the configs, but thats not done in a sec.
Generally speaking, punt on the problem. Hand those strings to something else, and let it do the work.
Nah,, that is not my thing, i want to learn... I can give someone fish.. Then next time they come back again. If i learn people to fish, your done, they get there own fish.
Or, use a database that returns the "known good" password to FreeRADIUS, and let FreeRADIUS do the work. While FreeRADIUS is complex, it isn't *stupid*. You can make it do pretty much anything you want. And the debug output shows you exactly what it's doing, and why.
I'll focus more on the debug outputs.. But you must understand that if one is setting this up, they most probley dont know/understand anything of what they are seeing..
Contrast that to "helpful" commercial tools. Often the best error they produce is "failed". <sigh> It's like they have a pathological hatred for their customers, and a deep-seated terror of giving the customer any useful information.
Hehe. :-) yeah, totaly agree and I often give to much info..
2) Do note on the REALM. I notice, and maybe you can verify this.
If realm is set as : [libdefaults] default_realm = internal.domain.tld
Trying to login with : username@INTERNAL.DOMAIN.TLD does not work. You must match CAPS/non-caps in REALM, dorrect?
That's really a Samba thing, and I have absolutely no clue about it.
Ah.. Well, i retested this again, and you can ignore it. It works with and without caps, most probley a left over from previous testing.
I would *hope* that it's not case sensitive.
Or can we handle this in the config?
Maybe. It's possible in FreeRADIUS to lowercase the domain, and pass that to ntlm_auth. The issue is that the MS-CHAP calculations are done using the name *as entered by the user*.
So if Samba doesn't get passed that *exact string*, then it's impossible to do the same MS-CHAP calculations, and it's impossible to authenticate the user.
Ok clear, i've learned somethings again today ( and yesterday ) .. A "resume" of the current working config, i'll post it here so it gets indexed by google and more easy to find for others. Setting up FreeRadius on Debian Buster agains Samba 4 AD-DC # Verified for debian stretch also. Samba versions 4.5.x upto 4.10.x # Should work on Ubuntu/devuan also. # minimal install apt-get install freeradius winbind krb5-user # stop the services and go configure these. systemctl stop freeradius winbind I now have made the minimal changes, which are. : 1) follow the steps on : http://deployingradius.com/ 2) follow the steps on : http://deployingradius.com/documents/configuration/active_directory.html My changes to the this example. # A minimal smb.conf. # The CAPS here are as they should by RFC. netbios name = HOSTNAME workgroup = MYDOMAIN security = ADS realm = REALM.DOMAIN.TLD # + and for all involving members and (samba4) AD-DC servers add in smb.conf (globl): ntlm auth = mschapv2-and-ntlmv2-only # + !!!!! setup the other settings for a samba member !!!!! # https://wiki.samba.org/index.php/Setting_up_Samba_as_a_Domain_Member # added freerad user to the winbindd_priv group. usermod -a -G winbindd_priv freerad
From : http://deployingradius.com/documents/configuration/active_directory.html I skipped the settings but used the showed tests. : goto: Configuring FreeRADIUS to use ntlm_auth My changes, edit the following :
cd /etc editor freeradius/3.0/mods-available/ntlm_auth # content is : exec ntlm_auth { wait = yes program = "/usr/bin/ntlm_auth --allow-mschapv2 --request-nt-key --domain=%{mschap:NT-Domain} --username=%{mschap:User-Name} --password=%{User-Password}" } editor freeradius/3.0/mods-available/mschap I enabled these. goto : # An alternative to using ntlm_auth is to connect to the # winbind daemon directly for authentication. # Enable winbind_username = "%{mschap:User-Name}" winbind_domain = "%{mschap:NT-Domain}" Later on : passchange { # This support MS-CHAPv2 (not v1) password change # requests. See doc/mschap.rst for more IMPORTANT # information. ntlm_auth = "usr/bin/ntlm_auth --helper-protocol=ntlm-change-password-1 --allow-mschapv2" ntlm_auth_username = "username: %{mschap:User-Name}" ntlm_auth_domain = "nt-domain: %{mschap:NT-Domain}" editor freeradius/3.0/sites-available/default GoTo : authenticate { # added on top. ntlm_auth editor freeradius/3.0/sites-available/inner-tunnel GoTo : authenticate { # added on top. ntlm_auth systemctl start winbind freeradius
But thank you for your responces so far.
You're welcome. It's what I do.
Alan DeKok.
And as spoken as Alan, my above example "it just works", its amazing :-) Thanks Alan, and the other people for all the help and support. And have a great weekend. Greetz, Louis
participants (2)
-
Alan DeKok -
L.P.H. van Belle