Strip off the domain part from the User-Name
Thomas Wunder
I'm currently trying to configure my Win7 clients to do wired 802.1X authentication using the credentials a user provides at the login screen. Wired 802.1X auth itself works fine but as soon as I have it use the logon credentials (using the "Automatically use my Windows logon name and password (and domain if any).") Windows sends User-Names like 'computername\\username'. That's normal so far I think.
To get the rlm_ldap related stuff working I simply changed my filter and groupmembership_filter settings in modules/ldap to be "[...]uid=%{mschap:User-Name:-%{User-Name}}[...]" instead of "[...]uid=%{%{Stripped-User-Name}:-%{User-Name}}[...]" and that works well.
But when it comes to MSCHAP authentication I've got a problem:
I get errors like
"[mschap] ERROR: User-Name (testpc\tom1) is not the same as MS-CHAP Name (tom1) from EAP-MSCHAPv2"
(...which sounds consequent) I've tried solve that problem by changing "with_ntdomain_hack = yes" (I know you recommend against that) without any luck:
+- entering group authenticate {...}
[eap] Identity does not match User-Name, setting from EAP Identity.
[eap] Failed in handler
++[eap] returns invalid
Failed to authenticate the user.
Login incorrect: [tom1] (from client swtswitch01 port 0 via TLS tunnel)
Somewhere I've read that in such a case one should use the realms concept but I can't seem to get it working. There's an entry like
realm ntdomain {
format = prefix
delimiter = "\\"
}
in the modules/realm but what else do I need?
Thanks!fr
Best regards
Tom
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Michael Lecuyer
Stripping the domain will therefore not work. The client is using the
domain\name in the hash and you're asking the server to use just the name.
Phil Mayers
> The MSCHAPs include the given name when calculating the hashes.
> Stripping the domain will therefore not work. The client is using the
> domain\name in the hash and you're asking the server to use just the name.
Actually that's not true; the mschap "response" field is calculated with
the bare username, excluding the domain. You *should* strip the domain
when you pass it into ntlm_auth; but not by modifying the original
username, as that makes EAP complain.
Phil Mayers
> But when it comes to MSCHAP authentication I've got a problem:
> I get errors like
> "[mschap] ERROR: User-Name (testpc\tom1) is not the same as MS-CHAP Name (tom1) from EAP-MSCHAPv2"
> (...which sounds consequent) I've tried solve that problem by changing "with_ntdomain_hack = yes" (I know you recommend against that) without any luck:
> +- entering group authenticate {...}
> [eap] Identity does not match User-Name, setting from EAP Identity.
> [eap] Failed in handler
> ++[eap] returns invalid
> Failed to authenticate the user.
> Login incorrect: [tom1] (from client swtswitch01 port 0 via TLS tunnel)
>
Please post a full debug. It's not possible to find the real cause of
your problem from the snippet.
I am guessing that you're attempting to modify the username; you can't
do that, EAP will complain (as you're seeing)
Thomas Wunder
> Please post a full debug. It's not possible to find the real cause of
> your problem from the snippet.
>
> I am guessing that you're attempting to modify the username; you can't
> do that, EAP will complain (as you're seeing)
By the way this was the policy which I have used:
strip_off_domain{
if( User-Name =~ /^(.*)\\(.*)/ ){
update request {
User-Name := "%{2}"
}
}
}
Apart from this, what can I do have rlm_mschap cope with the domain prefix?
Thanks in advance!
Phil Mayers
Use %{mschap:User-Name} everywhere; this will give the bare username
(and also correctly translate host/name.domain.com, if you later do
machine auth)
Thomas Wunder
> Use %{mschap:User-Name} everywhere; this will give the bare username
I use the policy.conf (as you can see by the debug output from my previous posting) to define some policies that are later on used within the 'authorize {...}' groups of sites-available/default and sites-available/inner-tunnel. I don't utilize rlm_files any more but I use rlm_ldap to retrieve user/group information from my LDAP-server. The only place where I consciously reference any User-Name attribute is the modules/ldap and there I already do as you suggest (see attachment).
Where else do I need to explicitly specify '%{mschap:User-Name}' to have rlm_mschap accept user names that incorporate a NT-domain name (i.e. to have rlm_mschap ignore the domain component of the user name)?
My modules/mschap config file is pretty lucid at present:
mschap {
use_mppe = yes
require_encryption = yes
require_strong = yes
with_ntdomain_hack = no
}
And what about the realms approach? Can I save the trouble?
> (and also correctly translate host/name.domain.com, if you later do
> machine auth)
Thanks!
Nolan King
My environment uses ntlm_auth and ldap modules.
in mschap module, i have a line like:
ntlm_auth = "/usr/bin/ntlm_auth --request-nt-key --username=%{%{Stripped-User-Name}:-%{User-Name:-None}} --challenge=%{mschap:Challenge:-00} --nt-re$
also, in ldap:
filter = "(&(sAMAccountName=%{Stripped-User-Name:-%{User-Name}}))"
no edits to default or inner-tunnel (other than to uncomment the ntlm_auth and mschap lines).
I use this method to auth users connecting to wireless APs with xp, ios, linux, and win7 machines. I want users to be forced to enter their password to connect, so the clients are configured not to use the domain\username, just username and pw. Set up this way, a client sending username in domain\username form will be rejected. I am not sure this is "right", but it allows me to use mschap auth with several different types of clients, and control access with an ldap group without worrying about the domain\user nonsense. Of course, i only have a single domain which simplifies things.
Nolan
>>> On 3/25/2011 at 7:41 AM, in message
<201103251541.070...@swt-bamberg.de>, Thomas Wunder
Robert Roll
I seemed to notice that the "Out of the Box Config" does not seem to actually create
a Stripped-Username and Realm. I did find that when I created a "real" realm in the proxy.conf
file, then a Stripped-Username and Realm were available. So, I thought that if I really wanted
ALL usernames "stripped" into their component parts, I would just change the example.com realm
in the proxy.conf file to be "DEFAULT" ? This then seemed to send the request into some sort of
endless loop ?
Thanks,
Robert
________________________________________
From: freeradius-users-bounces+robert.roll=utah...@lists.freeradius.org [freeradius-users-bounces+robert.roll=utah...@lists.freeradius.org] On Behalf Of Nolan King [nk...@mnwd.com]
Sent: Friday, March 25, 2011 10:35 AM
To: freeradius list
Subject: Re: Strip off the domain part from the User-Name
Alan DeKok
> We're currently running 2.1.10..
>
> I seemed to notice that the "Out of the Box Config" does not seem to actually create
> a Stripped-Username and Realm.
It creates those attributes if you define a realm. If you don't
define a realm, it doesn't know how to create a "Realm" attribute.
> I did find that when I created a "real" realm in the proxy.conf
> file, then a Stripped-Username and Realm were available.
Yes...
> So, I thought that if I really wanted
> ALL usernames "stripped" into their component parts, I would just change the example.com realm
> in the proxy.conf file to be "DEFAULT" ? This then seemed to send the request into some sort of
> endless loop ?
Uh.. if you don't read the documentation and don't understand what
you're doing, it probably won't do what you want.
Rather than randomly making changes, perhaps you could explain what
you're trying to do, and why.
Alan DeKok.
Robert Roll
> you're doing, it probably won't do what you want.
Sometimes true, sometimes not :)
> Rather than randomly making changes, perhaps you could explain what
> you're trying to do, and why.
Right now, I'm just experimenting and trying to learn how things work...
In any case, to give you an idea of one of the things I was thinking about...
One idea, is that we have a number of departments that want to be put into
a particular VLAN when they login. When a user normally logs in, they simply
use their username. This simply puts them in the general user VLAN. However,
if they login with username@department, and they are authorized, we will return
the particular radius attribute to put them into their specific department VLAN.
A normal authorize might look like:
ldapAuthUser
if( %Realm ) {
ldapAuthVLAN
}
If one is smart about naming the Group in ldap the same as the Realm,
then one can quite easily construct a search filter in the ldap module to
look at the appropriate group in ldap. That group would actually have the
particular radiusReplyItem to return the correct VLAN...
Note that in the above the Realm is quite useful, but there is NO need to
actually do proxy, so really no "REAL" need to get into the proxy.conf ?
Thanks,
Robert
________________________________________
From: freeradius-users-bounces+robert.roll=utah...@lists.freeradius.org [freeradius-users-bounces+robert.roll=utah...@lists.freeradius.org] On Behalf Of Alan DeKok [al...@deployingradius.com]
Sent: Friday, March 25, 2011 1:09 PM
To: FreeRadius users mailing list
Subject: Re: Strip off the domain part from the User-Name
Robert Roll wrote:
Fajar A. Nugraha
> A normal authorize might look like:
>
>
> ldapAuthUser
>
> if( %Realm ) {
> ldapAuthVLAN
> }
>
> If one is smart about naming the Group in ldap the same as the Realm,
> then one can quite easily construct a search filter in the ldap module to
> look at the appropriate group in ldap. That group would actually have the
> particular radiusReplyItem to return the correct VLAN...
>
> Note that in the above the Realm is quite useful, but there is NO need to
> actually do proxy, so really no "REAL" need to get into the proxy.conf ?
If you just want to split username@realm into username and realm, you
should be able to use this in authorize section
if ("%{request:User-Name}" =~ /^(.*)@/) {
update request {
Stripped-User-Name := "%{1}"
Realm := "%{2}"
}
}
As a side note, even if you only use freeradius locally (without any
external server to proxy to), using proxy can be useful if you have
multiple realms with different configurations. Using proxy you can
split the request into different virtual servers based on their realm.
--
Fajar
Fajar A. Nugraha
> On Sat, Mar 26, 2011 at 4:45 AM, Robert Roll <Rober...@utah.edu> wrote:
>> A normal authorize might look like:
>>
>>
>> ldapAuthUser
>>
>> if( %Realm ) {
>> ldapAuthVLAN
>> }
>>
>> If one is smart about naming the Group in ldap the same as the Realm,
>> then one can quite easily construct a search filter in the ldap module to
>> look at the appropriate group in ldap. That group would actually have the
>> particular radiusReplyItem to return the correct VLAN...
>>
>> Note that in the above the Realm is quite useful, but there is NO need to
>> actually do proxy, so really no "REAL" need to get into the proxy.conf ?
>
> If you just want to split username@realm into username and realm, you
> should be able to use this in authorize section
>
> if ("%{request:User-Name}" =~ /^(.*)@/) {
Sorry, that should be
if ("%{request:User-Name}" =~ /^(.*)@(.*)/) {
Robert Roll
>should be able to use this in authorize section
>
> if ("%{request:User-Name}" =~ /^(.*)@/) {
> Stripped-User-Name := "%{1}"
> Realm := "%{2}"
> }
> }
>
Yes, thanks, and we may end up doing exactly that. However, I just
point out that freeradius OBVIOUSLY already has the capability to do
exactly this, so why re-invent the wheel ?
>As a side note, even if you only use freeradius locally (without any
>external server to proxy to), using proxy can be useful if you have
>multiple realms with different configurations. Using proxy you can
>split the request into different virtual servers based on their realm.
>--
>Fajar
Yes, I do agree... As I said earlier, some of what I am doing is just to
try and experiment and see what is possible. I'm actually quite impressed
with Freeradius and right now, we are still a ways from what I would consider
any kind of final configuration...
Thanks,
Robert
________________________________________
From: freeradius-users-bounces+robert.roll=utah...@lists.freeradius.org [freeradius-users-bounces+robert.roll=utah...@lists.freeradius.org] On Behalf Of Fajar A. Nugraha [li...@fajar.net]
Sent: Friday, March 25, 2011 4:00 PM
To: FreeRadius users mailing list
Subject: Re: Strip off the domain part from the User-Name
On Sat, Mar 26, 2011 at 4:45 AM, Robert Roll <Rober...@utah.edu> wrote:
> A normal authorize might look like:
>
>
> ldapAuthUser
>
> if( %Realm ) {
> ldapAuthVLAN
> }
>
> If one is smart about naming the Group in ldap the same as the Realm,
> then one can quite easily construct a search filter in the ldap module to
> look at the appropriate group in ldap. That group would actually have the
> particular radiusReplyItem to return the correct VLAN...
>
> Note that in the above the Realm is quite useful, but there is NO need to
> actually do proxy, so really no "REAL" need to get into the proxy.conf ?
If you just want to split username@realm into username and realm, you
should be able to use this in authorize section
if ("%{request:User-Name}" =~ /^(.*)@/) {
Phil Mayers
>> If you just want to split username@realm into username and realm, you
>> should be able to use this in authorize section
>>
>> if ("%{request:User-Name}" =~ /^(.*)@/) {
>> update request {
>> Stripped-User-Name := "%{1}"
>> Realm := "%{2}"
>> }
>> }
>>
>
> Yes, thanks, and we may end up doing exactly that. However, I just
> point out that freeradius OBVIOUSLY already has the capability to do
> exactly this, so why re-invent the wheel ?
In fact, if you're just using variations of the username to signal
different intent (an interesting idea in the context of vlan
assignment), then you're actually doing something similar to old-style
"hints" - the "hints" file that comes with the server has examples.
You can certainly use the "realm" module for this, and we used to do
just that - but I've recently been convinced of the superiority of
unlang, because you have a lot more control over the behaviour
If you're bothered by unlang making your radius policy too unwieldy, you
can make use of "policy.conf" to write a virtual "module" e.g.:
policy.conf:
policy {
optional_realm {
if (User-Name =~ /(.+)@(.+)/) {
update request {
Stripped-User-Name := "%{1}"
Realm = "%{toupper:%{2}}"
}
updated
}
else {
notfound
}
}
}
sites-enabled/XXX:
authorize {
optional_realm
if (updated) {
update reply {
Vlan := "%{ldap:... %{Realm} ...}"
}
}
}
>
>> As a side note, even if you only use freeradius locally (without any
>> external server to proxy to), using proxy can be useful if you have
>> multiple realms with different configurations. Using proxy you can
>> split the request into different virtual servers based on their realm.
>> --
>> Fajar
>
> Yes, I do agree... As I said earlier, some of what I am doing is just to
> try and experiment and see what is possible. I'm actually quite impressed
> with Freeradius and right now, we are still a ways from what I would consider
> any kind of final configuration...
In which case it's definitely worth trying the unlang approach, just to
get familiar with the differences.
You can also of course do actual proxying, either to remote servers or
other local virtual servers; just update the stuff above to also do:
update control {
Proxy-To-Realm := "..."
}
This is an area where unlang is superior - you might want the "realm"
and "proxy-to-realm" to be completely different and related in ways
non-obvious, and impossible to express in proxy.conf (e.g. via an SQL
lookup)
[1] Different for regexp realms, of course.
Phil Mayers
>
> Note that in the above the Realm is quite useful, but there is NO need to
> actually do proxy, so really no "REAL" need to get into the proxy.conf ?
This is a good reason to use unlang rather than realm. "realm" is
designed for proxying, always gets it list of realms from "proxy.conf"
and sets the control:Proxy-To-Realm attribute.
You also may not realise that user@undefined realm will set:
Stripped-User-Name = use
Realm = DEFAULT
i.e. the Realm value does *not* preserve the text after the @.
Your original problem (crazy loop) occurred because the DEFAULT realm
you defined in proxy.conf was pointing somewhere else - probably back at
the very same radius server, resulting in an infinite loop.
HTH
Robert Roll
I did NOT realize that user@undefinedRealm would NOT
preserve Realm..... That does make a hugh difference...
I did read your other post, and am really NOT adverse to making use of
unlang. I did start to read a little about policy.conf and like the idea of
sort of "subroutines" defined there...
Thanks Much,
Robert
________________________________________
From: freeradius-users-bounces+robert.roll=utah...@lists.freeradius.org [freeradius-users-bounces+robert.roll=utah...@lists.freeradius.org] On Behalf Of Phil Mayers [p.ma...@imperial.ac.uk]
Sent: Saturday, March 26, 2011 4:59 AM
To: freeradi...@lists.freeradius.org
Subject: Re: Strip off the domain part from the User-Name
On 03/25/2011 09:45 PM, Robert Roll wrote: