On 03/23/2011 08:30 PM, Michael Lecuyer wrote:

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.

On Thursday 24 March 2011 09:36:28 Phil Mayers wrote:

Please post a full debug. It's not possible to find the real cause of your problem from the snippet. (see attachment)

I am guessing that you're attempting to modify the username; you can't do that, EAP will complain (as you're seeing) Yes, I've tried to modify the username (using a policy which I've invoked as the first item of my authorize blocks in inner-tunnel and default) but since I realized that this doesn't help either I don't do so any more (removed the policy). 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!

On Friday 25 March 2011 11:15:58 you wrote:

Use %{mschap:User-Name} everywhere; this will give the bare username That sounds consequent but what exactly do you mean by "everywhere"? 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!

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. 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.edu@lists.freeradius.org [freeradius-users-bounces+robert.roll=utah.edu@lists.freeradius.org] On Behalf Of Nolan King [nking@mnwd.com] Sent: Friday, March 25, 2011 10:35 AM To: freeradius list Subject: Re: Strip off the domain part from the User-Name freeradius 2.1.8: 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.07053.thomas.wunder@swt-bamberg.de>, Thomas Wunder <thomas.wunder@swt-bamberg.de> wrote: On Friday 25 March 2011 11:15:58 you wrote: Use %{mschap:User-Name} everywhere; this will give the bare username That sounds consequent but what exactly do you mean by "everywhere"? 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!

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Uh.. if you don't read the documentation and don't understand what> 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.edu@lists.freeradius.org [freeradius-users-bounces+robert.roll=utah.edu@lists.freeradius.org] On Behalf Of Alan DeKok [aland@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:

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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

On Sat, Mar 26, 2011 at 5:00 AM, Fajar A. Nugraha <list@fajar.net> wrote:

On Sat, Mar 26, 2011 at 4:45 AM, Robert Roll <Robert.Roll@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}" =~ /^(.*)@(.*)/) {

                       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

On 03/25/2011 10:09 PM, Robert Roll wrote:

...

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.

Thank You ! This is very good information... 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.edu@lists.freeradius.org [freeradius-users-bounces+robert.roll=utah.edu@lists.freeradius.org] On Behalf Of Phil Mayers [p.mayers@imperial.ac.uk] Sent: Saturday, March 26, 2011 4:59 AM To: freeradius-users@lists.freeradius.org Subject: Re: Strip off the domain part from the User-Name On 03/25/2011 09:45 PM, Robert Roll wrote:

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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html