UserPrincipalName with ntlm_auth, trying to get it "right"
Dear List I have a setup where users should move to using their UserPrincipalName which conveniently matches their mail adddress. (something they tend to remember easily) Now ntlm_auth doesn't quite like UPNs, it wants a sAMAccountName, I found about that. If sAMAccountName was equal the first part of the UPN, i found the following in proxy.conf would give me the first part of the given UPN as Stripped-User-Name (since no nostrip option) and continue to process things locally. realm "thissuffix.tld" { authhost = LOCAL accthost = LOCAL } However in this directory the *prefix in the UPN doesn't match with the sAMAccountname* (for $anyreason). ntlm_auth obviously fails there. I came across a thread on UPN usage from early 2015 (and couple others), yet I couldn't come across something giving me a clearer idea.* My current impression is that at some point, if given a UPN, an LDAP search should be done first to return the samaccountname. Then use that with the ntlm_auth binary in modules/mschap to check credentials and do the MSCHAP challenge. Am I on the right track? - I saw something on stackoverflow using a bash script that is executed via mods-available/mschap**, but not sure about that yet if that's the right place. I'm thankful for any pointer into the right direction. Let alone that AD domain computers should be able to still authenticate with their own format that Windows clients use instead of the UPN when they are part of a domain... -- Mathieu * http://lists.freeradius.org/pipermail/freeradius-users/2015-January/075376.h... ** https://serverfault.com/questions/686470/active-directory-freeradius-ntlm-au...
On Jan 13, 2016, at 4:47 PM, Mathieu Simon (Lists) <matsimon.lists@simweb.ch> wrote:
I have a setup where users should move to using their UserPrincipalName which conveniently matches their mail adddress. (something they tend to remember easily)
That's always a good idea.
Now ntlm_auth doesn't quite like UPNs, it wants a sAMAccountName, I found about that.
It's more that AD wants it. ntlm_auth is just a shim which talks to AD.
If sAMAccountName was equal the first part of the UPN, i found the following in proxy.conf would give me the first part of the given UPN as Stripped-User-Name (since no nostrip option) and continue to process things locally.
Yes, that works.
However in this directory the *prefix in the UPN doesn't match with the sAMAccountname* (for $anyreason). ntlm_auth obviously fails there.
Yes. A potential solution is to use the UPN to look up the sAMAccountname, then pass the sAMAccountname to ntlm_auth. But that doesn't always work. If you're using MS-CHAP, or PEAP (which uses MS-CHAP), the UPN is part of the MSCHAP calculations. Which means sending the sAMAccountname instead *guarantees* that the MS-CHAP calculations will be based on the wrong thing... and will fail. Alan DeKok.
Hi Thank you Alan, that's quite good news. I was writing about what I got a bit further done while your message arrived. Am 14.01.2016 um 16:29 schrieb Alan DeKok:
However in this directory the *prefix in the UPN doesn't match with the sAMAccountname* (for $anyreason). ntlm_auth obviously fails there.
Yes.
A potential solution is to use the UPN to look up the sAMAccountname, then pass the sAMAccountname to ntlm_auth.
That's what I somewhat ended up, learning another thing or two about FreeRADIUS: rlm_ldap is really different with 3.0 than 2.2, basically ldap.attrmap seems gone and I was looking in the wrong place. Alan: However even the branch for 3.1 doc/modules/ldap_howto.rst mentions it - is that still valid? It seems getting the value from LDAP during a request is pretty easy after all, no need for extra scripts... hmm. dictionary, adding a custom attribute: ATTRIBUTE AD-Samaccountname 3003 string mods-available/ldap: update { control:AD-Samaccountname := 'sAMAccountName' [...] user { filter = "(userPrincipalName=%{mschap:User-Name})" This made FR look up sAMAccountName and populate the attribute as defined in dictionary. So far so good. mods-available/mschap: ntlm_auth = /usr/bin/ntlm_auth \ [...] --username=%{control:AD-Samaccountname} Then mschap used the obtained LDAP attribute instead of User-Name. That seemed to work after with eapol_test and some real devices.
But that doesn't always work. If you're using MS-CHAP, or PEAP (which uses MS-CHAP), the UPN is part of the MSCHAP calculations. Which means sending the sAMAccountname instead *guarantees* that the MS-CHAP calculations will be based on the wrong thing... and will fail. Sounds scary, I guess I'll have to double-check with a couple of devices and users. I don't want to spoil the success I just had :-\
"Thankfully" domain-joined Windows systems do their own thing, when logging in with their host credentials ("host\thishostname") and users wil just send the samaccountname Both "needs" both ways to be accepted. Would it be better to proxy all requests with a domain suffix to another (virtual) server and have rlm_mschap and rlm_ldap configured there differently for this purpose? -- Mathieu
On Jan 14, 2016, at 10:47 AM, Mathieu Simon (Lists) <matsimon.lists@simweb.ch> wrote:
That's what I somewhat ended up, learning another thing or two about FreeRADIUS: rlm_ldap is really different with 3.0 than 2.2, basically ldap.attrmap seems gone and I was looking in the wrong place.
Alan: However even the branch for 3.1 doc/modules/ldap_howto.rst mentions it - is that still valid?
No. I'll go fix that.
It seems getting the value from LDAP during a request is pretty easy after all, no need for extra scripts... hmm.
Yes. 3.0 / 3.1 are *much* simpler than version 2 for a lot of things.
Then mschap used the obtained LDAP attribute instead of User-Name. That seemed to work after with eapol_test and some real devices.
If it works, it works... but there's no *guarantee* it will always work.
Both "needs" both ways to be accepted. Would it be better to proxy all requests with a domain suffix to another (virtual) server and have rlm_mschap and rlm_ldap configured there differently for this purpose?
That should work. Alan DeKok.
Hi Am 14.01.2016 um 16:53 schrieb Alan DeKok: [...]
Alan: However even the branch for 3.1 doc/modules/ldap_howto.rst mentions it - is that still valid?
No. I'll go fix that. Thanks, I simply stumbled upon this when grepping through the source.
It seems getting the value from LDAP during a request is pretty easy after all, no need for extra scripts... hmm.
Yes. 3.0 / 3.1 are *much* simpler than version 2 for a lot of things. Definitely, I need to get those version 2 habits out of my brain...
Then mschap used the obtained LDAP attribute instead of User-Name. That seemed to work after with eapol_test and some real devices.
If it works, it works... but there's no *guarantee* it will always work.
I see eduroam folks use a username@homeorg.tld format which does look like a UPN (maybe on their backend it isnt). I'd also guess that some organizations have Active Directory as backend, and I see some also use PEAP-MSCHAPv2 ... thus there must be similarities to what I have here. If anyone on this is willing to share how they did it, that would be interesting to hear and how (well) it works for them. I hope I could then avoid stumbling into a potential pitfall with MSCHAP...
Both "needs" both ways to be accepted. Would it be better to proxy all requests with a domain suffix to another (virtual) server and have rlm_mschap and rlm_ldap configured there differently for this purpose?
That should work. Thanks for that indication Alan.
-- Mathieu
On Fri, Jan 15, 2016 at 09:44:15AM +0100, Mathieu Simon (Lists) wrote:
I see eduroam folks use a username@homeorg.tld format which does look like a UPN (maybe on their backend it isnt).
It's an NAI. There's a difference. See RFC 4282.
I'd also guess that some organizations have Active Directory as backend, and I see some also use PEAP-MSCHAPv2 ... thus there must be similarities to what I have here.
Yes. sAMAccountname@realm Though for completeness here our UPN is the same as sAMAccountName@realm (for one version of "realm" anyway).
If anyone on this is willing to share how they did it, that would be interesting to hear and how (well) it works for them. I hope I could then avoid stumbling into a potential pitfall with MSCHAP...
Used sAMAccountName. I'll spare the list the details of the arguments I've had with people here on on "it's their e-mail address", "no, it's username@realm". Aside from when we started to permit people to have their name as their e-mail address, and suddenly all the documentation had to be changed because e-mail address no longer worked for those that changed e-mail address. :-) But if you try it with UPN and it works reliably then it would be interesting to know. Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
Hi Matthew Thanks for sharing this! Am 15.01.2016 um 12:43 schrieb Matthew Newton:
On Fri, Jan 15, 2016 at 09:44:15AM +0100, Mathieu Simon (Lists) wrote:
I see eduroam folks use a username@homeorg.tld format which does look like a UPN (maybe on their backend it isnt).
It's an NAI. There's a difference. See RFC 4282. Aha, again, learned something (also the updated RFC 7542 Alan mentioned)
[...]
Yes. sAMAccountname@realm
Though for completeness here our UPN is the same as sAMAccountName@realm (for one version of "realm" anyway).
If anyone on this is willing to share how they did it, that would be interesting to hear and how (well) it works for them. I hope I could then avoid stumbling into a potential pitfall with MSCHAP...
Used sAMAccountName.
I guess that you strip @realm and ntlm_auth will use sAMAccountName for authentication with ntlm_auth (or libwbclient) with no negative effect on MSCHAP challenge?
I'll spare the list the details of the arguments I've had with people here on on "it's their e-mail address", "no, it's username@realm".
Now mix it with the situation that some (unnamed cloud) providers will tell in their login forms to enter user names as xyz@example.org actually validating the UPN... users often guess that anything name@domain.tld must be a mail address but isn't. [...]
But if you try it with UPN and it works reliably then it would be interesting to know.
I feel like I've just changed from being the one testing to being the guinea pig myself ... ;-) I still have a time frame to test things and see if this is reliable with a couple test users. I'll let you know once I think I have some amount of test results. -- Mathieu
Hi, As a quick follow-up on that topic referrring to Matthew Newton Am 15.01.2016 um 12:43 schrieb Matthew Newton:
But if you try it with UPN and it works reliably then it would be interesting to know.
To which I answered back then:
I feel like I've just changed from being the one testing to being the guinea pig myself ... ;-)
The guinea pig (me) thinks that after I got hands on a couple of different devices to test against that there is time for an update on the results: I've now tested with several different Windows-ish Notebooks/Tablets/Phones, MacBooks, iOS and Android versions and devices I could get my hands on. I've used different UPN names on them always with PEAP-MSCHAPv2 as outlined previously in this thread and none has yet failed. *touches wood* Actually the way Windows domain member devices send authentication requests under some configurations when enabling their "Single Sing On" option is giving me more issues now than the UPN based authentication on personal/BYOD devices. -- Mathieu
participants (3)
-
Alan DeKok -
Mathieu Simon (Lists) -
Matthew Newton