definitive info on authenticating to AD via NTLMv2
Hi., I've been running ntlm_auth to authenticate our 802.1x users against AD for a number of months without problems…… until this morning when our Systems group tightened up auth requirements to only use NTLMv2. and my ntlm_auth module started failing I'm running FR van 2.2 and samba Vsn 3.6.3 All the web stuff I've found doesn;t seem to mention v2 at all. Back in the dim and distant past I got round the ntlm v2 issue when using OSC Radiator by proxying off auths to Radiator running on a windows machine bound to AD and using their AuthBy LSA authentication mechanism. So, anything special I need to do to auth using ntlmv2? Can it be done? only reference I found was to have client ntlmve auth = yes in smb.conf Rgds Alex
Alex Sharaz wrote:
I've been running ntlm_auth to authenticate our 802.1x users against AD for a number of months without problems…… until this morning when our Systems group tightened up auth requirements to only use NTLMv2. and my ntlm_auth module started failing
Which breaks RADIUS.
So, anything special I need to do to auth using ntlmv2? Can it be done?
It can't be done. ntlmv2 is a *completely* different protocol. nvlmv1 is pretty much MS-CHAP, which is why it works. Ask the AD administrators to make an exception for the Samba server. Nothing else will work. Alan DeKok
On 26/03/2013 14:21, Alex Sharaz wrote:
Hi., I've been running ntlm_auth to authenticate our 802.1x users against AD for a number of months without problems…… until this morning when our Systems group tightened up auth requirements to only use NTLMv2. and my ntlm_auth module started failing
As Alan says - you're hosed. They will need to rollback the change if you want Samba/ntlm_auth to continue working.
All the web stuff I've found doesn;t seem to mention v2 at all. Back in the dim and distant past I got round the ntlm v2 issue when using OSC Radiator by proxying off auths to Radiator running on a windows machine bound to AD and using their AuthBy LSA authentication mechanism.
When you say "windows machine", do you mean "ordinary domain member" as opposed to "domain controller"? If so, this is interesting. It suggests that MSCHAP can still be checked with NTLMv2 enforced, just not via whatever API Samba/ntlm_auth uses. You should ask on the Samba lists - if a windows domain member can do it, there must be a newer API/RPC which Samba could implement. It is possible, though unlikely IMO, that one of the other ntlm_auth modes, such as --helper-protocol=ntlm-server-1 ...use different RPCs, and may work. If you can, try and get a valid challenge/response pair, and then drive ntlm_auth using the ntlm-server-1 protocol (see "man ntlm_auth"). If that works, it would be possible in theory to use a wrapper script. But IIRC, it's the same code path, so Samba fixes will be needed. The other "option" (yuck) is to run NPS (or Radiator) on a Windows server, and proxy your MSCHAP to that. But if other RADIUS servers have the ability to work with NTLMv2 enforced, it would be nice to get it with FR too.
On 26/03/2013 15:00, Phil Mayers wrote:
You should ask on the Samba lists - if a windows domain member can do it, there must be a newer API/RPC which Samba could implement.
In fact, a couple of minutes with google gives me this thread: https://lists.samba.org/archive/samba/2012-March/166440.html There is a magic flag that Samba needs to set on the RPC. It's unclear from the thread if that was ever patched into Samba, but if it was, it was after March 2012, so you'd need at least version after that. I will see if I can find if it was implemented and when.
On 26/03/2013 15:09, Phil Mayers wrote:
On 26/03/2013 15:00, Phil Mayers wrote:
You should ask on the Samba lists - if a windows domain member can do it, there must be a newer API/RPC which Samba could implement.
In fact, a couple of minutes with google gives me this thread:
https://lists.samba.org/archive/samba/2012-March/166440.html
There is a magic flag that Samba needs to set on the RPC. It's unclear from the thread if that was ever patched into Samba, but if it was, it was after March 2012, so you'd need at least version after that. I will see if I can find if it was implemented and when.
It doesn't look like this ever went in - there's no sign of the MSV1_0_ALLOW_MSVCHAPV2 flag in the latest Samba3 or Samba4 sources except in header def. files and flag/debug output. As Andrew Bartlett pointed out, if you allow any MSCHAPv2 (NTLMv1) login you're effectively not enforcing NTLMv2, but I suppose you could argue the TLS surrounding PEAP make it "ok". If you want this working you'll need to download the Samba source and make the patch described in the thread - in ./source3/utils/ntlm_auth.c find the "contact_winbind_auth_crap" function, and add: MSV1_0_ALLOW_MSVCHAPV2 ...to the "request.data.auth_crap.logon_parameters" flags. You might want to re-(re)-raise this on the Samba lists. It seems like it would be pretty easy to have a "--allow-mschapv2" argument to ntlm_auth which sets this flag conditionally, and avoids the "we shouldn't set it all the time" issue.
Phew! o.k. many thanks for this phil. I'll probably have a bash at this but, as I've done it before, just setting up radiator as something that just says yes/no sounds a lot easier :-)) Rgds Alex On 26 Mar 2013, at 15:27, Phil Mayers <p.mayers@IMPERIAL.AC.UK> wrote:
On 26/03/2013 15:09, Phil Mayers wrote:
On 26/03/2013 15:00, Phil Mayers wrote:
You should ask on the Samba lists - if a windows domain member can do it, there must be a newer API/RPC which Samba could implement.
In fact, a couple of minutes with google gives me this thread:
https://lists.samba.org/archive/samba/2012-March/166440.html
There is a magic flag that Samba needs to set on the RPC. It's unclear from the thread if that was ever patched into Samba, but if it was, it was after March 2012, so you'd need at least version after that. I will see if I can find if it was implemented and when.
It doesn't look like this ever went in - there's no sign of the MSV1_0_ALLOW_MSVCHAPV2 flag in the latest Samba3 or Samba4 sources except in header def. files and flag/debug output.
As Andrew Bartlett pointed out, if you allow any MSCHAPv2 (NTLMv1) login you're effectively not enforcing NTLMv2, but I suppose you could argue the TLS surrounding PEAP make it "ok".
If you want this working you'll need to download the Samba source and make the patch described in the thread - in ./source3/utils/ntlm_auth.c find the "contact_winbind_auth_crap" function, and add:
MSV1_0_ALLOW_MSVCHAPV2
...to the "request.data.auth_crap.logon_parameters" flags.
You might want to re-(re)-raise this on the Samba lists. It seems like it would be pretty easy to have a "--allow-mschapv2" argument to ntlm_auth which sets this flag conditionally, and avoids the "we shouldn't set it all the time" issue. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Alex Sharaz wrote:
o.k. many thanks for this phil. I'll probably have a bash at this but, as I've done it before, just setting up radiator as something that just says yes/no sounds a lot easier :-))
I doubt it. The problem is with AD, not with any RADIUS server. And that the ntlmv2 protocol is *completely* different than the ntlmv1 protocol. Don't blame the messenger. FreeRADIUS is the victim of the changed AD policies, and the limitations of ntlmv2. Switching to another RADIUS server won't help. Unless it's NPS, which uses the AD replication protocols to bypass ntlm entirely. Alan DeKok.
On 26 Mar 2013, at 15:47, Alan DeKok <aland@deployingradius.com> wrote:
Alex Sharaz wrote:
o.k. many thanks for this phil. I'll probably have a bash at this but, as I've done it before, just setting up radiator as something that just says yes/no sounds a lot easier :-))
I doubt it.
Actually I found the way Radiator worked simpler than getting to grips with FreeRadius, but then again that's probably because it was the 1st one I tried :-)) . Running Radiator just to auth users against AD and send back an access-accept/access-reject packet was fairly simple once you set up ActivePerl.
The problem is with AD, not with any RADIUS server. And that the ntlmv2 protocol is *completely* different than the ntlmv1 protocol.
o.k. fair enough.
Don't blame the messenger. FreeRADIUS is the victim of the changed AD policies, and the limitations of ntlmv2. Switching to another RADIUS server won't help.
Unless it's NPS, which uses the AD replication protocols to bypass ntlm entirely.
Well, I was running Radiator for a couple of years authenticating users against AD. ( sent out a snippet from the Radiator manual in another message) so I guess it wasn't using ntlm. but, from the point of view of getting the job done, it did work. Rgds Alex
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Alex Sharaz wrote:
Well, I was running Radiator for a couple of years authenticating users against AD.
Yes... I didn't say that wouldn't work.
( sent out a snippet from the Radiator manual in another message) so I guess it wasn't using ntlm.
The text you posted showed it used ntlm.
but, from the point of view of getting the job done, it did work.
The text you posted showed that Radiator ran on Windows. In which case, it can bypass the AD replication protocols, and poke Windows directly. That's why it was less work to set up. You didn't need Samba. If anyone is willing to sponsor FreeRADIUS on Windows, we can do the same thing. It's not hard, it just requires time and effort. Alan DeKok.
Hi,
o.k. many thanks for this phil. I'll probably have a bash at this but, as I've done it before, just setting up radiator as something that just says yes/no sounds a lot easier :-))
RADIATOR on Windows can use <AuthBY LSA> which is a direct access to AD method and doesnt use SAMBA stuff at all - you'd have the same problem with RADIATOR on Linux. alan
On 26/03/2013 18:03, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
o.k. many thanks for this phil. I'll probably have a bash at this but, as I've done it before, just setting up radiator as something that just says yes/no sounds a lot easier :-))
RADIATOR on Windows can use <AuthBY LSA> which is a direct access to AD method and doesnt use SAMBA stuff at all - you'd have the same problem with RADIATOR on Linux.
In the interests of clarity: The LSA isn't magic; it uses pretty much the same RPCs as Samba does. There's nothing hidden or special, and no "direct access". The problem here is that Samba doesn't have any way to set MSV1_0_ALLOW_MSVCHAPV2 when calling the relevant RPC. This is a trivial, one-bit flag. NPS and Radiator are obviously setting that flag when talking to the RPC. We (because we're reliant on Samba) are not. Fix Samba, and we will magically work - no effort required.
On 26 Mar 2013, at 15:00, Phil Mayers <p.mayers@IMPERIAL.AC.UK> wrote:
On 26/03/2013 14:21, Alex Sharaz wrote:
Hi., I've been running ntlm_auth to authenticate our 802.1x users against AD for a number of months without problems…… until this morning when our Systems group tightened up auth requirements to only use NTLMv2. and my ntlm_auth module started failing
As Alan says - you're hosed. They will need to rollback the change if you want Samba/ntlm_auth to continue working.
All the web stuff I've found doesn;t seem to mention v2 at all. Back in the dim and distant past I got round the ntlm v2 issue when using OSC Radiator by proxying off auths to Radiator running on a windows machine bound to AD and using their AuthBy LSA authentication mechanism.
When you say "windows machine", do you mean "ordinary domain member" as opposed to "domain controller"?
Yup. From the Radiator manual This module provides authentication against user passwords in any Windows Active Directory or NT Domain Controller, by using the Windows LSA (Local Security Authority). Since it accesses LSA directly, it can authenticate dialup or wireless pass- words with PAP, CHAP, MSCHAP, MSCHAPV2, LEAP and PEAP. AuthBy LSA is only available on Windows 2000, 2003, 2008 and XP. (Windows XP Home edition is not supported). It requires the Win32-Lsa perl module from Open Sys- tem Consultants. Install the Win32-Lsa perl module using PPM and ActivePerl 5.6, 5.8, 5,10 or 5.12 like this: ppm install http://www.open.com.au/radiator/free-downloads/Win32-Lsa.ppd To use AuthBy LSA, Radiator must be run on Windows as a user that has the ‘Act as part of the operating system’ security policy (SE_TCB_PRIVILEGE) enabled. This is not possible with Windows XP Home edition. Hint: Users can only be authenticated with AuthBy LSA if they have the ’Access this computer from the network’ security policy enabled (this is the normal configuration for Windows Domains). AuthBy LSA honours the Logon Hours, Workstation Restrictions and ‘Account is Disabled’ flags in user accounts. Hint: CHAP passwords can only be authenticated if the user has the ‘Store password using reversible encryption’ option enabled in their Windows Account. Hint: See goodies/lsa.cfg and goodies/lsa_eap_peap.cfg for examples on how to config- ure Radiator to authenticate PAP, CHAP, MSCHAP, MSCHAPV2, LEAP and PEAP against Windows user passwords. Hint: If you are running Radiator on unix or Linux, and wish to authenticate to Win- dows Active Directory or to a Windows Domain Controller, see “<AuthBy NTLM>” on page 223. I ran a 2 tier radius service. Tier1 ran radiator on linux with a back end mysql databases. All 802.1x and macauth stuff ran against mysql. Visiting eduroam users got proxied off to a part of "eduroam" front ends that proxied them off to remote home sites and processed inbound local user auths. When I started rolling out dot1x for our staff/student images I just added another proxy server with radiator that ran on a windows box and passed back an Access-Accept/Access-Reject response to the "tier 1" radius servers.
If so, this is interesting. It suggests that MSCHAP can still be checked with NTLMv2 enforced, just not via whatever API Samba/ntlm_auth uses.
You should ask on the Samba lists - if a windows domain member can do it, there must be a newer API/RPC which Samba could implement.
It is possible, though unlikely IMO, that one of the other ntlm_auth modes, such as
--helper-protocol=ntlm-server-1
...use different RPCs, and may work. If you can, try and get a valid challenge/response pair, and then drive ntlm_auth using the ntlm-server-1 protocol (see "man ntlm_auth"). If that works, it would be possible in theory to use a wrapper script. But IIRC, it's the same code path, so Samba fixes will be needed.
The other "option" (yuck) is to run NPS (or Radiator) on a Windows server, and proxy your MSCHAP to that. But if other RADIUS servers have the ability to work with NTLMv2 enforced, it would be nice to get it with FR too. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (4)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Alex Sharaz -
Phil Mayers